Podcast audio transcript

[0:04] Hey now. Welcome back to the drupal Ey podcast. This is season 17, episode 4. My name is Mike Anello, AKA Ulta Mike, and in today's episode, I'll be talking with a friend of the podcast, Ted T-Bone Bowman. We'll be talking about one of the premier planned features of drupal CMS, AKA drupal Starshot, experience builder. In fact, TED is here specifically to answer all of my personal questions about exactly what Experience Builder will do. We'll also learn a little bit about its current development progress. As always, please keep drupal Easy in mind for your project coaching, drupal migration, and long-form drupal training needs. Learn more at drupal Easy.com. Welcome back to the drupal Easy podcast. Ted Bowman, never a stranger. How's it going, Ted? Pretty good. How about yourself? If you say so. Yeah.

[1:26] Uh, yeah, mostly, um, trying to think, I feel like we've done some stuff through contrib, but mostly that, yeah. And, you know, you were actually a co-host of the Drupalpley podcast for a while as well. My glory days. Yeah, that was one big time. So, these days, and for, I guess, the past years, how long have you been working on Experience Builder? Well, I've been actually like working on the development of it probably just since this summer. Uh, maybe a little before that. I've been looking at like the space as far as, I don't know which drupal kind of has announced that Tres was like, you know, sort of need to revamp the page building experience. So probably since then or a little before I've been looking at the space as far as like what competitors are doing. What people expect outside of the drupal community, as far as when they see modern page building tools or I don't I don't know if they always think of them as page building, but like visual web building tools, what they expect from like a marketer standpoint or like a developer standpoint, what do they expect to be able to like make something that'll integrate with that tool. So probably for like a year on and off.

[2:41] So was this always meant to be Like Layout Builder 2.0 or Layout Builder, the Next Generation, or, Layout Builder 2, Electric Boogaloo, or Layout Builder Revolutions, I guess like it was Builder Attack of the Clones. I have a few more. Let me finish please.

[3:02] It was tackling a lot of the same space, but it was, and we did look at like, you know, should we just make the current layout builder better. But it was really, I think, hard to make that work with what people, I mean, obviously, you know, layout Builder's gotten better in core, but also especially to the contribute space over the years since it's been there. But I think it's hard to build. What if you didn't already know layout builder what people sort of expect in this kind of tool within the current sort of layup folder framework of and also of like building a tool that's gonna be rendered by the server side and PHP. So, I, I think what you're saying is, if you have. Knowledge of using Layout Builder and how Layout Builder works, that's almost Like you don't want to call it Layout Builder too, cause then people might expect it to act like Layout Builder just evolved. And it really shouldn't act like layout Builder evolved, is that kind of what you're saying?

[4:09] Like a like a fresh approach was needed. Yeah, it's not like we want sort of lay let's let's turbocharge layout builder. It's like let's look at what people I mean, one, what people sort of complain about or want in the drupal community, but also if we want to draw new people in, you know, they're not gonna know layout Builder and say, oh yes, this is, you know, layout Buer 2.0 is very much better than Layout Builder 1.0. They're gonna say, this is either as, you know, this is similar to the tools and I can do the kind of things I can do in other tools, or I can't, you know, or it's, I can, but it's much harder to use. There's, I think, yeah.

[4:48] So let's, let's position experience builder first. So, Experience builder is just a part of drupal CMS. The two are not the same thing. There's a lot of aspects to to drupal CMS or Starshot, code name Starshot. Experience builder is just one slice of what drupal CMS is going to include. That's fair to say, correct? Yeah. And I've, I've, you know, I haven't been involved lately, been pretty heads down with experience builders, so I don't know the scope. I mean, I know the general scope of drupal CMS, but like it could technically like it's not. Dependent on experience builder as far as like it's integration with recipes and just sort of trying to make a better experience for, you know, people who are starting out with Drrupal. It does seem like it's, it's one of the, if not the flagship feature or Kind of premier feature that folks are talking about though when they talk about, talk about CMS though, isn't it? That's, I think that's fair to say. Sure, yeah, but I think we could launch launch either one. Like either one would be a a big improvement without the other. They'll be better together, like, I don't know, chocolate and peanut butter, whatever, but chocolate is is good without peanut butter and peanut butter is good without chocolate. Yeah, yeah, preach, preach, my brother.

