Pattern Libraries im Zentrum von Entwicklung und Design

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.

521db10df5241d9b2b70a555cc54e9e8?s=128

Jens Grochtdreis

June 04, 2019
Tweet

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.
  3. None
  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/

  27. None
  28. Maintainer gesucht https://styleguide.sc5.io/

  29. None
  30. http://trulia.github.io/hologram/

  31. None
  32. None
  33. Patternlab

  34. https://patternlab.io/

  35. None
  36. None
  37. None
  38. None
  39. None
  40. None
  41. None
  42. Selbstgemacht

  43. https://github.com/jensgro/Initialize

  44. None
  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/

  55. None
  56. None
  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

  61. None
  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

  93. None
  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