Talking Drupal #518 - Drupal Canvas

Lauri: This is Talking Drupal, a weekly chat about web design and development from a group of people with one thing in common. We love Drupal. This is episode five 18, Drupal Canvas. On today's show, we're talking about Drupal Canvas, what it is, and when we can use it with our guests. Laurie Timmanee. We will also cover starshot Demo Design System as our module of the week.

Welcome to Talking Drupal Today, our guest is Lauri Timmanee. Lauri works as at Acquia as a product manager. He's managing Acquia Source and Drupal Canvas. He's been actively contributing to Drupal since 2013 and has been a core committer since 2017. He has contributed to Drupal eight, the Umami demo, Claro CK Editor, five single directory components, Drupal CMS and more.

Lauri, welcome back to the show and thanks for joining us.

Thank you. Very excited to be back to talk about Drupal Canvas, which was called Experience Builder since we last, last, talked about it. Yeah. Yeah. It's funny.

New, new name. New new, new tool. It's, it's a, it's gonna be a, it's gonna be a good show.

For of you that don't know, I'm John Picozzi, solutions architect at EPAM, and today my co-host is Nic Laflin, founder at nLightened Development.

Nic: Happy to be here. Excited to learn what's changed in the last about, I think it's been about a year, and learn when it's coming out.

John: Before we get into our primary topic, let's talk about our module of the week.

To do that, we're gonna turn it over to Martin Anderson Klutz, a principal solutions engineer at Acquia, and a maintainer of a number of Drupal modules, recipes, and yes, even a theme of his own. Martin, what do you have for us this week?

Martin: Thanks John. Have you ever wanted to try out Canvas? Previously known as Experience Builder with a fully built out design system?

There's a Drupal theme for that. It's called starshot Demo Design System, and it was created in July of 2024 by a longtime Drupal list. Kristin Pol of Salsa Digital, and it has a 1.0 0.6 version available, which supports Drupal 10 and 11. It is actively maintained and has both security and test coverage and for documentation, there is a multi PageUp of the. Starshot Demo Design System also known as SDDS, including Contribution and Development Guides, does have 34 open issues, three of which are active bugs, and it is officially in use by 79 sites according to drupal.org, although I suspect most if not all of those are sort of local development sites. Now, some of our users may have already tried out the pre-release demo of Canvas that Fin Proximal posted on GitHub that actually has the starshot demo design system or SDDS baked in.

So even if you have watched a demo video of Canvas, you've probably seen SDDS in action. Now, SDS is itself built on civic theme, a Drupal theme built to act as a component-based atomic design system. As such, civic theme includes a rich component library built from published Figma and storybook UI kits.

And because some of the early bills for SCDS were for gov CMS, the Australian whole of government CMS project, it is accessible with WC a G 2.2 compliance out of the box. While the official purpose of SDDS is providing a platform to use for demos in DRE notes and other presentations to illustrate the progress being made on Canvas, I think it's also safe to say that testing the latest features of Canvas with a fully realized design system has also helped to identify issues in Canvas itself.

That means the, the products of all the work that has gone into SCDS will include a more production ready and stable release when that gets tagged, hopefully in time for Vienna. So let's talk about the Starshot demo design system.

John: Hmm.

Martin: I have,

Nic: boy, I have one. I have one question. I opened it up and I noticed as a web pack folder.

So is this a move in the direction of allowing themes where you can have a build process included in that?

Lauri: I don't think the SDD structure to demo design system is supposed to make any opinions about sort of the technology behind it. It's really what we always focused on, on that, on, I was involved in building that with, with Kristen as well from the canvas side of things.

The, the focus was how do we actually present component based design systems that highlight the power of canvas. And it was like, I completely leave it up to you how you want to build this use, you know, whatever tools you, you, you, you want to use. And they then decided that they would be using the set of tools that gov CMS are now blanking out.

What is the name of the t? Well, but is the name of the theme that is spelled the doubles. Civic Civic theme? Civic theme. Civic theme. Yeah. So essentially they decided to just use a tech stack. The civic theme is using, it's not really saying that, okay, this is better than another way of doing it. It's just one way of doing it.

And I think in, in a, in a moment, we're gonna talk about, there's also a Dr c, a mass design system called Mercury that is being built, which does use actually a built step as well, but there's a different set of tools that is being used in there. Okay.

So one thing that I always struggle with, especially with things that are very visual, is the lack of visuals.

When you're looking at like the, the kind of like the module page, right? So like, I guess from my, from my like, you know, small brain thinking here, I'm kind of like, oh, it's a design system, so I should be able to see like components and like how, how those things kind of go together and like what I might be able to build with this.

And I'm. I've clicked on a couple of links. I've gone down down a few of, of of the module pages, rabbit holes, if you will, and like, you know, I'm still trying to struggle. I'm still struggling to figure out like what I get, like what, what, what's a good, what, what components am I gonna be able to build with?

So, Martin, any insight into that?

Martin: So I think if you go to the civic theme project on there, it has links to the Figma UI kit as well as there's links to UI kits in GitHub and Storybook. So those are probably good places. If you wanna do kind of a, a visual browse, that project page also has links to example sites that will also give you a bit of a feel for, you know, how that looks when it's implemented for, I think it's got a default one, not, not exactly sure what that one is, but also government, higher education and corporate sites.

You can sort of see how that design system looks applied to kind of different verticals or use cases.

Lauri: So if you get into, I found it, the Figma, you can kind of see color schemes and different, there's also a

Nic: story about

Lauri: link different different stuff. Yeah. Okay. All right. That makes sense. Figma Figma Figma is not, not always the easiest thing to use, but yeah, you can definitely get a flavor of what what, what the goal is here, which is nice.

And so I think it's

Martin: maybe worth mentioning while we're talking about civic theme. You know, one thing that occurred to me as I was looking at the, the Starshot demo design system is if you were in the early stages of building a site that you figure is gonna launch a few months or even a year from now, and you really wanna use Experience Builder as kind of the layout engine within that, or sorry excuse me, canvas as a layout engine within that, then, then maybe starting with civic theme as your base theme is, is a good approach because there's a whole team that's, that's sort of working on the ongoing process of making sure that there's a layer to, to help Canvas run on top of civic theme.

And so that could be a good solution, you know, particularly if you don't have the resources to kind of do all of that integration with more of a custom theme yourself. Yeah. And

Lauri: SDDS is a great example of how you would implement one of those themes yourself, because that's an implementation of semi civic theme.

Nic: And, and that was actually gonna be my question. So what, what's the, what's the long-term goal for the Starr demo design system? Is it really just a kind of interim, easy way, easy way to test canvas and starshot? Or is it meant to be kind of like a long term, kind of like what Umami was before Starshot

Lauri: it.

So the SDDS was built in mind of just really creating different kinds of demos with it. Okay. It, it is a great way to test Canvas and to see how you would implement it, a design, design system, but it was not necessarily implemented to act as a starting point. As, as such, I believe that probably there will be.