[6:14] Absolutely. All right, so I think we've already done it, but how would you, you know, for someone who is, is, you know, outside the drupal community, how would you explain experience builder? Yeah, so it's, it's, you know, eventually it will be an easy way to create dynamic pages and also to control the look of other parts of your site. So to let you start to create with visual patterns that you may be seeing in other tools, things, I mean, not exactly, but things like what is the big one Squarespace, build. IO I think is Builder IO is another one that if you're a developer but not within drupal, you might know where you drag on components and then you sort of connect up the component properties to either static values or data sources that you get from somewhere else. And in a lot of the case for drupal, especially.

[7:02] With the sort of first generation experience build will be, you know, be pulling it from the drupal data model, which drupal is very good at, uh, you know, setting up structured data, and so this will be sort of combining, that structured data with a more sort of modern way to build a page building experience. Yeah, it seems like, you know, in following the weekly progress updates that your colleague Wim Lear's blogs about. It seems like the development so far is like very much heavily focused on integrating, JavaScript components, or maybe not integrating maybe isn't the the right word, but building experience builder so that it can just consume a JavaScript component, have it appear in the interface, and then, somehow connect to to the data that your drupal site has.

[7:58] Am I, am I paraphrasing that properly? Yeah, I mean, so right now we're gonna start with uh single directory components and so you'll be able to make or take an existing single directory component. I think there are certain Things that we need as far as like how the properties are defined, but I'll, I think a lot of them should be either compatible or, you know, upgradeable to it, because we need to sort of know, what your properties are, you know, you can't just say, I have a property called title. You have to tell us it's a string. Let me make an example. Let me, let's do like a little thought experiment example. The way I Believe things are going to work based on what I read and hear. Obviously I'm not involved in the, in the development of Experience Builder at all. But it seems to me that, let's say you, you have a, a content type on your drupal site called Call to Action, right? Very simple. It's got a title, maybe that has an icon, and, and, and a URL. Very simple, right? It's got 3 structured data, it's like we always do content types, 3 drupal fields, all that stuff.

[9:01] You go to the experience builder interface or whatever, assuming that there is a call to action single directory component available, you drag that into the working area or the page or whatever. And then somehow you indicate that the CTA icon field from your content type should go in the CTA icon field of your component. And you kind of link things that, is that what I'm Yeah, except the developer of the, Component doesn't necessarily need to know about the content type and the developer of the content type doesn't need to know about the component. No, yeah, absolutely. So the content type, it doesn't matter what kind of content type it is. They can drag over that a CTA component and then just map three similar field types into their component. OK, so does that, so that kind of means in my head, that means that.

[10:00] Experience builder or maybe maybe it's more of the drupal CMS thing is has to kind of ship with a bunch of default kind of single directory components available. Yeah, so right now we are shipping with some, not too many, but then the Starshot uh design demo will ship with a bunch. So I was just actually testing with it yesterday, so Starshot would Which ship with a bunch of components and they should just work inside Experience Builder. All right, so I think what you just said was Experience Builder itself is gonna have a few, but then Starshot slash drupal CMS is gonna have.

[10:45] Yeah, and I think it's to be determined how much starshot or how much experience builder would that actually should. We need them now because we need to be able to test it and but I think that's flexible. We could take most of them out and put them all in test modules if we need to, to just test it, or we could leave some building blocks in like we think, well, everybody's gonna need like a header component and an image component. And maybe some particular layouts, but then a recipe may, you know, include modules or a theme that have them, so Starshot will have some. I'm not sure where they, I think they would be included in a theme that comes with Starshot and the drupal CMS. But eventually, we want to get to the point where you can import like a design system where somebody made a bunch of SDCs and they're not in a drupal module. And you're gonna say, OK, here's my folder of my design system, and then we would import them into components. And I think initially, yeah. It seems like there's a lot of effort going into experience builder, you know, lately in the past, you know, 3 months, whatever it's been to lay the groundwork for that. Yeah.

[11:55] Yeah, cause we don't want to get to the point where like, we want that to happen eventually. And then the like the data model that we have underneath it really doesn't support it. And then we, you know, we shipped the first version that's usable of Experience Builder and everybody, you know, a lot of people are using that. And we were like, oh, we didn't really think about how this or that was gonna work. So we're gonna have a kind of painful upgrade path and sorry. We want to support, you know, Importing a design system later, so we made a mistake. So we're really focusing in my part of the backend team like on the data model, making sure it can support these things that we maybe won't support in 1.0, but won't. It won't be a pain to support them later. Yeah, I look at some of the, the issues that mentions in his updates, and, you know, the ones that you're involved with and some other folks are involved with. I mean, they, they take a significant amount of effort just for me to understand, like, what, what the task is.

