Modular Web Design With Components

Slide 1

Slide 1 text

Modular Web Design With Components Think modular, think smart

Slide 2

Slide 2 text

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

Slide 3

Slide 3 text

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

Slide 4

Slide 4 text

Introducing modularity

Slide 5

Slide 5 text

Blocks Components Modules Elements Atoms Molecules Organisms Pages Templates OOCSS SMACSS BEM SUIT CSS Bootstrap Foundation Widgets Material Design

Slide 6

Slide 6 text

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

Slide 7

Slide 7 text

CompoWHAT?

Slide 8

Slide 8 text

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.

Slide 9

Slide 9 text

“Think of components as Legos: interchangeable building blocks you can assemble into pages.”

Slide 10

Slide 10 text

No content

Slide 11

Slide 11 text

The benefits of components

Slide 12

Slide 12 text

The benefits of components 1. Modularity. 2. Extensibility. 3. Testability. 4. Reusability. 5. Consistency.

Slide 13

Slide 13 text

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.

Slide 14

Slide 14 text

Modularizing your design

Slide 15

Slide 15 text

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.

Slide 16

Slide 16 text

No content

Slide 17

Slide 17 text

No content

Slide 18

Slide 18 text

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.

Slide 19

Slide 19 text

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.

Slide 20

Slide 20 text

“Good component logic provides useful constraints.” –Dennis Kardys

Slide 21

Slide 21 text

Component creation process

Slide 22

Slide 22 text

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

Slide 23

Slide 23 text

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.

Slide 24

Slide 24 text

Always respect the rules already defined in your Design System. Things like: ● Grid ● Spacing ● Color palette ● Typography ● etc... 1. Respect your Design System

Slide 25

Slide 25 text

No content

Slide 26

Slide 26 text

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.

Slide 27

Slide 27 text

2. Check the purpose

Slide 28

Slide 28 text

Existing component? Purpose Create new component No Yes Same structure/behavior? No Yes Same appearance (skin)? Yes Use existing component Modify existing component No

Slide 29

Slide 29 text

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

Slide 30

Slide 30 text

Existing component? Purpose Create new component No Yes Same structure/behavior? No Yes Same appearance (skin)? Yes Use existing component Modify existing component No

Slide 31

Slide 31 text

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

Slide 32

Slide 32 text

Existing component? Purpose Create new component No Yes Same structure/behavior? No Yes Same appearance (skin)? Yes Use existing component Modify existing component No

Slide 33

Slide 33 text

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).

Slide 34

Slide 34 text

No content

Slide 35

Slide 35 text

Beware of Redesigns Avoid redesigns as much as possible (unless there’s a good reason to). Redesign Modify existing component

Slide 36

Slide 36 text

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

Slide 37

Slide 37 text

No content

Slide 38

Slide 38 text

No content

Slide 39

Slide 39 text

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.

Slide 40

Slide 40 text

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

Slide 41

Slide 41 text

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

Slide 42

Slide 42 text

3. Define expected behavior and interactions

Slide 43

Slide 43 text

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.

Slide 44

Slide 44 text

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

Slide 45

Slide 45 text

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.

Slide 46

Slide 46 text

Last, but not least... Don’t forget to update your Design System with whatever changes you made. 5. Dogfood your Design System

Slide 47

Slide 47 text

A classic problem

Slide 48

Slide 48 text

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

Slide 49

Slide 49 text

Imagine you're designing a new popover component. I’m a developer. What do you expect me to implement?

Slide 50

Slide 50 text

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?

Slide 51

Slide 51 text

Anatomy of a component

Slide 52

Slide 52 text

No content

Slide 53

Slide 53 text

Let's take a real world example, based on DO Notification component. Anatomy of a component

Slide 54

Slide 54 text

No content

Slide 55

Slide 55 text

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

Slide 56

Slide 56 text

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

Slide 57

Slide 57 text

The cost of creating new components

Slide 58

Slide 58 text

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

Slide 59

Slide 59 text

“It’s not just about using a design system, it’s about creating your system.” –Brad Frost

Slide 60

Slide 60 text

Q&A

Slide 61

Slide 61 text

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 ;)

Slide 62

Slide 62 text

Made with love by @nadalsol , on Nov. 2017