Short session
- Deleted and old version of the tabs component. Misc cleanup
- Moved some stuff out of the 'Core Components' frame
I need to restructure this file…
When I started it last March, it made sense to break up the master components into different pages, but also keep copies of everything in like an index page so people could see everything at once.
Since then, new features have shipped and this structure isn’t super necessary. So right now this file is almost twice as large as it needs to be. I need to move the masters to the main page and delete all the copies
It’s also become clearer that the ideal way to use this file is to grab only the component or handful of components you need, move them over to your file or design system, then change them to fit your context.
Copying the entire file and restyling it is definitely not the move.
…
As for ‘real' work done today, I just deleted a bunch of stuff and styles.
4
Misc. thoughts
I think I’m going to separate type styles into two groups
- Standard type sizes
- Specific roles e.g. 'table header'
I should have 1 or two standard line-heights. Then clamp things down to a multiple of eight. This is what Figma does in UI2.
I’m using Inter for everything, so I’ll use it’s tool to get the right tracking
Got an early start but still managed to procrastinate. Getting familiar with a plugin called Smart Text that makes documenting things way easier
3
Working on shadows next. This shouldn’t take long. I’m only gonna make 4 levels, 3 of which have already have specific role. And they’re not super complicated or layered.
I think a good shadow is made of 2 shadows
1. A small one to define/outline the shape
2. And a larger, softer one that that has an offset to create some depth
I think the main challenge here is: making it easy for someone to adjust and add steps. I think I could write some simple rules/instructions for doing this manually, then write a script later.
I wrote a script a while back to batch change the color of shadows. I should add to this…
A solid hour of working on color. The process is a little frustrating. The tools are so much better than they were a few years ago but… even with all the tools I’ve chained together, including the modest ones I’ve made, I still feel like I’m moving at a tenth of the speed and 90% of what I’m doing is busy work a computer should be handling
1
Revising colors…
Trying to get the entire process in the screenshot, so this isn’t what it actually looks like, =
1. Set the general feeling in ColorBox
2. Use Leonardo to get colors at the exact contrast ratios
3. Add the colors to Figma
4. Create color styles and test
Color is the first thing I need to tackle when I get large blocks of time to work on DSSK
Another short day:
1. Updated some icons across the project that got their color overrides lost when I outlined the icons a few days ago
2. Turned misc non-components into component instances with the Master plugin
Okay, keeping these icons as strokes was a mistake, even though I flattened each icon to a single vector/layer. Wrote a tiny script to outline the strokes in bulk.
They’re a nice set of icons
Trying to put together color scales bu starting with these required contact ratios and building around them. I’m using this tool called Leonardo to place some steps between the bottom of the range ~1.05 and the first required contrast ratio. Not sure how the tool is doing this or what the pattern here is, but I’ll use it for now. then maybe reference some other color scales
- AAA Normal Text (7:1)
- AA Normal Text (4.5:1),
- AA graphics and ui components (3.1)
Slowly resuming writing and designing the website.
There’s a baseline grid, but aligning to them like you would in print isn’t really feasible. They’re still useful for getting a vertical rhythm though. Make the line-height (24px) a multiple of the baseline (8px), then make the spaces between stuff a multiple of the line-height. (48, 96, etc.)
More date picker improvements
At the moment, the date shortcuts are buttons. You click on a shortcut, then it selects the date(s) and closes the calendar. Thinking these should be tabs instead. You click on a shortcut to select the date(s), but instead of closing the calendar the tab becomes active.
Covers
(Draft)
After the first release, this’ll continue being an ongoing project. I see it slowing down, but never actually ending. I like the idea of having a different cover (e.g.) every month. They’d be a fun way to denote when a particular version of the file is from, and they’d be the one part of this project where utility isn’t a concern.
For the first year or so, I’ll use colorways of the “cubes” cover. They’re pretty easy to make:
1. Choose a background color.
2. Make the line-work cubes the background color, but change the blend mode to ‘Multiply’
The hard part’s choosing the background colors. I don’t want them to be arbitrary. They should relate to the project, even if only tenuously.
Because it’s what I prefer, and because it’s what we use at work, this project is, and will ultimately be, a Figma file. That’s a good place to start. I think it would be cool to pull colors from the UI before moving on to more obvious colors, or more esoteric colors.
I think I’ve settled on the first four colors/covers:
1. #00a1ff (Blue), from the selection bound of a regular object/layer
2. #7b61ff (Purple), from the selection bounds of a variant or component
3. #e249af (Pink), from the smart selection overlays
4. #e5e5e5 (Light gray), from the default canvas background
I’m still slowly turning components into variants…
I need to speed things up a bit. I’m presenting at a side project showcase zoom call and, although my presentation’s more about the process (work on it every day for ~30 days; post to FL), it would be good to have something ‘complete’ and shareable
More importantly, the sooner I can get his in front of people that can test it and give me feed back the better
Next steps
- Wrap up the transition to variants
- Make v1 of the color system and styles
- Add auto layout v3 features wherever it makes sense. (Auto layout v3 should be launching this month)
- Writ a ToC and readme
- Throw together a website, which will probably just be loose port of the ToC and readme
- Publish the file to the Community
So here’s an instance where some things don’t slot perfectly into variants.
I have 2 properties: Day and Selected. Toggling Selected on, changes the Day property to Selected Day. Changing the Day property to anything other than Selected Day toggles the Selected property off
Nothing’s broken, but this doesn’t feel quite right.
ColorBox by Lyft Design
Colorbox is a color tool to produce color sets.
Wondering about color…
Required contrast ratios
- Graphics & UI: 3.0
- AA: 4.5
- AAA: 7.0
Non-critical elements
- Very light background: 1.06
- Keyline: 1.11
- Light background: 1.2
- Darker border 1.6
Base/bg colors
- #FFF
- Very light bg
- Light bg
Color Scales
- Text
- Main color
- Info
- Positive
- Caution
- Critical
- Promote
Tools
- Colorbox to create the general feeling
- Leonardo to set the final colors using the hexes brought in from Colorbox
The kbd tag
Tangentially related scripts
Glued together the "Batch Create/Update Local Styles" script and the "Color Stepper" script.
Batch Delete (Local) Color Styles
let node = figma.currentPage.selection[0]
let nodes = figma.currentPage.selection
nodes.forEach (node => {
let localPaints = figma.getLocalPaintStyles()
localPaints.forEach (localPaint => {
if(localPaint.name === node.name){
localPaint.remove()
}
})
})
Keep writing the description
A Figma-first component library to kickstart or supplement design system projects.
The starter kit should be
- Minimal
- Flexible
- Systematic
Concrete goals
- Compact layer lists and layer names
- Don’t use the layer list to change state
- Build for instance swapping
- Use pages and frames to create related instances
- Use the tool—not shared context—to enforce convention
- Auto Layout, guides, text cse
- Create a library, not a framework. More context
Write the description
DSSK is a Figma-first component library to start or supplement
Concrete goals
- Compact layer lists and layer names
- Build for instance swapping
- Use the tool—not shared context—to enforce convention
- Create a library, not a framework. More context
Idea: composer
- Dragging components onto the canvas is slow
- Making a component for every common grouping isn’t a good solution
Something like Emmet for placing and nesting components
vstack width320
h3
field name
field email
button.primary
hstack 0 0 8
tag "design"
tag "code"
tag "books"
Shadows
Problem: editing shadows is a drag, especially if the shadow style contains multiple shadows
// Set shadow colors
let node = figma.currentPage.selection[0]
let nodes = figma.currentPage.selection
function clone(val) {
return JSON.parse(JSON.stringify(val))
}
const baseColor = findOne (swatch =>
swatch.name === "shadowColor"
)
nodes.forEach (node => {
let newEffects = clone(node.effects)
newEffects.forEach (effect => {
effect.color.r = baseColor.fills[0].color.r
effect.color.g = baseColor.fills[0].color.g
effect.color.b = baseColor.fills[0].color.b
})
node.effects = newEffects
})
Hello world
More background on the project as a whole later
For now here are some buttons I’ve been slowly working on.
Things to consider
- How to best use Auto Layout
- What to name the components themselves—and how to these names affect instance swapping when people finally start using it… Who will use it and for what
- What to name the layers inside