[12:59] Yeah, it's too. It's a lot of like configuration. It sounds like it's leaning heavy on the configuration validation work that Wim I know has spent a ton of time on. Yeah. And I can only assume that a lot of that work is so that when other non-SDC components are made available, that the properties that they expose can be properly made available for linking with drupal IA. That's the way I think about it. I don't know if that's the right way and it's not like, yeah, I mean, it's to lay the future work, but also so that people who make SDCs don't have to. Know that much or presumably anything about the drupal, how drupal stores data. They can sort of, OK, somebody new to drupal could come in and say, OK, I know JSO schema, so I know how to define my properties, and then, you know, drupal will be able to find, hey, here's a field or like here's a content type that's gonna match that, whereas we don't want people to be like, OK. You know, you're gonna make SDCs, but then you really have to know all of this about the drupal data model. So the fact that that'll be easier for the connection sort of on the fly and sort of we look at your, Drrupal data model and the fields that you have, then we look at the components, then we say, OK, these things match up, means that eventually later, yeah, if, if they weren't SDCs, we would also be able to match them up.

[14:24] Yeah, this is great. So I think it's perfectly clear to anyone listening right now how easy this is all going to be for someone coming from Nick.

[14:33] Well, let's, well, I want to go to the other, I want to go to the other side, because for me, like what we just talked about that, that to me, that's the most interesting part and exciting part, I think. But the other side of it is, you know, it has to be easy for folks. To use for non, for people who don't speak Drupales to use. And correct me if I'm wrong again, um, I think a big part of that is when you are actually using the interface and you're moving components onto the page, it's not like in Layout Builder, where you're just kind of bringing this generic block over. You're actually bringing a fully rendered preview of that component on, and as you hook it up, your data is going to appear there. So it's gonna be very You know, I, I don't want to say what's the right word. It's I'm thinking realistic, but that's not the right word. I you can probably come up with a better word, but it's gonna be, you know, very accurate to what the final product's gonna be after you hit save, I guess. Yeah. And, you know, you're gonna be able to drag them on and then when, you know, they'll be an edit in the right, so you can add the values, and then you should see the values like updating as you switch the image or whatever. You should see them to update in the component, which I think Layout Builder currently doesn't have, and I think even like.

[15:51] Even if we were, I know, I did some experiences with trying to do stuff like that with layout folder, but it really requires going back to the server to get that to work. So because the components are sort of defined well as far as their, you know, what the schema is for them, then you should be able to do a lot of the previewing without going back to the server, a lot of the update of the preview without going back to the server. You said should. I just, I just want to note you did say should. You didn't say well.

[16:22] You will be able to for a lot of it, but I say eventually, maybe we'll support like generic blocks because we want people to be able to import blocks that, or use blocks that they've already created for their site. So for some things that we might support that are more Drupalisms that say you didn't make an SDC for it, but you have a block that used in Layout Builder and you want to use it in in Experience Builder, eventually want you to be able to use that to make it easier for people to migrate to Experience Builder. And so that kind of stuff probably will, you know, require a back a request to the server to re-render it. So we're not tackling that part of it now and so I think that's sort of to be determined how that preview would work. You know, I meant to ask you something earlier, and I forgot, just popped in my mind. I think it's still a valid question though. I know at the very beginning of all this, and Reese may have even mentioned something like this in his keynote in, where were we? Where's the last drupal found? Portland? Yeah, Portland, yeah. Yeah, earlier this year in Portland, where experience builder, you know, would, would bring together the best of layout builder and paragraphs and visual site building. Yeah. So, is that still You know, like I, I understand like the layout builder stuff. The best of paragraphs is that just in saying that, well, a paragraph type is kind of like a component? Is that kind of the idea there?

[17:47] Or is there other, is there other functionality of uh experience builder that is more paragraphs like?

[17:54] That's always stuck in the back of my head for some reason, that phrase, and I'm just wondering if it's still valid. So I'm not sure eventually what the plan will be like, will you be able to like just, you know, put paragraphs into Experience Builder as is? Presumably you should be able to do that with work. So in that way, maybe it could be the best of and that and that you could take your existing work and put an experience builder like I have no idea where that would be though in the roadmap or if that would just be, make experience builder flexible enough so you could make an experience builder paragraphs. Um, model, but I think a lot of like some of like what I saw in the paragraphs ecosystem when we were looking at like.