Starting point themes. Civic theme might be one of those mercury another one that is being built. So there will be themes that essentially then fill, fill that gap as well. But they are potentially more generic in the, in the nature that hey, they are designed to be extended and built on top of, instead of being, just working as this we will be using SDDS going forward to do demos.

And, and I guess that's one way of getting a visual is watching the DRIs notes. If you watch any of the videos or where Drupal cameras is being shown there you would see SDDS. All of those were powered by it.

Awesome. Cool. Well, Martin, as usual, very topical. And we appreciate you bringing us this, this wonderful module of the week.

If folks wanted to connect or suggest a module of the week, how could they go about doing that?

Martin: We are always happy to talk about interesting candidates for module of the week in the Talking Drupal channel of Drupal Slack. Or folks can reach out to me directly as man clue on all of the Drupal and social channels.

Great. See you next week Martin. See you.

Lauri: Okay, Lauri. So Drupal Canvas previously known as Experience Builder, just in case anybody hasn't been paying attention or is just coming into this like, Hey, what is this thing? What, what is it? What does, what does it do? What does Dral

Canvas do? It is a, it started as a page builder project and then essentially from there we figured, okay, it's page building is actually a kind of complicated topic because that's really just how you put together that that's the end stage, the last stage of the delivery of like building something that you actually shit and.

Essentially it became experience builder from there because it's really about all of, you know what it takes to build an experience, and it's, so that means building components, building the whole visual design of your site. How do we make that as easy as possible? Because we realize that there's a lot of points of fiction in there today, and we wanted to create this new experience then for, for building sites.

And ultimately now it became then Drupal Canvas. Lately that was not really something we wanted to do. We, it was sort of forced upon us due to a legal issue. But on the bright side, it actually does open up the horizon to even broadening what, what it actually means that it can do because of especially now with ai.

Being this, this hot topic we've been looking into, okay, how do we actually adopt AI as part of this process? And it's very interesting to see, there's a lot of opportunity in there because of with Drupal Canvas, we've had to re-architect how the sort of admin interface is being built. It's being built with with React instead of purely being based on PHP.

That new architecture that we now have on Drupal Canvas actually provides a lot of opportunity to add new, new kinds of things on top of it. And I think that Drupal Canvas is a name is, is actually now great because it, it, it sort of allows us to go any direction that we want to.

Feels very creative, right?

It feels very like, hey, you're, you can just, you can just paint your pages and you know, you can add whatever you want. It hearkens me back to like, I don't know if this is gonna be either a dated reference or not, not a widely known reference, but Bob Ross. Like, I'm just, I'm just imagining building my Drupal pages now with happy little Trees.

Nic: So when, when will the, I, I see that the original owner of the Canvas, same space and Drupal and the Drupal Project, turn that over to this project. When will that re repository kind of switch take place? Because it, there's a lot of issues, there's a lot of code, there's a lot of references. Who, who's working on that?

When, when can we expect that to be finished?

Lauri: I'm hoping, fingers crossed it will be finished by the time that the episode gets out.

Nic: Okay. So next, so you're listening to

Lauri: this, you too can go to drupal.org/project/canvas and, and hopefully find Drupal Canvas right there. I'm

sure you will find at least. Part parts of Drupal Canvas in there if it is fully working, because it's gonna be very tight.

So, there's a lot of work that needs to be done. It's a little bit unknown because it's not something we've really done before. So, we don't fully grasp what all needs to be done, but we are planning to focus on that essentially between exactly. Between when we are recording this and the next and when the episode is, is out.

So I guess how that all works out, you listening, this will, will, you're able to find it out by just going to check.

Nic: I mean, I mean the, the, the, the, there's, there's two pieces to this. One is, you know, all of the issues and stuff moving over, which I'm sure, I'm sure the dral org team might help with. But I mean, you could always just create canvas as.

A sub module and then have a sub module that's called experience builder and just have canvas depend on that, and then take your time migrating stuff to the correct name space. Yep.

Lauri: We're, we're trying to take the approach where we go, this is all in, just do everything at once. And the reason that's because of, we are actually, we were supposed to release a beta at the end of July.

We, we actually completed all of the beta blockers by that time, but then sort of this new issue was discovered just around that time. And because of that, we really would like to, we're really anxious to release that beta release so that we can actually get broader adoption of canvas and, what we know is that makes sense. The more we can change before, the less pain it, it, it causes up down the road. Yeah. For us, I'm a big

fan of ripping the bandaid off. That's, that's my preferred, preferred method of, of doing things. So I can, I can understand that. Yeah. I'm curious as to where, like where did the idea of Drupal canvas come from?

Right? So like I know a lot of other systems out there have kind of this sim similar sort of page builder sort of, canvas idea. Right. And, you know, Drupal had, had, well had, still has, has a layout builder has paragraphs which have both been used for for this same sort of, same sort of task. But I'm wondering where, where the idea came from or is it really just like an evolution of some of these other things?

I don't think it really is an original idea. If you, if you think about layout builder and Drupal core, we sort of, tried to solve that in there. So we sort of were aware of the problem, but we didn't quite fully grasp all of all of the things that would have to be fixed. Where I became aware of this was in 2023 I, I, I shifted roles from being a framework manager for Drupal core to being a product manager.

And that's when I started sort of figuring out, okay, so what that whole problem space was, was about, and started getting a sense on like what all of the initiatives that were in motion, like what is the value that they're delivering to our users. That was automatic updates, project, browser and so on.

And I actually talked to first I think like 15, 20 different agency leaders, developers, site builders. I tried to get sort of the whole spectrum represented there. And what it was interesting was I was, I was really trying to learn about like, what, like what, how can I help them best with the initiatives that I sort of have in motion right now?

What's interesting was that everyone was sort of steering the conversation towards all sorts of site building and page building issues that they were facing. And then I went to Pittsburgh Pittsburgh later that year. They were, I think I was in June and, and that's when I sort of went in and talked to even broader set of people because I, obviously at DrupalCon it's easy to do conversation at scale and I just realized that, you know, this is a massive problem.

At that point, I was also a little bit more focused around page building because of, I had sort of heard about that. I wanted to dig deeper into that and just realize that, hey, this is a problem that everyone is concerned about. This is something that causes friction to literally every agency out there.

We're there essentially different agencies are wasting so much investment in building their own solutions around this, that this is a huge opportunity, opportunity for us to solve, solve this. Later in the year, this was announced as an initiative in DrupalCon, DrupalCon Lil based on just learning, okay, this is something we have to do.

We didn't have a full plan back then. We didn't know how we were gonna make it happen. I think we didn't fully understand the scope back then. I think it was only up until like maybe January the following year when it was like, okay, this is a, like, that's when we had done competitive analysis sort of drafts because I had to learn what this problem space is.

I actually have built page builders two times to a customer when I was working in an agency. Like I've, I've, I've, I've worked on it myself. Okay. But I was so disconnected being a framework manager from that, that I didn't really, you know, have that in my head. And I, I couldn't immediately say that, Hey, that's the problem we have to go solve first.

