Wie passt das "Design" in ein agiles Webprojekt?

1. Modulares Design
Wie passt das Design in ein
agiles Webprojekt?

2. Wer bin ich?
● Wer bin ich?
● Wer seid Ihr?
● Design in einem Webprojekt
● Modulares Design
● Alternative
● Tools und Werkzeuge
Inhalt
Herzlich willkommen zu meinem Vortrag “Modulares Design”, wie passt das “Design” in ein agiles Webprojekt. Falls Sie Fragen haben oder etwas unklar ist, bitte unterbrechen Sie mich. Zu Beginn möchte ich
mich kurz vorstellen.

3. HALLO!
Ich bin Dirk Benkert,
ein freiberuflicher Softwareentwickler
spezialisiert auf Webanwendungen und -
seiten.
https://www.dirk-benkert.de
mail@dirk-benkert.de
Wer bin ich?
http://de.slideshare.net/dirkbenkert/modulares-design
web:
email:
slides:

4. Historie
▸ Seit über 15 Jahren Webentwickler
▸ Viele Web-Projekte in allen Größen
▸ Autor für das PHP Magazin
▸ ISAQB Certified Software Architect
Wer bin ich?
Als Webentwickler gehören für mich Frontend,
Backend und Infrastruktur zusammen!
Ich arbeite seit über 15 Jahren als Webentwickler und habe in diesem Zeitraum viel Projekte in allen Größenordnungen und in verschiedenen Rollen miterlebt, bzw. durchgeführt. In der Vergangenheit habe ich
Artikel für das PHP Magazin geschrieben, der letzte liegt aber auch schon ein paar Jahre zurück und ich bin ISAQB zertifizierter Software-Architekt. Ich arbeite dabei mit PHP, als serverseitiger
Programmiersprache und natürlich HTML, CSS und Javascript auf der Clientseite. Ich versuche mich in Webprojekten aber nicht nur auf die Programmierung zu konzentrieren, sondern möglichst viele
Bereiche abzudecken. Daher bin ich auch im Umgang Webserver und Datenbank vertraut, bzw. kann auch eher Marketing getriebenen Themen wie z.B. Suchmaschinenoptimierung abdecken. Ich komme
aber aus der Software-Entwicklung und bin kein Designer.

5. Wer seid Ihr?
● Wer bin ich?
● Wer seid Ihr?
● Design in einem Webprojekt
● Modulares Design
● Alternative
● Tools und Werkzeuge
Inhalt
Jetzt würde ich gerne etwas über Sie erfahren. Dazu würde ich Ihnen ein paar Fragen stellen und um entsprechende Handzeichen bitten.

6. Umfrage
Wer von Ihnen versteht sich als Designer?
Wer von Ihnen versteht sich als Programmierer?
Wer seid Ihr?
Mehrfachmeldungen sind durchaus erlaubt, Sie müssen sich hier nicht entscheiden.

7. Umfrage
In welcher Form liefern Sie einen Design Entwurf ab?
Photoshop / HTML Prototyp
An wen wird der Design Entwurf geliefert?
Nicht-Entwickler / Entwickler
Wer seid Ihr?

8. Umfrage
Wer von Ihnen verwendet ein Grid-System?
Bootstrap / 960grid
Wer von Ihnen benutzt einen Javascript Module Loader?
require.js / browserify / webpack
Wer von Ihnen benutzt einen CSS Preprocessor?
SASS / LESS
Wer von Ihnen benutzt einen Task Runner?
gulp / grunt
Wer seid Ihr?
Und für wen von ihnen sind das böhmische Dörfer? Wer hat davon noch nie etwas gehört?

9. Design in einem
Webprojekt
● Wer bin ich?
● Wer seid Ihr?
● Design in einem
Webprojekt
● Modulares Design
● Alternative
● Tools und Werkzeuge
Inhalt
Kommen wir zur Rolle des “Designs” in einem Webprojekt, bzw. wie laufen Webprojekte klassischerweise ab.