[18:35] In turn, you know, like in the drupal community, how people solve this and externally how people solve this is, you know, paragraphs has the ability to like put, have a sort of layout paragraph. So you can put that onto a page and then it has like a nested layout and then you could probably put a nested one inside of that, right? So you're really flexible on the sort of how you build what in layout builder we called sections.

[19:04] Whereas in layout Builder itself, it's really hard to make sort of complex nested sections. But in paragraphs, it was easier, though I think still with the way that it's rendered from the server, like the UX is is hard to get really right. Like contrib has done a lot to make it better. But I think Experience Builder, we definitely, you know, started with like, you know, inside the drupal community, people have built. Tools for this sort of nested layouts and sort of on the fly layouts where you were sort of combining, you know, you have the outer layout and then you should just be able to drop an inner layout in there, and they really don't shouldn't have to know about each other. And so, you know, obviously like when doing a, you know, need search for experience builder, we saw that, OK. People within the drupal community need this. People outside the drupal community, like most of the tools have this, so it's like, well, we can't just not have, we can't just like build a, you know, page building 2.0 and just be like, well, we're still not going to have that feature.

[20:09] People wouldn't, it wouldn't feel the needs of what people want. So in that sense, it's, you know, part of it is, looking at the best, the best of paragraphs and the best experience builder what they both do really well and what people have like put a lot of effort into contribute into like expanding on each of the things and sort of making sure we can support those use cases inside of. Experience builder. And I think that's what, you know, we're working on now to make sure that the model supports that. As far as like, will you be able to actually just use paragraphs inside layout build inside experienceBuilder. I'm not sure. I think we're building it so that you could, but I don't know where that is on the roadmap as far as I think the the first conversion will be focused around STCs, I think. Yeah, and that seems like a reasonable starting point. Yeah, cause it's just a lot to to support all of it, yeah. So as.

[21:08] You know, I'm gonna use the word complicated, but. I'm talking more about like the development of this is complicated. You know, the, the end result, hopefully the for users will, will be the opposite, will be elegant and not complicated. But as complicated as the development of this sounds, what really kind of blew my mind, and it was a few weeks ago, and I just noticed you put, you mentioned it in the rundown that we have here, is that there's the concept of a component tree. So you can have a component. That is inside of another component, like so like nested components. So, first of all, give us like a an easy example of what that is. And what's the level of effort to go from just a list of components, you know, splattered on the page somewhere, to now nesting? Like, is that, is that like a huge like a huge push, or?

[22:05] A huge push for the user or for like for just to implement. Oh, it's, I mean, it's kind of baked in, so it's not really, I mean, once we set up the data model to be able to support that, then it's not like a, I mean, obviously we're not done with all of that. But the idea is basically, I think. Like in drupal core, SDC support properties and slots. I'm not sure that slots are used that much in SDCs and core, but in in a slot, you can put another component, you can put one component in another components slot. Yeah, that's the idea. And a property is just data that you put into it, yeah. Yeah. OK. So what would be, like, what's an example of, of where that would be used? Is that something like where you could have an image component to, like, you know, maybe it, it outputs an image in some cool way, and then you can use that image component inside like a I don't even know, uh, like a hero component or something or yeah, or call to action where you have the image, like maybe. I mean you could make your call to action like image and button where the image is just a property, or you could say, well, the image is actually, we're gonna call this a slot, and you could put whatever, you know, image component you want to put in there. Right now we don't have the concept of like restrictions on slots.

[23:31] Where we can say momentum though towards creating very fine granular components and then kind of building up meta components made up of those finer components.

[23:43] Or, or is it mainly gonna be, there's gonna be a CTA here are 3 properties, have at it, and if you want it customized, go mess with the CSS and the SDC. I use 6 letters in that sentence, that's pretty good. Well, I mean, I think the the idea is like how you might implement a design system. Experience builder is not particularly opinionated on that. Like we give the ability to, but then drupal CMS will ship with the design system, and it could be very opinionated about how it wants to set up the components. So I think experience builders should support like multiple ways of like, well, you want really fine grain components. Or really well defined ones, or maybe you just want very simple elements and then you build up a page from there. Experience builders should support like different ways of using it, but as far as, you know, if we're thinking of drupal CMS as here's something that we want it to be easier to learn and maybe maybe to be more opinionated.

