Components, patterns and sh*t it’s hard to deal with @ Intersection

Slide 1

Slide 1 text

INTERSECTION CONFERENCE UX & Development - Milan - October 1-2 2018

Slide 2

Slide 2 text

No content

Slide 3

Slide 3 text

Modular architecture

Slide 4

Slide 4 text

Modular architecture Classes and components

Slide 5

Slide 5 text

Modular architecture classes and Components and modifiers

Slide 6

Slide 6 text

Modular architecture classes and Components, modifiers and overrides

Slide 7

Slide 7 text

Modular architecture classes, modifiers and overrides Components,   patterns and sh*t it’s hard to deal with

Slide 8

Slide 8 text

@cedmax Webmaster before it was cool   Tech Lead   Condé Nast International

Slide 9

Slide 9 text

Components,  patterns and sh*t it’s hard to deal with

Slide 10

Slide 10 text

or… How I came up with a good use of quotes from Lost in Translation Components,  patterns and sh*t it’s hard to deal with

Slide 11

Slide 11 text

Basically Lost in Translation?

Slide 12

Slide 12 text

“This movie is an hour and some odd minutes of my life I will never get back.” JoeB. on Metacritic Disclaimer

Slide 13

Slide 13 text

“Meaning is complex and often gets lost in translation. Everybody has their own mental model of things” Alla Kholmatova Lost in Translation

Slide 14

Slide 14 text

Modular design

Slide 15

Slide 15 text

2013 - 2015

Slide 16

Slide 16 text

No content

Slide 17

Slide 17 text

Atomic design Brad Frost · October 2013

Slide 18

Slide 18 text

Web components announced in November 2011

Slide 19

Slide 19 text

Pattern Library “Pattern libraries are something I do a lot for client projects. […] It’s a technique I first saw […] Natalie Downe develop for client projects back in 2009” Anna Debenham

Slide 20

Slide 20 text

MISSING SLIDE* ABOUT PATTERN LIBRARIES * on purpose, I promise

Slide 21

Slide 21 text

Pattern Library “Pattern libraries are something I do a lot for client projects. […] It’s a technique I first saw […] Natalie Downe develop for client projects back in 2009” Anna Debenham

Slide 22

Slide 22 text

ReactJS First release: March 2013

Slide 23

Slide 23 text

Where are we at, today?

Slide 24

Slide 24 text

Basically Frame the issue

Slide 25

Slide 25 text

It's not that simple “When you actually try to apply a modular approach to your day to day work, it isn’t really that simple” Alla Kholmatova · June 2015

Slide 26

Slide 26 text

The issue

Slide 27

Slide 27 text

The issue How do we manage our code, to re-use patterns without making them too rigid for the day to day activities?

Slide 28

Slide 28 text

The issue How do we manage our code, to re-use patterns without making them too rigid for the day to day activities?   How do we re-use our patterns in slightly different use cases?

Slide 29

Slide 29 text

Wish I could sleep

Slide 30

Slide 30 text

It’s NOT about any specific tech stack or module implementation: most of the patterns can be applied with BEM, styled components, css modules… *    It’s about modularity at its core    It’s about modules responsibilities    It’s about maintainability  (among other coding practices)

Slide 31

Slide 31 text

Classname   injection I'll be in the bar for the rest of the week

Slide 32

Slide 32 text

Slide 33

Slide 33 text

Slide 34

Slide 34 text

//_content-actions.scss .content-actions { //[...] &__button { flex: 1 0 auto; padding: 1rem; line-height: 1.5; &:hover, &:focus { background: $grey-1; } &:active { background: $grey-2; } } }

Slide 35

Slide 35 text

//_content-actions.scss .content-actions { //[...] &__button { flex: 1 0 auto; padding: 1rem; line-height: 1.5; &:hover, &:focus { background: $grey-1; } &:active { background: $grey-2; } } }

Slide 36

Slide 36 text

//_content-actions.scss .content-actions { //[...] &__button { flex: 1 0 auto; padding: 1rem; line-height: 1.5; &:hover, &:focus { background: $grey-1; } &:active { background: $grey-2; } } } What's the effect on the base button?

Slide 37

Slide 37 text

Slide 38

Slide 38 text

This is the most flexible way to extend anything. What works

Slide 39

Slide 39 text

What really doesn't 1. The default style could be overridden in unexpected ways. 2. We are creating many variants of the original patterns.

Slide 40

Slide 40 text

- You're too tall.  - Anybody ever tell you you may be too small? Ad hoc modifiers

Slide 41

Slide 41 text

from: https://uxplanet.org/best-practices-for-modals-overlays-dialog-windows-c00c66cddd8c

Slide 42

Slide 42 text

No content

Slide 43

Slide 43 text

No content

Slide 44

Slide 44 text

No content

Slide 45

Slide 45 text

Slide 46

Slide 46 text

Slide 47

Slide 47 text

//_dialog.scss .dialog { //[...] &--register-user { width: 43.75rem; height: auto; } }

Slide 48

Slide 48 text