10. Projektbeteiligte
Kunde
Designer
Entwickler Frontend
Entwickler Backend
Design in
einem
Webprojekt
Das Projekt beginnt immer beim Kunden. Dieser hat einen Wunsch, er möchte einen neuen Shop, eine neue Webseite, Blog, was auch immer. Damit geht er dann zu einem Designer und beauftragt diesen:
“Mach da mal einen Entwurf dazu!”. Dieser Entwurf wird dann von einem Frontend Entwickler umgesetzt, bevor dieser Prototyp (oder Click-Dummy) dann von einem Backend Entwickler zerlegt und in die
Templates des CMS, oder Shop-Systems gegossen wird.

11. Design in
einem
Webprojekt
KundeDesignFrontendBackend
Anforderungen
Design
Frontend
Backend
Abnahme
des Kunden
Abnahme
des Kunden
Abnahme
des Kunden
Zeitlich betrachtet finden diese Schritte in der Regel nacheinander statt und erst wenn eine Projektphase vom Kunden abgenommen ist, wird mit der nächsten Phase begonnen. Das ist natürlich eine sehr
abstrakte und einfache Betrachtung. Es zeigt aber relativ deutlich woran viele Webprojekte kranken. Was passiert denn, wenn der Backend Entwickler eine Frage hat, weil der Kunde vergessen hat eine
Anforderung zu beschreiben? Dann gibt es dafür kein Design, kein Frontend und man muss das Thema nochmal neu von Beginn an aufrollen.

12. Klassisches Vorgehen
▸ Wasserfall
Modell
▸ Lastenheft und
Pflichtenheft
▸ Erstellung von
Photoshop
Entwürfen der
Webseite(n)
Vorteile:
▸ Bekannte
Methodik
▸ Time und
Budget klar
definiert
Nachteile:
▸ über 60% der IT Projekte
sind nicht erfolgreich
(Chaos-Studie*)
▸ Kosten für Änderungen
steigen
*https://de.wikipedia.org/wiki/Chaos-Studie
Design in
einem
Webprojekt
Die Vorgehensweise, nennt man auf Projektmanagement Ebene “Wasserfall Modell”, Dazu gehört die Erstellung von Lasten- und Pflichtenheft. Und dazu passt auch sehr gut die Erstellung von Photoshop
Entwürfen. Die Methodik hat durchaus auch Vorteile. Zum Einen ist es in Industrie und Fertigung als Standard etabliert zum Anderen sind Projektlaufzeit (Time) und -kosten (Budget) klar definiert. Wenn man
jedoch IT Projekte betrachtet, dann sieht die Sache nicht sehr gut aus. Die Chaos-Studie nennt immer noch über 60% der IT Projekte als “nicht erfolgreich”. Die Ursache liegt häufig darin, dass in dem
Moment, wo sich Änderungen ergeben, Zeitplanung und Kosten aus dem Ruder laufen.

13. Mögliche Ursachen
▸ Internet ist hoch
dynamisch.
▸ Projektlaufzeiten für
Webprojekte auch
größer als 6 Monate.
▸ Webprojekt nicht mit
dem Go-Live
abgeschlossen.
▸ Anforderungen zu
Beginn nicht
vollständig
beschreibbar.
▸ Änderung der
Anforderungen ist
Realität.
Design in
einem
Webprojekt
Die Grafik zeigt dass die Kosten deutlich steigen, je später im Projekt eine Änderung vorgenommen wird. In Webprojekten im speziellen tritt diese Problematik meiner Meinung nach verstärkt auf. Das Internet
entwickelt sich rasend schnell, gleichzeitig haben Webprojekte aber auch lange Laufzeiten. Dass es hier Änderungen geben wird, ist schon zu Beginn des Projektes klar. Häufig können zu Beginn nicht mal die
Anforderungen vollständig beschrieben werden. Darüber hinaus ist ein Webprojekt eigentlich mit dem Go-Live nicht abgeschloßen, im Gegenteil: Änderungen und Weiterentwicklung beginnen gerade dann
erst. Was tut man also um dieser Problematik aus dem Weg zu gehen und eine reibungslose Projektabwicklung zu ermöglichen?