[24:44] Like their design system probably. And I've just started to look at that because I needed to basically load test our experience builder to make sure, hey, if you have a ton of components, you know, what's the lag like or whatever. So I just, you know, downloaded or installed their design system on Experience Builder and, you know, wow, I see like tons of components now. So I think they will be more opinionated as, you know, drupal in general has been not very opinionated, especially when you install it. Sure. But yeah, but the design system, I think, which right now I think is more just a demo, but if I think eventually when you install drupal CMS it should come with a bunch of components. And so that is probably up to another team to decide, well, we want to build the components.

[25:32] You know, this way or that way, whatever the better sort of UX is. So, with all this work that the experience builder team is doing with SDC or in order to consume single directory components, has there been much of a change to single directory components as we know them? Like, has there been from the experience builder team saying, you know, it would be easier for us if this was changed with this the way single directory components are implemented in drupal core. I know we filed some core issues and we have a couple to do's in the code base saying like, you know, remove this when this core issue gets in. And I think, yeah, I don't think it's any huge stuff that I remember. Well, that's good.

[26:17] Yeah, I think it's just making sure the property is more well defined.

[26:22] Yeah, and we're just sort of expanding. The use case of what hasn't, you know, what hasn't really been used much before. I think there has been some pretty, there's a pretty big contrib ecosystem around SDC components. I don't say big, but like a few key things that always forget how to pronounce his name, his usernameellipso Matteo has built like, yeah, like SDC blocks that's really makes you be able to use SDC components in. Inside layout builder. So I think he was already probably pushing up into the limits and sort of like finding the limits and sort of like, OK, this is what we could, cause he was integral in SDCs in the first place. I think SDCs were already improving in court even before Experience Builder came around, so I think it's just sort of, this is a continuation of like, let's make them more useful. Awesome. So did we miss any anything big about Experience Builder in the last 20 something minutes? There should be a demo at drupalon and so we'll be able to see, you know, what it visually is gonna look like. Let's not mention which Drupalon cause I'm not sure when this episode's coming out, so don't say which Drupalon we're talking about.

[27:36] Yeah, that, that's most of it. And I think I'm trying to think there is, you know, it is installable now, especially if you get the drupal design system. I mean, it's, you know, it's, it's a 0.1 edition. So I'm sure, you know, it's not like, don't use it on your sites. I'm sure you'll find bugs, but, but I'm constantly in because one thing is interesting working on this is You know, I talked to the frontend people, but we're on different scrums. And so we're trying to make this so that, you know, we're making the data model and we're making the, you know, the API calls that the front end team can use, but they are sort of developing at a different speed than us as far as, you know, I don't. It's not like layout builder you kind of had to because it was sort of made the more traditional drupal way. You sort of see all the progress at once. Like I couldn't, as I was, um, building layout Builder, it's, it's sort of hard to not know what's going on, the front end changes. Where's a weird flex you just made. I'm gonna just clarify. There were other people who helped out with Layout Builder. It wasn't all you, Ted. Wait, I said when we were making, I was taking part in the making of yo. Well, that's not what you said a second ago, but it's OK. I was not the lead developer. I'll make sure people know exactly your role.

[28:53] That was a mere peon, a peon. So yeah, I mean it's interesting like, you know, I'm sort of rein constant reinstalling and like checking that something works and like, oh wow, this new UI part is like I hadn't seen this before. Like one example is like the side hierarchy or whatever now. Like a lot of tools now, you don't just see the preview, but you see like a hierarchy on the say left of all the components listed by name or whatever. It's sometimes easier for navigation or you give an idea of what's going on. So, you know, that will just pop up and that is sort of totally independent of what's going on in the back end.

[29:31] So, what has been, I'm gonna ask you 22 similar questions here, maybe you turn them into one, but like, what's been the most surprising thing and the most challenging thing about experience builder development for you today? I think the most surprising thing is the sort of separation between the front end and the back end and and the The idea that the front end as far as like, I'm aware, they're not like building something with like a restriction of like, how does drupal work and how does the data model work and, you know, they're building it more off of, you know, they are. You know, more familiar with front end development and also more familiar with like the UX of tools that people expect, people getting involved that like have no coding front in experience or backing experience, they're just UX people, and so they're building the sort of the preview design of how it should work. And so I guess leading with that as opposed to leading with how a lot of times we do stuff in drupal is like, OK, this is how it's gonna be stored in the data and then like, oh yeah, and this is how we want the user interface to look like, but the user interfaces, not necessarily an afterthought. I think Layout Builder kind of shifted.

