It's mostly about work this week, but that's OK, I've not done that for a while, and it's been very positive so why not?
Here's a few other things before we get into the work posts:
Good things
- Chris visit
- Drinks in a pub
- Replacement glasses for free
- Aubergine mozarella bake
- Strawberry milkshake
- Time alone in the loft 😀
- Journalling with my new blackwing pencil
Miscellaneous interests
- New website side project 🤫
- Fonts
- LSDJ
Design System Team work
The Design System Team's first sprint finished up, and really, there's no way it could have gone better.
A one week sprint in which we finished all our tickets, achieved the sprint goal, had enough momentum to launch us into the next sprint and everyone was super positive about the others' work and the progress we'd made collectively.
I presented my two suggestions in the Start category, had none in the stop category, and was obliged to breeze over my five or six Continues saying, basically, that we were off to a really strong start as a new team doing scrum and I hoped we could keep it up.
As we moved onto planning for the next sprint, we seemed to lose our confidence somewhat. We didn't seem capable of defining exactly what we wanted to achieve (despite my pleas for PRINCE2-like output definitions!) and we faltered somewhat.
A couple of folk started making comments that gave me the heebie-jeebies: "It would be good to see more tickets appearing in this column", "We need to go list all the things that need to be done and figure out how long each one will take"…
NO!
I launched into a speech about how we've been conditioned to treat the work as a to-do list of ticketed requirements when in fact it's a dynamic process that we're all feeding into and shaping as we go.
I couldn't have known, in the last sprint, that my techincal spike would have had such an active dialogue with Kyle's type scale investigation. Leaving ourselves that space to discover how things fit together is part of what makes this working method effective.
So yes, it does feel a bit weird to not know exactly how things are going to play out, but we need to embrace that uncertainty and trust ourselves to make the best use we can of the time. There's plenty to do and none of us will be left twiddling their thumbs.
And then everybody clapped 😜
Obviously not, but I had some heads nodding in agreement and the conversation moved on without some deferred requirement-gathering exercise being tabled, so I assume my point was well made.
Fluid type scales
I've been intrigued by fluid type for ages, but I never got the whole "music scale" thing, and I didn't know CSS clamp, and I couldn't get my head around what was actually happening and so it's never gone anywhere for me… UNTIL NOW!
Implementing the thing was the easiest part: you just stuff the custom properties (or the SCSS function that generates them) into an appropriate place in the codebase and they work as expected 😮
The hard part was knowing what to expect. The penny-drop moment for me was when I was plugging values into the utopia type calculator as placeholders: I used a major third scale for min and max viewports because we didn't know if they'd be different. Similarly, it hadn't been confirmed that on large screens we'd use a base font size of 18, so I left that as 16 for both.
Now, looking at my fontsize steps, I realised they were the same for 320px screens as for 1920px screens? Huh?
And then I realised: if we have no variation in font size and no variation in scale there's nothing for a responsive font to interpolate between. What we've generated is a static scale, and the whole point of this is that the scale's values are dynamic.
So now I understood why Kyle and I were talking at cross-purposes some of the time. He was aimed towards choosing a static scale from which values would be cherry-picked for different viewport sizes; I was working towards a dynamic scale in which the values themselves would adapt responsively to the screen size.
This led me on to the other thing I was proud of achieving this week: responsive Figma components. I've wanted to crack these for a good long while.
It was felt that with fluid type we might need multiple variants of design tokens and that managing these in the design phase would add a lot of complexity. My feeling was that this is precisely the kind of thing that modern design tooling like Figma ought to handle for us.
Sure enough, with just one evening of unpaid overtime I figured out how to create Figma variables that have different modes. Creating a type component that can be switched between modes is the next piece of the puzzle, and along the way I learned how design component variants work. Finally, setting the component to automatically inherit its mode from a parent frame results in type components that scale to the correct font size when they're used in situ.
I was riding high when I nailed all of this into place. It's made me think a lot about how this new team is exactly where I need to be in my career trajectory. Front end of frontend, but maybe equally backend of design. I'll muse on that some more — there's an article in it if someone hasn't coined that exact phrase already.
Randogram
END