A Vision for Style Guides in 2015

A Vision for Style Guides in 2015

28e1c6e895146e8217caf14eb56feb7b?s=128

Nico Hagenburger

October 13, 2014
Tweet

Transcript

  1. 5.
  2. 10.

    Dead Style Guides ★ Confusion about latest version ★ Hard

    to distribute ★ Hard to edit/change/keep up-to-date ★ Perfect for Corporate Design
  3. 12.

    Living Style Guides ★ Are made with HTML and CSS

    ★ Use the production CSS ★ Are under version control (GIT) ★ Separate design and code ★ Automate as much as possible
  4. 13.
  5. 14.

    Back-end Developers ★ Will love it, when they don’t have

    to care about CSS ★ Will love it, when they can start functionality right with something looking good.
  6. 18.

    Separation of 
 content and design 
 (in the 3210

    era) ★ HTML on one side ★ CSS on the other side
  7. 19.

    Separation of 
 content and design (today) ★ HTML on

    one side ★ CSS on the other side ★ Data
  8. 22.
  9. 26.

    Show all versions? v31.2.0 v16.1.3 v8.5.0 A concept for versioning

    in style guides (developed in 2013, never implemented in a real project)
  10. 30.

    What’s an edge case? ★ Having the same HTML with

    different amount of text ★ Having the same HTML without image (user with no profile image) ★ Having the same HTML with too small image
  11. 32.

    What’s an edge case? ★ Having the same HTML with

    different amount of text ★ Having the same HTML without image (user with no profile image) ★ Having the same HTML with too small image
  12. 33.

    DRY

  13. 34.
  14. 35.
  15. 37.

    If we extract the template, the back- end developer has

    to copy the ID, not a bunch of HTML.
  16. 40.

    APIs ★ One specified “call” per action ★ Specified input,

    output, and name/URL/ID ★ Written tests for every action
  17. 41.

    Style Guide APIs ★ One specified “template” per action ★

    Specified input, output, and ID ! ★ We just need the tests
  18. 43.

    Before committing ★ Automatically take a “screenshot” of every example

    ★ Include all edge cases ★ Compare before/after ★ Warn for every change
  19. 45.

    Each template 
 should have: ★ The HTML ★ The

    CSS ★ Normal examples ★ Edge cases ★ Reference screen shots _user.mustache _user.scss _user.md _user.md + @test _user-1.png, _user-2.png, …
  20. 51.

    Show code/data/… ★ For front-end developers: show HTML, variables, mixins,

    @extend templates, … ★ For back-end developers: show data structure ★ For QA: show all edge cases ★ For designers: show colors and fonts ★ For HR: show your quality work
  21. 52.

    Mark edge cases: @test @template _my-template.hbs @data { name: "Homer"

    } Will most likely be implemented in the LivingStyleGuide Gem. https://github.com/hagenburger/livingstyleguide