7 | {paragraphTheme.maxWidth && paragraphTheme.maxWidth.map((maxWidth, m) => (
8 |
47 | ))}
48 |
9 |
45 | ))}
46 | {fontSize}px + {maxWidth}
10 |19 | Short Text Example 20 |
21 |30 | Medium length text example where it's a few lines of wrapping 31 | text but not a full paragraph. 32 |
33 |42 | Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum. 43 |
44 |
22 | 
23 |
24 | I'm here to talk about Design systems, Css, Js and of course Css in Js.
25 | And what does that look like if we as a community try to think at 10,000 feet?
26 |
27 | When I say 10,000 feet I don't just mean think abstractly. I mean actually do
28 | it. You should visualize yourself being far above something. But what is the
29 | thing? One thing I meditate on is looking at a timeline of history from very
30 | far away. And if we look at a timeline of how humans have designed and built
31 | things throughout history...how do the problems and the process in which we
32 | solve them evolve? Particularly since we started styling digital ui with css?
33 |
34 | A guy I collaborate with that goes by the name John Otander [(@johno)](https://github.com/johno) is pretty
35 | good at thinking at 10,000 feet. He comes up with *wild* ideas. Last year he decided to
36 | download the css for top million websites, in 1 month intervals, dating back to
37 | 2005 (if available).
38 |
39 | My first thought was - that's pretty neat. We can show people their css graphed
40 | out over time.
41 |
42 | 
43 |
44 | 
45 |
46 |
47 | You can learn a bunch just by analyzing your own site. *But, what does it look
48 | like to see this at 10,000 feet?*
49 |
50 | [Ask Audience]
51 | What do you think you could learn by analyzing this data? What kind of tools could you build with it?
52 |
53 | Some possibilities that come to mind for me:
54 | - Can analyze values and look for trends
55 | - Find most common property value rules for given components with common class names
56 | - Identify pattern outliers
57 | - Find common mistakes and try to build automated tools to solve them
58 | - Could overlay other data: Browser usage, timeline of introduction of various technologies (frameworks, addiitons to the spec, etc.)
59 | - We can visualize the history of design systems. We can animate them and watch how they evolve over time!
60 | - Given an array of urls, you could visualize the intersection of common values
61 | for things like: type scale, colors, background colors, font-family. This can
62 | help show how consistently your brand is implmented across a number of
63 | different front-end code bases. Most companies have different code bases
64 | for: their marketing site, their blog, their app, docs, external status
65 | page, and potentially a number of other micro sites. Having a feedback
66 | loop of common values can be helpful when trying to standardize an
67 | existing palette, or creating a feedback loop moving forward to see if you
68 | are becoming more or less consistent.
69 |
70 | [Harley Turan](https://twitter.com/hturan), scraped a bunch of data and did exactly this. Here is a collection of color
71 | palettes pulled from multiple sites that belong to the same company visualized from 2009 through 2017.
72 |
73 | 
74 |
75 | Now those are just a few half-baked ideas around what you can do to analyze static
76 | files. And I'd love to do nothing else then to sit and chat about what we can do with
77 | all of this data but that's a different story for a different time.
78 |
79 | Below is a list of css properties. I often think of css as the styling api for
80 | html. At first glance it's a lot of stuff. Especially if you're a beginner.
81 |
82 | But you can build a lot of pretty neat UI without worrying about a lot of these
83 | properties and how they work. When I am a beginner one of the most difficult
84 | things is figuring out what *to* worry about and what *not to*. I can confidently
85 | say, when styling a button, I've never needed to set caption-side. Or
86 | counter-increment, counter-reset, or volume for that matter. This doesn't mean you
87 | should never use them, but they aren't common properties attached to button
88 | styles.
89 |
90 | Can we use this pattern to potentially make front-end code more accessible for new people?
91 |
92 | Components could, essentially have all of the necessary visual styling properties
93 | exposed, where a designer can configure the values they want to pass in.
94 |
95 | Instead of a blank slate, they could discover common things to account for
96 | within different components. The pseudo state :focus would be a tough thing to
97 | intuitively account for if you've never worked on the web before. Offering it
98 | in configuration can at the very least, offer guidance around what to research.
99 |
100 |
101 | *List of Css properties*
102 | ```
103 | accelerator
104 | azimuth
105 | background
106 | background-attachment
107 | background-color
108 | background-image
109 | background-position
110 | background-position-x
111 | background-position-y
112 | background-repeat
113 | behavior
114 | border
115 | border-bottom
116 | border-bottom-color
117 | border-bottom-style
118 | border-bottom-width
119 | border-collapse
120 | border-color
121 | border-left
122 | border-left-color
123 | border-left-style
124 | border-left-width
125 | border-right
126 | border-right-color
127 | border-right-style
128 | border-right-width
129 | border-spacing
130 | border-style
131 | border-top
132 | border-top-color
133 | border-top-style
134 | border-top-width
135 | border-width
136 | bottom
137 | caption-side
138 | clear
139 | clip
140 | color
141 | content
142 | counter-increment
143 | counter-reset
144 | cue
145 | cue-after
146 | cue-before
147 | cursor
148 | direction
149 | display
150 | elevation
151 | empty-cells
152 | filter
153 | float
154 | font
155 | font-family
156 | font-size
157 | font-size-adjust
158 | font-stretch
159 | font-style
160 | font-variant
161 | font-weight
162 | height
163 | ime-mode
164 | include-source
165 | layer-background-color
166 | layer-background-image
167 | layout-flow
168 | layout-grid
169 | layout-grid-char
170 | layout-grid-char-spacing
171 | layout-grid-line
172 | layout-grid-mode
173 | layout-grid-type
174 | left
175 | letter-spacing
176 | line-break
177 | line-height
178 | list-style
179 | list-style-image
180 | list-style-position
181 | list-style-type
182 | margin
183 | margin-bottom
184 | margin-left
185 | margin-right
186 | margin-top
187 | marker-offset
188 | marks
189 | max-height
190 | max-width
191 | min-height
192 | min-width
193 | orphans
194 | outline
195 | outline-color
196 | outline-style
197 | outline-width
198 | overflow
199 | overflow-X
200 | overflow-Y
201 | padding
202 | padding-bottom
203 | padding-left
204 | padding-right
205 | padding-top
206 | page
207 | page-break-after
208 | page-break-before
209 | page-break-inside
210 | pause
211 | pause-after
212 | pause-before
213 | pitch
214 | pitch-range
215 | play-during
216 | position
217 | quotes
218 | -replace
219 | richness
220 | right
221 | ruby-align
222 | ruby-overhang
223 | ruby-position
224 | -set-link-source
225 | size
226 | speak
227 | speak-header
228 | speak-numeral
229 | speak-punctuation
230 | speech-rate
231 | stress
232 | scrollbar-arrow-color
233 | scrollbar-base-color
234 | scrollbar-dark-shadow-color
235 | scrollbar-face-color
236 | scrollbar-highlight-color
237 | scrollbar-shadow-color
238 | scrollbar-3d-light-color
239 | scrollbar-track-color
240 | table-layout
241 | text-align
242 | text-align-last
243 | text-decoration
244 | text-indent
245 | text-justify
246 | text-overflow
247 | text-shadow
248 | text-transform
249 | text-autospace
250 | text-kashida-space
251 | text-underline-position
252 | top
253 | unicode-bidi
254 | -use-link-source
255 | vertical-align
256 | visibility
257 | voice-family
258 | volume
259 | white-space
260 | widows
261 | width
262 | word-break
263 | word-spacing
264 | word-wrap
265 | writing-mode
266 | z-index
267 | zoom
268 | ```
269 |
270 | Some people [jxnblk](http://jxnblk.com) have told me that Component Styling API is a
271 | horrible name for this concept and he's likely correct. Regardless, I think the
272 | following descriptions, from a website called wikipedia, are interesting to
273 | consider.
274 |
275 | *API: Application programming interface*
276 |
277 | > "In general terms, it is a set of clearly defined methods of communication between various software components."
278 |
279 | > "By abstracting the underlying implementation and only exposing objects or actions the developer needs, an API simplifies programming."
280 |
281 | > "Thus, the design of an API attempts to provide only the tools a user would expect."
282 |
283 | [https://en.wikipedia.org/wiki/Application_programming_interface](https://en.wikipedia.org/wiki/Application_programming_interface)
284 |
285 | When I'm styling a button, I don't expect to use volume. Or page-break. Or a
286 | number of other properties. The goal though is not to eliminate options, it's
287 | to narrow focus on the essential, allowing for expansion and exploration if
288 | necessary. But this idea defining a component API has benefits extending beyond
289 | this.
290 |
291 | The most influential tip on how to think about designing a component I've ever
292 | seen is from Nicole Sullivan's excellent article [The media object saves
293 | hundreds of lines of
294 | code](http://www.stubbornella.org/content/2010/06/25/the-media-object-saves-hundreds-of-lines-of-code/)
295 |
296 | > "When I’m building a new object, the first thing I do is to figure out which parts are reusable components, and define what I know and do not know about them."
297 | > "For example: Can be nested, Optional right button, Must clearfix"
298 | - [Nicole Sullivan](http://stubbornella.org)
299 |
300 | I can't recommend this process for designing and developing components enough.
301 | One of the things I like about react and css in js, is that it's easy to work
302 | within this mental model. It's helpful to actively think and sketch out what
303 | you know and what you don't know. This can help you build components that are
304 | more resiliant, flexible, and reusable.
305 |
306 | So, say we defined some scales, or options to work with for the following
307 | properties.
308 |
309 | #### Typography
310 | - Font-family
311 | - Line-height
312 | - Type-scale
313 | - Measure (max line length)
314 | - Font Weights
315 | - Text Transform
316 |
317 | #### Layout
318 | - Spacing
319 | - Width
320 |
321 | #### Theme
322 | - Colors
323 | - Border Widths
324 | - Border Colors
325 | - Border Radii
326 | - Box Shadows
327 |
328 | #### Motion
329 | - Animation speed
330 | - Easing Functions
331 | - Movement patterns
332 |
333 | Maybe this would look something like this
334 |
335 | ```
336 | const theme = {
337 | breakpoints: [
338 | 36, 48, 64
339 | ],
340 | fontFamily:[ '"Gotham", "Avenir Next", "Proxima Nova", "Helvetica"' ],
341 | fontSize: [
342 | 12, 14, 16, 20, 24, 32, 48, 64, 96, 128
343 | ],
344 | fontWeight: [ 400, 600, 700 ],
345 | lineHeight: [ 1, 1.25, 1.5 ],
346 | colors: [
347 | { text: "#000", bg: "#fff" },
348 | { text: "#374047", bg: "#f8f9f9" },
349 | { text: "#7f8a93", bg: "#f8f9f9" },
350 | { text: "#0077cc", bg: "#f8f9f9" },
351 | { text: "#005da0", bg: "#f8f9f9" },
352 | { text: "#00365d", bg: "#f8f9f9" },
353 | { text: "#00a243", bg: "#fff" },
354 | ],
355 | borderStyle: [
356 | 'solid',
357 | 'double',
358 | 'dotted'
359 | ],
360 | borderWidth: [ 0, 1, 2, 4 ],
361 | borderDirection: [
362 | 'all',
363 | 'top',
364 | 'bottom'
365 | ],
366 | radii: [
367 | 0, 3, 5, 17, 9999
368 | ],
369 | space: [
370 | 0, 2, 4, 8, 16, 32, 64, 128, 256, 512
371 | ],
372 | measure: [ '20em', '30em', '34em' ],
373 | boxShadow: [ '0 0 16px rgba(0,0,0,.2)' ],
374 | }
375 |
376 | export default theme
377 | ```
378 |
379 | Some of you might have already seen a file like this before. Maybe it was a js
380 | file, maybe it was a sass, less, or stylus file. This is pretty boring and
381 | there isn't anything new about it. It's just a theme.
382 |
383 | Thinking about the previous quote by Nicole Sullivan... What if I had to
384 | design a button and I wanted it to use values from our design system. We could
385 | define the styling API for a button. (People love buttons.) Potentially, we
386 | could define a template for a button styling API. So we'd need to think about
387 | which properties we *always* want exposed. I think it's safe to say that people
388 | should be able to set the background color on a button. The default color isn't
389 | perfect or anything. It's reasonable for a well designed interface to have buttons with
390 | different background colors. As a section in the button API we'd also want to
391 | declare which properties should be available to style on hover. I believe it's reasonable
392 | to change the background color on hover. So I think that should also be a part of the
393 | API. Returning to the base part of the button API, it would be seemingly
394 | reasonable to be able to set the font-weight to something other than the
395 | default. In all my years of browsing the web I've never hovered on a button and
396 | seen the font-weight change and thought "This is so nice." My first thought is
397 | generally "Well this must be a bug." So here we could choose to leave font-weight out of
398 | the hover, focus, and active sections in the API.
399 |
400 | A generic template for a button styling API might look like this:
401 |
402 | ```
403 | import theme from './theme'
404 |
405 | const buttonThemeTemplate = {
406 |
407 | // Typography
408 | fontFamily: [ ],
409 | fontSize: [ ],
410 | fontWeight: [ ],
411 | textTransform: [ ],
412 |
413 | // Palette
414 | colors: [ ],
415 | backgroundColors: [ ],
416 |
417 | // Borders
418 | borderColors: [ ]
419 | borderRadius: [ ],
420 | borderStyle: [ ],
421 | borderWidth: [ ],
422 | borderDirections: [ ],
423 |
424 | // Spacing
425 | paddingTop: [],
426 | paddingLeft: [],
427 | paddingBottom: [],
428 | paddingRight: [],
429 |
430 | // Hover states
431 | hoverColor: [ ],
432 | hoverBg: [ ],
433 | hoverBoxShadow: [ ],
434 | hoverBorderColor: [ ],
435 | hoverSize: [ ],
436 |
437 | // Focus states
438 | focusColor: [ ],
439 | focusBg: [ ],
440 | focusBorderColor: [ ],
441 | focusBoxShadow: [ ],
442 | focusSize: [ ],
443 |
444 | // Focus states
445 | activeColor: [ ],
446 | activeBg: [ ],
447 | activeBorderColor: [ ],
448 | activeBoxShadow: [ ],
449 | activeSize: [ ],
450 |
451 | transitionProperty: [ ],
452 | transitionDuration: [ ],
453 | transitionTimingFunction: [ ],
454 | }
455 |
456 | export default buttonThemeTemplate
457 | ```
458 |
459 | Then we could define what values we want to pass in. We might pass in an entire
460 | array, declare literal values, pass in a filtered array. We have javascript. We
461 | can do whatever we want!
462 |
463 | ```
464 | import theme from './theme'
465 |
466 | const buttonTheme = {
467 | radii: theme.radii, // Entire scale
468 | space: [
469 | // Explicit steps from the scale
470 | theme.space[3],
471 | theme.space[4],
472 | ],
473 | fontSize: theme.fontSize.slice(0,-8), // Everything but the last 8 steps in the scale
474 | fontFamily: theme.fontFamily[0], // An explicit step in the scale
475 | borderStyle: [
476 | theme.borderStyle[0],
477 | theme.borderStyle[1]
478 | ],
479 | borderWidth: theme.borderWidth,
480 | fontWeight: theme.fontWeight,
481 | colors: theme.colors,
482 | backgroundColors: theme.colors,
483 |
484 | // hover, focus, active states
485 |
486 | hoverColor: [
487 | theme.colors[0].text,
488 | theme.colors[1].text
489 | ],
490 | hoverBgColor: [
491 | theme.colors[0].bg,
492 | theme.colors[0].bg
493 | ],
494 | focusColor: [
495 | theme.colors[1].text,
496 | theme.colors[1].bg
497 | ],
498 | textTransform: ['uppercase', 'capitalized'],
499 | transitionProperty: ['opacity', 'color', 'background-color'],
500 | transitionDuration: ['.25s'],
501 | transitionTimingFunction: ['ease-out'],
502 | }
503 |
504 | export default buttonTheme
505 | ```
506 |
507 | As a design community, we could make boilerplate config files for common ui components.
508 | Over time we could reinvent fewer and fewer wheels. This would allow us to go deeper on
509 | other areas that haven't been explored as much as button styles.
510 |
511 | This is where I think it gets *really* interesting.
512 |
513 | Now we have a system.
514 | We can use combinational logic to generate all possible combinations of buttons
515 | given the input provided by a theme file. We could also use this pattern to
516 | create a finite state machine, and visualize transitions between any discrete
517 | state a given component can be in.
518 |
519 | A simple config file like this generates thousands and thousands of button designs.
520 | Here is an example of generating avatars and buttons.
521 |
522 | https://examples-jchwaftrgo.now.sh
523 |
524 | Or we can make this a finite state machine and animate between the options. You
525 | know, if you don't like scrolling for days and days and days. (Again, animation
526 | created & provided by the one and only Harley Turan).
527 |
528 | https://examples-wrjcynrjhj.now.sh
529 |
530 | *Let's step back and think at ten thousand feet again.*
531 |
532 | - We can show how many options a design system can generate. This can be
533 | helpful because some people feel they might be constrained by working with
534 | defined scales. This can help show how varied their visual designs can still
535 | be. A lot of people still haven't worked with scales and as a creative person
536 | constraint can be scary at first.
537 | - We can quickly identify desirable regions, which can help us quickly discover
538 | patterns of inputs needed for a desired output. This can expose properties
539 | you might want to couple together and set rules for. Sense of proportion can
540 | change dramatically at each end of the scale.
541 | - Could automatically a/b test design options with real user metrics
542 | - Wire up options to an interface that allows for collaborative voting on which
543 | component variations feel most on brand. You could even hook this voting up
544 | to a neural network.
545 | - One of if not the most difficult part about image classification is coming up with the training data.
546 | The generated data could help train an image classifier which will in turn
547 | help audit existing UI on websites. Imagine being able to input a url and
548 | query the design with questions lke:
549 | - "Show me all of the buttons."
550 | - "Show me all of the orange buttons."
551 | - "Show me all of the buttons that have inaccessible color combinations."
552 |
553 | This is an exciting reality to live in. We can more quickly generate lots of design
554 | options to test with real users. We can shorten the feedback loop around discovering
555 | what matters and what doesn't. This is a stark contrast to our current reality, which is that
556 | most designs we ship have not been validated with real users. We don't design multiple options in
557 | parallel. We end up designing a single option that is optimized for getting stakeholder signoff in a series
558 | of status meetings.
559 |
560 | But at the very least this concept is exciting to me because I'm very lazy and
561 | I don't want to design buttons anymore.
562 |
--------------------------------------------------------------------------------
/examples/README.md:
--------------------------------------------------------------------------------
1 | This project was bootstrapped with [Create React App](https://github.com/facebookincubator/create-react-app).
2 |
3 | Below you will find some information on how to perform common tasks.