14. Lösungsansätze
▸ Agiles Projektmanagement (Scrum / Kanban)
▸ Agile Software Entwicklung (Testdriven
Development, Extreme Programming)
Design in
einem
Webprojekt
Welche Lösungsansätze gibt es für das Design?
Im Projektmanagement und in der Software Entwicklung sind die Schlagworte “Agiles Projektmanagement”, bzw. “Agile Software Entwicklung”. Das Ziel dieser Methoden ist es, Änderungen jederzeit zu
ermöglichen und auch ohne vollständige Anforderungen starten zu können. Doch wie integriert man das Design in einem agilen Webprojekt?

15. Modulares Design
● Wer bin ich?
● Wer seid Ihr?
● Design in einem Webprojekt
● Modulares Design
● Alternative
● Tools und Werkzeuge
Inhalt
Dazu möchte ich aus einem Projekt berichten, welches ich in den letzten drei Jahren begleitet habe.

16. Projekt
▸ Ein Shopsystem
▸ 3 verschiedene Marken
▸ 3 verschiedene Designs
▸ 3 verschiedene Design-Agenturen
▸ Projektlaufzeit bis Go-Live der 3. Marke, ca. 3 Jahre
Modulares
Design
Requirement Engineering Implementierung
Go-Live
1. Marke
Betrieb
Go-Live
2. Marke
Go-Live
3. Marke
Plan Build Run
Design
1. Marke
Design
2. Marke
Design
3. Marke
2013 2014 2015
Dabei ging es um ein Online-Shop-System auf Magento Basis. Mit 3 verschiedenen Marken, 3 verschiedenen Designs und 3 verschiedenen Design Agenturen. Pro Marke jeweils 3-4 unterschiedliche Shops in
verschiedenen Sprachen für Deutschland, Österreich, Schweiz, Niederlande. Den Ablauf des Projektes kann man grob so skizzieren: Ein Jahr Anforderungsanalyse und Konzept, ein Jahr Implementierung bis
zum Go-Live der ersten Marke, anschließend Rollout auf die übrigen Marken. Wie haben wir uns dabei organisatorisch aufgestellt?

17. Organisation
▸ Projektmanagement: Wasserfall Modell
Klassisch, vom Kunden gefordert.
▸ Entwicklung: Agile Software Entwicklung
Anforderungen an kritischen Stellen zu unpräzise.
▸ Design:
Modulares Design!
Modulares
Design
Das Projekt wurde nach außen, dem Kunden gegenüber, klassisch als Wasserfall Projekt abgewickelt. Die Implementierung erfolgte intern aber “agil”, da Anforderungen an einigen, zum Teil auch kritischen
Stellen, zu unpräzise waren. Da das Design zu unterschiedlichen Zeitpunkten in das Projekt einfließen sollte, haben wir uns hier eine Vorgehensweise überlegt, welche wir “Modulares Design” getauft haben
und die wir den drei beteiligten Designagenturen an die Hand gegeben haben. Entstanden ist die Vorgehensweise dadurch, dass wir versucht haben, Methoden aus der Software Entwicklung wie z.B.
Abstraktion und Kapselung auf das Design zu übertragen.

18. ▸ Styleguide-Ebene
globale Vorschriften: Farben, Stati, Schriftarten
▸ Layout-Ebene
Positionierung: Grid, Header/Footer-Bereich, Seitenleiste
▸ Modul-Ebene
Definition von funktionalen Modulen und Design-Elementen
Wie kann man das Design zerlegen?
Modulares
Design
Das hast dazu geführt, das wir als Erstes das Design in drei Ebenen zerlegt haben.
Und entsprechend dieser Ebenen haben wir die “Deliverables” von den verschiedenen Agenturen gefordert.

