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

Modular Web Design With Components

Dfffc33a2fd0fb35e5e9234a062a037d?s=47 Nadal Soler
November 14, 2017

Modular Web Design With Components

I made this talk to help my Design Team colleagues, at [Digital Origin](https://www.digitalorigin.com/), to better understand the importance of designing in a modular way.

Modularity is the key to creating a flexible design system. For a system to be modular, it must have interchangeable parts (components).

Watch my slides if you want to learn Modular Web Design, to reach a smart system of reusable design patterns, interchangeable components, and well-planned system logic.

Dfffc33a2fd0fb35e5e9234a062a037d?s=128

Nadal Soler

November 14, 2017
Tweet

Transcript

  1. Modular Web Design With Components Think modular, think smart

  2. [`nadal sol ear] Meticulous Front-end Developer. Proudly coding since 2001.

    @nadalsol
  3. “We’re not designing pages, we’re designing systems of components.” –Stephen

    Hay
  4. Introducing modularity

  5. Blocks Components Modules Elements Atoms Molecules Organisms Pages Templates OOCSS

    SMACSS BEM SUIT CSS Bootstrap Foundation Widgets Material Design
  6. “Modularity is the key to creating a flexible design system.

    For a system to be modular, it must have interchangeable parts (components).” –Dennis Kardys
  7. CompoWHAT?

  8. What’s a component*? Definition (*) aka module or widget. 1.

    Generic term for any pre-defined object that you intend to use across multiple pages. 2. In order to be reusable, they must be standardized in appearance and function. 3. Each component will render reliably regardless of the context it's used in.
  9. “Think of components as Legos: interchangeable building blocks you can

    assemble into pages.”
  10. None
  11. The benefits of components

  12. The benefits of components 1. Modularity. 2. Extensibility. 3. Testability.

    4. Reusability. 5. Consistency.
  13. What makes a component modular? 1. Standardized design: Predetermined appearance.

    2. Centralized code: Unique code should not be needed each time you reuse the component. 3. Controlled via system logic: Predefined formatting should occur based on system rules, not content author discretion. 4. Customizable: Display, content, and functional options.
  14. Modularizing your design

  15. Modularizing your design Eliminate discrepancies and boil each component down

    into a standardized model. Be deliberately lean, removing any page-specific component customization that doesn’t benefit the system as a whole.
  16. None
  17. None
  18. Define & document system logic To make components reusable, they

    need rules. Without system logic defining how they can and should be used, we’d be back at freeform design.
  19. Define & document system logic Documenting component rules lead to

    more efficient UI and code. It can provide reference to content authors seeking to understand what components they have access to, and what the expectations and best practices of use are.
  20. “Good component logic provides useful constraints.” –Dennis Kardys

  21. Component creation process

  22. Source: https://design.canonical.com/2016/07/getting-vanilla-ready-for-v1-the-roadmap/

  23. Follow the steps 1. Respect your Design System. 2. Check

    the purpose. 3. Define expected behavior and interactions. 4. Consider context. 5. Dogfood your Design System.
  24. Always respect the rules already defined in your Design System.

    Things like: • Grid • Spacing • Color palette • Typography • etc... 1. Respect your Design System
  25. None
  26. Follow the steps 1. Respect your Design System. 2. Check

    the purpose. 3. Define expected behavior and interactions. 4. Consider context. 5. Dogfood your Design System.
  27. 2. Check the purpose

  28. Existing component? Purpose Create new component No Yes Same structure/behavior?

    No Yes Same appearance (skin)? Yes Use existing component Modify existing component No
  29. Let’s create a new component when... • When you DON’T

    HAVE an existing component with the same purpose. • When you DON’T HAVE an existing component with the same structure/behavior. Create new component
  30. Existing component? Purpose Create new component No Yes Same structure/behavior?

    No Yes Same appearance (skin)? Yes Use existing component Modify existing component No
  31. Let’s use an existing component... • When you ALREADY HAVE

    an existing component with the same purpose. • When you ALREADY HAVE an existing component with the same structure/behavior. • When you ALREADY HAVE an existing component with the same appearance (skin). Use existing component
  32. Existing component? Purpose Create new component No Yes Same structure/behavior?

    No Yes Same appearance (skin)? Yes Use existing component Modify existing component No
  33. Modify existing component Let’s modify an existing component... • When

    you ALREADY HAVE an existing component with the same purpose. • When you ALREADY HAVE an existing component with the same structure/behavior. • When you DON’T HAVE an existing component with the same appearance (skin).
  34. None
  35. Beware of Redesigns Avoid redesigns as much as possible (unless

    there’s a good reason to). Redesign Modify existing component
  36. Beware of Redesigns Redesigns may imply code refactors, or even

    breaking design consistency across different contexts, causing collateral damage (atoms tend to be used in different molecules). Example: Button size (atom) in different contexts (molecules). Redesign Modify existing component
  37. None
  38. None
  39. Follow the steps 1. Respect your Design System. 2. Check

    the purpose. 3. Define expected behavior and interactions. 4. Consider context. 5. Dogfood your Design System.
  40. At DO we want to be agile, so we're far

    from creating Functional Specifications Documents (FSD). The FSD is what's given to: • Developers: so they know what to build. • Testers: so they know what to test. • Stakeholders: so they know exactly what's being created. 3. Define expected behavior and interactions
  41. Therefore, the best way to describe interaction is to model

    it with an interactive prototype. In other words... What happens when you interact with elements in the mockup? 3. Define expected behavior and interactions
  42. 3. Define expected behavior and interactions

  43. Follow the steps 1. Respect your Design System. 2. Check

    the purpose. 3. Define expected behavior and interactions. 4. Consider context. 5. Dogfood your Design System.
  44. Context is important Always test your new component proposal in

    many contexts, in order to detect different use cases, as well as possible inconsistencies. 4. Consider context
  45. Follow the steps 1. Respect your Design System. 2. Check

    the purpose. 3. Define expected behavior and interactions. 4. Consider context. 5. Dogfood your Design System.
  46. Last, but not least... Don’t forget to update your Design

    System with whatever changes you made. 5. Dogfood your Design System
  47. A classic problem

  48. I’m a developer. What do you expect me to implement?

  49. Imagine you're designing a new popover component. I’m a developer.

    What do you expect me to implement?
  50. In order to build and test popovers, Developers and Testers

    need to know: • Do you expect to be dismissible? • Do you expect to be repositioned (i.e. on window resize)? • Do you expect to be placed on top, right, bottom, left? • Do you expect the same behavior on mobile and desktop devices? • etc... I’m a developer. What do you expect me to implement?
  51. Anatomy of a component

  52. None
  53. Let's take a real world example, based on DO Notification

    component. Anatomy of a component
  54. None
  55. How this component could be affected? 1. Different appearance (skin):

    yellow background, green background… 2. Different content (structure): message only, message plus heading, message plus action… 3. Different interaction: always visible, flash message (toast), dismissible, contextual messages... Anatomy of a component
  56. When you need to change your component appearance (skin) or

    content (structure), but not its purpose, CSS modifiers are handy. Other examples: • Notification: alert, success, info... • Button: small, medium, large... • Popover: top, right, bottom, left... • etc... Anatomy of a component
  57. The cost of creating new components

  58. What do you think? Let’s discuss...

  59. “It’s not just about using a design system, it’s about

    creating your system.” –Brad Frost
  60. Q&A

  61. References: Atomic Design, by Brad Frost. Modular Web Design: Designing

    With Components, by Dennis Kardys. SMACSS (Scalable and Modular Architecture for CSS), by Jonathan Snook. BEM (Block Element Modifier) methodology. My own experience ;)
  62. Made with love by @nadalsol , on Nov. 2017