I was sick, but at least it made me rest
I am late with my weeknote again, this time because I had a bad fever over the weekend.
My temperature touched 101°F, and it didn't help that I had not been getting good sleep the entire week (which is an entirely separate problem... and not a new one).
I'm oddly grateful for the sickness though, as it forced to rest and get some sleep that my body clearly needed. I slept for nearly 20 hours over a 24h period between Monday and Tuesday afternoons.
I suppose it really wasn't that bad in the grand scheme of things. I've had much worse bouts of sickness in the past, particularly in childhood and when I was in college. Somehow, my sickness frequency has dropped drastically in recent years—most likely because I work from home now and meet fewer people.
So of course, I fell ill right after going to the office three times in one week.
Naming design tokens is a headache
Last week, I wrote about creating a new design system for work.
To create a design system, you have to start with a set of design tokens. Design tokens are essentially aliases, or variables, that you reuse across your project: colours, spacing, font-sizes, and all that.
Naturally, I found myself obsessing over something seemingly trivial: how to name the tokens.
Which is such an inane problem, when you think about it. I know what tokens I need, but I can't decide how to name them.
Should the token be called color-button-primary-bg, or button-bg-color-primary, or some other variation of it?
I should have realized it earlier, but there is no universal best way to name tokens. All major design systems (MD, Ant, Carbon, and so on) differ from each other in how they define their tokens. The only sensible approach really is just to do "whatever works for you and your team" (and then stick to it).
The good news is that the front-end team agrees that we do need a new set of design tokens because existing ones (or mostly, the lack of them) makes their job harder.
The second thing we agreed on was that we would like to use Storybook to document our design system and component library. We used Storynook my previous project and it easily saved us hundreds of hours during design and development.
Separately, I'm also working with the marketing on a brand guidelines document. (It's interesting how even multi-million dollar companies can operative, and even thrive, without something which I would have otherwise thought to be fundamental.)
Links
- The Design Sytem Guide is a genuinely great resource, and has a really cool guide on creating design systems. I only wish I had found it a week earlier, for that would have saved me some unnecessary deliberation on inconsequential decisions.
I made pad thai, should I have a recipe section on my website?
I made pad thai for the first time last week. It is an exceedingly simple recipe for how good it tastes.
The first time used wheat noodles because that's all I had. But I wanted to try it with rice noodles, so I made it a second time a couple of days later. Turned out pretty amazing both times.
I love trying new recipes. The best (by which I mean: easiest to follow) recipes tend to be on YouTube. And while YouTube is often the easiest place to learn, videos are a pain to shuffle through when you need to go back and forth between steps. Written recipes should solve this, but most recipe sites are a mess.
The recipe pages on the Bong Eats website are a joy to use, and there are a few other bakery websites which I've come across occasionally which do things well. But generally, the state of affairs is sad.
Which makes me wonder: should I start a recipe section on my website? Could be fun.
Cinema Next Door schedule for December
This one is a bit of a cheat, because this is an update from week 48, and not 47...
The licensing situation for the Cinema Next Door screenings is more or less sorted.
I've set up an account on Instagram and now need to set up the website next.
Anyway, here's the schedule:
