Modularisierung von Webseiten

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

4. None

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

12. None
13. None
14. None
15. None
16. None

17. Jedes dieser Module ist eine eigene Datei

18. None
19. None
20. None

21. Inhalte differieren zwischen Layout und Realität

22. None

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

48. None

49. Schnipsel im CSS dank Präprozessoren

50. CSS ist manchmal nervtötend unflexibel.

51. None

52. zentrales Stylesheet importiert Module und generiert ein CSS-File

53. None
54. None

55. Variablen

56. None

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/

68. None

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/