19. Was liefert der Designer?
▸ Einen Styleguide
Zusammenstellung der globalen Vorschriften.
▸ Layouts
ohne Inhalte!
▸ Für jedes Modul ein eigener Entwurf
Entwurf beschreibt nur dieses eine Modul.
Modulares
Design
Das bedeutet, für die Styleguide-Ebene einen “Styleguide”, entsprechend für die Layout-Ebene, Entwürfe für die verschiedenen Seiten Typen (Content einspaltig, zweispaltig, dreispaltig) und Spezifikation
eines Grid Systems auf dem diese Layouts basieren. Und Entwürfe für die einzelnen Module. Man könnte sich dann fragen, was macht denn der zweite Designer dann überhaupt noch? Er hat ja keinerlei
Gestaltungsmöglichkeiten mehr? Das kann man so aber nicht stehen lassen.

20. Was dürfen die Designer ändern?
▸ Styleguide-Ebene
darf komplett modifiziert werden! Gleiche Systematik schafft
Synergie-Effekte.
▸ Layout-Ebene
darf komplett modifiziert werden! Gleiche Systematik schafft
Synergie-Effekte.
▸ Module-Ebene
Funktionalität muss gleich bleiben! Aussehen ergibt sich aus den
globalen Vorschriften oder muss entsprechend definiert werden.
Modulares
Design
Auf allen Ebene können durchaus umfangreiche Änderungen durchgeführt werden. Der Styleguide könnte z.B: eine unterschiedliche Anzahl an Farben vorgeben. Generell werden aber bei Verwendung der
gleichen Systematik erhebliche Synergie-Effekte geschaffen. Für unser Projekt bedeutet das, …

21. Styleguide
Layout
Module
Styleguide
Layout
Styleguide
Layout
Marke 1 Marke 2 Marke 3
Modulares
Design
… dass wir drei unterschiedliche Styleguides erhalten haben, relativ ähnliche Layouts, doch auch hier gab es gravierende Unterschiede, so sind z.B: nur 2 der 3 Layouts “responsive”. Und dann ein großer
Topf von Modulen, die funktional für alle drei Designs identisch sind. Nicht zu verwechseln mit “identisch aussehen”, das tun sie nämlich nicht. Wie schaut das jetzt also real aus?

22. Was ist ein Modul?
Modulares
Design
Das ist ein Screenshot aus dem Dezember 2015. Was schätzen Sie, wieviele Module auf der Seite zu sehen sind?

23. 1: Vertrauensleiste
2: Logo
3: Suchschlitz
4: Service Navigation
5: Warenkorb-Anzeige
6: Hauptnavigation
7: Slider
8: Teaser
9: Karussell
10: Produkt
2
1
3
4
5
6
7
8
8
10
9
Modulares
Design
Ins. sind es hier 10 Module. Von Vertrauensleiste, Logo und Suchschlitz Teaser und Karussell. Und die selben 10 Module im zweiten Design …

24. 2
1
3
4 5
6
8
8
88
1: Vertrauensleiste
2: Logo
3: Suchschlitz
4: Service Navigation
5: Warenkorb-Anzeige
6: Hauptnavigation
7: Slider
8: Teaser
9: Karussell
10: Produkt
7
10
8 8
8
10
10
9
9
Modulares
Design
Da die 3. Marke noch nicht live ist (Ende Januar 2016), darf ich Ihnen davon leider keine Screenshots zeigen, aber auch hier werden die selben 10 Module auf der Startseite verwendet. Wie groß der
Unterschied, va. im Bezug auf Gestaltung und Design ist, sieht man am besten wenn man die beiden Screenshots einmal neben einander betrachtet.

25. Modulares
Design
Das möchte ich auch mal kurz unkommentiert so wirken lassen.
Man erkennt glaube ich ganz gut, dass Vivanda luftiger, breiter und eleganter wirkt, während Waschbär deutlich kompakter, kachelig und eher lang gezogen wirkt.
Wie bekommt man jetzt aber einen Designer dazu “modular” zu arbeiten?