John: Yeah. So it

Lauri: took me half a year to learn, okay, what does this mean? What are our competitors doing? What is actually the expectation around that? And I think in January we realized that, hey. The gap between what we have is that, hey, we, our solution is, is here, and then the expectation is gonna be much, much, much higher than that if we, if we wanna compete.

People have, agencies have been solving that gap, like where agencies are, like, they're getting pretty close to where the competition is. Obviously there's a gap in terms of the experience. Our solutions are really powerful, but it's in the experiences where we've always been lacking a bit more. And that was where, okay, how do we actually now not only build a solution that is powerful, but has the experience that not only competes in, you know, 20, 24, 20 25, but also serves us going forward.

And that's when we realized, hey, the scope of this is massive. And so we

Nic: Oh, and, and, and was one of those require, it sounds like one of those requirements too is to make it so that site builders can interact with it, right? Because Yeah, because if it's a solution that only big agencies can accomplish

Lauri: Yep.

Nic: That, that doesn't help with the adoption of the lower end of the market.

Lauri: The goal was essentially set where a site builder, designer, and content creator, they, even if they'd never used Drupal before, they should be successful with this product.

Yeah. So that, I mean, that, that, that feels like the, like the MVP to me because, like similarly to you, Lauri, like I've, I've, in the past, I, I've, I started, I built something you know, a, a page layout tool with paragraphs very early on for a large insurance company.

And like that was very much like, okay, like here's, here's the, the component, which is just a paragraph that you kind of drag out onto the page and put it where you want. And like there are all these, you know, dropdowns that kind of let you to configure it. Right. And then, you know, more, more recently, the next, the next iteration for another client there was, was layout builder, which was, which was great, but like, ultimately.

Using Drupal Canvas, seeing demos, seeing Dre's notes. I'm like, okay, this is like, this makes a lot of sense. And this has to be, you know, so fluid for content creators so they can just pull out components and build these pages with without a lot of effort. So, follow up question here, I think is and, and this is kind of like, not, not in our list of questions, but like a lot of people, like, to me, I, I always liken I liken the, the page building experience to like Squarespace, right?

If you've ever used Squarespace, it's like super, super easy. Maybe not as intuitive, but like any, almost anybody could go in there and, and build a page, right? I mean in your, like in your thinking, is that where we're trying to get to where like, hey, you could install Drupal CMS and get in there and start building pages in this kind of like component, very easy to use sort of, sort of manner.

Yeah. That's definitely the future that we want ahead towards. We have an example of that, which is the first example where we are trying to lower the bar is we have code components in Drupal Canvas where you can actually create components using a built in browser code editor.

Yeah.

Which now you don't actually need to have an ID or development environment to be able to build those components in there.

That's just the first step because you have to start somewhere. But as the follow up step there, we will be adding more visual tools where even less technical user would be able to accomplish those things. Yeah. Obviously we have to lean into what is our strength. We are open source product and I, the strength, I believe that open source products is that it's, you can build great.

Environments for developers, site builders and content creators to collaborate on. Yeah. Because if you can build a solution where developers have much more extensibility than yet than you would have on a traditional proprietary solution, and I think that's the, the strength that we need to lean onto is, okay, how do we not just create a solution that is great for site builders and content creators, but one where actually developers can get a lot of value as well, where they, they can actually extend the tool as well.

And it's, I'm not necessarily talking about extensibility in terms of the interface so much more, more or integrations and, you know. Actual additional capabilities you need to add in.

Yeah. That, that's really where it levels up, right? Because with, with something like Squarespace, you are restricted to their, their set of predefined components, their set of preexisting integrations, right?

If you wanna build, as you said, your own components, or you wanna do your own integration, if you have like an ERP system or a third party system you need to integrate with, like Drupal provides, provides a great platform and a great framework for that, right? So, I mean, I think that's kind of where we, we, you know, we, we, you know, rise above, rise above kind of those mainstream solutions.

And it's, it's funny 'cause I, I was just at Drupal GovCon and I was having a conversation with somebody and I'm like, you know, Squarespace is kind of eating our lunch right now in the, in the like page layout. And they're like, no, no, no. Like we are, we are not competing with them. And I've heard that quite a bit.

When I bring, when I bring up Squarespace, it's like people don't. People don't really get it as far as like Yeah. You know, they have a, they have, they have the ease factor, they have the, you know, the, the person that doesn't necessarily need a super advanced site can go there and for a couple hundred bucks get a website that, that is really easy to build.

Right. But like, I, I would like to see something similar to Drupal because that, that opens the gates for those in intro users to get familiar and then come in into the ecosystem. And, you know, I think Drupal Canvas is a great, a great way for, for that to get started. Nick's muted and he is talking, he's gonna make a really good point.

I can see it in his face. Yeah. But

Nic: so, and Drupal does have a huge advantage over Squarespace. Right? And, and that is the information architecture, right? We all, we all know that the deployment, the stability, and if Squarespace could, they would've already built that on their system. Right. So we, we have that advantage.

We're trying to match the other end of the market, which is the page building experience. Yep. That being said, Squarespace does have a pretty big limitation when it comes to page building. And I'm curious, Lowery if Canvas has the same limitation or if we found a solution to it. And that limitation is that because of the flexibility that you have in Squarespace or Wix or any of these page builders, each page is kind of its own page.

Like keeping consistency or updating an existing component to look the same across multiple pages. Especially when you get past 20 pages. If you have a page site that has 30, 40 pages and you decide your CTA wants to change that, that can be pretty, pretty gnarly. So does Canvas have that same kind of limitation where each page is gonna kind of be one off?

Or is it. Is it still using components in such a way that if you decide to do kind of a bulk update to something, you can pretty easily do that?

Lauri: So we are supporting both approaches in with Drupal Canvas. And the reason being part of the research that I did was that actually because Drupal hasn't been very good with the sort of fully flexible solution, I've seen a lot of site-built where, where essentially the site builders and developers have tried to accomplish that very flexible type of experience by just trying to Jan it in the, in the, in the tools that they are provided with.

And that essentially because of they're not very, they're not designed to build that type of experience. It's actually leads into fairly complicated user experience. Like imagine building a full, fully baked out page builder in paragraphs like you can imagine, you, you paragraphs is not necessarily designed to for that.

It, there's great use, use cases for that, but just doing like a Squarespace level of flex flexibility in there is where you sort of go outside of, of what what is possible. That's where with Drupal Canvas we have where you can create pages essentially using your components. Components are already where you can control centrally how those components look like.

So you can manage the CSS essentially how they look like. You can update them centrally the pages that themselves are flexible and don't necessarily have any structure to them. The second way in which you can use those same components in Drupal Canvas is you can create templates. For example, you can create either page template, which is your header and footer, so that's where you use the same components, but you want, and, and you want the header to be the same across your whole site.