[30:52] More in the direction of like thinking first how the user experience is gonna look like, but it was always sort of integrated with how the data model works on drupal, whereas we're sort of not expecting people. I think when you build that way, you kind of inherently even though you don't intend to kind of, It makes it harder for people to use the tool if they don't understand how it works underneath. Well, yeah, there's a, there's a bias that's introduced. Yeah, you know, yeah, yeah, yeah, absolutely.

[31:19] So building with the sort of UX first approach, I think has been the biggest change and, you know, positive. And how about the most challenging bit, uh, the most challenging is sort of from my, I mean, because now I'm sort of like the code owner of the data model part. So for me it's been basically figuring out. Like how to store all of this, where, you know, the basically the page builder eventually will just send us a blob of JSON and say this is what the page is, and we have to store it on the drupal side and basically uh making sure that it's going to work well with like, revisioning and make sure the data model is not gonna blow up or make sure that like storage is not gonna blow up incredibly huge. So like sort of. I think, you know, and I wasn't integral in this, but like determining like how we store the tree of like the components and the props that fill the components sort of separately, but in one field, uh different properties on the same field. I think that that's been challenging and then also figuring out like how to connect the schema that we know about from the drupal side, which has been getting better. I think it's been better over the years, you first started with API first, where, you know, when you want to like.

[32:36] Validate somebody, you know, updating the arrest, you need to know more about the actual data that's being validated, so you have to take a lot of that outside of forms and put it in constraints so that the data models more well defined. So taking that work and now sort of combining it with basically the SDC components where they define the data a little bit differently and sort of mashing those up has been. Hard, but it's the kind of stuff we want to do now, so we don't have to figure out later, while this is not actually gonna work. Yeah, that must be challenging because I tuned out about 30 seconds ago.

[33:13] It's challenging not to make that part boring. All right, two final questions. This one, this, I, you know, I'd like you to give a completely unofficial, this is Ted Bowman's opinion only. This is not an official statement from the Experience builder team. Give me a percentage. How far along is Experience Builder? Is it 50% done, 40%, 20%, 80%? If you had to just take a wild guess. Um, I don't know, maybe 30% done of what that first release will be, maybe. I don't know. I'm, yeah. And I'm not, I'm not even gonna ask you about the date. I'm not even gonna, I'm not even gonna, you know. What I am gonna ask you about, and this is, you know, the whole drupal CMS thing is super exciting. For me, I, I think you could do it like a 1.0 release with just Project Builder, automatic updates, and just a bunch of recipes. I think that could be a 1.0. Yeah. But that's, that's just my opinion. The piece of drupal CMS that I find incredibly daunting and scary just from a, as a community member is the styling and the browser. So, is there, is there, as experience builder is being built.

[34:33] Is there thought into how Experience Builder might interact with whatever that future styling in the browser tool might be? Yeah, I mean, my understanding is that will be experience builder. That will all be, that will be part of Experience Builder. OK. Yeah, like right now we're focusing on like the page building experience. Sure. But I think we don't want it to be a separate experience where you like, do your page building and then you go to some other tool to do like the styling and the browser. So we're Yeah, we're building, I think also like the storage model to be able to like store that extra information, even if like if experience building support that, if you had a tool that, you know, allowed you to do the styling and the other thing that I think also.

[35:20] One of the reasons we went with this component module or component sort of model of doing things is in the layout builder itself, like the sections or the layouts were separated. They didn't really have properties that you could set, so there was like layout builder styles which sort of hacked around that, but we wanted from default from like the get go, like if you throw on a You know, like a 3 column layout, that should be able to have properties so that you can sort of eventually put styles in there if you wanted to. So it's not. In, yeah, in layout builder like layouts and then things you put inside layouts were two separate things, where in experience builder they are the same thing. It's just some of them might not have properties, some of them might not have slots, but any particular component could have both. So I think it makes it eventually easier to do that kind of styling because at every level you have the ability to put that extra information, the properties there. And they're just properties. Like the styling might just be more properties on a particular component. Sort of. Yeah, yeah. I don't want to go too far down this rabbit hole. So yeah, I haven't really, I haven't really, we look to see that that would be possible, but I'm not sure how that's gonna be done. Elle.

[36:39] All right, thank you very much for your time. All right, thank you. This is fantastic, uh, exciting, and Yeah, it was great talking to you again. You too, you too. All right, we'll see you soon. See you.

[36:57] Thanks for listening to the drupal Easy podcast. Don't forget to check out all of our long-form drupal training courses at drupal Easy.com, and stay tuned for the next episode of the drupal Easy podcast.

[37:09] Music.