//_dialog.scss .dialog { //[...] &--register-user { width: 43.75rem; height: auto; } }

Slide 49

Slide 49 text

//_dialog.scss .dialog { //[...] &--wizard { width: 43.75rem; height: 35rem; } &--register-user { width: 43.75rem; height: auto; } &--save-results { width: 23.75rem; height: auto; } } How many variants do we have to account for?

Slide 50

Slide 50 text

This practice allows for flexibility, giving a reasonable control and keeping all the variants in proximity. What works

Slide 51

Slide 51 text

What really doesn't 1. The generic component style have knowledge of specific implementations. 2. The file size might be effected by unused code. 3. It doesn't scale

Slide 52

Slide 52 text

Specialised patterns I'm special

Slide 53

Slide 53 text

Slide 54

Slide 54 text

Slide 55

Slide 55 text

No content

Slide 56

Slide 56 text

//_dialog.scss .dialog { //[...] &--prompt { display: block; overflow: hidden; max-width: map-get($dialog-prompt, max-width); height: auto; margin: map-get($dialog-prompt, margin); padding: 2rem 0 0; border-radius: 3px; } }

Slide 57

Slide 57 text

Slide 58

Slide 58 text

The patterns are at the centre: no special cases, but pre-defined flavours of the basic components. What works

Slide 59

Slide 59 text

What really doesn't 1. It might drive to preemptive abstraction 2. It does account for a finite number of use cases

Slide 60

Slide 60 text

Slide 61

Slide 61 text

I still wish I could sleep A no go: it deﬁes the point of having a pattern library A code smell, it's an hack and it should be treated like one The best approach, even though sometimes Classname   injection Ad hoc modifiers Specialised patterns

Slide 62

Slide 62 text

Basically I'm stuck

Slide 63

Slide 63 text

It's not that simple “It isn’t really that simple” Alla Kholmatova · June 2015

Slide 64

Slide 64 text

The issue How do we re-use our patterns in slightly different use cases?

Slide 65

Slide 65 text

What am I trying to solve?

Slide 66

Slide 66 text

Arrangement within parent components

Slide 67

Slide 67 text

Slide 68

Slide 68 text

Slide 69

Slide 69 text

//_dialog.scss .dialog { width: 100%; height: 100%; //[...] } //_game-intent.scss .game-intent { //[...] &__dialog { width: 43.75rem; height: auto; } }

Slide 70

Slide 70 text

//_dialog.scss .dialog { width: 100%; height: 100%; //[...] } //_game-intent.scss .game-intent { //[...] &__dialog { width: 43.75rem; height: auto; } } Each component has its own responsibility

Slide 71

Slide 71 text

This practices defines responsibilities in a neat way and it enables for specific implementations without invalidating patterns. What works

Slide 72

Slide 72 text

Slide 73

Slide 73 text

What really doesn't Potentially you might need a wrapper HTML element that could have been avoided.

Slide 74

Slide 74 text

Space in relation to other components

Slide 75

Slide 75 text

Slide 76

Slide 76 text

Slide 77

Slide 77 text

It reduces the need to come up with new class names and it moves the conversation regarding component relationships back to the pattern library. What works

Slide 78

Slide 78 text

from: https://medium.com/eightshapes-llc/space-in-design-systems-188bcbae0d62

Slide 79

Slide 79 text

What really doesn't 1. The positional classes might get stale if not codified properly in the pattern lib. 2. The flexibility of the helper classes is limited

Slide 80

Slide 80 text

"Open" components

Slide 81

Slide 81 text

//_question-content-block.scss .question-content-block { //[...] &__icon-button { //[...] .icon { width: $content-block-icon-large-size; height: $content-block-icon-large-size; } }

Slide 82

Slide 82 text

//_question-content-block.scss .question-content-block { //[...] &__icon-button { //[...] .icon { width: $content-block-icon-large-size; height: $content-block-icon-large-size; } }

Slide 83

Slide 83 text

//_question-content-block.scss .question-content-block { //[...] &__icon-button { //[...] @include icon-size($content-block-icon-medium-size); } } //_icon.scss @mixin icon-size($size) { .icon { width: $size; height: $size; } }

Slide 84

Slide 84 text

Slide 85

Slide 85 text

Slide 86

Slide 86 text

Slide 87

Slide 87 text

1. Every base component can be as flexible as it defines itself to be. 2. Developers always have control on what they expose. What works

Slide 88

Slide 88 text

What really doesn't 1. This technique involves more complexity in thinking about the components 2. It's a slippery slope 3. How does an "open" component fit in the patterns?

Slide 89

Slide 89 text

Basically Does it get easier?

Slide 90

Slide 90 text

No content

Slide 91

Slide 91 text

The more you know who you are and what you want, the less you let things upset you

Slide 92

Slide 92 text

I just don't know what I'm supposed to be

Slide 93

Slide 93 text

“A common language is a first step towards communication across cultural boundaries. ” Ethan Zuckerman

Slide 94

Slide 94 text

The issue How to understand - and convey - the meaning of an exception in our patterns?