There were 4 major announcements at this year's Config that impact past advice I've published in blog posts:
As I was processing my notes, I realized a handful of the 22 blog posts I've published could be considered "stale" now that we have these new features available to us. 7 of my posts cover topics that probably ought to mention the features above given their subject matter. I have yet to do a close reading of any of these, but based on their titles alone I can remember the main points and how variables, wrapping auto layout, min and max width controls, and prototyping updates will affect them. Here's some early thoughts on how they will need to be updated:
With Dev Mode comes the ability to mark sections as "ready for dev", using a dedicated flag or button next to the section title. But the way this was demo'd at Config was in the context of a local file, and not a component library. I will need to do some research to see how this small but mighty feature works in that different context.
I have a hunch that variables combined with auto layout wrapping could make this use case for zero frames obsolete. Heck, it could make zero-frames obsolete!
If that ends up being the case, I'll need to decide how I might want to "flag" that on that old post... Perhaps this is a sign that I need a sort of "compost bin" or "graveyard" for posts that go the way of all things due to new features coming out.
I recall a few sections of this post involve activities for reducing the number of variants in a set. Variables will no doubt have a positive impact on this area, so I need to fold that information in.
My argument in this post is that auto layout is hard to learn because it is hard to iron out wrinkles. If you don't know what I mean by that, read the post (it's a bit much to explain here).
Without a doubt, the new minimum and maximum width controls and wrapping are great. But they're going to cause even more wrinkles than before. I want to account for this in my advice so folks can confidently and successfully iron their frames out.
✅ Updated August 12, 2023
Pre-variants I had a handful of small examples that described using variants for certain uses, such as managing attributes like "size":
If you're handling breakpoint with variants, make sure it's always called "Breakpoint" and not "Device" or "Size."
Now that we have variables, I'd recommend using variables for things like that. I combed through the post and either updated these with a modern example or eliminated them entirely. Additionally, under Quality 2: Make common modifications are accessible from the component's top layer, I had an example of how I'd use variants to manage a ◈ Star rating component. But now with features like component swap properties, there's a whole different property setup available!
The percentage makes that sound like a ton of visuals, but the first post had 2 visuals and the updated version has 5. I did this because as I was re-reading the post, I realized it's one of my headier ones. Adding more visuals should make it easier to illustrate important points.
✅ Updated July 19, 2023
I used to have a huge section in this post titled "Things you could use either separate components or variants for." But I didn't want to leave people hanging at a fork in the road with no guidance.
The issue was that making those decisions was tough! There were a lot of factors you had to weigh: How big is your team? What plan are you on? How many variants are in your component set? How sensitive are you to lag and performance issues?
I suspect while this was helpful food for thought, it was still a LOT for any one person to navigate.
That section is * poof * ... gone. All thanks to two things:
The same sub-sections are still relevant, but they’ve all moved into sections that start with “Always use…” And I don’t take “always” lightly.
I touched on what strategies we had to use before certain features were released, but in a way that wasn't very organized or scannable.
Now that we're 3 features deep (variants, component properties, and now variables) on this topic, I wanted to offer a more structural timeline using headings.
I had only ever updated this post once in December 2022 (11 months after initially publishing it for the first time), and at the time I felt the "Updated on" timestamp at the top was sufficient. And that update wasn't nearly as big as this one, I was mostly just adding the section "Always use component properties" because that feature had recently come out.
At the verrrrry end of the post I have a brand new change log that will summarize every update I make to this post going forward. I'll probably do this for any post that gets updated 3 or more times.
I also will have links to old versions (thanks Wayback Machine!) for anyone who wants to compare to the latest.
This is another one for the graveyard / compost bin. With variables, there's no need to use variants for a property like "size."
The better method is to create some number variables and use those for padding. Then make sure min and max width are dialed in. Hopefully it's that simple!
It will take me a bit of time to do it, especially for some of those posts that are longer, but I hope to have these all spruced up <s>before the end of the year</s> in 2024. Originally my plan was "before the end of the year" but I took on a teaching job that I need all my spare time for until the semester ends in December. If you'd like to know exactly when I publish updates to the posts above you can do so here:
<a href="https://alicepackard.ck.page/1287055e65" class="button primary" style="padding:16px,0px; margin:auto; border-bottom:0px solid">Select blog posts to get updates on</a>
And something you could do that would be hugely helpful is to email me with questions about these topics and Figma's new features! I want these updated posts to be as helpful as possible, so anything that has you not feeling confident is something I want to know about.
If you'd like to be notified of when I publish a new blog post, joining my newsletter is a great way to keep up. Readers get extra insight behind every post.