Modular Web Design With Components
3 likes339 views
The document discusses modular web design, emphasizing the importance of creating reusable components or modules to facilitate a flexible design system. It outlines the characteristics of effective components, their creation process, and the benefits of modularity, such as consistency and testability. Key recommendations include respecting the design system, standardizing components, and documenting rules for efficient use and development.
![[`nadal sol ear]
Meticulous Front-end Developer.
Proudly coding since 2001.
@nadalsol](https://image.slidesharecdn.com/modular-web-design-with-components-171114143144/85/Modular-Web-Design-With-Components-2-320.jpg)
Modular Web Design With Components
- 1. Modular Web Design With Components Think modular, think smart
- 2. [`nadal sol ear] Meticulous Front-end Developer. Proudly coding since 2001. @nadalsol
- 3. Were not designing pages, were designing systems of components. Stephen Hay
- 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. Whats 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.
- 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.
- 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 doesnt benefit the system as a whole.
- 18. Define & document system logic To make components reusable, they need rules. Without system logic defining how they can and should be used, wed 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
- 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
- 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.
- 28. Existing component? Purpose Create new component No Yes Same structure/behavior? No Yes Same appearance (skin)? YesUse existing component Modify existing component No
- 29. Lets create a new component when... When you DONT HAVE an existing component with the same purpose. When you DONT 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)? YesUse existing component Modify existing component No
- 31. Lets 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)? YesUse existing component Modify existing component No
- 33. Modify existing component Lets 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 DONT HAVE an existing component with the same appearance (skin).
- 35. Beware of Redesigns Avoid redesigns as much as possible (unless theres 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
- 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... Dont forget to update your Design System with whatever changes you made. 5. Dogfood your Design System
- 48. Im a developer. What do you expect me to implement?
- 49. Imagine you're designing a new popover component. Im 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... Im a developer. What do you expect me to implement?
- 51. Anatomy of a component
- 53. Let's take a real world example, based on DO Notification component. Anatomy of a component
- 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? Lets discuss...
- 59. Its not just about using a design system, its 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