Matthew P Munger: Welcome to the restock podcast by no code supply Co where we highlight people and the things they build. I'm Matthew P monger. Corey Moen: I'm Corey Moen, what's up y'all? Matthew P Munger: And today we have a special guest with us. have Alessia. Hi, Alessia. Corey Moen: Woohoo! Alessia Sannazzaro: Hi everyone, thanks for having me. Matthew P Munger: Alessia is here because she has recently built something ⁓ her team called Blocks. It is a component first framework. And here to talk about that today. So Alessia, what is Blocks? Why is it named Blocks? And kind how did it originate? Alessia Sannazzaro: So first of all, I'm terrible at naming things. Thank you. Blocks comes from building blocks. So it's basically building blocks that you put together, slot inside each other, and that creates the component framework. So that's kind of where the name came from. not the best name, but that's what stuck. So there it is. ⁓ Corey Moen: I like the name for what it's worth. Matthew P Munger: No, it's good. Corey Moen: love it. It says everything it needs to, especially for others that want to use it or even pitch it into clients, all that, for sure. So great. Matthew P Munger: And it also, I think it also leans in a little bit to obviously HTML. It is a block based box model, right? It's blocks. ⁓ I think it of leans into that as well, which is nice. Alessia Sannazzaro: I feel like that. Corey Moen: Yeah, yeah. Alessia Sannazzaro: And I feel like components, they're like the word components is used for so many things. If you look at Reboot, they have components, but they're not actual Webflow components. And when talking to clients, to keep the jargon to a minimum, we usually just call it like building blocks or like, oh, drag these sections or blocks together. So that's kind of where it came from. Matthew P Munger: Yeah. So it kind of came naturally out of how you were talking with clients anyway, already. Corey Moen: Hmm. Alessia Sannazzaro: Yes. ⁓ And then we didn't name it and it stayed blocked. Corey Moen: Love that. Matthew P Munger: find that is often like a good way to name things is kind of just don't name it and just see how people talk about it and like things will naturally emerge like whether it's you know verbs adjectives or just like an actual name noun but yeah. Corey Moen: To that point, I'm curious with clients, has that gone? Having blocks, is that part of your pitch, if you will? Or do you find that including that or since using that or maybe even anything in the past, does that help ⁓ clients excited, convince them of the value, help them see the picture of how they'll manage the site, that kind of thing? Yeah, tell us about that. ⁓ Alessia Sannazzaro: Yeah. And also we like, um, stepping a little bit back from that, uh, we saw a shift. So before, when talking to clients, I don't know, five years ago, they didn't really care about design systems. Uh, they were like, Oh no, we want a site. We want it on brand. Um, you know, they, were used to the dev team managing the site. So they weren't really used to knowing the benefits of a design system. And. Corey Moen: Hmm. Alessia Sannazzaro: think it was in the past maybe one or two years that we saw this shift that all of a sudden marketing teams asked for a design system and for something that it's scalable, that they can ⁓ around ⁓ themselves or something that they can build with while on brand and consistent throughout the site. So that's also a shift that we took to make sure that it was ⁓ Corey Moen: Hmm. Alessia Sannazzaro: client friendly so that they could play around within the limitations, within the constraints of the design system and the brand something that they could use. So that shift became ask from the client. ⁓ Cause I think like we always have this conversation about open components, closed components, open components, find them a lot more. Corey Moen: Mm. Alessia Sannazzaro: Flexible, personally they're my favorite because I can play around with them. I can create lots of different layouts and not necessarily having to create each section or like kind of layout in there. But a certain, maybe less technical clients, they're like, no, no, I just want to drag and drop things. So it always becomes a bit of a mix of the two where maybe the open components are used by... Corey Moen: Yeah. Hmm. Mm-hmm. Alessia Sannazzaro: developers or more tech savvy marketing teams and then from that creating close components for maybe the less tech savvy teams that they won't just want speed and dragging and dropping components in. Corey Moen: you Yeah. Matthew P Munger: They want more of that kind of Squarespace blocks. I think they do call it blocks. They're elements. Kind of experience, you know, where it is that simple and it's like the creativity is within the bounds of ⁓ defined properties within that block. Corey Moen: Mm-hmm. interesting too when you say seeing the shift because what that made me think of too is if you all, mean, ⁓ I know Alessi, you've done this for a long time. Matthew and I also been in and out around the community for a long time. And I remember five, six, seven years ago, was like client experience and pitching was so different in the way of we just had like lot of people didn't even know of Webflow. So they'd reach out and just they need a website. And then ⁓ It seems like in the last few years that shifted to where like, they know they want to use Webflow. Now they're trying to find the best partner. And so then now there's this next step of what you just said that feels like the next layer on top of that. They know they want Webflow, but they also know that they want to use Webflow in a way either that's using the latest features or in a way that maybe they've seen others posting about or their friends using it or something like that that is very module and more self-serve than the past. Which I think is so fascinating. And I think what's interesting is in the same realm, did you, also said the term client first, which made me think of like, OG client first framework, know, here there on preference of using it. I think it's still, it was one of the first and we all owe that inspiration. But I think what's interesting is seeing how that has even changed in the Webflow community, right? To where like a framework used to be so much more emphasized on like, Alessia Sannazzaro: Yes. Matthew P Munger: That's Corey Moen: how we're using classes and divs and just straight up dev workflow. Didn't really have any correlation to clients other than the original client first name and inspiration was like, maybe we can teach clients how to use classes and like, let's be super real. I don't know that I've ever heard that go well ⁓ hopefully your client is technical. And so to your point, like how has your own team and your devs thought about that evolution too? You know what I mean? Like, ⁓ or that come up? Alessia Sannazzaro: Yeah. Corey Moen: in terms of when you're standing up a site for a client thinking about not just classes and semantic HTML structure, but then how it translates to components and do your devs actually find it faster and ⁓ to use components to build at least certain layouts and stuff? Alessia Sannazzaro: Yes, 100%. I think it takes a bit longer to create all the components, especially if you create them specifically for that client. And that's where Blocks came about. It's kind of a boilerplate. It's by no means the end result. It's just the components that we find reusing on all of our sites and rebuilding them all would take a very long time. So having that... Corey Moen: Hmm Alessia Sannazzaro: base that then you can build on top. I find, yeah, components have their own limitations as well as we all know. And of making sure that you look at the full design and really plan how everything is going to slot together or be merged together into one component, whichever direction you want to go to. That takes a bit more time. Corey Moen: Yeah. Alessia Sannazzaro: in my opinion, but then once that foundation is set up, it's so much quicker. And we heard that not just from the developers, but also from the clients that have been using it. And yeah, they can spin up campaign pages ⁓ a day ⁓ worrying about the design because everything it's on brand and yeah, just focus on launching and getting those customers in. Corey Moen: you Love that. Matthew P Munger: Yeah, I think it's interesting, Corey, what you're mentioning about that transition we're trying to sell clients ⁓ using Webflow to them. Now they to use Webflow ⁓ from beginning. And so now what you're actually selling is how you use Webflow and how you implement it for them and ⁓ what of tool you have in your agency bag ⁓ to them be successful. Corey Moen: Totally. Alessia Sannazzaro: Yeah, because there's so many ways you can build in Webflow, right? There's nothing wrong to not use components at all. It's perfectly fine. It's just what you want the outcome to be for the client and the experience the client to be. Corey Moen: Mm-hmm. Yeah. I think that part is key. And you already kind of alluded to this, that the other thing I see, especially from like Webflow designer devs learning and newer in the community is sometimes they see frameworks like a template where it's like, it's everything pre-built. All you have to do is just change some settings and ⁓ you're And it works for every possible client. It's like, no, no, no, no, no, no, not the point. It is what you said. It is a starting point. It is a foundation to build upon. Matthew P Munger: Yeah. Alessia Sannazzaro: You Corey Moen: But you really need to be in tune with what your client's technical ability and preference is on whether or not things should be more closed components or open components. For anybody listening to you on that, the main difference there, if you're getting into Webflow is, Alessi, you also said it, is like there's this concept of component slots where you can put components in the slot of another component. and open component frameworks are heavily lean into that. And so you are very easily able to mix things around and mix and match and adjust layouts entirely from components. Whereas closed is like, as the name kind of applies, everything is kind of just locked on a single layer. The only thing you can edit in a component is like specific properties, like title, subtitle, and button, text, and link or something, for example, which are great and easier arguably to use for certain less technical clients. But I think I'm curious too, because even to that point, have you had any client experiences in that where even if they aren't technical, the of slots, especially I think blocks take such a nice approach to this where the use of variance to adjust things is very intuitive, I would say, and there's not a ton to learn, right? As long as they understand some of the fundamentals and realize they can copy and paste entire groups of components. ⁓ Matthew P Munger: Okay, yeah. I'm ready. Corey Moen: How has that gone? Have you had any client or even dev experiences that gotten the hang of it, even though it felt like a little more intimidating at first than closed components? ⁓ Alessia Sannazzaro: Yeah, so with all of our clients, we always do a discovery session where we show them the two approaches or even a mix of the two and see what they would like most and what would work for their workflow and how they want to edit things. ⁓ think the reason ⁓ personally prefer open components is because a lot of the time, Corey Moen: Hmm. Alessia Sannazzaro: Well, it happened both ways. some clients are like, no, we want everything close so we can drag and drop things that lot easier. And then they start doing that and they're like, but a lot of the sections look similar. lot of the pages look similar. So we want more variation of that. And so you go down the variant route of, know, if the purpose of that section is the same, but just different variation of the layout, for example, you create new variants. ⁓ ⁓ or you end up creating a lot more components like section closed components there. And then, you you to annotate how you name things because then they need to learn what to use where. So they both kind of their pros and cons. ⁓ I've like the blocks has actually been inspired from a client, a that we ⁓ Corey Moen: Mm. Alessia Sannazzaro: worked on on their site and they had hundreds of pages and they never wanted, well, they have a few repetition, but they wanted to be quite in all the layouts that they had on every single page. didn't want ⁓ pages to feel the same or like, ⁓ it was repeating a lot. ⁓ ⁓ exactly. Corey Moen: Good evening. Matthew P Munger: Right. They don't want that template. The page template feel, yeah. Alessia Sannazzaro: So that's where it of sparked, it gave me those kind of constraints of like, okay, we need something that is super flexible, but that the client can use without being too technical. And at this time, it was actually before variants. It was when Webflow just introduced slots. So it was a, I think we still. named it Blocks internally, but it was kind of like a pre version of where Blocks is now where instead of the variants, you just had a bit of text and you had to enter the class name for it to whatever you wanted to do ⁓ ⁓ that CSS. And had, ⁓ I I presented it to the client and the client was super happy at the time because it kind of did what. Corey Moen: Hmm. Alessia Sannazzaro: they needed to do and I was speaking to their developers and they created this huge like cheat sheet with all the class names. They basically printed it out and every time they wanted to make changes, they were like, okay, I'm editing this and this is the class I want and then typing it in. that was the biggest friction I found and the biggest problem. Matthew P Munger: That's what I was going to say. You need a teacher. And that's the monitor. They were probably excited in the moment because it was very freeing, know, it's like, you know, empowering to them. But then it's like, ⁓ but now I have to keep doing this again and again. Yeah. Alessia Sannazzaro: Exactly. But then they were like, ⁓ all these classes. Corey Moen: Yeah. Alessia Sannazzaro: How can I remember them all and say a framework or a design system, I feel like only works if it gets adopted. So if that friction is. Corey Moen: Mm. Mm. Matthew P Munger: Exactly. Yeah, what do call a design system that hasn't been adopted? Alessia Sannazzaro: Yeah. Matthew P Munger: I feel like that's like the start of a joke or something, but I'm like, don't know the punch line, but there is one. Corey Moen: I don't know what the... Yeah, I don't know a name, it's a real thing. Like that absolutely happens. Yes. And I guess experience of that circumstance is it's usually the first signal that a refresh is going to come sooner than later. You know, cause like people just can't use ⁓ site that isn't totally. Yes. ⁓ Or it just starts creating technical debt really, really fast. Alessia Sannazzaro: Yeah Matthew P Munger: Yeah, it's pain. It's painful. That's a lot of wasted. Hmm. So you should stop investing in the design system that's not working. Corey Moen: in the site, like some of the past freelance clients that I worked with, it was always wild to see like the state of their site, their Webflow site before we would rebuild it. And was usually from exactly that. They started from a template or maybe had some other team build it, but then stop working with them and still just try to ⁓ manage themselves. And so there's all these duplicate classes and broken layouts and just like, ⁓ a mess. I think what's funny is in a similar way, even to the point of ⁓ that you're saying and adding this like class props and all that, I've also noticed in the community that like that was a lot of the first attempt at some of this. And ⁓ the great was that you still had the high flexibility ⁓ of using and adding and removing them, but it created a layer of safety where you no longer have the risks of like the client first days where it's like you just go edit the global container and not realize it. The non-technical person gets into the designer and they're just like, no, I just want more spacing at the top of this container or whatever. I'm just gonna drag the padding and not think twice and publish. And so at least... Matthew P Munger: Right, because we're using utility classes to do that. Alessia Sannazzaro: And then all of a sudden, all of the pages have a massive bang in there. Corey Moen: ⁓ yes, ⁓ yes. And they're like, what happened? And then what's interesting is, yeah, what's interesting is that in that, I don't know if you all have felt this as well, it only takes a couple of those times to happen where then it stirs a fear in your collaborators. And that is a hard thing to then overcome. And then they end up starting to recede and then just always asking for help with the simplest updates, which is never the goal. And so I think just the layer of safety that components creates is so valuable. And even when you're using an open framework that is more flexible and all that, there's still only so many things they can do that would really break a layout. even then, it's usually very simple to fix. It's not something that they can accidentally globally alter. So yeah, don't know where I'm going in that other than like... Alessia Sannazzaro: you Corey Moen: I guess I'm very grateful that there are enough feature support with components in Webflow now. And we've developed as a community frameworks like Blocks and Mast and Lumos and all that that are creating more and more and more of the safety for people to confidently go and make edits and publish. Because isn't that like just the ironic thing is like of all the fancy features in Webflow and other website tools, oftentimes the scariest part or the hardest part is just to get our clients OK. ⁓ and confident with just clicking publish. You know what I mean? Like it's so ironic. Alessia Sannazzaro: Yeah. Matthew P Munger: Yeah. Cause that, that, that's the superpower, but it's also like, it's a superpower and it can be, ⁓ wielded, not necessarily dangerously, but you know, there, there, there can be consequences, right? So people are, people can be scared to use that. ⁓ I want to go back to the open and close thing. Cause I'm, more of the camp that it's going to take a mix of open and close. Like in reality, I don't think it's ever going to be one or the other. Alessia Sannazzaro: you Corey Moen: mmm Totally. Alessia Sannazzaro: Use it wisely. Corey Moen: Yeah, yeah. always. Matthew P Munger: But we also have something newer ⁓ in Webflow, which is the conditional visibility, which I think makes closed components more powerful and can ⁓ like open components, ⁓ in a more safe way if you actually use conditional visibility and some props actually control, ⁓ let's the layout or like what kind of variety of elements are shown within a component. Now, unfortunately, at this time, the props don't respond based on that conditional visibility. So all props will be visible, even if the element that is not visible. But besides that, any kind of thoughts there on how can we kind of explore and push this a little further now with these conditional visibilities? What have you done with success with them so far? Alessia Sannazzaro: Yeah, I mean, it gives you a lot more flexibility in terms of the layout, Cause you have, you can have completely different HTML ⁓ or show depending on the variant of that component. The way that I've been using it is mainly not so much on the close components, ⁓ more on ⁓ elements that you like the content. the article ⁓ the, Matthew P Munger: Mm-hmm. Alessia Sannazzaro: I don't know, the author kind of component that you have there. So the smaller elements making sure that all of the variants have the same purpose. So for example, if I have going back to that author ⁓ where it might be the ⁓ the name, the ⁓ ⁓ the company or whatever you want to put on that, that ⁓ component. It might have lots of variations of maybe the layout or something like that, but the content itself and the purpose of the component is the same. So that those props, maybe you don't use all of them. Matthew, you mentioned like they're always visible, but the, you know, it will, it might always have a image for the avatar of the person. It will always have the name. It will always have the role. So the context is always the same. I would not use it for a completely different. Corey Moen: Hmm. Alessia Sannazzaro: things because then you kind of lose the purpose of that component. Corey Moen: Totally. Matthew P Munger: Right, yeah, the danger is you try to build section to rule them all, ⁓ it's like every potential layout and combination is ⁓ within and controlled with ⁓ ⁓ But that can other impacts beyond just a cluttered proc bar. But I do think what's interesting, because you can use variance ⁓ ⁓ a right? Alessia Sannazzaro: Yeah. Yeah. Corey Moen: Totally. Matthew P Munger: Like before this, you could just use variants to control the styles, right? When you switch the variants. Now with the visibility, you can actually control, like you were saying, we can control the structure and the styles, or you could just control like the structure to completely change the layout of that, know, avatar kind of element, ⁓ know, to be horizontal, to be vertical, to be a card, to be inline, you know, you could have that and it's adjusting the styles and the structure at the same time. just with that one kind of little selector variant control. Corey Moen: think what's interesting too is Matthew, you alluded to like the conditions don't alter the props conditionally. Like it doesn't hide and show what props are shown. But I think what's ironic is that is also the reason I love open approach. Again, to be clear, not for everything. You're still gonna have close stuff. But like general point was like always. ⁓ Matthew P Munger: Mm-hmm. Corey Moen: If you need to edit a thing, you just click on it and then you see only the props necessary for that thing instead of like you click on it and it's the whole section of props and you have to like sift through the sea of prop types and groups and like it's so hard to read. And again, like I've always gone back to, want to have as little and simple training as possible for a client or collaborator to get them onboarded to using this confidently. Alessia Sannazzaro: love that. Matthew P Munger: Now, yeah. Corey Moen: And so brain has always gone to like, are the things they already know how to use if they know how to use a computer? Like they can click, they can copy paste, they can, you know, when they select something, they probably have a semblance that it might have settings. It's no different than like a highlighting text in a Google doc and you can make it bold or whatever. Like there's some of those base fundamentals that I think can really be leveraged in how you use components in Webflow. and leaning more into slots, even in the context of having conditional stuff, I really helps with that. There's definitely, it's not perfect. ⁓ I there's still always ⁓ component that are sometimes harder for non-technical people to understand. If ⁓ an is within a card and they wanna move the card, they gotta realize they gotta select the card, not the avatar, and drag. ⁓ Matthew P Munger: Well, is, yeah, I was going to say it's like those instances where it's like you have content in a column and it's like, they understand enough to be able to select the column to be able to adjust the properties of that column? Or are they trying to click on the content within that column and not seeing the controls that they're expecting? Right. It's like there's some borders there where it's hard. Corey Moen: Mm-hmm. Hmm. Yeah. Right. I think, yeah, totally. And I think that's where that early education is valuable. In the context of MAST, for example, with columns, was for, I totally agree. And what's funny is that topic always makes me think of, I've gone back and forth for years and still get a lot of flack for why are you using Flexbox and not Grid and Blob. And it's so old school to have the column padding set Matthew P Munger: Never either or, people. Corey Moen: and offset by the negative margin in the row and all that. But like what's ironic is as things shifted to component first, I actually thought that became a little bit of a benefit because you have this like little bit of a gutter, the padding of the column that is a like clickable area to select the column. Whereas in a grid, it's not, you have to use the navigator or your arrow keys to be able to go up and select that parent to be able to move a column around. And then even in maths, like there's a little, when you hover on the column, It shows this angled line pattern in that little padding. was trying to, how do I make this clear as this is a grabbable area? To be clear, I don't know that it's really perfect. It's just, yeah, I think it's a considered factor in all of this is what is the easiest, quickest path? Because let's be real. Maybe this is a good question for y'all, Alessia, is like... Do you, what is the handoff process like for y'all? Like, especially in the context of frameworks, do you give them like videos or a huge booklet of docs and all that? And I'm asking out of the candor of like, have, it feels like I've spent so much of my life writing documentation that nobody reads. ⁓ Matthew P Munger: Here's the raw documentation. Alessia Sannazzaro: Yes. Matthew P Munger: time like you do that, like it's, it's a, always feels like starting over, like documentation, you're starting from beginning and you never know if it's going to, how, if they're actually going to use it. ⁓ Corey Moen: Yes, and it's hard to maintain anyways. Yeah. Totally, totally. Yeah. How's that gone for y'all, Alessia? Alessia Sannazzaro: So our handoff is always either in person or on video. So go through kind of how everything has been set up, all of their. Matthew P Munger: Do you prefer in person? I'm curious if you're in the same city. Alessia Sannazzaro: I actually prefer online cause I record the session. ⁓ so I can record my screen and then I'll send them the recording. So they have as a reference to go back. Corey Moen: Nice. Yeah. Matthew P Munger: including any questions that they asked live. All that's captured, Alessia Sannazzaro: Exactly, yes. So I find, yeah, we tried kind of pre-made videos that I send them of like specific things, but like you mentioned, Corey, like you spend all these time recording, documenting and everything, and then literally the day after they go, ⁓ how do you do this? And it's like, I just like spent all this time doing this. I find that if Matthew P Munger: Mm. It's the link I already shared. It's right up there. Corey Moen: Here's the link. Here's the link. Here's the link. Yes. Alessia Sannazzaro: they're in the digital room off Zoom or Google me or wherever you have your conversation with the client. If they're there, then they can ask question and if anything is unclear, they can go straight into it or they ask maybe something like for me layout and understanding how layout works is quite important. But actually some clients are like, no, no, no. Like I wanna see how you do this specific thing. Corey Moen: Hmm. Alessia Sannazzaro: ⁓ And so we can go right down into what it's important for them and record everything so they can go back to it. you know, I always invite as many people as possible join the meeting, but because it's recorded, they can then also share it with all of their coworkers as well. So that's basically ⁓ we ⁓ the ⁓ just like hour ⁓ call. ⁓ Matthew P Munger: Yeah, you're taking care of the handover and the documentation at one time. Alessia Sannazzaro: Exactly. And it's all in one. then, I mean, most of our clients, ⁓ connect through Slack. So if they have the occasional question, was like, ⁓ how do you do this? Like it wasn't, we missed that in the handover. Then at that point, I'll record a quick loom to show them exactly how to do it. ⁓ that takes a lot less time than trying to document ⁓ And then it never gets run. ⁓ Corey Moen: Yeah. Hmm. Totally. Right, right. Anticipation is so hard. One related question that came to mind with this too is like, does team have a preference towards like project-based work versus like retainer-based work? Mostly the question being like, do you think it's, if you do work with clients on an ongoing basis, even after a launch, do you think enabling them more with components and all that so that in theory they should be able to do more on their own? ⁓ Has that changed that dynamic of a longer term relationship with them? In other words, does that make it so they, a lot of, think I've heard from devs that like, well, why would I want to do that? And they don't need me. And it's like, no, you're thinking about that wrong, I think. But what has your experience been with that? Alessia Sannazzaro: So we have both, I'd say it's usually 50-50, the amount of work that we have, like 50 % retainers and 50 % initial project that might or might not turn into a retainer afterwards. mean, I always like to empower the client because honestly, ⁓ don't want to do copy changes or like that. ⁓ They do all of that. ⁓ And did have clients that no matter how much trading you give them, they still ask you, ⁓ can you change this copy to this? Matthew P Munger: You Alessia Sannazzaro: And in terms of, you know, the fear of empowering your client so that they can do things yourselves. Yes, it could mean that they are like, like, okay, we're self-sufficient. Like we don't ⁓ need you anymore. Feel like we need you anymore. That happened. It also has happened that they ⁓ hired So they hired a Webflow developer and yeah, one ⁓ very feedback was, ⁓ we weren't. We wouldn't be able to hire in-house without your framework in place because it made it so much easier to then train people. there is always that aspect, but like could happen even without a framework, right? It could happen anyway. There's also ⁓ if they a component first framework, there's always the need for new components. So who's going to build that? That could be. ⁓ a good way in of like, you know, let's keep the conversation going and then I'll always create new components, depending on what kind of campaigns, what kind of content you want to put out there and help you that way. And then the third thing is, you know, they can all of this together, but they might forget to add alt text for images ⁓ ⁓ know, all the SEO. kind of tags ⁓ you can add. Most of the marketing team doesn't even bother ⁓ those. So could say, okay, our retainer is actually to double check and make sure that everything is correct that you're putting out. So you're doing 80, 90 % of the work and then we just there to check that everything is in place. Yeah. ⁓ Matthew P Munger: QA and audit. Corey Moen: Yeah, quality and optimization for sure, for sure. Alessia Sannazzaro: Exactly. Matthew P Munger: Well, I think you just said it in, I think, point two there. It's like can come back to you if they want to grow and add things to the system. But that's the thing about design systems, right? They are living systems. They're not like, ⁓ it and forget it. ⁓ don't define it and then you're done. The and the needs out of the system are always going to be changing. ⁓ Alessia Sannazzaro: They're never done. Corey Moen: Hmm. Matthew P Munger: based on what is being built and kind of as the industry changes, as of web tech evolves, you know. So the design system is always going to have to be changing and evolving with it. Corey Moen: orderly. Alessia Sannazzaro: Yeah. And then on top of that, Webflow is always evolving as well. the example of, you know, before variants, we had everything with the of the class. Then as soon as Webflow introduced variants, it was quite easy to translate all of those components to have variants instead class naming. So we basically updated the whole component system that we did for that client to the new version. ⁓ So it's also Matthew P Munger: Right. Alessia Sannazzaro: making sure that you stay away from tech debt and evolve with the platform. Corey Moen: I think this ⁓ also makes me think of, I think there's a lot of correlation potentially between devs designers in our general industry and fear around, it's inevitable, we can't not say the term of AI, I'm sorry. But it came to mind, ⁓ sorry, I think there's similar, ⁓ Matthew P Munger: minutes without it. Alessia Sannazzaro: We're so close. Corey Moen: There's similar fear around, well, if my client can just prompt to build a website, why do they need me? And I think, I don't know about y'all, but I think this is the same situation. if they can fully get the hang of components and build everything themselves, they're still gonna be stuff. There's still gonna be additions and advice expertise. I chatted with Mason. ⁓ from Ed Ground the other day, and I can't stop thinking about how he said, we're moving from knowledge work to wisdom work. And I'm forever going to stamp that because I think it's the same thing. ⁓ it made me think of is even as you're describing that, Alessia, it's like, even in the context where a client's maybe going to hire their own Webflow dev, there is trust and acknowledgement of expertise that is like greatly defined when you are their partner and come alongside them to bring this new vision and site to life. And even if you fully enable them and give them all the keys and tools, it's still building that trust and relationship for us as humans that is the longer lasting business value, money earning aspect of all of this. And I don't think that changes even in this age of AI. I think it just simply means what you said, like sweet, maybe all the... higher likelihood I don't have to do copy changes because they can just even with like Webflum CP, hey Claude, can you just go make that copy update or get this blog post ready or whatever. But there's still all the other technical integration nitty gritty stuff that comes up inevitably that if you're building relationships and helping them define business value and ways that they can grow, that is the underlying route that I think they will keep coming back to you for. But that's my opinion. don't know. What's your take on that? How does this fit Matthew P Munger: I've been thinking it kind of throughout this whole conversation, I keep hearing little nuggets of it, and it is trust. The best quality of a design system is that it builds trust within the technical pieces of it and the players, the people who are using it. And sure, now we have a new player who is using the design system, our AI friends. so it's just a continued. Corey Moen: so much. Matthew P Munger: conversation is just, you know, has a bit of a new angle to it. But it's all about trust. Can I trust styles? Can I trust the components? Can I trust the system that's been built? And either, you know, have AI generate a layout using that system so that can then refine it or, you know, ⁓ my client you know, spin up ⁓ campaign pages scratch, you know, using these components in the system. So, yeah, it's about trust. That's what I think the core of a design system should achieve. Alessia Sannazzaro: And I feel like if you start with the fear, I was like, ⁓ if I introduced this, then the client will no longer need me. Then I think there's a bigger problem there. Cause even, ⁓ if you empower them to do everything themselves, they you to other companies and because of the amount of value that you brought to them. So I see that. Yeah. I never see it as a negative thing. Matthew P Munger: very short-sighted to just see that. Corey Moen: Yeah, yeah. And it's funny because when I think back to the best experiences I've had or positive feedback I've gotten or even seen others get, it's oftentimes not related to like, man, you really put those divs and classes together so fast and so well. It's like, you were so quick to respond and help. You were always so ⁓ at feedback. ⁓ like all these human things that have nothing to do with the website ⁓ is what defines longer term. ⁓ Alessia Sannazzaro: Yeah. Corey Moen: relationships with clients or also, again, maybe the experience even helps to sell new clients, right? It's because you form a quicker bond or semblance of trust out the gate. Like, it's so funny too, because I think it, I love metaphors so much. I see the world through them. And like, what this makes me think of too is like, even in a world of other things, like furniture is ⁓ example that always comes to mind with this. It's like, you can go to Ikea or ⁓ Wayfarer or all these other places and get machine-built furniture with cheaper materials that are cheaper and all that. ⁓ undeniable that in this day and age, there is an underlying lack of trust or assumptions that come with like, I'm going to save some money here, but I know it's probably going to just fall apart in five years. Whereas the other end of handmade, and it is mind-bending to me. ⁓ I've seen out there on social media, for example, of like, you know, handmade tables things like that, that, ⁓ my gosh, that sell for astronomical prices ⁓ clearly still have a lot of demand, if not increasing demand because of that inherent trust that if something's handmade by another human, it is therefore thoughtful and higher quality and longer lasting. ⁓ in my opinion, that same aspect applies to websites, you know, or just again, abstracting it further up to how you help a client Matthew P Munger: Give me some solid wood. Corey Moen: become visible in the world. I don't know. Yeah, it's interesting but also all the same that we've seen before, just a different perspective, right? ⁓ Alessia Sannazzaro: Yeah. And then, mean, this is ⁓ but you mentioned the human aspect of it. And we work with some of our clients for four or five, ⁓ longest one is like nine years on and off. and a lot of the questions sometimes is, you train the new person that joined because you know, you're here and you're good at it. So can you just train all of our new employees? ⁓ Corey Moen: Wow. Alessia Sannazzaro: on what, you know, how everything has been set up, but the, the funny ones are, ⁓ someone left ⁓ ⁓ don't have the passwords. Do you have our Google analytics? ⁓ Can get access to our own, you know, things? but ⁓ because you've been with us for four years, you basically have all of that knowledge stored. ⁓ And even if code of 100. teams changes and we get new developers or anything, everyone is trained and we have all of that data anyway. So we're kind of the safe that holds all of the information for the company. So that's, I guess that's a more human thing. was like, I forgot my password. Can you help me? Matthew P Munger: You're a constant, you're dependable, yeah. Corey Moen: That's so awesome. Totally, totally. And even if there's not an official retainer in place or something, like, hey, I'm around. Just let me know if you're stuck. Again, the bigger picture, the longer term relationship, I think is so valuable. I know, ⁓ yeah, cautious of time. One other ⁓ question had that came to mind that could be a concise one. ⁓ As team been using component first and frameworks and blocks and all that more, ⁓ are there specific features you're hoping... Alessia Sannazzaro: Yeah. Corey Moen: Webflow will ship or work on related to components that feel like gaps or, yeah, desired capabilities, things you've heard from clients, et cetera. Alessia Sannazzaro: Yeah, I've got two that pop to mind. So the first one is kind of related to Matthew, what you were saying. All the props are the same regardless of the variant. It would be nice if you could hide or show some of them depending on the variant so that you can avoid that me dreaded list of props for clothes components that you have and at least make it a bit more synthesized of what you're showing. Corey Moen: Let's go. Alessia Sannazzaro: And the second one would be a default component inside of a slot. So for example, especially with closed components, you might have an FAQ section. So that's a closed component, but you want to like drop into the slot the amount of FAQs. So each FAQ is an accordion. It would be nice if ⁓ would be already inside the slot and then you can duplicate it to add more. Corey Moen: poorly. Alessia Sannazzaro: as kind of like a default component in there. Corey Moen: Let's go. I couldn't work on both of those more. ugh, yeah, so good. Matthew P Munger: haha Alessia Sannazzaro: Do it. I mean, also if all the props were collapsed first instead of expanded, that's a fairly, hopefully quick one. Corey Moen: Yeah, yeah, I wish you could at least set the preference there. I want this group to always default closed and this one not or whatever. here we go. We'll keep putting the request, the good word. ⁓ It's exciting. At least the foundation is there. ⁓ Alessia Sannazzaro: Yeah. Yeah. Matthew P Munger: Yeah, components have really a long way in the past ⁓ three years, I think, to now where we can actually build component-first frameworks. And if is interested in checking out blocks for themselves, ⁓ they can to ⁓ slash blocks. ⁓ from there, can check out the clonable or you can view the docs. Corey Moen: Yeah, since the civil day. Matthew P Munger: And I really like these, are these lot of animations on these icons? I like those. Alessia Sannazzaro: No, those are actually just PNGs. Matthew P Munger: an animated PNG. ⁓ Alessia Sannazzaro: Yeah. So, what we, ⁓ well, we, we created a little snippet of code that takes SVGs, but, as an image, ⁓ you know, in Webflow, if you add SVG as an image, it still has the image tag and not the SVG tag. So it takes that converts it into the actual SVG embed. and then we have a little, SVG animation. Corey Moen: Go. Mm. Alessia Sannazzaro: in there. Matthew P Munger: Cool, I like it. Corey Moen: Love it. Alessia Sannazzaro: so that clients can just upload SVGs without having to worry to embed them. Matthew P Munger: Very cool. Well, excited to see Blocks grow and evolve from this kind of launch point here today. So I think that'll wrap it up for us here today. Thanks for joining us, Celesia. Alessia Sannazzaro: Thank you. And I just want to say thank you, Corey, for building MAST because it's been such an inspiration, especially the docs, the MAST, the blocks docs will not exist without MAST because as you can see, it's like an exact copy behind that. It's quite different, terrible documentation. So thank you so much for doing that. Matthew P Munger: off. Corey Moen: Yo, on your. ⁓ It's the saying like, rising tides lifts all boats, right? And again, I'm just beyond stoked to see the community all starting to do their own thing and experimenting and all that. Like it's been better for all of us for sure. So thanks so much for joining. It's been great. ⁓ Bye. Alessia Sannazzaro: Yeah. Matthew P Munger: Absolutely. Thank you. See you all next time. Alessia Sannazzaro: Thank you. Bye bye.