26. Regeln
1. Jedes Modul kann überall positioniert werden.
2. Module dürfen beliebig oft auf einer Seite
verwendet werden.
3. Module können ineinander verschachtelt werden.
4. Breite kommt vom Grid, Höhe wird vom Inhalt
bestimmt.
Modulares
Design
Wir haben versucht den Designern ein paar Regeln an die Hand zu geben. Die bei der Definition der Module berücksichtigt werden müssen.
1. impliziert, dass ein Modul Entwurf sich nur mit dem Modul selbst beschäftigt. Wenn es solche Abhängigkeiten gibt, dann müssen diese eventuell bei einem übergeordneten Modul definiert werden.
2. impliziert, dass ein Modul in verschiedenen Varianten oder Versionen definiert werden kann/muss.
3. impliziert, dass ein Modul (va. funktional) nicht vom Inhalt abhängen darf.
4. impliziert, dass ein Modul nicht an eine bestimmte Position gebunden sein darf.
Um Abstraktion und Kapselung weiter zu verdeutlichen, haben wir noch zwei weitere Prinzipien an die Designer weitergegeben.

27. Modul: Trennung von Struktur und Aussehen
▸ Beispiel Teaser: Überschrift, Text, Bild, Link
Modulares
Design
Das ist 1. die Trennung von Struktur und Aussehen.
Ein Modul hängt auch immer mit eine Datenstruktur zusammen. Diese Datenstruktur spiegelt sich sowohl hinten in der Datenbank als auch z.B. in der Semantik des HTML Quelltextes wieder. Und das hat
erstmal nichts mit dem Aussehen zu tun. Oder anders formuliert, nur weil es uU. anders aussieht muß es kein eigenes Modul sein.
Das 2. Prinzip …

28. Modul: Trennung von Container und Inhalt
Teaser A
Modulares
Design
Teaser A
Teaser B
Teaser C
Teaser C
Teaser D
… ist die Trennung von Container und Inhalt.
Sprich wo ein Modul angezeigt wird, kann Einfluß darauf haben welche Inhalte angezeigt werden. Das sind dann weitere Regeln, die die Verwendung eines Moduls betreffen. So könnte man z.B. festgelegen,
dass die Varianten A) und B) des Teasers nur im Content Bereich der Seite verwendet werden, C) und D) nur in der Marginalspalte.

29. 1: Vertrauensleiste
2: Logo
3: Suchschlitz
4: Service Navigation
5: Warenkorb-Anzeige
6: Hauptnavigation
7: Slider
8: Teaser
9: Karussell
10: Produkt
2
1
3
4
5
6
7
8
8
10
9
Modulares
Design
Zusammen gefasst entsteht so eine Hierarchie mit Styleguide, Layout- und Modulentwürfen, welche sehr exakt festlegen, wie die Seiten aussehen können. Dieses Vorgehen ermöglicht jederzeit Änderungen
durch zu führen, egal auf welcher Ebene und kann parallel zur Implementierung durchgeführt werden. Sobald der Entwurf für ein Modul abgenommen ist, kann es implementiert werden. Styleguide und Layout
entstehen parallel dazu. Wenn dann durch ein Modul z.B: eine neue Farbe dazu kommt, muß man entscheiden ob diese Farbe auch für andere Module benötigt wird. Wenn ja, wird der Styleguide
entsprechend erweitert. Falls nicht, dann wird die Farbe nur innerhalb des Moduls definiert. Da dieses Vorgehen stark an die Software Entwicklung angelegt ist, ergeben sich in der Implementierung weitere
Synergie Effekte.

