Pattern Libraries im Zentrum von Entwicklung und Design

Ich diskutiere in diesem einenhalbstündigen Vortrag die Vorteile und Herausforderungen, die mit einer Einbindung einer Pattern Library in den Entwicklungsprozess einer Webseite kommen. Tools werden vorgestellt, aber der Fokus liegt auf der Kommunikation im Team.

Transcript

1. Pattern Libraries im Zentrum von Entwicklung und Design Jens Grochtdreis
2. Eine Website besteht aus vielen Einzelteilen, die oft beliebig miteinander kombiniert werden können.
4. Pattern Libraries helfen bei der Kommunikation und bringen Übersicht!
5. Patterns Design Konzept Entwicklung Fachseite Redaktion Teil der Kommunikation
6. Eine Pattern Library kann Teil eines umfassenderen Design Systems sein.
7. ‣ Farben ‣ Schriften ‣ Voice and Tone ‣ Patterns ‣ Coding Guidelines ‣ Animations-Richtlinien Design System?
8. Namenskonventionen werden etabliert!
9. ‣ Collapse ‣ Klappmodul ‣ Toggle ‣ Aufklapper ‣ FAQ ‣ … Wie heißt das Ding?
10. Farbnamen https://atlassian.design/guidelines/brand/color
11. Photoshop und andere Bildbearbeitungsprogramme skizzieren nur Ideen!
12. Die Wahrheit liegt in den Browsern.
13. Deshalb die Ideen möglichst schnell in HTML und CSS wandeln.
14. Aber zurück zu Pattern Libraries
15. Eine Pattern Library ist aktuell eine technische Sackgasse.
16. Wer hat den Lead und pflegt die Pattern Library ?
17. Gleiches gilt für Design Systeme
18. Eine Pattern Library ist ein Tool, nicht notwendigerweise ein eigenes Produkt.
19. Eine Pattern Library kann für sich selbst stehen, kann aber auch Teil des genutzten CMS sein.
20. Die Pattern Library sollte immer auf dem aktuellen Stand sein und „die letztgültige Wahrheit“ repräsentieren.
21. Die Pattern Library soll helfen. Dafür muss sie konfiguriert werden.
22. Reine Pattern Ablage oder Living Styleguide?
23. Es gibt viele unterschiedliche Arten von Pattern Libraries (Styleguides)
24. http://styleguides.io/
25. Die alte Garde
26. http://warpspire.com/kss/
28. Maintainer gesucht https://styleguide.sc5.io/
30. http://trulia.github.io/hologram/
33. Patternlab
34. https://patternlab.io/
42. Selbstgemacht
43. https://github.com/jensgro/Initialize
45. Fractal
46. https://fractal.build/
47. https://components.designsystem.digital.gov/components/detail/graphic-list.html
48. https://styleguide.liip.ch/components/detail/expertises-tiles.html
49. https://style.eurostar.com/components/detail/basket-total.html
50. https://stijlgids.stad.gent/components/detail/button-drop.html
51. https://github.com/tollwerk/fractal-typo3
52. https://tollwerk.de/blog/show/Post/fischer-automobile-barrierefreies-typo3-mit-living-styleguide/
53. Malvid
54. https://malvid.io/
57. Neues Modul erstellen ‣ Einfach einen neuen Ordner in das Arbeitsverzeichnis kopieren.
58. Mein Testprojekt
59. UI Engine
60. Quickstart https://github.com/dennisreimann/uiengine
62. Die sichtbare Struktur wird konfiguriert!
63. uiengine.config.js
64. ‣ Die Konfiguration von UI Engine ist bequem und sehr flexibel. ‣ Es ist möglich, in der Navigation Unterordner zu erzeugen und die Module so zu strukturieren. Das hat nichts mit der Dateistruktur zu tun. ‣ Das Handling externer Dateien oder das Building von Sass- und JS-Dateien wird von UI-Engine nicht übernommen. Dafür muss man selber sorgen, bspw. per Grunt oder Gulp. ‣ UI-Engine will also eher ein Dokutool sein, weniger ein Tool, in dem gearbeitet wird.
65. Ausgebautes Beispiel https://uiengine-sample-react.uix.space/design-system/ https://github.com/dennisreimann/uiengine-sample-react
66. Neues Modul erstellen https://github.com/jensgro/uiengine-test
67. Die Einzeldateien und Varianten in Unterordern müssen selber erstellt werden. Eine README.md ist vorgeschlagen.
68. Die Konfigurationsdatei ist leider nicht vorausgefüllt. Ihr Inhalt muss aus der Doku oder einem Beispiel kopiert werden.
69. Mein Testprojekt
70. Storybook
71. https://storybook.js.org/
72. Vorteile
73. Aktuelle Übersicht über alle Module kann unnötige Designtätigkeit verhindern.
74. ALLE Projektbeteiligten bekommen einen Überblick über die Formen der Inhaltspräsentation.
75. Alle Module können immer aktuell sein, wenn sie mit dem CMS gekoppelt sind.
76. Die Pflege ist einfacher als beim traditionellen PDF-Styleguide.
77. Nachteile
78. Es gibt bislang keine Plattform, die eine einfache Zusammenarbeit zwischen Designern und Entwicklern problemfrei gestaltet.
79. Keine einfache PDF-Produktion für die Leitungsebene.
80. Einrichtungsaufwand ist größer als beim traditionellen PDF-Styleguide.
81. Jede bisherige Form eines Styleguides oder Pattern-Library ist auf ein bestimmtes Gewerk fokussiert.
82. Einige wichtige Grundbestandteile
83. ‣ Buttons für unterschiedliche Mediaqueries. ‣ Diese sollten leicht editierbar sein. Skalierungshilfen
84. Modul in extra Fenster öffnen Isoliert auf einer Seite sind Tests mit dem Browser und dessen Entwicklertools einfacher, als innerhalb der Pattern Library.
85. ‣ Möglichst ein einblendbares Menü für alle Module ‣ Strukturierung nach Kategorien ‣ Schneller Wechsel ohne Umweg über eine Startseite ‣ Interne Benamung und Namensvergabe in der Pattern Library müssen nicht identisch sein (.o-mein-tolles-modul), denn die Library richtet sich nicht nur an Entwickler Einfacher Zugriff auf die Module
86. Einfacher Zugriff auf die Module
87. ‣ Nicht jede Applikation ermöglicht eine einfache individuelle Anpassung der Sortierung. ‣ Gerne wird die Atomic Design-Methodologie genommen. ‣ Die Sortierung muss für das Projekt passen und für die Projektbeteiligten einfach verständlich sein. Sortierung der Module
88. Wenn das Projekt nicht allzu komplex ist, kann man auch auf eine Sortierung verzichten.
89. ‣ Beispielcode sollte direkt kopierbar sein. ‣ Gerne als HTML und als Template bzw. JS-Komponente Codedarstellung
90. ‣ Welche Optionen hat das Modul? Was ist einstellbar? ‣ Was tut es und wo? ‣ Existieren Abhängigkeiten? ‣ Hinweise für Nicht-Entwickler nicht vergessen! Dokumentation
91. http://fractal.clearleft.com/components/detail/banner--notice.html
92. https://kanbasu.liip.ch/2/components/detail/table-responsive.html
94. Herausforderung
95. Akzeptanz bei der Einführung schaffen
96. Lohnt sich ein eigenes Team für das Design System/ die Pattern Library?
97. Kann die Pattern Library als globales Tool für mehrere Projekte fungieren?
98. Verknüpfung zwischen Pattern Library und (mehreren) CMS
99. Angst, Pattern könnten die Kreativität einschränken?!
100. Erst in die Pattern Library schauen, dann konzipieren, dann designen.
101. Wie flexibel können/müssen Patterns sein?
102. Workflow zum Informationsaustausch etablieren. Wer kann welche Informationen wie zugänglich machen? Wie werden neue Inhalte beworben?
103. Wie geht man mit verschiedenen Versionen eines Patterns um? Weiterentwicklung des Patterns bei gleichzeitiger Einfrierung des Entwicklungsstandes in Produktion
104. Wir konzentrieren uns auf einzelne Module und vergessen das Zusammenspiel der Module auf einer Seite.
105. Immer mal wieder Beispielseiten mit den isolierten Modulen erstellen.
106. Wünschenswert wäre eine einfache Möglichkeit, aus einer Pattern Library Einzelteile zu einer Seite zu kombinieren.
107. Jens Grochtdreis http://grochtdreis.de http://twitter.com/Flocke https://github.com/jensgro http://webkrauts.de https://speakerdeck.com/flocke