 Alright so before we get started I want to see, because I've been to a lot of these and I'm seeing a whole bunch of new faces. How many folks here? It's your first DrupalCon ever. Holy moly. Congratulations. And also big congratulations last session, last day. You're all here. You have smiles on your faces under the mask, I'm sure. And so we really appreciate you guys coming out. Today we're just going to be doing a more kind of informal chat. We've got folks up here that are great at what they do and they want to share their knowledge. But if throughout the time, if you have a question that you want to interject, let's try to make them questions so we can drive a conversation with the panelists. But if you have a question just go ahead and raise your hand. It's the last session. We're all a bit tired so let's make sure we have some fun with this. Design systems are the thing this year. I saw a bunch of sessions talking about it and all of them had full room. So it's great to see folks actually diving into these and getting to know what they are. So first off, we just want to say hello. And thank you for coming. I'll introduce ourselves here, down at the end. Yep, introduce ourselves, yeah, that would be me. I'm Jonathan, head of technical at CellarDoor. I'm a new designer, no, web developer at CellarDoor. Yep, and my name is Chris, founder of CellarDoor, front end dev-ish at times, even though they try to keep me out of it as much as they can now. So today we're going to be talking, I'm going to be kind of facilitating and letting them do all the talking because they're the experts in this field. But today we're going to be first talking about design systems. What are they? Why are they all their age? Layout builder, for those of you that are using it, great. For those of you that aren't, then we're going to talk about collaboration. Everyone's favorite topic, right? Everyone here loves their designers, all you designers love your developers, right? And then last, we're going to be talking about kind of where do we go from here and what's next. But before we get into this, how many folks here can say that the project or projects that they're working on now actively have a design system? Okay, great. That's more than I thought. And that's good to see that folks are starting to adapt for this. And for those that are using Layout Builder, how many folks are using Layout Builder? Awesome. How many folks are here to learn about Layout Builder and try to implement it? All right, so we've got kind of a 50-50 folks learning how to implement a little better and we'll go through Layout Builder for those that aren't as familiar with it and how we end up using it. So with that, we're going to kick into design systems. And so we're going to start it off super easy, super basic. The first question is, what is your definition of a design system? So there are many definitions of design systems out there and you probably hear already some of them between the halls this week. I particularly have kind of an odd definition. For me, it's your own certification process. Your team are going to be writing the rules and you have to follow those rules and be sure you are building the website that you need or your client needs and building with your team. Yeah. Yeah, I was just going to kind of, yeah, basically add to that, you know, the concepts of it's the roadmap or it's the blueprint to building the sites or those kinds of concepts. And while like the structural part of that is for sure true, I think one of the things that I try to keep in mind, especially with the clients is sort of the idea that it's a dictionary, right, like this is your tool to get across your ideas, right, and fundamentally capturing how that's going to work. And so, yeah, I tend to be more of the architectural nerd that like is thinking about the database and stuff and not so much about how it's going to look. I kind of think in those terms. Yeah, it's like a dictionary mixed with a Rosetta stone that different people from different angles can all talk the same. So then as we're looking at the design systems that we are creating and interacting with, one of the questions is how granular do you want to get with your design systems? I think I'm very specific. I like to go very specific on this. From your topography, your style, your headings, your paragraphs, the spacing you have between your components and build from that. And I think from the Drupal point of view is very easy if your designers know how do we are building those things. Because if they base their designs on fields like we do with Drupal, it's way more easier than if them. Oh, yeah, oh, yeah. Yeah, for sure. I was going to jokingly say subatomic. We're all familiar with atomic design. And I'm like, yeah, please, subatomic. To me, I really think that the system needs to encapsulate everything that you're going to need to do and start from the ground up. And to your point, as we're building these out, it's every minutiae that needs to be shown on the front end needs to be captured somehow. How does the end user interact with it? How does the editor interact with it? I mean, again, I think that's often one of the parts of the design system that gets lost, which is your editors actually interact with this too, right? Like it's a translation layer for them as well, not just the designer. And we all know that Drupal has a great editor experience. Oh, yeah, it's wonderful. Yeah, yeah. No, it takes some finesse. And that's part of it is if you're making a design system to build a design within the website, you want to make it easy to use, right? So you have to make those decisions on where do you use a field? Where do you use a view mode to try to make that editor? Yeah, and frankly, to me, again, I tend to build the data architectures and the editor experience in kind of that aspect of it. And I rarely focus on sort of the end users experience. But for me, the very strength of Drupal and its framework is that, where every client isn't going to have the same editing experience, nor should they, like clients interact with their own information in their own heads differently. And so the framework of Drupal allowing you to say, hey, the editing of this particular component is slightly different between projects makes total sense, right? Honing it into the editors themselves. The more specific you have your basics, the more consistent and are going to be your components. And it's going to be easier for the users to build up things. Right, because you never get a component that looks like another one except for a green button instead of a red button, right? Right, yeah, exactly. That's the capture at the lower end so that as you're building up, you have consistency across the stack. And again, to me, that simplifies the editing experience. And it simplifies how much I have to save in the database so that I'm not creating 45 components. I'm creating 15 that are interusable. Right, right. So then where do you start when you begin to build a design system? How do you start one? I know you guys both come out from different angles. Because you're the technical side. You have more of the design in the front end. So it'd be interesting to see how do you both approach the beginning of a design system. My background is more a designer. Seven years ago, I was the designer leading a team and we hired somebody to build our website. And I usually start my design system from the designs or from some requirements that you talk with your stakeholders. And you say, we want this to be our design system. But today, we know that this should not be. Six years ago, we were talking about content first webs. But I think it's not the case in most of our projects, right? We never think about the content or why are we doing this? What do we want to communicate? And that should be the starting point. Right. And generally, yeah, exactly. I'm coming from the exact, I guess, opposite direction but with the same philosophy. Which is, weirdly, my brain, when I start seeing designs or figmas, I'm thinking, OK, great. Where's that going to get saved? And how is the editor going to interact with it, right? I'm thinking content. I'm thinking, OK, cool. There's an image and there's a button. And there's a setting. And that one's blue. And I'm thinking in those terms. And it's the exact essentially opposite direction. But it's the exact same concept, content first. Like, what are they trying to say? And how do we make that happen? Right. So then what is one tip to keep in mind when you're starting to build and create your own design system? If you could distill it all down in just one tip. I think keep up in the conversation between designers, developers, and stakeholders. Yeah, I think this shouldn't be one person leading or handling the design system. It should be all of the team and own it. It's our tool. And we need to work on this tool every day. Do I have to limit it to one? Right. No, I mean, I guess if, yeah, I think the most important things would be that. It would be, again, going back to the content first, right? There are other tips. I'm throwing more out there. Atomic design really is your friend. Like, fundamentally understand the reusability of design concepts, right? And real quick, are most folks familiar with atomic design and the concepts behind it? I'm seeing a lot of nodding heads. Cool. And since, yeah, since we're all familiar here, then I guess the statement to that would be make your clients aware of what that means. It's really fundamentally crucial that the editors and the folks trying to actually get the message out understand that concept, too. Because as when we get into Layout Builder, we're kind of cover, like, how that concept actually translates into how they'll use Layout Builder. But anyway, yeah. For me, this should be like a Lego, I don't know. It's the best example I can think of. It's a set of pieces that is limited to a small amount of pieces. And you build things from there. This is why we get along, because we like playing with Legos. Yes. Great. Well, let's start diving into the Layout Builder then. And so first off, why are you using Layout Builder and not Paragraphs? What's the drive there for you? OK. I love paragraphs. So for those who love paragraphs here, yeah. Forgive me, but I really love paragraphs. I loved what it represented. And it really drove a lot of people towards thinking of component-driven and atomic design. Yeah, for sure. To me, yeah, it was like that first tool to really start capturing the concept of atomic design and components and things. Obviously, we know the performance woes of paragraphs and revisions and all of that. I think hopefully folks are kind of familiar with that. Anybody need an explanation of that? I can give you kind of a dissertation after the session. But really, in my mind, again, especially from the content editor aspect, and then trying to translate into the design system sort of the visual is the flexibility that the Layout Builder gives you to truly go atomic, to truly get down to what is the smallest thing to communicate the message I have that I need to put on the page? And then with that library, how can I better make my communication? Give me the tools, the Legos to play with to put them in there. And I think Layout Builder really fundamentally grasps that at its core. Yeah, I don't have much to add there. I know the database and the issues that part of have are more evident for large websites. Maybe if you have a small website, it's OK to use part of it for you. And we have building a website with paragraph for years, mostly in Drupal 7. We have a bunch of them. And it was fine. It was more than fine. But yeah. Yeah, I mean, I guess that, yeah. So still have clients that are very micro brochure sites, right? So for them, maybe conceptually, for their mental model of, I want to put content of the page. So I'm going to put this thing that lets me put an image and some text or a table and a video or whatever, like a very simplistic. Kind of row by row. Yeah, and sometimes that's a little easier to grok as like a new person really using the web, basically. But if you can really get the concept of here's a box of Legos and here's a tool to be able to lay them out and convey the message you want, then it really gives them the freedom to start thinking differently about what they're actually doing with their information. And so yeah, smaller sites maybe. But even then, I think I would still drive towards a layout builder approach, even if it's simplistic. Great. So then how do you use layout builder and the concepts within layout builder to drive and help your design system? I can go with that. So for me, the most important thing is you are separating the grid system from your components. So when I start with layout builder, I want to set what are my rules for my grid and what are going to be my components or my basic components. Because you're probably going to start with four components or six components and this is going to grow, yeah. Yeah, for sure. I mean, as a starting point, and these are the concepts, of course, that when you start to get into design systems and layout builder implementation is you have your information, the thing that your client's trying to get across as an information piece. But that's often or should be separated from how that's getting laid out on the page, right? That's the flexibility of layout builder. So I guess it's just help. Yeah, OK, so yeah. I guess it just boils down to, again, layout builder to me fundamentally grasped the idea of here's your content separate from your layout, and you can move it around, place it here, do some settings, and get your info across. And that's because you're not just working in full horizontals. You can break it into a component lives within the region or the portion of the page that is in that section. But you're not building these big monolithic rows anymore. Yeah, it gives a lot of flexibility to your content editors and marketing teams. And that's a really actually from a conceptual standpoint, that's a huge one to get across, which in the paragraphs days, because you were kind of limited to these bands, you theoretically could create a band that was a layout and then have ad hoc things you can place in there. But you didn't often do that, and you didn't often want to do that. With layout builder, you're separating your actual content. So for instance, if I'm going to create a component that allows for an image and some text, that would be a paragraph. And you may have another paragraph that's a two column that lets maybe different entities or different data structures. And even though you may repeat the text block in each of those, you would have to repeat that in the paragraphs, because your folding states and how it collapses and all of that is dependent on that row. Whereas in layout builder, you look at that, and you're like, OK, that's a text block, and I'm using it in six different places. Well, I only have to build that once. I only have to conceptualize that once, right? Not six different ways because of how it all folds down. That's a pretty fundamental concept of the difference there. So then that's a great transition into how has layout builder changed your approach to site building? Really, fundamentally, to me, it finally allowed me to capture the concept of content first. And the content is what you're going for, and the content is what you're building for. That's the separation of the layouts. Anatomic design. Right. And it's the separation of, yeah, yeah, yeah, that's great. I can do two columns and three columns and all these different which side does it go on and how does it collapse? But to me, that's almost ancillary to the data that you're trying to present. And that's, for me, layout builder, that was one of the biggest mental shifts I was able to finally make when I pulled myself out of paragraphs. And I think there's the magic. We didn't think we were conceptually changing our website. We changed with the technology. Right. Yeah, and if you compare and contrast, I know I had a joke in there earlier, it being Drupal's Gutenberg. But for those of you that have used the WordPress Gutenberg, it's a brilliant way to get content onto the screen. It flows with how you think. It's intuitive. But the hardest part that I have with it is the data structure behind it because there's not a lot of data structure. And layout builder, I think, kind of gives you that blend of usability while still retaining control over the architecture and the data. Right, and that's also another concept that becomes really useful as the reusability is the data architecture and the technical debt that comes from that, especially building everything as a band so you have to repeat stuff and you have to repeat fields. And your technical debt to maintain all of that becomes huge, even really, really, really big sites. You can limit what you're actually building down quite a bit. It's a much smaller subset, especially as you decouple layout from content. I think we haven't talked about this, but you should be thinking on your content structure when you are creating those components. For sure. Because someday you're going to need to migrate this website or change the whole structure of the website. And you have a bunch of content and different types of content in different broad pages and you won't be able to move that anywhere. Yeah, and again, as you can hone down the actual components you're building, the technical debt of, OK, new requirement, it's been updated in the design system. Client says, I want XYZ that actually requires sort of like a fundamental change to the data. It's a lot easier to have one or two of those you're having to deal with and then verify than it is to have six or 10 or whatever, right? And having to programmatically adjust for each variation of that. I think that also helps as well. So this is one that Jonathan and I continually go back and forth on as we're architecting. And again, a lot of the times they like to push me out of that role in projects because we go back and forth on how heavy do you leverage CK Editor and I know that we're getting CK Editor 5 and in Drupal 10 and it's going to be awesome and there's so many cool features to it, right? So where do you draw that line between on creating a block or I'm going to be using CK Editor? Or how do you draw that line? Or do you draw that line? My personal approach is I like to use blocks and fields and have all my content well structured. But I know content editors, they don't like that. They don't like to be a square. Well, yeah, it's that loggerhead of like, I want total flexibility and I can do whatever I want. And then there's the, yeah, but I want structured data and this thing should make sense elsewhere. Yeah, for me, I've gotten to, I love CK Editor, but in my mind, the editor should be sort of what it sounds like. It should be for editing copy in my opinion. And in the editor, you should provide tools for doing copy, copy styles, structured copy and H2 followed by a paragraph by an H3 that, you know, like actual structured information, properly structured information. But basically anything outside of that, the embedding of imagery or other entities or that kind of information, I try to keep completely out of the CK Editor with of course the caveats of the really hard of like, I have this really random layout where I'm dropping in random media objects and the text should flow around them, but it's like two thirds and one third, you know, that stuff gets a little more complicated. But I would rather build that one little special animal as a component than have any media or entities within CK Editor. But I think it depends on your website because if you have a blog, probably gonna make sense to have the image embed on your text and that's okay to have on your blog pages, but. Yeah, I think again, the simplicity of what you're trying to communicate and the simplicity of the site. I mean, we've run repeatedly into issues with using very well-established embedding tools and having them break over time. And unfortunately, the biggest problem with that is you have markup in your database essentially and that is what goes wrong. Like your data attribute between version one and version three has suddenly changed and now you have to scrub everything, right? Or it completely breaks. And we have several fairly large sites that really highly depend on embedding media or other entities within the CK Editor and they're almost constantly a struggle. And so those are the types of things that I personally try to avoid, even from a mental model. Again, editors like structured content. That's what I'm doing right now. I'm not doing media. And it also depends on the ability of the skills of your content creators. For sure. For your content editors. If they're advanced editors or just beginners, they could help you in the process to clean up this markup or not. Right, right. So then, similar to what we went through before, if you had one thing that you wish you knew before you started using Layout Builder and started designing with it, for those that in the room that haven't used it, what would you give them as your, the one thing that you wish you knew before starting? Sorry, I'm stumping you on a Thursday afternoon. I guess for me, the answer that I was coming up with, I don't know if it really encapsulates the biggest one thing, but the thing that strikes me nowadays in most of our projects is the concept of content first, component-driven X, fill in the blank, component-driven content, component-driven design, right? That whole stack is all coupled together tightly. And so the biggest struggle we have is getting everybody involved on that same mental note, even your stakeholders, even the, hey, I wanna do X, Y, and Z. And often when they're given a design, and I think maybe this is just how people have fallen too, they're seeing these bands or they're seeing these big chunks of like, well, that's called latest news and it has these different cards here and these smaller ones here and that line there. And so they see it holistically when you really want them to start conceptualizing that card, that individual card or that heading and the tools you can do in that heading and what you can change. So for me, I really wish I would have known how difficult it is to convey that because I still struggle trying to figure out how to actually communicate that to people. Today we spend a lot of time sitting with our clients having those conversations. And at the beginning you make this, I have option A, option B, option C and give the decision-making to the client. And they would choose whatever they think is better but they usually don't have the information to make that decision. Yeah, that's right. Just make it on the air. Right. Well, that brings up our favorite topic. As I was mentioning, all you designers in the room love your developers and all your developers love your designers. So when it comes to collaboration, how do design systems help with that collaboration in your mind? So once you have established this system and you have your agile methodology around it and you make your scrum sessions and you start making decisions about like, okay, we have a new component and we need to do this and you ask them, do you really need a new one? Can we use this component? And that speed up the conversation like to the moon. Yeah, I would say as I listen in on calls that they're on with folks as we're building out design systems, it almost feels like you're negotiating Oh, for sure. Design through the design system. It's the method by which you're negotiating but do we really want that to be a new button or can we use this button and pull this here and those kind of conversations couldn't be facilitated without that. I had a whole list of things I was gonna kind of add on this one and I'm hearing that. It really is to me, the biggest takeaway is ambiguity. Like, properly built out design system that everybody follows from the stakeholder to the backend developer and everybody in between. It really reduces confusion and it reduces redundancies. Yeah, working with designers that maybe aren't fully grasping the idea of truly component and so again, everything becomes a bigger object on the page and you're like, but that card, it's a card has all the same information looks 99% identical but it has one little tweak and you're like, eh, really? Yeah. If you are in a meeting, if you are going through these new designs and you don't have a design system that you can see and everybody in the meeting can see at the time, you are asking like, oh well, but we have this blah, blah, blah, blah, blah here and I don't see that we are making a big change with this new component and if you don't have the design system there, most of the people in the meeting, they don't have that visualization of the whole thing. Right, your conversations very quickly get mired with, well, we have that, right? Like if you did this one thing and you flip that one switch, it looks like this, right? And there's a lot of that like back and forth and the developer's like, yes, I know I built that, I remember seeing it, right? And sometimes the designer's like, hey, look, I made this completely new component. It's like, eh, it's not really and you'll spend 30 minutes on just that conversation. And if you don't have your naming or your components, yeah, across the- Back to the idea of it being a dictionary. Right. Yeah. So you are talking about the Fisher part and the other guy is talking about the Lightning card and- And why is everything called a card? Right, there they are. So then that brings up a great question of who actually owns the design system? Is it the designer? Is it the developers? Who should own the design system? I do. No. Do you go first? Cause yeah. Okay. Yeah, I think the whole team has to own this, this sheet, they, sorry. I should not have to say that. So I think everybody on the team has to be, to be involved in the process. Yeah. They all have to own it. They all have to feel they can change it. They can modify the things in there and improve them. Yeah, I mean, joking aside, if you're trying not to get on meetings with 35 people and they all have ownership of the design system, I get those conversations, but frankly, ownership of the design system has to be the client, the designer, the front end developer and the back end developers and the content strategist. Like they all have to sign off on it because again, what you're fundamentally building is, hey, I'm a client and I have something I'm trying to message to people, how do I get it on the page, right? Everybody has to agree. You know, what am I trying to say? How am I gonna, how am I gonna say it? What are the, what's my editing experience with that? Like we run into, we have several where it's like either being driven from the back end, which is like, this is the easiest data structure. Here you go. And the front end's like, I can't even use that. On the flip side, you have the designers that are like, everything is a new component. And the back end's going like, well, wait a second. Now we have this thing that has 45 options. Is that really necessary? So it needs to be collaborative. It really does. So how do you keep that in line? The, well, the design system to begin with. But then you, as far as like data structure and all that, you couple that with a properly built spec sheet. Which is that the next slide? Well, hey, we just happened to have an example of one. So how do you use a spec sheet like this to drive your design systems and the ownership of it? So generally speaking, this is more like the data architecture's playground. But I don't know if folks have seen this. This is widely available. Aquia provides this. Thank you, Aquia. It's a go grab it and they keep it up to date with new functionality. But I've added some new functionality, which I might talk to Aquia folks that I see in the room someday. But basically the concept is, as you can see, it's just a spreadsheet. And we try to tightly couple, you know, where are we getting the concept of what we're building? What is the naming of that thing? What does it do? What is the front end component called, right? How are we coupling the back end editable ability to the front end? And then we just capture it literally. This would be truly more of a blueprint. This is the nuts and bolts of what you're building. But this comes after that design system is completely built, right? And the concepts are identified. And it's on a place where everybody can access at any time and solve their questions about, do we have this already? Do we have something that is similar that or what we wanna build? Right, and when you're having those discussions of we're creating a new thing and we're in the design system and we're talking about how this card is slightly different than that card, this is a good way to then come back to saying, okay, here's the tools on the editing side that we already have available to us to then leverage over here without reusing. Again, field underscore title should basically act the same anywhere it is on the site. Again, so that's also a mental model for your editors. They know to expect field title does this and not like wildly diverge in what it actually does. Yeah, and for folks that are building decoupled sites, a spec sheet like this that goes all the way down to the machine name basically becomes your guidebook for the API, right? And you know how to interact with it because you know what fields you're looking for and as you're building things out it becomes that central point that all decisions are finalized in. Yeah, and that's something we'll get to later, but yeah, this also outlines the ability for this to be not just, okay, I'm putting this in twig. Like where else is this going? And it helps a lot to keep consistent naming because you see all the things here. Yeah, I think we all agree on that. Naming is hard, I've heard. So then how often are you updating your design systems? Every day, every single day. Every meeting we have, every component you are building, every time you open a ticket and you go to the spec sheet and you check all your fields are in there or not. Maybe you have your designs, your comps here on your ticket and then you go to a spec sheet and you say like, oh, this is not here or this is something I don't know, it should be a field or it's just a static content and we go over to our team meeting and ask as a static content, it's okay. And we have the same word over and over or you need a field that it has dummy content that is gonna be like default and then you can config that field if you need to. Yeah, for sure. I mean, the hard and fast rule that I try to use is that are you changing anything in how this is getting communicated? I mean anything. So if it's purely an editor experience, change request from the client where they don't like a dropdown and they want something, that doesn't affect the design system or really the end product of the communication, right? So those obviously you probably aren't putting those in your design system, that's where the spec sheet comes in handy. But any kind of change that changes content or the ability to display that content, like it's the entry, you start with the design system. So then as we're getting into the final minutes here, again, informal conversation, if you wanna raise your hand and ask a question at any time, just please do so. But now let's start looking into the crystal ball and saying what's next. Where do we go now that we know these designs? Oh, yes, there's a question? No, okay, sorry. So now that we know how we're kind of building these design systems, how we're layering it in with Layout Builder, what is the one feature that you'd like to see added to Layout Builder? I'm going for the content editor experience here because I'm always looking into how content, how editors are experiencing this thing. And I would love to have Assuming Zoom Out and a kind of a mobile version preview because it's true, you can move things up and down with Layout Builder, but sometimes these layouts, they grow so fast. There is, you cannot have all in one screen. So I would like to have like Zoom Out and I have all my components, just squares, probably not that many detail on it, and just move them around. I hadn't thought about that. That is a very good feature. Yeah, yeah. I think, yeah, from an experience that would be an amazing feature. What was I gonna say? From the back end or the? Oh, yeah. Yeah, this is my again, yeah. Data. I think the biggest feature that I would like to see would be context aware blocks. Basically running into kind of some issues where theme switching on a particular content type and context of what the content type is and context of where it is. I would love to see in, this may end up like exploding the data layer, but some ability to say, okay, I'm this type of block, that's my parent and these are my siblings. And then you can really start leveraging like web components and APIs and that kind of stuff to display the information because that block already has all the data it needs to know who it is and where it's at. That would be one that would be important, although I think that one totally trumps what I was gonna say, so. No, no, we have tried to do it. We have tried to do it. No, I want that one first, I totally agree. That's a really good one. I think for me, one of the ones that I, I think there's an issue for it and there's some back and forth on how it's gonna end up being implemented, but the idea of global blocks versus local blocks and how do I take a local block, make it global, take a global, make a copy, bring it local, right? How do you interact with that? I think, again, I've seen some page builders for WordPress and others that have, that concept kind of drilled down really easily where you have kind of template blocks where it's a global block you can add it in, but as soon as you change a word, it becomes a local block and you're not constantly dealing with this, which one's global, which one's local. I changed it here in, oh crap, now. And using the libraries, like, you know, we have a really, the media library, which is wonderful and obviously the content table, which is essentially a drillable library and stuff. And I think really having that work with your reusable components so that somebody can say, you know, I made this card and like, wow, okay, I really like that and it's pretty neutral and I can use it all over, great, make that reusable. Now it's gonna show up in that table so that then later on they can go to the table and go, actually I wanna tweak that a little and I know it's gonna affect all of them. That would be great. I'm sorry, we are speaking too fast because I think this concept of a global component or a local component cannot be familiar for everyone. Is anybody familiar, everybody here familiar with our A&M questions about inline blocks versus reusable blocks and looks like folks are familiar. I saw there was one question in the back. Yeah. We don't have any screenshots that we'll kind of dive into on that, but yeah, I think out of the box, that's a great question. What are some of the modules that you use day in and day out with LayoutBuilder in order to shape that editing experience? I'd have to look at the site. LayoutBuilder modal and... The ecosystem, LayoutBuilder ecosystem website in Drupal RG. Yeah, and section libraries and some of the played around with some of the bootstrap style, like pre-configured settings for the blocks, that sort of thing. But I mean, to the question, we're kind of almost constantly tweaking it. We both tend to often agree as well on like the editing experience. And so if the budget and the time allows, we're always sort of trying to make that better. So there's a fair bit of customization, especially in conjunction with the theme, the backend theme. Yeah, I know that the contributors are being working on this experience a lot last years. And they haven't finally found the recipe to make it like perfect. It's not perfect. It's still a bunch of work there to contribute with. But yeah, sometimes we put some hours, some energy into little details to make it easier for the content editors to access the bottom or the engine. I think that would make a really good bof that's like four hours long of like, you know, LayoutBuilder show and tell, hey, I did this cool thing. Look how that works, right? Like, because there's a lot of folks in the room, a lot of folks playing with different aspects. That would actually kind of be fun. And so we've got time for maybe one more question than if there's any questions out there as well. But this one's kind of the fun one for me. I've been playing around with this concept lately is, do you think in the future we're gonna see hybrid themes, themes that work on WordPress, Drupal, you name it, Gatsby, the rest? We should. We should be able to speed up atomic design driven themes that can work for. Yeah, and we've chatted this and we've looked at different implementations, but I would, yeah, I think that's for sure the future. And I think, again, as more and more agencies, especially the larger ones adopt their design systems and they have sort of a unified language to get things across, what you can see is where the applications are similar, you can sort of couple them a bit at a certain layer. Like the fundamental structure of a card in twig can be similar in WordPress as it is in Drupal. And that layer can be maintained in its own library, right? And then brought into the web components to go specific Drupal, specific WordPress. And I think that kind of future full tail with the design system is actually gonna be incredibly powerful. Yeah, it's been fun to see we actually have a few sites that have kind of abstracted twig templates that come from outside of Drupal. And so then you're basically marrying the fields in layout builder through Drupal's templating system to these kind of generic twig templates that can then be used all over the place. And that's where the kind of the spec sheet comes in because at that point you have, you can then say, okay, great, now I'm gonna go create a WordPress version of that. And I already know what all of my variables on the front end are supposed to be called. So now all I have to do is hook up, okay, how am I gonna get that to them? And then with that, are there any questions or comments as we've been talking this whole time? And I've been preparing these questions, but are there any from the crowd as well? Yes, all the way against the wall there. And then we'll work our way back here. Yes. Oh, I can get on a soapbox for 15 minutes. I'm just on just layout builder versus Gutenberg. I love the WordPress community. I'm friends with a lot of folks there. I always, whenever I'm there, I always describe myself. I'm like, oh, I'm a Drupal that's here. And finally they had to tell me to stop and just say you're a WordPresser as well. So I love it. I love the interaction of Gutenberg, the ease of use. I think that's what, as Drupal, and we're talking about kind of the editing experience and what we do to modify that, I think that's the direction and almost the beacon that we should be trying to go towards. There are some accessibility and usability issues of it. But then when you look in the backend, it just takes that all and just smashes it into the body field on a blog post. And so there's zero structured data. And there's zero structured data in WordPress in general. And I think that's one of the things that I always look at when I say, am I going Drupal or am I going WordPress? It's do I need structured data? If I'm just creating a brochure and I want somebody to have an easy experience or they're creating a blog, Gutenberg all day long. But the moment that you wanna start breaking things apart and then reusing that structure, that data elsewhere, it just falls, it starts to fall apart. And then you're tacking on so many plugins to make Gutenberg do that that you've just built Drupal through plugins. So it's not worth it. For me, it comes back to that structured data concept. And so it limits the flexibility of like, if you're building a website and it's simplistic or not simplistic, whatever, if you're just building a website, that can make sense. It makes a really great editor experience, but you're getting blobs, right? If you're trying to build a communication platform where it'll get used in other places, then you need that structured data. Next question here, yeah. Right. Right. Right. I forgot why it's necessary to say one or the other because having the paragraphs allows us to also control which blocks that you put into the races when you put certain things in certain places. Right. And then also allow us to keep the kind of relationship between, so the component would be couldn't go to a paragraph and that paragraph could then be used within the two column layout but not in the three column layout. Right. I think, which we're like constantly battling that one. So yeah, I don't, it's not necessarily an either or. I think fundamentally we're able to tackle those exact problems just directly within Layout Builder native and, you know, blocks like using fundamental native Drupal concepts. There are add-ons for instance, and to the point back there, Layout Builder restrictions where you're like, three columns, that component can never go there. Like, and you can get more sophisticated with that there are like restrictions by role and there's those types of things. So you can get very sophisticated in like where your editors can place things. And so for me, when I'm looking at how I'm gonna build that structure, you know, starting with the design system, you have your concept of these components already. I don't wanna get mired down in yet another maintenance tool that I have or even a data structure maintenance, right? If I'm using blocks throughout, then structurally I'm using blocks throughout. Oh, totally, yeah, so, yeah. I'll be the controversial one and say I have no reason for paragraphs ever again. And I'm totally open to my mind being changed on that, but if you dive in, I mean, at the heart of it, an entity's an entity, right? And that's kind of the beauty of Drupal is that everything is an entity and it's all fieldable. But I've found that using blocks and how blocks are so core to what Drupal is, all of the tests, everything just work on blocks. And again, at times in some of the paragraph sites, we were kind of pushing the boundaries of where paragraphs was at. And you could see that it was not a core entity. Like there are certain aspects of it that just hadn't been thought of. And I would say, and again, I totally find being proven wrong here, I don't see anything that would happen in paragraphs that I couldn't also do with blocks. And so it's me that I'm having to maintain two things, going back to the maintenance thing and it just becomes a hassle for me. So basically in paragraphs, you have entities inside entities inside entities. That could happen with blocks too. You can end up building columns inside a block inside of a tab component. But if the more simple you keep the things, they're gonna be easier to handle draft edition or publish content workflows or translations. That's something I wanted to bring up too. That was the entity revision. An entity revision and stuff that paragraphs is going through. Again, it kind of being not core. We found certain situations, especially in like a decoupled website where the revision of the parent didn't boil down to the sub paragraph. Cause whenever we were building in paragraphs it was like a paragraph and a paragraph and a paragraph and a paragraph and a paragraph in order to get the atomic design that we wanted. And so then you end up running into these entity revision complex. Entity revision requests don't work with all entities. And it's at this point pretty limited to core specific entities, especially in a decoupled site. Yeah, so we have one over here and then we'll come down here and then I think that'll be our time. Yes, right. Is blue, is green, is check box, is radio, right? Like it ends up just being a bunch of fields that are not even dated, like not even content. It's just how to manipulate it. I think Jonathan, the way that he uses view modes, I'll prop him up on this. The way he uses view modes in that takes all that away because then you just are creating view modes for that block and you just have them select, again going back as the design system is the reference, I want the small card, I want the big card, I want the horizontal card, horizontal card. And that because you know the context of it from your design system, all you're doing is you're creating now a new template within your theme and it has those pieces pre-baked in. It doesn't give you the check box where you can create like 10,000 configurations from those fields, but again going back to the design system, you almost don't want that, right? You don't want somebody to, and then you have to start writing custom logic of like you can never have a red button next to the green eyebrow. And actually another part of that which is that whole context aware block and sections and things, the other strength there is you don't have to have a setting for turn my text white, right? If you're context aware and your design systems built properly, when I place this section and I turn the background dark, I want my text light, that's context, you don't need your editors to mess with that. The design system should be accounting for that, right? So in that way for sure, it helps a lot. We start removing things like the content creator being able to change the spacing between one component and another component. That should not be a decision for the content editor. It should be part of the design system. It should look good all the times. Right. All right, one last question here. Yeah, more from adding to what Chris is saying. So layout with paragraph, that would be a long discussion. The original idea of layout was to do what's paragraph, what people was trying to do with paragraph in a more controlled way and in a brutal way that integrates better with better performance. At the time, you would be seeing databases of 10 gigabytes, where six of those were two paragraph addition things. Right. And when you go to my SQL, that's about if you're looking at that table, that just doubled the time you look at it. Yeah, right. Yeah. If you're not just looking at a paragraph. We have a site right now that's 80 gigabytes in the database and it's made mostly of paragraphs and it's huge. And to go as an example of what Chris was saying, the reason for that was, or that got fixed two or three years ago, but it was a big endeavor. Right, yeah. One of my customers paid for part of that. I'm very aware, was believing a revision, changing a revision or believing something, it was hard to get to the actual paragraph, some of the paragraph that had the paragraph, side of the paragraph, and onto the paragraph and get all those revisions done. Right. At some point with that customer, I tried to do some SQL to get orphan revisions. Right. It wasn't me. Right. So that was the idea. Now that said, many people have been investors in water. Right. It's not a dead ecosystem by any means. And for folks that are building on it, that's totally legit as well. So I don't mean to be like, if you're doing it, you're doing it wrong. It's more just, as I'm looking at it now, I've been building Drupal for 12 plus years now and I used to do these like wild and crazy builds and now it's like as simple as possible. If I can create one thing and then place that one thing in 30 different places or whatever, oh, I'm awesome. And if I can use Drupal native as much as possible. And I'm not maintaining a large core. So. To finish my point, I think layout paragraph is fantastic for those that want to move away as a transition because yeah, well invested paragraph is really good at what it does. And really bad at what it does at the same time. Right. My advice, I'm kind of like my customers is always, if you can use this stuff to walk away or something that is not well integrated between Drupal because A, eventually, you're gonna have issues maintaining that. And B is gonna come back and buy you at some point because you cannot enhance it, you cannot improve it in terms of reliability, et cetera. Even if you're in a small website and on the side, since I just wanted to say, give your users freedom, but they don't give them that much freedom. Yeah. But they just like system workforce. So we're about five minutes over. I wanna respect your guys' time and I appreciate again making the check out last day, last session coming out. If you have any questions, feel free to write us an email, come up and talk to us. If you wanna change my mind on paragraphs, I'm all for it. Thank you.