30. Technische Unterstützung
CSS / Less
▸ CSS
Precompiler
▸ Variablen und
Mixins
Javascript
▸ Scaleable Javascript
Application Architecture
▸ require.js
Automatisierung
▸ gulp
▸ Staging System
▸ Versionsverwaltung
Modulares
Design
Ein CSS Precompiler ermöglicht die Definition von Variablen und Mixins für die globalen Vorschriften. Modulares Javascript und Dependancy Management stellen sicher dass Javascript Code kollisionsfrei
funktioniert (Mehrfachverwendung auf deiner Seite, bzw. Verschachtelung von Modulen) und nur die Module geladen, werden die auf der Seite benötigt werden.
Build- und Deployment -Tools, bzw. Versionsverwaltung vervollständigen die Entwicklungsumgebung. Es entsteht so pro Modul eine Less- und eine Javascript Datei die einzeln versioniert werden kann. Der
Build Prozess fasst alle Module zusammen und erzeugt eine minimierte CSS bzw. Javascript Datei die auf der Webseite eingebunden wird.

31. Nachteile & Vorteile
▸ Erfordert eine andere
Vorgehensweise.
▸ Erfordert
Vorstellungskraft.
▸ Design ist länger im
Projekt eingebunden.
▸ Passt gut zu agilen
Vorgehensmodellen (z.B. SCRUM).
▸ Änderungen können zu jederzeit
implementiert werden.
▸ Das Design der Module
berücksichtigt Interaktion und
die Änderung des Inhalts bereits.
▸ Responsive Design ist der
nächste Schritt.
Modulares
Design
Natürlich hat auch diese Vorgehen nicht nur Vorteile, sondern auch Nachteile. Am Größten ist wohl, dass es anders ist und man seine Vorstellungskraft braucht um sich ein Modul auf einer Seite vorzustellen.
Wobei es eigentlich kein Problem ist ein Modul nachträglich zu modifizieren, wenn dem Kunden etwas nicht gefällt. Zusätzlich ist das Design länger im Projekt eingebunden. Nicht umbedingt im Sinne von
Aufwand oder Kosten, vor allem wenn man all die Rückfragen in Richtung Design in Betracht zieht, die üblicherweise zustanden kommen. Gut passt das Modulare Design zu agilen Vorgehensmodellen.
Änderungen können jederzeit durchgeführt werden. Auch werden Interaktionen und Änderungen am Inhalt so deutlich besser im Design berücksichtigt. Und Responsive Design ist nur der nächste Schritt,
denn vollständige Seiten mit Photoshop Entwürfen responsive zu designen ist kaum möglich. Für einzelne Module jedoch weniger problematisch, da die Aufgabe in kleinen Portionen bearbeitet werden kann.

32. Synergie-Effekt
Marke 1
100%
Marke 2
ca. 33%
Einsparung von ⅔ pro
zusätzlicher Marke!
Modulares
Design
Marke 3
ca. 33%
Was hat uns dieses Vorgehen nun unter dem Strich also effektiv gebracht? Wir haben für das 2. und 3. Design jeweils zwei Drittel der Kosten eingespart. Wir haben die Designentwürfe und den HTML
Prototypen parallel entwickelt. Auch alle Rückfragen in Richtung Design im weitern Projektverlauf konnten problemlos, nachträglich eingebaut werden. Das hat wirklich, wie geplant, gut und reibungslos
funktioniert! Auch nach dem Go-Live können Änderungen und Erweiterungen, egal über welches Design initiiert, problemlos hinzugefügt werden. Das ist auch langfristig so möglich. Wir haben eine
gemeinsame Code-Basis, mit drei verschiedenen Styleguides, so dass wir ein mal entwickeln und dreimal “bauen/compilieren”, testen und verteilen. Aber auch andere Arbeiten inzwischen “modular”.

