UX Audit

Wir trainieren dein Team? Buch unsere Workshops, Trainings und Coachings.

Zeigt her!
Close

Storybook, die bessere Kitchensink?

Unsere Erfahrungen mit Storybook und was wir davon halten.

Bild
Headerbild zu Blogartikel Storybook

Die Idee hinter Storybook ist, das Entwickeln von Komponenten zu vereinfachen und übersichtlicher zu gestalten und das ganze isoliert von jeglicher Business Logic. 

Storybook ist ein Open Source Tool, welches in ein Projekt integriert wird und so koexistiert. 

Storybook existiert schon seit mehreren Jahren und wird laufend weiterentwickelt. Die aktuell (stable) Version liegt derzeit bei 6, wobei sich Version 7 schon in der Pre-Release Phase befindet und voraussichtlich in den nächsten Wochen bis Monaten (als stable Version) verfügbar sein wird. Es gibt die Dokumentation sowohl für pures JavaScript, als auch für die gängigsten JavaScript Frameworks, wie zum Beispiel Angular, Vue oder React.

Für jede Komponente, die ein Teil von Storybook sein soll, legen wir eine “.stories”-Datei an. In dieser definieren wir dann Stories mit Mock-Daten, die wir gern testen möchten. In den “.stories”-Dateien wird definiert, wie die Komponente heißt, die in Storybook hinzugefügt werden soll, welche Werte zum Testen zur Verfügung stehen sollen und wie Kombinationen aus Komponenten (auch das ist möglich) miteinander zusammenspielen sollen.

Konkret sieht das dann in unserem Fall so aus:

Bild
5CFTRPWf9QVMssqaBRuUx4_pinNd8z8r2duJhkdq_urZ4yQJ4iFnwLxrhUtGrTQwULMKYTBdXG4QNcOkQmQUzLf64NWDnhAkJi8rSvNN4kp1UbD1pqAMDurax_N4fjCCGdHHhrxnjZNql8FqJOPPkvw
Storybook in einem Angular-Projekt

Die Beschreibungen, Namen und Standardwerte der Inputs holt sich Storybook ganz magisch 😉 selbst aus dem Code. Et voilà, die Komponente kann in Storybook getestet werden. Werte können direkt im Browser geändert werden und deren Verhalten und Aussehen getestet werden.

Im Browser schaut das ganze dann so aus:

Bild
YEFip-9lSc5DBcfiTvEeBc5lDmqrkyBdkft-5dZb3j8iEFD62iuKoHJl_xqoHuS8rMHn_zTQiA88CITZ-Zg41ADgb73zGghsSDkWN3aR7p7_fHOp2zyvxM5xYz_zHgXac8MaMjLmhincjMDCZgy1MYc
Storybook im Browser – man kann hier beispielsweise die verschiedenen Buttontypen (primary, secondary) auswählen und der Button spiegelt das direkt wider.

Unsere Erfahrungen

Es sind die verschiedensten Frameworks gut verständlich dokumentiert,  dadurch ist Storybook schnell aufgesetzt und es kann ohne viel Aufwand gleich damit gestartet werden.

Durch den Einsatz von Storybook nehmen wir uns automatisch mehr Zeit, Komponenten und deren Features genau durchzudenken. Komponenten werden zunächst am Reißbrett gedacht, ohne sich zu sehr mit den speziellen Anforderungen für die App aufzuhalten. Das hat uns automatisch dazu gebracht, die Komponenten granularer zu denken und so aufs Wesentliche zu reduzieren und mehr auf Wiederverwendbarkeit zu achten. Im zweiten Schritt kann dann noch genauer überlegt werden, wie die Komponenten für die spezielleren Einsatzzwecke erweitert werden müssen oder ob dafür weitere Komponenten nötig sind.

Uns passiert es oft, dass im Laufe eines Projekts das Kommentieren des Codes vernachlässigt wird und wir uns dann Monate später beim Weiterentwickeln ärgern, dass Kommentare fehlen. Da Storybook Kommentare von Datenfeldern erkennt und als Beschreibung darstellt, laufen wir weniger Gefahr, das Kommentieren zu vernachlässigen. 