Very similar to block layout interval, but instead of having sort of a different building blocks in there, you're using those same components in there. Now, other form of template that we have is you can create content templates, which is where you could use a display. Your content types or taxonomy, for example.

And that's where you can create a template where it es essentially cascades across all of the nodes that you have in a single content type. And then you can update that template centrally for those. So that's how you get that scale.

Nic: So it's similar to layout Builder, where you can have like a custom template per per entity or per bundle, right?

So this, this content type has one layout, or you could say, Hey, this one, each time I create a page, I create a custom layout similar to that. It's similar

Lauri: with the exception that canvas doesn't provide right now, the per page overrides for oh, your content type. So you would use pages for that use case because essentially when we looked at how a lot of I, I talked to.

Over 50 people when I, when, when we did research on design, I, I like, it was very hands on. Like they would show me, okay, hey, this is how we built sites in here. And what we saw is that there was actually very few use cases where they would actually have like a fully built out template where they would do one of overrides in there.

It was more like, okay, they maybe want to provide a starting point in there or that they just wanna, wanna have that consistent layout across all of the pages.

That's, that's typically what, what I've, I've experienced as well where you have like, hey, the structured content pages, like, hey, my blog post page is always gonna be like, kind of like structured in this way.

And then you have kind of the I used to, I used to call 'em the flexible layout pages where like, Hey, you can do pretty much whatever you want here. Like go for it, go to go to town. I will say recently I was looking at layout builder and the ability to, use kind of a flexible template page, but have, and this would be a different content type, but like, have that be like templated where it's like, hey, these are the blocks that are on this page, and you can edit those blocks and if you really want to maybe move them around, but you can't, like they have to be on this page.

Right? Yeah. And there, there are some modules out there that can help with that. Yeah. So yeah, I think, I think you're right on with the, with the idea of like, hey, here's your flexible page that you can like build a layout page or a landing page with get go nuts. And then here's like your structured content for your resources, for your blog posts, for your events, that sort of thing.

Another variation of that we discovered is, is so sort of a hybrid, which is not supported initially, but we will have that in future where very common in the use case of products, for example, where if you're selling bicycles, for example, you wanna have like the skews, the name, price, maybe that like.

Different size options that you have. Yeah. Images on the top, and you wanna have a consistent layout for how the product is laid out. But then maybe after that, what follows is more like you tell a story about that bicycle. It's not really the specs anymore at that point. And that's where it's really marketing's responsibility to come up with what that content is.

John: Yep.

Lauri: And you know, if it's a race spike or if it's a mountain bike, the story and the way that you tell it might be quite different, right? If it's your flagship bicycle, you might actually put much more effort into that product. Versus if it's, if it's out of, you know, a, a bicycle that very few people purchase and you don't wanna put any marketing effort into that, maybe it's very, a very simple page at that point.

And so that's something we want to support eventually, is where you can do, do those hybrid pages as well.

Is the idea with those hybrid pages that you'd have, like almost like a canvas field where it was like, Hey, here's all your fielded data up top. And then the canvas field kind of allows you to drop in components pretty much.

But basically you don't really have to think about a field because if you're just building a template and saying that, Hey, here's a slot where you can place components, right? And, and behind the scenes we create a field for that. But as a user, you don't really have to know about that. Sure.

Nic: You, you, you found that solution pretty quick, John.

I'm, I'm, I'm impressed.

Lauri: It,

Nic: it's, I mean, it, it took, it took a fair amount of discussion to come up with the actual nuts and bolts solution for that. But yeah, pretty.

Lauri: It's something that I've, I've, I've played with before in the past. Yeah. It's, it's a, it it, when you get, when you start working with marketing teams, man, they want, they want those pages to do a lot of different things.

And then sometimes, you know, and, and I will say it's one of those things that I kind of implemented a little bit with like paragraphs. Like back in the day it was like, here, this is all like the static stuff that you have to fill out. And then here you can drop whatever paragraph you want in here to build out the very similarly Laurie's right?

It was, it was actually for a e-commerce site. So,

and, and this is actually a use case where paragraphs is really good at like, when you don't have to like, do full on like, like really complex pages like do for this use case, it works really well. Yeah. So, and that's what we want wanted to do is look at, hey, we have power graphs and layout builder that have their pain points, but also there are some things that they're really good at.

Mm-hmm. Obviously, because they are getting a lot of adoption. So we don't wanna be arrogant. We want to learn about what those use cases already work really well. And then, okay, how do we. Essentially provide a similar experience or better than that for those use cases.

It's, it's interesting to me 'cause you said, you know, that earlier on you said you'd, you, you had built various solutions for clients in agency life a couple of times that used a couple of different things.

And it got me thinking of like, man, once, once Drupal Canvas is kind of like out and, and kind of incorporates a lot of these different ways of using it. You know, the, the number of people that are, are going to kind of maybe migrate to it or start using it or be involved in it, is gonna kind of exponentially grow.

Which is, which is kind of, kind of exciting.

John: Yeah.

Lauri: That's definitely part of the mission is to build a platform that ideally multiple existing ecosystems can, you know, collaborate on now. So we could get folks from power Grass, from from layout builder and now build one cohesive Yeah. Platform.

That's awesome.

Nic: So. Getting, getting back to kind of the initial feature set, will Canvas itself launch with existing components and building blocks, or will there be a kind of a sibling module that you can install or, you know, how, how will the actual components themselves come into play?

Lauri: So, canvas itself is not shipping any components.

We actually removed all of our default components this very recently, probably a few weeks ago. We will have components in future we will call them elements. Those are sort of built in because they're built in, they're not really components. Components are supposed to be the ones that you, you all built in our, in your sites.

And so we, we'll have elements in future, but that's not in the initial scope for the project. But how components can be fed into Canvas is you can either use code components inside the, interface of Drupal Canvas or you can build SDC components and if you, if you get an SDC component, it automatically becomes available in, in Drupal Canvas.

There's, there's gonna be a new property in, in SDCs where you can indicate if you don't want them to appear in there. Okay. But, but right now that's, that's going to be there in 11.3. I think. Wait, until then, all of their SDCs are automatically in there. There's a UI that we provide where you can turn off components that you don't want.

Nic: So, oh, thank God. Because that, that, sorry, sorry, John. That, that's one of the biggest pain points of layout builder is that you have to like. Right. So much code to be like, okay, in this case don't show the 14,000 blocks that there, there's a module,

Lauri: there's a module that lets you just shut up. It only shows certain blocks and layout builder

Nic: at this point.

At this point there's a module. But if you wanna customize further, you u usually you have to have a custom module that customizes a lot of layout builder. So having an interface to be like, now is that global? Is it like either it's on or off for all instances of, of canvas or is it per per slot?

Lauri: It is on or on, on or off.