33. Weitere Umsetzungsbeispiele
▸ http://styleguide.bundesregierung.de/
▸ http://rizzo.lonelyplanet.com/styleguide
▸ http://www.starbucks.com/static/reference/
styleguide/
Modulares
Design
Der Online-Styleguide der Bundesregierung ist meiner Meinung nach ein sehr gutes Beispiel für einen Styleguide der eine ähnliche Trennung (Globale Vorschriften, Layout/Positionierung und Module)
vornimmt. Lonelyplanet hat nur sehr reduzierte Globale Vorschriften und keine Layouts, statt dessen aber sehr ausführliche Modulbeschreibungen. Starbucks hat im Gegensatz dazu gar keine Globalen
Vorschriften, dafür jedoch ausführliche Dokumentation zum Grid-System (Layout) und den Modulen. Alle 3 Beispiele liefern jedoch meiner Meinung nach einen guten Einblick um eine eigene Struktur für
Module, Layouts und globalen Vorschriften zu erstellen und stellen die Module in den Vordergrund.

34. Alternativen
● Wer bin ich?
● Wer seid Ihr?
● Design in einem Webprojekt
● Modulares Design
● Alternative
● Tools und Werkzeuge
Inhalt

35. Alternative Konzepte
z.B. Atomic Design by Brad Frost
(http://bradfrost.com/blog/post/atomic-web-design/)
▸ Atome -> Moleküle -> Organismen -> Templates -> Pages
Nachteil: Detailstufe, keine “globale Ebene”
Alternativen
Als Alternative kann man “Atomic Design” von Brad Frost verstehen. Atomic Design definiert jede einzelne CSS Anweisung als Atom, aus mehreren Atomen wird dann ein Molekül zusammen gesetzt (z.B. ein
Button in einer bestimmten Farbe und Schrift). Aus mehreren Atomen werden dann Organismen definiert (z.B. ein Button und mehrere Formularfelder, etwa vergleichbar mit einem Modul), diese wiederum
definieren ein Template (vergleichbar mit einem Layout) und ganz oben werden sog. Pages definiert (vergleichbar mit dem Styleguide). Mir fehlt dabei jedoch eine Hierarchie, alle Anweisungen wie z.B. Farbe,
Schrift etc. auf atomarer Ebene sind gleich gestellt. Das macht es schwierig, z.B. eine globale Hauptfarbe zu definieren. Ebenso ist der Detailierungsgrad sehr hoch, was bei kleinen Projekten zu unnötig
hohem Aufwand führt.

36. Tools und Werkzeuge
● Wer bin ich?
● Wer seid Ihr?
● Design in einem Webprojekt
● Modulares Design
● Alternative
● Tools und Werkzeuge
Inhalt
Es lohnt sich aber einen Blick auf den Artikel von Brad Frost zu werfen. Ebenso möchte ich abschließend noch ein paar Tools und Werkzeuge empfehlen, die wir in dem Projekt erfolgreich eingesetzt haben
und die sich gut in eine modulare Arbeitsweise einfügen.

37. CSS Precompiler
▸ Sass
▸ Less
Javascript Module
▸ AMD
▸ require.js
Living Styleguide
▸ Pattern Primer
▸ kss
Automatisierung
▸ gulp
▸ grunt
Testing
▸ Karma
▸ Jasmine
▸ Selenium
Tools &
Werkzeuge
CSS Precompiler, Javascript Module Loader und die Taskrunner, habe ich ja bereits angesprochen. Darüber hinaus gibt es Tools zum Living Styleguide, welche über Kommentaren im CSS (also innerhalb der
Less Dateien) automatisiert eine Dokumentation der einzelnen Module erstellen. Diese können in den Build Prozess integriert werden und aktualisieren automatisch mit jedem Release die Dokumentation.
Auch Tests sind häufig ein schwieriges Thema. Auf Grund von zu vielen Abhängigkeiten können nur Integrationstests automatisiert durchgeführt werden. Wenn man modular arbeitet, könne jedoch auch recht
einfach Unit-Tests für diese Module erstellt werden.

38. Let us keep talking ...
https://www.dirk-benkert.de
mail@dirk-benkert.de
http://de.slideshare.net/dirkbenkert/modulares-design
web:
email:
slides:
Damit komme ich zum Schluß. Ich bedanke mich für Ihr Interesse und habe Sie hoffentlich überzeugt in Zukunft “Modular zu Designen”.