Wenn wir an die Weiterentwicklung von Projekten denken, dann sehen wir den größten Vorteil von Storybook darin, Anpassungen und deren Auswirkungen von Komponenten effizienter testen zu können. Denn durch die verschiedenen Stories, die im Vorfeld angelegt wurden, kann so jeder Use Case durchgetestet werden. Vor allem auch Use Cases, die nicht oft vorkommen und daher leicht übersehen werden können. 

Zum Beispiel soll eine Komponente, die mehrere Status hat, die die Darstellung jener Komponente beeinflussen, weiterentwickelt werden. Angenommen, es kommt ein neuer Status dazu, durch den Änderungen am Layout notwendig sind. Durch die schon vorher definierten Use Cases (bzw. Storys), kann jetzt Story für Story kontrolliert werden, ob und welche Auswirkungen die Änderungen auf die Komponente haben.

Zusammenarbeit mit Design

Bevor wir Entwickler:innen mit dem Programmieren loslegen, bekommen wir von unseren Designer:innen einen Style Guide. Dieser definiert unter anderem das zu verwendende Farbschema, Typographie und Spacing-System. Das sieht dann zum Beispiel so aus:

Bild
143GKOwYQ2cYF5Qh-GeB2yMRA7JIvcCnnkV9mj0Uu0w6ccGsNwR9iDguTaputmxexk-lspdbAPyUCXbGXiDoYpP-EylicHbRMzpwgjAkFiwnRq5kV5pi9b_vl90AtBGK7cf9L_OlOQpfWUeweGrMWTA
Bild
OEkwn8kZOGxK7DQzSLfqFuX_cBPxwtPSxf6cjlxcGBsRVqg2OuoMuptgEciXnQC_SKrSy3LKUIHAg66Ca0ZMleTE4LdW3GpKNQUfGiFIx_I4996sjO7YkuH1wsvmXkIX2XpI45_V4DuLcSbN1wAISUk

Aber nicht nur das, im Style Guide sind ebenfalls alle Komponenten und deren Zustände  genauestens beschrieben. Hier ein kleiner Auszug wie so etwas aussieht:

Genau da kommt Storybook zum Einsatz. Mithilfe von Storybook entwickeln wir die Komponenten genau nach Vorgabe des Style Guides. Zusätzlich gibt es laufende Abstimmungen mit unseren Designer:innen während der gesamten Entwicklungszeit, um sicherzugehen, dass die Komponenten genauso aussehen und genauso funktionieren, wie von unseren Designer:innen konzipiert. Diese Kombination aus Dokumentation und Abstimmungen zwischen den Abteilungen hilft uns enorm bei der Qualitätssicherung.

Fazit 

Für mich hat Storybook nur Vorteile. Es verbessert die technische Dokumentation, hilft bei der Weiterentwicklung von Projekten (oder Teilen davon), hilft bei der Abstimmung mit anderen Teilen des Teams oder das Übergeben des Projekts an Kolleg:innen, hilft langfristig die technical debt zu reduzieren, hilft bei der Qualitätssicherung und beim Testen, … . Wie man sieht, könnte ich noch ewig so weitermachen ;).

Deshalb ist für mich Storybook die bessere Kitchensink.

Hast du schon mit Storybook gearbeitet? Welche Erfahrungen hast du mit Storybook gemacht?

Du willst mit jemanden über das Thema plaudern?

Einen kostenlosen Termin mit CEO Susanne vereinbaren!

Nicole Pepelko

Meine Rolle bei Liechtenecker: Female Dev Power Wenn es weder IT noch Digitalisierung gäbe, wäre mein Beruf: Ärztin Mein Herz schlägt für: Sojageschnetzeltes
Bild
Header-Bild: Barrierefreiheit im Fokus
UX/UI Design – Blogbeitrag

Barrierefreiheit im Fokus

Spätestens seit dem neuen Barrierefreiheitsgesetzt kommt man um das Thema Accessibility nicht mehr herum. Und das ist auch gut so. Von der Berücksichtigung verschiedenster Bedürfnisse bis hin zur Umsetzung von WCAG-Richtlinien – lasst uns gemeinsam entdecken, warum eine inklusive Online-Erfahrung für alle unverzichtbar ist.

Jetzt lesen

Interesse mit uns zu arbeiten?

Lass uns plaudern …

oder vereinbare gleich mit unserer CEO Susanne einen kostenlosen Termin.