We are looking into per slot restrictions as well. And that's an SDC level capability we would be adding where the SDC itself could say that, hey, this slot can accept these components in here. Okay. So it would not be in this universal interface. Okay. Interesting. So, and that's one of the big mindset shifts for, dral Canvas is that we are really trying to think the frontend developer as a key persona using this okay. It's, it's, it is sort of the site builder can, can use what the frontend developer has done or the site builder might be doing the front end development then themselves. But we are thinking, okay, in both scenarios where you have a site builder using predefined components or you have a front end developer just, you know, or, or site builder building those components, how do we, and which layer do we need with what information?

And we are actually moving a lot more information to the components than what we've had before. In fact, like components really wasn't a concept in Drupal until like few years ago, until SC came about. And now Drupal Canvas is heavily using SDC and adding to that the s STC spec to have more capabilities such as like slot restrictions.

We're adding things like variance support in there. And now the option to actually, for the s the SDC author better Site builders, one developer to tell if the, if that component is internal component if, and if, if it's an internal component, it means that none of the display builders, so we are collab, collaborating with the UI suite folks as well, because that's another display building Yeah.

Solution. So we are collaborate, collaborating with them that the scheme that we are building around SDC is something that makes sense for both of us. And it's, it's actually a great way for us to validate as well that the, the things that we're putting in there, that there's sort of universal needs because that's a lower level API.

So it's not just sort of hardwired the Drupal canvas because of, you know. There's other things that can consume those components

as well. You, you, you actually said something that I wanna, I wanna dig into a little bit 'cause it, I don't know, it seemed a little concerning to me and I wanna make sure I understood you correctly.

So you said that, that you recently took out all of the default components from Drupal Canvas. So did they get moved to a submodule that you can enable or are they, are they just not there anymore? They're in a submodule. Ah, so they are still

there. Deleted. They're gone.

They can never

Nic: see them again.

Lauri: No, that's terrible, Nick.

That would definitely be a bad, bad user experience. So they're moved to a submodule. That was, that was the, the answer. Okay. So yeah, the

idea being just that majority of, in ma majority of scenarios, you actually don't want those mod components to be there. They're great if you're, if you're, if you're just testing it out, they're great for that use case.

Yeah. Actually. SDDS that was featured earlier, I think is even better because it's even a more realistic and more, more full design system solution. So, but if you just wanna test out a couple things, we're using them for our testing and, and things like that at the moment. Okay.

Sense. So if, if you, you, I'm just, I'm just like going down the future, the future path here, right?

So like if you install Drupal CMS and it has Drupal Canvas installed, right? Or, or enabled Right. Does is it also gonna ins enable those default components so you could actually start building pages.

So Drupal CMS itself is, is going to be delivering this concept of site templates in triple CMS 2.0.

And that's where, so, so the site template is where you would be getting those components from going forward, and that, that way the components that you're getting, they're specific due to site templates, the site template you want.

Huh. Okay. That makes, and now

maybe we can see how the different dots now

are starting to connect, right?

Yeah, we can, we we're starting to get a constellation. Yeah. The stars are, the stars are connecting. You see what I did there? Yeah. I brought it back to the Star Show. Nevermind. Continue. Constellation

brings me fun memories because of the internal pro project name for a product that we were building in relation to Drupal Canvas.

Was, is, is Acquia source, which is what I'm product managing on. And it kind of goes to the how as well, where we had to figure out, okay, how are we going to fund an effort that is this big? And we decided that we were gonna build a SaaS solution that leverages DRAL Canvas. And essentially we decided, okay, hey, the major stakeholders here are going to be our SaaS solution and Drupal CMS as the open source solution.

Sort of there became a constellation of those two efforts around DrupalCon Portland, and we, we decided. Building the two things at the same time. Aquasource launched in, in, in July and has, has Drupal Canvas already. We're supporting it internally in there. And what's actually interesting about Aquasource, why I see it aligns with Drupal CMS really nicely is that it's built on top of the same building box.

It's essentially powered by Drupal CMS.

John: Mm-hmm.

Lauri: And it's behind the scenes, so it's using Drupal. And what we actually allow folks to do there is you can explore your Acquia source site into a Drupal CMS site. And that's kind of where, that's Squarespace developer experience. All, all sort of, all starts to connect together.

Because if you want the Squarespace experience where, you know, you want to start with something where your marketing team just sets up something quickly together, you can go to Acquia source and it's a fully maintained SaaS platform.

John: Yeah. But

Lauri: if you run into a limitation with the sas, well guess what?

Now you can export that. Aqueous source side into a triple CMS side. And as a developer, you can do all of the magic that you can do in triple cms

or, or even like, you know, my, my kind of vision there is that like you start with aqueous source, right? And at some point down the road, you go up, we've outgrown this, we need to integrate with X system or Y system or whatever.

Yeah. Now you can take that and bring it to a, bring it to an agency, bring it to a, a Drupal certified partner and Exactly. And say, Hey, I need to work, I need, I need this to work differently. Can you help me with this? And, and you can, you know, you're not starting all over again. You actually have this, this aqueous source starting point basically to bring it into Drupal CMS or, or I would imagine just Drupal itself if you really needed to.

Right? Yeah. So,

Nic: so what's the, what's the pricing for Acquia source then? If I, if I have a, i, I have a couple of clients where they sometimes do like pop-up landing page sites, and if we could move those in Drupal, that'd be. That'd be pretty beneficial. Do, do you have pricing for, or is it just part of a bigger package that Aqui provides?

Lauri: It, it is a part, part of a package where we would sell usually multiple sites. Because of it is really designed for, for situation where you have more, more than one site. It is much more affordable than aqueous offering outside of it because it is targeting, you know, a different space in the market.

Yeah, I don't have a, I don't have a specifics on that, but it is somewhere in between Squarespace and where aqueous current offerings are Nick.

So is asking those hard hitting questions,

Nic: I mean, asking the product manager how much the product costs is, is not super hard hitting, but I, I can understand why you wouldn't have those details readily available.

But if, if there's any like, documentation on that, we can rather than show notes because like I said, I, I have a couple clients that may or may not be interested. Okay. So get getting back to Canvas. You mentioned that the original beta was scheduled for July and was delayed for reasons outside of our control where you're trying to get stuff moved over to the new canvas namespace by the end of this week.

When, when can we expect, when can we expect to be able to use Canvas and client projects in a reasonably and, and be reasonably sure that it's not gonna kind of fall apart under us because it's still too early?

Lauri: So I guess first of all, first thing that I do wanna mention, we are taking a very responsible approach that we actually didn't want to talk the beta just because of that.

We need that. We needed, yeah. No coming up. I think otherwise agree.

Nic: I agree. That's a great, great decision. I a hundred percent appreciate that. A, a few weeks delay is much preferable than the name changing under the hood. Yep. In, in the middle of a release.

Lauri: Aquasource is already using Drupal Canvas, so we are using it ourselves in production already.

There's some things that we have to do slightly differently than, you know, to provide that, that stability in there. But otherwise I think we are really close to getting a place where it is from stability perspective, we're stable enough for you to use it in client project and it's not going to explode.

