Modularisierung von Webseiten

Vortrag auf der Webtech 2012. Eine Webseite besteht aus vielen einzelnen Modulen, die alle als eigenes Universum betrachtet werden können. CSS-Präprozessoren helfen bei der effektiven Behandlung der Module. Prototyping im Browser und ein neuer Workflow werden dadurch einfacher.

Transcript

1. Modularisierung von Webseiten Jens Grochtdreis
2. ‣Frontendentwickler ‣seit 1999 Arbeit im und fürs Web ‣seit 2009 selbständig ‣Frontendentwicklung ‣Schulung ‣Beratung ‣twitter.com/Flocke
3. Seite ist eine Ansammlung von Modulen
5. Platzierung sollte egal sein
6. Module entwickeln, nicht ganze Seiten!
7. Layout entseht separat - mit eingefügten Modulen
8. Layout: Seitengrundgerüst
9. Module tragen Designinformationen
10. Umfangreiche Modulliste
11. http://structurae.de
17. Jedes dieser Module ist eine eigene Datei
21. Inhalte differieren zwischen Layout und Realität
23. ‣ Bei deutschsprachigen Seiten auch deutschen Blindtext nutzen. ‣ Möglichst früh mit realen Inhalten arbeiten. ‣ Möglichst früh mit realen Navigationsnamen arbeiten - auch wenn diese sich noch ändert. http://grochtdreis.de/weblog/2009/10/18/schoener-navigationstitel/
24. http://www.blindtextgenerator.de/
25. http://bueltge.de/html-ipsum/
26. Dummybilder http://dummyimage.com/ http://lorempixel.com/
27. Dummybilder http://placekitten.com/
28. Module richtig entwickeln
29. Das Modul ist sein eigenes Universum!
30. Trennung zwischen Layout und Design
31. Semantisch = HTML Design = CSS
32. http://jsfiddle.net/Flocke/psAwV/
33. Richtiger Umgang mit Klassen
34. https://github.com/stubbornella/oocss/wiki
35. https://smacss.com/
36. http://bem.github.com/bem-method/pages/beginning/beginning.en.html
37. Semantische Klassen?
38. Nein! Pflegbare!
39. CSS = Optik Semantik = HTML
40. Nach Farben benannte Klassen sind dann okay, wenn klar ist, dass diese Farben Konstanten sind.
41. Grundsätzlich sollten Klassennamen nicht zu nahe am Objekt sein. Abstraktion ist wichtig. Und Pflegbarkeit.
42. Alles hat seine Vor- und Nachteile
43. Sparsam Klassen vergeben
44. ‣ Bei OOCSS und SMACSS vergibt man an möglichst alles Klassen. Das ist ungünstig. ‣ Wollen/können wir Redakteuren in WYSIWYG-Editoren die Vergabe von Klassen an Listen und Absätze aufbürden?
45. IDs sind böse? Nein, aber sie sind meist unnötig!
46. ‣ IDs benötigen wir, um Labels mit Formularelementen zu kombinieren. ‣ IDs sind dann sinnvoll, wenn ich einmalige Seitenbereiche auszeichne und diese auch im CSS lesbar/erkennbar haben will: ‣ #header ‣ #footer ‣ #wrapper ‣ Manche CMSe vergeben von sich aus IDs.
47. Allgemeine und spezielle Klassen
49. Schnipsel im CSS dank Präprozessoren
50. CSS ist manchmal nervtötend unflexibel.
52. zentrales Stylesheet importiert Module und generiert ein CSS-File
55. Variablen
57. Positiver Nebeneffekt
58. ‣ Geschwindigkeit in der Entwicklung ‣ Rapid Prototyping mit dem Designer zusammen möglich ‣ Photoshop ist für Webdesign nur sehr bedingt geeignet. ‣ Der Browser sollte das Designwerkzeug sein! ‣ Es heißt http:// nicht psd://
59. http://www.flickr.com/photos/artrock2006/4177475479/
60. UI-Sammlungen
61. http://foundation.zurb.com/
62. http://twitter.github.com/bootstrap/
63. http://foundation.zurb.com/grid.php
64. http://twitter.github.com/bootstrap/components.html
65. http://foundation.zurb.com/docs/navigation.php
66. http://chriscoyier.github.com/SurveyMonkey-Design-Patterns/ https://github.com/chriscoyier/SurveyMonkey-Design-Patterns
67. http://bootsnipp.com/
69. Jens Grochtdreis http://grochtdreis.de/ http://twitter.com/Flocke http://webkrauts.de http://grochtdreis.de/+ Diese Präsentation steht unter der Creative Commons Lizenz „Attribution-ShareAlike 2.0“ http://creativecommons.org/licenses/by-sa/2.0/de/