Modular Front-End Architectures with Pattern Libraries

Modular Front-End Architectures with Pattern Libraries

The way we build applications and websites has shifted from building pages to building design systems. During this session we will review an enterprise case study of what to do and what not to do when moving to a modular design approach. We will discuss useful principles that will help you improve consistency, efficiency and maintainability across multiple projects.

This session will also cover modified workflows that incorporate pattern libraries in your design and development process and give you practical tools on how to build your own pattern library.

Objective
Streamline the design process and improve collaboration with developers by breaking down pages into reusable modules.

Five things audience members will learn
• Discussion on the benefits of using a pattern library
• How to identify, review, and rate patterns
• Organizing patterns into a library
• Building and documenting patterns (including a healthy dose of Sass)
• Utilizing your new pattern library for rapid prototyping

7559f6cff1f5efc2d210965febd4d71c?s=128

Bermon Painter

March 16, 2016
Tweet

Transcript

  1. Modular Front-End Architectures @bermonpainter | Great Wide Open

  2. None
  3. None
  4. Patterns The foundation of repeatable interactions that when combined create

    rich and complex systems.
  5. None
  6. Benefits A useful tool to use when breaking down a

    user interface into it’s most modular pieces, instead of thinking about things as a series of disconnected pages.
  7. Benefits 1. Collaboration

  8. Benefits 1. Collaboration 2. Language

  9. Benefits 1. Collaboration 2. Language 3. Consistency

  10. Benefits 1. Collaboration 2. Language 3. Consistency 4. Efficiency

  11. Benefits 1. Collaboration 2. Language 3. Consistency 4. Efficiency 5.

    Speed
  12. Benefits 1. Collaboration 2. Language 3. Consistency 4. Efficiency 5.

    Speed 6. Maintainability
  13. Static Style Guides Built with (or generated) static HTML. They

    are standalone representations of modules that are build separately from your applications.
  14. None
  15. None
  16. None
  17. None
  18. None
  19. None
  20. Living Style Guides Generated HTML, typically created from parsing documentation

    created as comments in CSS files.
  21. None
  22. None
  23. None
  24. None
  25. Challenges You’ve implemented a pattern library. Now what? It’s difficult

    it is to get buy-in, train teams, maintain the codebase between the pattern library and one or more applications, deal with technical debt, etc.
  26. Challenges Adoption If the people that manage the money don’t

    see or understand the value in a pattern library, the won’t dedicate the time, resources, and budget to maintain one.
  27. Challenges Governance Loose collaboration will fail. The must be a

    framework that clearly defines roles, responsibilities, and who have the authority to make decisions and provide a clear direction to the team.
  28. Challenges Application The entire team must be on board on

    writing patterns, following code standards, and maintaining the patterns.
  29. Challenges Abstraction “Duplication is far cheaper than the wrong abstraction.”

    – Sandi Metz
  30. Conventions SMACSS, BEM, OOCSS, ITCSS, RSCSS, Atomic Design, Oxygen

  31. Folder Structure /assets /images /content /layout /fonts /javascript /libs /modules

    module-name.js /testing module-name.spec /sass /base /helpers /modules module-name.scss /setup /themes /theme-name module-name.scss
  32. Pattern Structure .parent {…} .parent-child {…} .parent-child-grandchild {…} 1. Parent-Child-Grandchild

  33. Pattern Structure .navigation {…} .navigation-item {…} .navigation-item-action {…} 1. Parent-Child-Grandchild

  34. Pattern Structure .plural-items {…} .singular-item {…} 1. Parent-Child-Grandchild 2. Plural-Singular

  35. Pattern Structure .images {…} .image {…} 1. Parent-Child-Grandchild 2. Plural-Singular

  36. Pattern Anatomy Focus on implementing modules as a “single source

    of truth” to be used across multiple application, without relying on copy/paste.
  37. .css Function & Unit Tests .html .js .coffee .sass .slim

    1. Responsive 2. Accessible 3. Versioned 4. Managed Dependencies Module
  38. .css Function & Unit Tests .html .js .coffee .sass .slim

    Pattern Library
  39. .css Function & Unit Tests .html .js .coffee .sass .slim

    Pattern Library Application
  40. .css Function & Unit Tests .html .js .coffee .sass .slim

    Pattern Library Applications
  41. Design System 1. Elements (base elements, like Normalize)

  42. Creating Pages 1. Elements (base elements, like Normalize) 2. Modules

    (combination of elements)
  43. Creating Pages 1. Elements (base elements, like Normalize) 2. Modules

    (combination of elements) 3. Theme (look and feel specific to an application)
  44. Creating Pages 1. Elements (base elements, like Normalize) 2. Modules

    (combination of elements) 3. Theme (look and feel specific to an application) 4. Layout (combination of elements, modules, theme)
  45. Creating Pages 1. Elements (base elements, like Normalize) 2. Modules

    (combination of elements) 3. Theme (look and feel specific to an application) 4. Layout (combination of elements, modules, theme) 5. Page (generated output served to the client)
  46. None
  47. API: Source of Truth

  48. PATTERN API PATTERN LIBRARY APP DATA

  49. Conclusion

  50. Fin.