I think where the real question is, is just when can I expect to have the right capabilities in place in there? Like it's not gonna have even when we have to pay out, when we have to release stable release later this year out, it's not gonna have all of the capabilities that people can expect to have from using layout builder or paragraphs because you know, we, we've focused on a lot on the experience side of it to make sure that it's really easy to use.

So. Those aren't following up, but,

John: yep.

Nic: Let me, let me, lemme share the specific use case. 'cause I have a client right now that's pretty, pretty excited about it and wants to use it and their, their their specific use case is they wanna provide it to an internal department for putting out their own blog.

Because right now all the blogs in that particular client go through one central editor and they wanna start increasing the, the amount of blog posts that go out for very specific products. And they wanna put some of that in the ha in the hands of the individual departments and they wanna use experience builder for that or ca canvas for that.

Yeah. So we're, if I, if I'm realistic with the timeframes, we're looking at prototyping that I ideally like some sort of solution end of September, beginning of October and launching some sort of feature for them. Probably end of November, beginning of December. Yeah. Is is that something that we could real, even if the capabilities are maybe limited from what they'll be long term, is that a realistic timeline do you think?

Or a project on campus? External doc we source?

Lauri: I think so. I, I, I think the, the September, october is, is sort of very tight, but you mentioned prototyping at that point. So I think that's, that's that, that should be fine. We are targeting stable release for October. So we would have multiple beta releases by by that time.

So I, I would, I would say, I would say that if you're not on a hard deadline where I have to start, actually the implementation is on of this project on the last day of September, for example, if, if there's a flexibility to actually potentially wait few more, few more weeks, then I think you're fine.

And it's actually even like, maybe you might be able to start even at that point because you know, necessarily have to. Expect to have everything fully polished. Yeah. By the time that you actually start it, you're launching at end of November, so that's when we've have had multiple releases on the stable already.

So we're expecting that we have 1.0, but we are going to have multiple releases then coming up. As you can see already, like whenever we've done releases before, we've, we've been doing frequent releases. It's been a bit less now just because of the fact that we, we are sort of in this confusing state with the naming and all of that.

But before that, we, we, we were making pretty frequent releases before that. So,

I mean, you know, you, you guys kind of were like, Hey, let's release a major, major feature. And oh, by the way, halfway through, we're gonna change the name of it. Like you, you're like, it wasn't halfway through. It was, you're piling on the way through.

Yeah. Piling on. So, you know, a little, little uncertainty there is, I think understood.

Nic: A fun, fun fact, by the way, I don't know if you know this lottery, but every once in a while, Tim, hess net outputs out some, some stats on like test usage and things like that. And Core obviously uses the most tests on, on GitLab, but number two is always experience builder.

Experience Builder is using a lot of GitLab CI minutes.

Lauri: I'm sure you mean Dral Canvas. It is, I guess it's,

it is still called Experience Builder as we are talking, so yeah, that's, and the historical

Nic: reports will still be experience builder, but Yeah.

Lauri: Yeah. Got it. It is, we have a very, we have a big team working on this.

We have well, would I say that it's very hard because we have contractors and, and, and full-time employees. We have design, but I would say we have around 20 people are, or Oh wow. Probably 20 plus people working full-time on this. So it's, it's a fairly significant effort that, that we're putting into this.

Nic: Yeah.

Lauri: So. Thinking about Drupal Canvas, thinking about kind of the, the, the demos that I've seen, thinking about kind of the upgrade path for folks that are using layout builder and paragraphs, I'm wondering, A, is there an upgrade path and B, you know, what does it look like? I know that in earlier, early demos you were able to pull in like dynamic components from which were basically blocks.

You could pull those into Drupal Canvas. Is that still the case? Because I imagine that could be a, a, a upgrade path from layout builder, but what does, what does, what does that look like?

You can still pull in blocks. In interpret canvas, it's still a thing. I think the reason it's getting less attention now is because it's just we've consolidated everything under one list of components.

Instead of trying to separate them in terms of how the actual upgrade path, we're not gonna have a upgrade paths available at the point when we launch this. It's also better for us to focus on just getting the feature set right so that we can actually get people who are building new sites to get their feedback first.

Yep. And then once we've proven the solution on, on that front, then we start focusing on, on migrations next. So you're gonna focus first on closing the feature gap, and then after that we, we will focus on migrations. What we are focused on is gradual adoption of Dral canvas, where, because it's a solution that you can essentially built your full site with.

Mm-hmm. The idea is that. You don't have to build your full site with it. You should be able to just use, for example, if you wanna use the triple Canvas pages, that's fine. Or if you want to enable it for specific content types, that's also fine. And then you can keep your existing things running on.

So what, whatever they are on.

Yeah. So if I were, if I were running Drupal 11 or 10, Drupal 10 or 11 now, right? And I said, okay, I wanna move to Canvas. Theoretically I could stand it up next to whatever my current page builder is and, and start building new pages in it and, and maybe working on migrating or recreating those other pages in, in Canvas in kind of like a, a structured, you know, timeline sort of way, right?

Yeah, exactly. And, and, and if you don't have a high number of pages, maybe migration is not even even worth it, like a migration where it comes to play a part. It's, it's really when you have these. Much larger sites and when you have a larger site usually, then also the features that that you expect is, is a bit more complicated, which is also why it might not make sense in the very beginning.

Obviously there are exceptions to that. You might have a. You might have a blog, for example, with a lot of content that doesn't actually have a lot of complex, so there are outliers to that.

John: Yeah.

Lauri: I, I

also imagine like a migration and, and Nick, you know, a fair amount of migration about migration, so you could probably chime in here, but like in my head, I'm trying to figure out how, like if I had a pa a site using paragraphs and I wanted to go to Canvas, like how would I write that migration?

Right? Because it's basically like, hey, it's the wild west of of page building who, right? Yeah. Like, it feels to me like you'd just be like, eh, we're gonna do a manual migration, just move pages one at a time, like as we, as we recreate them

or update Yeah. We've, we've talked about that conceptually already.

It's, it's a hard problem of course on the, when you go to the, like, not nuts and nuts and bolts level, but on conceptually we've thought about it where essentially one Drupal Canvas slot represents. One paragraphs field, essentially. Yeah. So now what you have to solve is, okay, how could we allow paragraphs to be displayed in Drupal canvas?

So instead of just showing blocks Yeah. Could paragraphs be a thing in there? We believe that it can, we haven't fully proven that it's possible, but like conceptually, yeah. You could

see in my head I was saying, I was saying like paragraph component to, to canvas component, and then just like mapping the fields and, and moving, you know, moving them over.

'cause you, you would know what the component was so you could, you could build a migration that way, but Yeah, like I feel like that's, that's a task.

Nic: Yeah. But you, you also have not to confuse name spaces even more, but I'm not sure if you're aware of the Mercury editor lottery, the one that uses Leo paragraphs that I think the atten design group.

