 All right. Well, hello everybody. My name is Jake Hallicott, and I'm really happy to see all of your smiling faces. At least I think they're smiling. I'm just going to assume that you're smiling, I think. But it's so nice to be here in real life, meeting actual humans, interacting with you all. So I'm really happy to be here to present on building at scale with design systems. Now on the agenda today, we're going to talk about, first we'll talk about some of the challenges that can hinder organizations from being able to communicate their brand identity. And then we're going to look at how we can create design systems that help scale with organizations as they grow. And then we'll look at how we carry that into the development process to get projects done faster. Okay. First, a little bit about Media Current. I am here on behalf of Media Current. And so Media Current is a full service digital agency, and we've got a distributed team that's in the US, but also across the globe. And kind of what unites us is that we're just very passionate about open source, about technology, and about solving problems and finding solutions. So as I mentioned, we're an agency. We work with clients across every vertical, including corporate, higher ed, nonprofit, government. And so I think that's really helped us over the years, gain a good level of experience working with different type of organizations that have different needs and challenges. And so I think that's really helped us fine tune our approach over the years. And if you don't know me, I've been around the Drupal community for a while. I think I'm not sure how long it's been, probably 15 plus years, something, I need to check it, but it's been a while. And I had Media Current's engineering team been with Media Current about 13 years, done a lot of Drupal development, architected a lot of different projects. And I've been a long time advocate for open source. And I just really enjoy working with the technology and again, helping organizations achieve their goals. Okay, so first I want to set the table for why do we need design systems. I think that most of us here understand that we need some kind of guidelines. We need some kind of system that's going to communicate an organization's brand. And yet our experience is that we see so many organizations really struggle with staying on brand and collecting design debt, things like that. And so it can be a struggle. Let's talk about some of the challenges. And so the thing that we've encountered is that there's competing needs. Okay, we only have so much time, so much energy, resource, money to devote to both kind of near term needs and long term needs. So you spend time on one, it takes away from the other. Okay, so it's competing. And a lot of attention gets put naturally towards those short term needs. And so we'll focus on that what I call functional work that's going to produce some immediate results. And so that can be things like trying to increase lead generation, run campaigns, increase conversion rates, things like that. And that's important. We need to do that. But we can't shortchange the more foundational work that's going to scale with us as the organization grows. And so a good design system is absolutely a foundational layer. And we need to devote time to that. We can't shortchange that because that's going to be with us for years to come. We want to invest in that. That's going to pay dividends in five years and 10 years. So speaking of challenges, a big thing that we see is fragmented experiences. And so who here has been on, let's say university? And, you know, a lot of time has been spent on all the beautiful branding and signage and all the print materials and all that stuff. And then you go to the website and it's like patchwork or just like way different than on campus experience. And so it's kind of all over the place. And so when we as like a user encounter those inconsistencies, it causes this like cognitive strain. And we really don't want to do that. We don't want to leave it up to the user to have to figure out how to navigate the system. And so systems will help us enforce the consistency. So to summarize design systems help teams build faster, understand the components and processes and create that consistent user experience that we want for our audience. Okay, so how do we do that? So at Media Current, we've got a creative team. They do UX design. And so they'll do like brand workshops, you know, to help kind of uncover like the brand voice and tone and, you know, that the organization wants to communicate. We do like, we just do everything, right? It's branded like rich media and video production and animation stuff and all the school stuff. But, you know, most relevant for this conversation is helping implement these design systems. And so I'm going to show you a little bit what this looks like. I'm going to cover some of the kind of some of the main deliverables that come out of like a redesign a brand redesign. And so this isn't like a super deep deep dive into design. We do have good resources on that. I am a developer by trade, but I can cover some of the highlights. So I'll do that now. Okay. So one of the first things that we deliver, and this is common, right, is a style tile. Sometimes some people call this a style guide, we call it style tiles. And this includes some of the fundamental elements of the brand, right? And so that'll be typography, color palettes, iconography, some of the fundamental elements. We also create mood boards. And I think that's really helpful in terms of a brand redesign. And so that'll be like a collection of images and texts and shapes. And it really helps communicate kind of design direction. And it's a good kind of precursor to component designs and layout designs, because it helps communicate that direction before you invest all the time into the full blown mockups and things like that, and get that buy in so that like the stakeholders understand what you're trying to accomplish. And so when we're kind of in agreement on the overall direction, we'll start getting into the component design. And so if you're familiar with kind of atomic design principles, kind of similar to that. And so we'll work on the different components, those will be pieced together into layouts. And so we'll deliver, we deliver wireframes and design mocks. And we try to not spend too much time on the wireframes, I'll say wireframes are useful like internal tool. I have found that sometimes the wireframes kind of bog down the creative process because we get kind of hung up on how things look. And the wireframes are not really supposed to communicate so much how things look. And so I would much rather get to one design comp that we can get approved and hand to the project team to execute, then spend weeks going over wireframes and then weeks going over designs. And then it's like the project team's on the sidelines. So yeah, I think trying to get to a design mock that the client can approve is really important. Now, this is a big part of how we execute this sort of thing and keep things organized. And I'm really big on this is a component matrix. And so this is like an inventory of all the design elements that are part of a redesign. And it's pretty simple. It's a spreadsheet. It tracks progress. It gets the, we share this with the stakeholders and the client so that they can understand and see like kind of a bird's eye view of how we're going to deploy all the different components across the website. So it's a good organizational tool. Get them thinking in terms of that this is a system. It's a collection of components. It's not just like, hey, design me, you know, five landing pages or something. It's like, no, this is like a system that we're going to use. And so this is really helpful. There's another screenshot. So we have a couple tabs in there. I've got a, we've got a template that I'll share later on, if you're interested in that type of approach. I think it's really helpful. It's also really good for backup, but it's really good for the project team as well, because we can hand that to the project team, keep things organized. They'll create your tasks off of that. They'll see which things are approved and ready to work on. So it's a really helpful tool. And then we are going to talk a good bit about the website development process. But, you know, when we're talking digital brand, that includes things outside the website, any sort of digital asset like decks, ebooks, documents, things like that. We will try to, again, empower the team that's the marketers, anybody who's touching content. We feel like everybody is a brand ambassador and certainly people who are creating content, they're part of communicating that brand. And so we try to make their life as easy as possible. Standardize things, say, here's the template, it's easy to, easy to use, plug in your content, and it's going to, you know, communicate that consistent brand message. Okay. So now I want to talk about how we bridge the design system that the creative team helped develop into the development process so that we can execute Drupal projects, because we're at Drupal Con, right? We can execute those more efficiently. So one thing I've been big on for a long time, we've been doing this for a long time, is implementing a style guide. And so we do training on all this kind of stuff. And it pairs really nicely with the component matrix and how things were organized during kind of the design phase. And so a lot of agencies do this. This isn't uncommon, but it's something I wanted to make the case for, because I do see organizations that don't use this. And I do think this helps you develop a design system that can scale. And so we like Pattern Lab because it supports Twig, it works with Drupal, and integrates pretty easily. There's other, you know, style guides, storybook, and so on. But Pattern Lab has been around and works with Drupal well. And so I'll make the case for it. One of the things that I really like about it, again, keeps things organized. It allows for parallel development. So you can have one team that's working on like Drupal site building and module development and things like that. And then you can have other developers just focused on the theming work, the branding stuff, just working in the style guide. And so there's less tasks that are blocked. And so we want to keep things moving. So that's really helpful. I also like that stakeholders can see progress much sooner. So they can point out problems, gaps, things like that. We can get approvals, we can get QA involved early on in the process, have them test for browser compatibility and breakpoints and accessibility, all that good stuff. And then, you know, another thing that I really like about this is I do think that when we're talking about system and something that can last with your organization for a while is I think it makes it easier to evolve your brand, to execute redesigns in the future when things are organized this way. You know, we know that Drupal, since Drupal 8, it's backwards compatible. And so Teresa is talking about Drupal, you know, Drupal 9, 10, 11, we don't have to rebuild the Drupal site. And I do think that having a tool like this will help you evolve your brand over time. All right, so now let's take a look at how a system like RAIN can add even more efficiencies to the process. And so the way I like to think of RAIN is like a collection of tools. What we, as an agency, we observed many years ago is that, you know, I said we've worked across a bunch of different verticals, and we saw even working with different organizations, there were still a lot of overlaps, there was patterns we were seeing, there was a lot of projects used similar features, similar configuration, content structure. And so we slowly started putting together some tools to help streamline the project development. And so this started, you know, pretty simple. We didn't want to box in the developers. Developers don't want to work with anything that's rigid, right? We love Drupal because it's so flexible. So we want to establish some patterns, tackle some kind of low hanging fruit, and then kind of evolve from there. And that's what we've done over a number of years. So it started with packaging, contributing modules, security features, but over time we've evolved it into something that's more full featured, including kind of like a theme system and layout builder integration. And so this is the part that helps us, again, take that design system that, you know, existed in Figma and stuff like that, and extend that into the Drupal space. And that's what enables our users to create these great layouts without having to think about it. And it helps us just streamline the whole process. And so, of course, this is all open source. It's freely distributed. I'm going to try to make the case for why this could be valuable here in a minute. So first I just wanted to go over a couple of quick project examples that we worked on recently. So the first one is bitsite.com. They're a security company. We launched this late last year, early this year, somewhere around there. And so we did the full kind of brand redesign, right? So we did the style tiles and the mood boards. And we did all the component design, the component matrix and all this different stuff, right? And we leveraged the style guide. Rain has a built-in style guide that I'll show you here in a little bit. And so we were able to leverage some of those content types, the many of the layout builder blocks that ship with the distribution. And we've got a base style guide that I mentioned. We're able to extend that. It just, I'll use the word streamline a lot, but it just makes things more efficient. And so it's very much still it's very custom design, custom website, enterprise level implementation. We've got HubSpot integration. It's got, we added new components to it, but we were able to leverage these different pieces to make things go more smoothly. ECI is another project that we did recently. It's mostly a theming project. And so I think Rain is a good fit for that type of project. I call it a theming project because it's like they really wanted to, they really focused on, again, communicating the brand. That's really important, but they didn't, you know, some projects have a lot of moving parts and a lot of complexity. This one is not that this one is really pretty straightforward site. And so we were able to leverage a good bit of out-of-box functionality. They were happy with a lot of the block types that we had out of the box. And so it allowed us to kind of move more quickly being able to leverage so much of that built-in functionality. And so one example of how it helped us work more efficiently. So when we got the first iteration of the home page, and this is just like a partial screenshot, but we had, you know, several different components on the page, we're able to take that first iteration design and turn it around to get it fully themed top to bottom in like 24 hours. And so that same week we're able to demo for the client, show them the layout builder stuff, everything like in context. It's not just like here's a flat file, that's the design, that's great, but it's so nice to be able to show them everything like in Drupal and we could still iterate. It's okay. And so I thought that was really cool. Okay, so now I'm going to let's take a look at the rain demo. And so I'm going to start with some of the kind of visual stuff, user experience stuff, and then kind of work my way into a couple of the technical pieces. And let me mirror my display. It'll make me make it easier to do that. All right, sweet, figured it out. Okay, so this is our rain demo, rain distribution, open source distribution. One of the things that we did is what this is, you know, when you want to evaluate something like this, you want to figure out very quickly whether it's useful and helpful for you. And so one of the things that we did a couple of years ago is add a lot of demo content, turn on all the features with our demo profile so that you could download it, set it up, install it, and figure out whether, you know, it would be useful for you. So we try to demonstrate a lot of the different block types and things like that. And so we've got a couple different pages that just have stuff, you know, already turned on for you. See if the internet works today. And kind of get a feel. So let me just show you a couple things on the homepage here. Okay, so you've got your hero, you've got cards, these are just some of the common components block types that we have out of the box. You got card list, quote, card views integration. And so any type of view that you can create, you can easily drop into the page. So they're just kind of like a sample, things that you'll see. Next, I want to show you what the layout builder experience looks like. So we'll click on the little layout tab. Now layout builder is a great tool. I'll say it's still a little bit tricky to set up and configure. And it's it's not maybe the best like out of box experience. And so we've done some of the hard stuff to like pre configure it and add some polish and do some different things add some contributed contributed modules that fill in some gaps that you might get just from straight core layout builder. So I think we've done a pretty good job with that. And our clients really like using this. In the past, we had used paragraphs, you know, a lot of you are familiar with that paragraphs works pretty good. But clients really like using layout builder because it's that visual tool. And again, we're talking about today, we're talking about systems and tools. You want to stay on brand. And so here, it's easy for them to arrange different blocks and different pages and still stay on brand. You're, you're kind of have some guard rails up a little bit. And so let me just these. Okay, so we did a good amount of work with the sidebar trying to make that really usable and accessible. And so these are all the different block types that ship with rain out of box, you can of course customize them extend them all that good stuff. So I'll just give you an example here, what this looks like. Layout builder is really nice just because you have that inline preview. So you can add content, you can move things around. I usually turn off the content preview if you need to move things around. Really easy to use. So if you need to make a change, you just go in there, make your little changes, change a little layout. It's our layout builder. Okay. So that's one of the things that we did. We worked with to improve the whole layout builder experience. And another thing that we did is create a new admin that adds a little bit of again, a little bit of polish easier to use. So this is our kind of rain admin package. You can use it even independently of rain. We tried to put, collect together packages where you don't have like a bunch of interdependencies. If you just like the admin, you can use that on your project. Again, we've got a bunch of demo content. We have lots of, lots of the sample content types turned on. Another thing that we tried to do with this is establish some kind of basic content patterns, like even just the way we organize fields, we try to establish some patterns for people to follow. But so it's nothing crazy, but I like our little sidebar thing. We spent time on this and making a little sticky nav and we got our little jump nav, which I really like, especially if you've got a content type that's got a lot of different field groupings. It makes it a lot easier for the content author to navigate. So as I mentioned, we have a lot of optional content features that you can turn on. And again, the idea is to keep things basic so that they're useful. What we don't want is something that's too opinionated. That's too rigid because people won't want to use it. You'll end up just fighting the system. You're like, why does it have all this stuff? It's just cruffed. Developers don't want cruffed. They don't want things to be rigid. And so we tried to strike a balance where we wanted to add some basic building blocks for people to be able to turn on and extend without making it try to do too much to where you're just thinking like, no, this is way too much. And so all of our content types, we keep them pretty simple. They follow the same basic patterns, but it just kind of gives you an idea. So that is the content authoring experience. Okay, so the next thing I wanted to show is our built in pattern lab style guide. And so, you know, I'm really big on style guides. I think that's a great way to organize your design system and implement it. And so this is a little bit more basic than than what you see in the rain demo. So the rain demo has some additional branding because it's it's a demo. It's trying to show you kind of what a what a real site might look like. But if we're actually going to create a real custom thing with this, we don't want to again, fight a bunch of, you know, extra branding. And so we try to keep things pretty simple and basic so that again, it's useful. And we like to think of this as like a starter kit. And so you have all of these basic components out of box to show you what this looks like, like on the back end, pattern lab organizes things really well. It's got different folders for all the different components. Again, the idea is that a developer is able to say, okay, I'm working on the heading component, whatever. Okay, so I'm going to tweak the the twig markup. I'm going to, I can see where the the demo content is, I can tweak the CSS. And so you can see how this can really add some efficiencies. And I'm going to show you what this how this works here in a second. Okay. So that's our pattern lab style guide in the in the beauty of it is that we've got all of those components already integrated with the layout builder blocks. And so you turn on the layout builder blocks, you don't have to spend the extra time doing the integration twig and things like that, you're able to just immediately jump into their branding work and maybe, you know, adding new custom components, things like that, not spend time on these really common components that we don't want to reinvent every time. Now, one of the things that we did recently is we saw that we had a little bit of documentation sprawl. And so we spent some time gathering, gathering together some of the documentation. So because we want to make it really easy for people to leverage this kind of system. And so we've got a full get book. It's the official documentation from the the triple dot org project page. And we've got a lot of information on how to install. So if you want to just try this out, we've got links to or we've got information on how to download the get repo, install the demo, see, evaluate it with all the stuff turned on. And then if you're ready, you're like, yes, I want to use this. And you want to create a real project, you're not going to want all the demo craft. And so it'll show you the commands for how to set that up. And then you turn on just the features that you want. We've got documentation on how to add content. And so we tried to be as comprehensive as possible. We're going to still be adding more, but I think it's pretty helpful. It says we've got documentation for the content types for the different layout builder components, show you how to add those. And then we spend a good amount of time on the theming pieces in particular, because Drupal theming can be tricky. We offer advanced component based training, training we did that this week. We know it can be real challenging. And so we've got some documentation that makes it easy to ease the commands to set up your new theme that uses the rain theme as a starter kit. And then we show you how we kind of inventory all the different components and show you where the pieces are. So you can be like, okay, the accordion component is tied to the accordion feature that's an optional feature. So that needs to be turned on if I want to use that feature. And this is where the component is. This is where the integration is. This is where the library. So if you've done any Drupal theming, you know, there's like a lot of pieces to it. And so we try to point out where all that stuff is. And my hope is that, you know, this is going to help onboard new people so that they can leverage the system just like our developers. And then I know this is a little bit technical, but just to show you what stuff looks like here. So all these different packages are in a Composer template. So if you're worked in Drupal, you're probably familiar with Composer. Drupal has kind of like an official Composer template. And ours, our template just extends that. So we add the different rain packages. And, you know, it's your Composer template. It's your Composer file. You can modify it, remove, add, do whatever you want with it. Again, we don't want Cruft. We don't want you feeling like you're married to any of the pieces. It's like, you can take it out. You can replace it. You can do whatever you need with it. So that's basically the rain demo. In terms of like roadmap, I don't have a roadmap graphic, but what we're planning on doing is adding, you know, some more documentation, more like video snippets to help. Might do like a full curriculum based on the Gitbook, things like that. You know, I watched the Dries earlier this morning. I know he's big on empowering site builders. And we're kind of of the same mindset. So I really enjoyed that. And so I think, you know, this will evolve if distributions aren't the best vehicle for this. You know, if it shifts to like starter themes and stuff like that. I mean, we're going to stay on top of that. And, you know, we'll adapt the system as core, you know, evolves over time. We'll adapt the system to that. So that'll probably be on the roadmap in the next, you know, year or two as we kind of get a picture for what they're trying to accomplish in core. Okay, so some of the key takeaways here. We don't want to shortchange the foundational work, right? We know we have limited time resources. We've got to we've got to do the functional work. That's the day to day stuff. But we also have to invest in the foundational work that's going to be with us for years to come. That's going to grow with the organization. We want to avoid fragmented experiences. And that's definitely easier said than done. Many organizations struggle with this struggle with having systems in place. It's one thing to have like guidelines. Guidelines have been around forever. And yet people don't follow the guidelines. Like you've got to empower the users, give them the tools. So we covered a lot of the deliverables from the creative team. We're trying to empower them with templates and things like that. And then on the dribble end, we're trying to give them the tools so that your content authors, you know, they're brand ambassador brand ambassadors, we want to make them not have to think about it. It's like stuff's going to be on brand because they're using the tools. The tools are easy. We've onboarded them, we've trained them. And we're going to stay on brand and avoid those fragmented experiences. So again, to summarize, it helps teams, the systems like this helps teams build faster, understand components, processes, create that consistency. And then of course, the tools to execute faster. So I made the case for style guides made the case for using a theme system, like what we've created with our distribution, you know, adopting some of these blocks and content patterns, and using these tools to again empower our users. Alright, now I will cover a couple links and resources. I'll make sure we post this on our Twitter account, the slide deck, just so you can have these links. So I mentioned earlier, I'm big on the component matrix. I think that's a really good tool, really good organizational tool. And so we've got a little template that's a good example for how you could use something like that. We've also got a template for if you're looking at a, you know, a new brand strategy, we've got a good template that kind of helps you organize that effort. We've got a link to that. And then, of course, our Drupal.org project page where you find out more information about the distribution, you've got a link to that full getbook documentation, would love your feedback on that. And then as I've said, I'm not a designer, I'm a triple developer by trade, but we've got a lot of good content on our website that if you want to know more about, you know, deeper dive into design theory and all that kind of stuff, we've got great resources on that. So I've got a couple links to presentations there. Got a lot of information. And so I'm pretty easy to find. I've got my email up here. We've got more media current folks at the booth if you want to talk more. And then I'll open the floor for questions. So Shrop's got a microphone. If you want a microphone, great. If you don't, if you just want to shout out the question, I'll try to repeat it. And then if you don't want to ask your question in front of everybody, you can always talk to me afterwards as well. So I really appreciate the time and I will open up the floor for questions. And yeah, we can hand the mic around. We'll try this. We'll see if it works. Is it on? Yeah. For the rain CMS, do you do the maintenance and support for the like the module updates and like all the dependent modules that it uses? Do you do the maintenance and support for that? So the question is like we media current do the the updates for the rain distribution. So like yes and no, like we make updates to it. But then you still own, you still own the composer update. So it's sort of up to you whether you want to stick with the updates to the rain projects. Like we'll change major versions from time to time. And so you can decide, okay, is it worth it for me to stay with those updates? One of the bigger advantages of using the rain packages is that we do abstract a little bit some of the dependencies. And so like rain core will have several dependencies sort of managed for you like meta tag and these different kind of common contributed modules. We've got shops like a garter distribution. It handles security hardening. So you don't have to like think about it, which is really nice. And so it can be an advantage to delegate some of the management of that to to these packages that we offer. But if it ends up being sort of a burden, you don't like it, you can detach from that at any time. And you still own the the composer, you know, a file, the project composers, what we call that. So I hope that answers the question. Hello, young sir. What is your question? So if I heard you right, Jay, during the design process, break away from the tradition of sending flat mock-ups and instead start with rain, theme it to their design system and style tiles and mood boards and all that fun stuff and show them a live version of that first page along with the way that they can edit it in the back end. And that speeds up the entire process. Yeah, so to summarize, I think it's an advantage to be able to even though I still think, you know, Figma and envision and so these different tools that show you design comps, like those are still helpful, we still do that. But it is an advantage to show them something real that's in the browser. And so we want to get to that as quickly as possible. I think it just helps the whole process. And so yeah, if we're able to leverage a system like what we do, where we have all these block types that we can leverage and get them themed and show them stuff in the browser, you know, a big thing with clients too is they they're always very eager to get going on content entry. And you're like, okay, well, you know, call me in two months when things are ready for content entry. It's like, no, we actually need to build content a lot sooner. And so if you are able to build in Drupal and not just deal with flat mockups for two months, if you're able to get things in Drupal more quickly, then you're also able to hand over content entry. So that's another big advantage of that. So this doesn't deal away with the whole process that you're of, you know, design comps and things like that. It just I would say it helps you get past that stage more quickly into actual Drupal development. And so you don't have your project team that's executing, you don't have them all staying standing on the sidelines waiting for the creative process to run its course, like you can get them involved much quicker. Who else had questions? I know we had all right, let me take one. We'll go back here. We'll get around as much as we can. Appreciate you shop. Yeah, we'll we could there's more questions we have time, but we'll definitely have time. My question is about what level of web accessibility rain has in it? Um, so that's a good question. So one of the things that we've done, because we have made some changes more recently, is that we're going to do another full audit. We've done it in the past, but we've made some changes recently. And so we've got a developer tasked with going through in that process has started. So we're going to go through in the in when we've completed the audit, we're going to show in the good book, like the tools that we use and what the results were are and what like level of compliance, it'll probably be like WCAG to, you know, whatever. And so the answer is it's we've we've done it, but we've got to do another audit update. Yeah. And so the kit books going to show you exactly what what we've done and that'll be soon. All right, who's yeah. Do you have any use cases where you're using your design system molecules, uh, outside of Drupal? So like in a decoupled scenario as well as a Drupal site? Yeah. So the, yeah, the question being, can you use it outside of the Drupal system? And I forgot to mention that earlier, but you know, pattern lab you can use outside. We have some organizations that that have a single source of truth kind of style guide design system. And it's, you know, easier said than done to be able to share that with different technology. Um, but it's something to look at. It sort of depends a little bit on how compatible some of the other, uh, web applications are with your design system. So if it's in pattern lab, is it can, is it compatible with twig? One of the things I was talking about with some developers in that we've kicked tires on is story books are very popular, uh, react based tool and, you know, some have integrated it with, with Drupal. We've looked at done proof of concept things. Um, I'd like to see, I know some different developers in the community, um, I've talking about it this week have done some extra work on that. I'd like to see that it's like, not just, it's past like the proof of concept and like actually getting it to work in large production websites. But the holy grail for me is storybook working in, in Drupal. Because if you're able to get, uh, have a single source of truth, storybooks popular, again, react based tool, if you're able to get it working in react and like a Gatsby site, something like that or next jazz or whatever, and then be able to share that with, uh, in Drupal integrated with twig. It's like technically possible. Um, you know, and, and then other applications, right? Uh, other applications that you might want to integrate with. And so, yeah, I'm, I'm some organizations we've worked with have done it. It's not trivial. And so you really have to weigh the, you know, pros and cons of it. But I mean, you really want to be able to leverage, uh, the, the style guide, I guess, wherever you can, because it's just a major advantage to, to have that single source of truth. Some good questions. Who's, who's up next? Questions? Okay. Okay. So the question is, are we, so we talked about layout builder. Are we locked in to layout builder or do we have integrations with paragraphs? So our previous iteration of, of the rain distro was paragraphs heavy before we felt like layout builder was in a good enough spot that we wanted to transit transition to that. That being said, we do have an approach that's very paragraphs alike. So, so in the demo, there's a content type called landing page, which is kind of similar. And we have a sample page. That's the homepage. Uh, let me see if I can find it actually. Okay. Let me show you showing easier than telling here. So we have the ability to do something that's paragraphs like is what I'm trying to say. So here's our alternate homepage. And so it still uses blocks, but it doesn't use layout builder because we wanted this to be possible, right? So it, you know, we do have a project that, that uses layout builder where they decoupled site. There's some limitations and some extra complexity with that. Maybe you wouldn't want to do that. And so this type of workflow is really good in some cases with the coupled, or if you just prefer this type of workflow where you have the different components and kind of a list format, these are the exact same block types. They're themed the exact same way. Everything looks the same visually, but then for the authoring side, instead of using layout builder, you're using this tool, which is, it looks very similar to paragraphs. It's just using inline blocks. And so we do, it is able to do that. It was pretty simple to set up, but that was something that we, even though we're doing mostly layout builder stuff, we wanted to have that alternative approach still available. Okay, question. Okay. So the question is, let me try to summarize it like, okay. So I can, I can tell you our methodology with how we handle the distribution because there's a couple different approaches. You can have kind of the starter kit approach and that's the approach we went with, or you could have the approach that this is like a system where we do want to inherit updates and be able to take advantage of the new features. We opted for the kind of starter kit method, even though it will be possible to add different features, but like if we make, let's say we tweak a configuration in one of our features, there, you won't inherit that configuration. The configuration is sort of one and done when you install the site. So it's meant to get you up and running because we, we didn't want a situation where we're having to support all these different sites doing different stuff and like worry about downstream updates, like breaking stuff. And there's pros and cons with that approach. And so we didn't want to feel like there are tethered to that and stuff could break. And even on the theme system, I don't like Drupal like sub theming necessarily, it still takes the starter kit approach where it generates the theme and you own all of the code in that theme. So you modify, you don't have to worry about, oh, I'm using a base theme. I mean, there's lots of base themes in Drupal and they're fine, but if you've ever used a base theme, you have the issue where they make some major updates and then it breaks your theme and then like everybody's mad. So we didn't want to deal with that. We wanted to speed up the process to get the project done and not have to worry about downstream updates, breaking stuff. And so you do inherit like the composer dependencies, but that's sort of it because again, flexibility was like our mindset. So hopefully that answers your question. Any other questions? Okay, question. Yeah, that's a great question. So the question was how many components do we have in the design system? How many actually get used with clients? And so I would say first answer is there's a bunch. There's a bunch of just components because we have, we separate some base components and that could be like breadcrumb component and button and stuff like that. So there's a lot of like kind of global components. Those get used a lot. And then there's what I would call sort of the optional components. And those are the ones tied specifically to the layout builder blocks. And I think we've got around like 15 or so it'll fluctuate and we like continually add will even remove it will remove some if we feel like nobody's using this feature. And so as far as clients, initially, it was difficult to get people on, you know, bought into using a lot of the pieces. And so we've slowly as we've gone along, gotten developers on board with using leveraging the different pieces of it so that they are using more and more of the out of box block types extending them, even if they have, you know, need to make changes, that's fine. What we don't want is like a situation where people are doing the same types of things, but in a different way. So you have you hand the same like design comp or requirements to like 10 different developers and they like have the same sort of ish block type, but it's like named differently every time. And it's like, it can be really confusing, especially like an agency where we have people bouncing around in different projects. So you wanted to establish some patterns. And so in terms of like how many we utilize on on projects, I think we're seeing in more recently as we've really grown this system that there's a lot more utilization like of those block types. So because we really tried to target those really common features, you know, heroes and cards and things like that, they're so like ubiquitous with like web projects, like we should be leveraging those like we shouldn't recreate stuff that looks exactly like it. So, you know, it's sort of mixed, you know, some projects that are like super hyper custom, we might use less. If we have a project like the one that I mentioned earlier, that's really really happy with our base components, they're like using all of them. And so it varies a little bit, but we really encourage our team to leverage as much of that as possible. Okay. So the question is, is it easier to extend a component or add a new one? And then does that cause problems with updates? So I don't think it would cause any problems with updates. Again, we're trying to do the model we go with is like the starter kit where it helps you get started, but you're not tethered to like updates down the line. The way we built it is that in my opinion, it's a lot easier to modify something that's there because we modify cards and stuff all the time. We had different layout options, we add fields to it, but in my experience, it's so much easier to add, you know, one field at a time. And so it's okay, I'm adding a field here, I'm modifying a twig template here, I'm modifying this CSS a little bit, you know, I know where everything is because I've looked through the get book and so I understand how the thing works. And I just find that you save a lot of time doing that myself. Now, we still create new block types, new components, and things like that. You don't want to shoe horns, you know, try to make a block type like do too many things. I think that's a mistake. You want to try to limit, you know, how much a single block type like what it's trying to do. But I found it that it's really helpful. And I think that's been the experience of the developers. Alrighty, well, like I mentioned, if you want to talk to me afterwards, you didn't want to say your question in front of everybody, I'll be here for a few minutes and then I'll be back at the booth. Thank you very much.