Upgrade to Pro — share decks privately, control downloads, hide ads and more …

A Vision for Style Guides in 2015

A Vision for Style Guides in 2015

Nico Hagenburger

October 13, 2014
Tweet

More Decks by Nico Hagenburger

Other Decks in Programming

Transcript

  1. Dead Style Guides ★ Confusion about latest version ★ Hard

    to distribute ★ Hard to edit/change/keep up-to-date ★ Perfect for Corporate Design
  2. 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
  3. 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.
  4. Separation of 
 content and design 
 (in the 3210

    era) ★ HTML on one side ★ CSS on the other side
  5. Separation of 
 content and design (today) ★ HTML on

    one side ★ CSS on the other side ★ Data
  6. 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)
  7. 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
  8. 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
  9. DRY

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

    to copy the ID, not a bunch of HTML.
  11. APIs ★ One specified “call” per action ★ Specified input,

    output, and name/URL/ID ★ Written tests for every action
  12. Style Guide APIs ★ One specified “template” per action ★

    Specified input, output, and ID ! ★ We just need the tests
  13. Before committing ★ Automatically take a “screenshot” of every example

    ★ Include all edge cases ★ Compare before/after ★ Warn for every change
  14. 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, …
  15. 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
  16. 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