Works on. I mean, that could be a way to see how to kind of map things into, but I, I actually had a, a different question I wanted to ask, and again, I apologize. I guess I, today's the day I'm asking all the hard hitting questions, but I feel like Layout builder was layout builder, kind of feels like it was in some respects a prototype of what Canvas is becoming.

Right. And Layout Builder is great. The sites that now that we've, it's been around for quite some time and we know like the use cases and the edges, it, there's no replacement for it, right? But there are, there are, you know, it's been a few years and are still some rough edges, and I'm curious if these are going to be rough edges in Canvas as well, or if it's something that's been planned for.

And in particular the, the three big ones that always catch me on, well, there's a few four, there are four things that always catch me on layout Builder one. Is translation is a, you have to plan a lot more for translation with Layout Builder. It's kind of like you make a decision whether they're gonna be symmetrical or not in the beginning.

And you're, you're kind of stuck with that long term is how is translation gonna work with the experience builder?

Lauri: So, on 1.0, not gonna have translation capability to point my, that's not something we provide, but something we've learned from paragraphs and lay layout builders that translations can be painful.

And we've learned about also this decision you have to make upfront around symmetric and, and asymmetric translations. And we've designed the data model around being actually able to support both and Okay. With the idea that actually you could even say that you could have one piece of content translated asymmetrically or symmetrically.

You could leave it up to the content creator to decide how they want to translate it. Okay. And. Fair. Fair, fair enough. We can do essentially how we want that dec decision flow to work is, is something we can decide, like that's just business logic. We would apply on top of it. Like whether you want, because you could say that, for example, all of the translations to a specific language must be symmetric.

Yeah, that could be, yeah. A way in which you want to do it another ways, which you say that you know, specific content type, for example, is always translated, translate in a specific way. Yeah. So we can add all of those because the data model is flexible enough to be able to accommodate both.

Nic: Okay. Se the second set of problems, I attribute them to the content being serialized, but, and I don't know how to particularly classify this, but it's layout builder almost feels like it's not Drupal in some respects.

Things like views integration or, or even as, as far as like. Sections or, or blocks don't know what section they're in. So like the, the, one of the strengths of Drupal is that content kind of knows where it is and where it's being rendered and how it's being rendered. And so if you need to make decisions based on that, you can, or if you need to query based on it, you can.

Is that, is that still a, something to expect for Canvas or is the data model such that you can you can interact with it the way you would expect to out of the box?

Lauri: So there are some ways in which you can interact with it. It's not necessarily the primary goal for that, that data, but we, we have made some efforts to improve how the data can be mapped.

There was sort of, data model was one of the big things that we be going back and forth over the last year and, and, and catch for, for example, from the Drupal core release managers has been very. Involved in, in Yes. Reminding us of all the sort of pain points that the previous solutions had to make sure that we don't fall into the same yes.

False. With this I was part, I was

Nic: part of those issues too. I'm, I'm part, I'm part of that voice. Okay. And then the, the final one, and this is almost, this is almost one of the biggest issues, is that so for example, if you choose to do custom layouts in layout builder for a content type and you create one, even if you delete it, you can't remove that ever.

Like, it's just like, like there's no, there's no way to back outta that decision period. So if you are, so, if you are making an experience builder page and you decide to modify that layout or structure somehow, is, is that something that you can control or is it like once you set it up, it's fixed in stone where the slots go?

And that's that, or is it, is it more flexible, I guess is the question?

Lauri: I would say right now there are a lot of limitations in what kind of changes you can make after you've sort of first committed to it after content. But, but there we are looking what are the different ways in which you have to be able to modify things after the fact.

So we will be adding more ways in future. Right now we are protecting some of the changes just because we want to make sure that, you know, data integrity is, is there Yeah. But, but we actually have in the backlog a lot of items where we can add back because we've already thought through, okay, this is how we can add, being able to modify this, like being able to, for example, modify your, the props modify for your component is it's, it's one very common aspect in which you would've to do so.

Right now it's limited in how you can modify them, but we have some of the foundations in place for that. So we are, for example, versioning, props that we've seen for components. So we can then provide totally ways to. Essentially upgrade to a new schema of props in there. Okay. And, and that's an approach that we're taking to not just component props, but the essentially different aspects in which you would've to modify something that was first committed to, and then later on Yeah.

Needs to be changed.

Nic: Yeah. That, that, that makes sense. Well, again, I, I apologize because those are, those are a little bit nitty little bit more nitty gritty than usual, but there are things that have been on my mind, so it's good. I'm cautiously optimistic with your answers that Yeah. We, we'll have solutions for these, but, but they are things that I deal with, if not daily, at least.

At least monthly with most of my clients trying to figure out how to, how to manage these situations. So having, having good multilingual support is one of the key selling points for Drupal. And so if we, if we lose that or kind of a new key feature that, that's something I'll have to be aware of what I'm selling.

So what I'm selling experience builder

Lauri: in the, in the vein of hard hitting questions. When do you think, if you had to guess, multilingual support for Canvas will be available?

I would guess some point probably Q1, 2026. I would, I would say that that's probably roughly, we'll hold you to that. It's pretty close, it's

roadmap after that, that, that's, that's an acceptable answer for me.

Yeah, absolutely. By the way, none of those questions were surprising to me. Like I've, like, I, I, I like, I feel like. You were summarizing a lot of the, the pain and, and, and, and frustration that I listened from many of those sessions that I had maybe with the exception that you did not com complain about the amount of effort you have to put into improving the experience.

That was probably what I've spent the most time listening to. But yeah, otherwise it's a lot of effort. Checks.

Nic: Yeah. It's, it's a lot of effort. But, but the, I I probably, because I'm not the agency, well probably because agencies are usually paying me to improve that. So for me, that's part of my bread and butter, I guess.

Right? Yeah. Making that experience better. But if, if we can focus those efforts on other areas, we can always make, we can make Drupal better and it, it's better. Yeah. I'd rather not be rebuilding the wheel for every client. So I, I'm, I'm excited to, to move on from, from having to, having to do that. But yeah, I, I guess the questions weren't in the show notes, so you just didn't have a, a, a direct preparation for it.

So, anyway, let we, we can move, we can move on. So there was a o one of the, I don't even know if I would call this a selling point, but one of the flashier things that DRIs demonstrated in a recent Drees note was utilizing AI to build out a component in Canvas. How close is that to actual reality?

And, and I know that, I know that he built that on a real demo, like it's not, but there, there's a, there's a, sometimes a far cry between what works in a even a real demo and what works in, in real life and real you know, real environments. How far away are we from utilizing AI in that type of situation?

Is it something that works most of the time? Never. Always.

Lauri: Yeah. So I, I think we've worked a lot to try to make that vision reality where I say that, why I say try is because it. Sort of defining success there is very subjective, right? Because of getting to some level of quality was, was pretty easy.

But then improving the quality from there on trying to get significantly better results is where it gets very tricky. And defining where, like setting a definitive line where that line of success is, is very hard. I would say where, where, where we are right now is where I'm utilizing the AI tools that we have in there myself.

