Normalising Designs For Better Quality CSS

Normalising Designs For Better Quality CSS at CSSconf.eu, Berlin. September 2013.

Video: http://bit.ly/15CS3VF

Transcript

1. NORMALISING DESIGNS FOR BETTER QUALITY CSS CSSconf.eu, Berlin – September, 2013 Harry Roberts – @csswizardry
2. RATIONALISING DESIGNS FOR BETTER QUALITY CSS CSSconf.eu, Berlin – September, 2013 Harry Roberts – @csswizardry
3. or…
4. WHY DESIGNERS HATE ME
5. #DesignersHateHim
8. Big sites…
9. …that only get bigger.
10. Lean. Scalable. Sane. Maintainable. Keep front-ends…
11. The easiest way to keep code maintainable is to write less of it…
12. …and the easiest way to write less is to build less.
13. Wait!
14. Not anti-design at all. Will not work on every site. Not necessary for every site. You might just disagree. Disclaimer
15. Disclaimer Not anti-design at all. Will not work on every site. Not necessary for every site. You might just disagree. #DesignersHateHim
16. Have a good relationship with designers. Discuss and explain everything. Collaborate to reach ideals. No means no. Making compromises
17. A PSD is a clue, not a contract.
18. No guarantee I will build exactly as designed. Too early to agree or commit. Gives me an idea of the overall design. A PSD is a clue…
19. Design ‘atmosphere’. @Malarkey
20. “It’s doable, but…”
21. Pretty much anything is buildable but… …not everything should be. I used to pride myself on writing tonnes of CSS to perfectly reproduce a design. Bad idea. It’s doable, but…
22. Just because you can doesn’t mean you should. http://bit.ly/17eRvVR
23. There’s no point having a shiny UI if it takes 20s to download.
24. Users love nice UIs. Users appreciate good design. Users will leave before waiting. Shiny UIs
25. Performance first.
26. 80:20 :
27. If we can achieve 80% of the design with 20% of the code, we should. 80:20
28. “I thought you were meant to be good at this stuff…?!”
29. Kinda makes me look like a bad developer. So much more to being a front-end dev than reproducing designs pixel-for-pixel. Look at the bigger picture. I thought you were good!
30. The better you get at writing code, the less you want to.
31. Resent writing code that could be avoided. Hate anything bespoke. Always recycle. Writing less
32. Normalise & abstract.
33. Spot repetition. Spot potential for repetition. Normalise
34. .header { padding: 20px; } .content { padding: 22px; } .footer { padding: 18px; }
35. .header { padding: 20px; } .content { padding: 20px; } .footer { padding: 20px; }
36. Wrap things up. Make things reusable. Decouple it all. Abstract
37. /** * Shared, but not abstracted :( */ .header, .content, .footer { padding: 20px; }
38. /** * Store in a variable. */ $padding: 20px;
39. /** * Use abstracted (silent) classes. */ .box, %box { padding: $padding; }
40. <!-- - Use in markup. -> <div class="box foo"> ... </div>
41. /** * Use with `@extend`. */ .foo { @extend %box; }
42. Premature abstraction.
43. Premature abstraction. Prepared
44. They’re called rule sets for a reason.
45. Good, consistent UIs are based on rules.
46. Rules that you do not break.
48. All your base…
49. html { font-size: 16px; line-height: 24px; }
50. /** * 1. Assume a 16px default. */ html { font-size: 100%; /* [1] */ line-height: 1.5; } http://bit.ly/13Vi6bu
51. html { font-size: 16px; line-height: 24px; }
52. html { font-size: 16px; line-height: 24px; }
53. Base spacing unit.
54. h1 { margin: 12px 0 38px 0; } p { margin: 7px 7px 20px 0; } .contact-form { margin: 10px 0 0 0; } ...
55. h1, h2, h3, h4, h5, h6, hgroup, ul, ol, dl, blockquote, p, address, table, fieldset, figure, pre { margin: 0; margin-bottom: 24px; } http://bit.ly/LidsHu
56. .island, .islet { display: block; } .island { padding: 24px; } .islet { padding: 12px; } http://bit.ly/13TfmeR
57. UI sizing scales…
58. .foo--tiny { 0.25x } .foo--small { 0.50x } .foo { 1.00x } .foo--large { 2.00x } .foo--huge { 4.00x }
59. .foo--tiny { margin-bottom: 6px; } .foo--small { margin-bottom: 12px; } .foo { margin-bottom: 24px; } .foo--large { margin-bottom: 48px; } .foo--huge { margin-bottom: 96px; }
60. .btn--tiny { padding: 6px; } .btn--small { padding: 12px; } .btn { padding: 24px; } .btn--large { padding: 48px; } .btn--huge { padding: 96px; }
61. My type of CSS!
62. html { font-size: 16px; } .read-more { font-size: 15px; } .caption { font-size: 17px; }
63. Typography Piggyback HTML elements. Body copy is the default. Headings and smallprint deviate. Most UI elements fall into one of the above.
64. /** * Everything. */ html { } /** * Exceptions. */ h[1–6] { } small { }
65. h1, .h1 { font-size: ; } h2, .h2 { font-size: ; } h3, .h3 { font-size: ; } h4, .h4 { font-size: ; } h5, .h5 { font-size: ; } h6, .h6 { font-size: ; } http://bit.ly/15B7wRf
66. Real life examples.
71. Tweak the design. Use illusion. Cheat!
73. How?
74. Background image? Extra request. Base64? Lots of ugly code. CSS gradients and pseudo elements? Hacky. How?
75. Change the design. How?
77. If it seems unreasonably difficult to build something, don’t build it.
78. Seek alternatives, change things, rationalise and normalise.
79. Take the easy road.
80. KISS
81. m.skybet.com Our most pared back, rationalised design. It still looks great. Our fastest site by far. Users love it.
82. In summary We don’t deliver designs, we deliver websites. Make compromises for the sake of build quality. Stick to the rules. Be clever; cheat!
83. Thank you! Consultant Front-end Architect – CSS Wizardry Senior UI Developer – BSkyB @csswizardry csswizardry.com/work