And I find that more than nine out of 10 times what I got out is, was useful. It, it accelerated what I was about to do. I think going from zero to 100 with what the AI does is not like, that's not reality at all. Like I think zero out of 10 times did I get from zero to 100. What the AI did, and the goal that we've, essentially, like the vision that DRE has is that we have these agents that can fully autonomously complete the tasks, if that's the, the, the goal which we are trying to hit, to we are not there.

And that, and it's still us trying to get to that level of quality. So, so how

Nic: far are, how far are you, sorry, John. I don't,

Lauri: so I don't, I mean, I don't think that the a hundred percent right. Autonomy is the goal, right? Because the AI initiative is very much like human in the loop, right? Yeah. So, I mean, I, but I think like, eh, 95%, right? Yeah. Where the human is the last, the

last checkbox, if you will. Yeah. Obviously, like the mistakes is, is a different part where even humans make mistakes, right?

Like a review. I'm not saying we are excluding reviews from the process. What I mean is that you could expect that the quality is similar to getting from a, from a human who also makes mistakes as they, as they work. As in like, you could somehow compare that. You, you, you could tell it, you could not tell it apart from a human doing the work got and,

Nic: and, and how far are we getting then?

So if you're, if you're using your scale of zero to a hundred, are we at 60%, 80%, 20%? How, how far is it accelerating you along that path at the moment?

Lauri: That, and that's, that's, that's a, that's a hard question because it depends where your skillset is. I think for me, because if I'm a front-end developer, for example, when generating components, I think it's actually doing a lot of the boiler boiler plates and I can do the nitty gritty of getting it to where we need very fast in there.

So for me, I would say it's probably like 70, 80% where we are of the effort because it sets up so much of the boiler pipe for me, and I can just like hammer through the rest. But for someone who is not like a front-end developer, it, I would say that they, they wouldn't necessarily even find it useful for them because it's not really doing the hardest part, which is to try to make, make it match the design for them.

So. For them. I, it's very hard for me to then say, oh, for them, how much is it actually of use for them? Yeah. So you still very much need developer. That's interesting as, as part of the process to, to, to get to that level of finesse that you wanna get. So just the conversation is a bit different because if it's not about the technical ability of it, it's more about pure quality of what it provides.

And I would say that there actually the, it, it's providing better results than for the components. Obviously the problem is much interesting, smaller because of, it's, it's just using components that are in the component library to create a page and there's just a finite set of things that you would essentially do usually.

So in there.

Two, two questions. One point of clarification and one additional question here, right? So in, in the DRE note, right, they take an image and they say, Hey, AI agent build this component for me. You're saying you, you know, with some help from you who knows, knows, code knows CSS, you can get to a hundred percent and there is AI that will be able to do that or it can do that currently.

Do you mean is there AI that could, can do the a hundred percent out there? No, no. I mean like is there AI that can get you to that 80% you, you see? Yes. You said yes. Okay.

Yes. So that's what we have today. That's cool. So the challenge is that it kind of takes broad strokes from that image and implements a component using those.

So it's like when you are front end developer and you really want to actually implement the design, you wouldn't consider that as a good enough because it's just, you know, it put those broad strokes together. Right? Yeah.

Right. Yeah. So that's fair. I mean, I think that's fair. So I think like that's, that's awesome as far as like pushing things forward.

Another question I have is, you said you have, you know, the AI working with Drupal Canvas, like does the, does a demo or a tutorial of this exist anywhere? Because like, I feel like I would like to see. I would like to see that and just, just, just kind of like, play with it, help out with, with you know, building that if it, if it's

possible.

I'm sure we'll have demos by October at Dre's note. Maybe some even before then. Yeah, we haven't done an updated demo recently. Got it.

Okay. So videos are in the works. Got it.

Videos are in the works for sure. Understood. We've, we've just started prepping for, for Dre note.

Nic: Awesome. Oh, okay.

Lauri: I I, I mean the Drupal Con Vienna Drees note is gonna be you know, and not to, not to steal not to steal an apple is, but it's gonna, it's gonna be the best DRE note yet.

So more of a, less of a Drupal canvas question and more of a, more of maybe a, future, future star gazing sort of, hypothesis question, but like, how do you think that, you know, Drupal Canvas is going to empower site builders and move the Drupal community forward in the future?

I hope that we can bring us together on one solution and built around it, similar to how Drupal Core has done.

And so one of the challenges we had with Layout Builder and paragraphs is that it's sort of a disjointed, it's, it's a fragmented community where there's like so many different solutions and like micro modules that exist around it, which in a, in a, in a way it's very fascinating to see happen, but as someone who is actually trying to get started and, and, you know, set up that initial experience is not necessarily, you know, it's not very easy to get started.

John: Mm-hmm. So.

Lauri: I hope that it brings us together and it, it sort of raises all the boats in the sense that we actually, that we can grow the community by making it easier for people to join our community because we make it so easy for, for people to get started. I think how I measure success for this is, is are we going to grow the amount of site builders that we have in our, in our community?

If we, if we manage to grow, then the amount of site builders we have in our community, I think, and, and, and Drupal Canvas, were able to help with that. That that's what success looks like to me.

That's, that's awesome. Lauri, thanks for joining us as always. It was super interesting and and all around a great conversation.

Nic: Thank you. Do you have questions or feedback? You can reach out to talking Drupal on social media with the handle talking Drupal or by email with [email protected]. You can connect with our show host of the listeners on the Drupal Slack in the Talking Drupal channel.

Lauri: Do you? Yes. You listening right now.

Wanna be a guest on Talking Drupal or our new show? Talking Drupal Cafe? Click the guest request button in the [email protected].

Nic: You can also promote your Drupal community event and talking Drupal. Learn [email protected] slash td promo.

Lauri: You can get the Talking Drupal newsletter to learn more about our guest hosts, show news, upcoming shows, and much more.

Sign up for the [email protected] slash newsletter.

Nic: And thank you patrons for supporting talking Drupal. Your support is greatly appreciated. You can learn more about becoming a [email protected] and choosing to become a patron button.

Lauri: Alright. Alright. If folks wanted to get ahold of you, talk about Drupal Canvas or any of the other cool stuff you're doing, like Aqueous or where could they go about doing that?

You can find me with la with three eyes on pretty much all the the different platforms. Platforms or on some platforms. I'm just la la Tim. That's sort of my less Drupal facing name.

There you go.

Yeah, Nick, feel free to reach out on Slack or wherever you find me. There you go.

Nick, what about you?

Nic: You can find me pretty much everywhere at nicxvan, N-I-C-X-V-A-N,

Lauri: and I'm John Picozzi. You can find me at picozzi.com or on social media and drupal.org at John Picozzi, and you can find out about EPAM at epam.com.

Nic: And if you've enjoyed listening, we've enjoyed talking. See you guys next week.

Lauri: Have a good one, everyone.