YouTube Video H8duBXx-YcU ![rw-book-cover](https://img.youtube.com/vi/H8duBXx-YcU/maxresdefault.jpg) ## Metadata - Author: [[YouTube]] - Full Title: YouTube Video H8duBXx-YcU - Category: #articles - Document Tags: [[development]] [[migration]] [[testing]] - Summary: YouTube Video H8duBXx-YcU - URL: https://www.youtube.com/watch?v=H8duBXx-YcU So I will be talking about um next steps for Drupal canvas. I'm curious how many of you have already tried out Drupal canvas former formerly called experience builder. Do you have maybe one of the group um I have some demos in the presentation but I don't have as many demos as what I've had in my previous talks because of the focus is a little bit more on what's coming up in future. So hopefully you get a little bit of a sense on you know what we have today. um but primarily on what you can expect from sort of 2026 and and and going forward. Um I'm Liman. I'm a senior product manager at Aqua and I'm leading the Drupal Canvas initiative. Um I'm also a product manager for a new product that Aqua is building called Aquia Source and I've been part of the Drupal community for 15 years. Uh luckily I have some space here. Maybe next time I'll update my bio to include that I'm a Drupalar 2025 treasure hunt winner. Uh seems like a great addition to the to the bio. So just to set a context on what I will be talking about today. Uh Dre set the vision uh in his Drupal Star keynote a few years ago um as that Drupal Drupal CMS wants to be the gold standard for no code website building in future. So we've been thinking about what does it actually mean to you know be the gold standard like essentially how I think about a gold gold standard is that when someone thinks about building on a website they would think that Drupal is the best choice for them to use for that and one key part of us getting there was the introduction of the experience roller initiative um which we believed was one of the most important initiatives that we could be taking on to get on to that uh vision. So the mission for the Drupal canvas initiative or experiential energy what it was formerly called is to make it easier and faster to build science and that sort of that is the context of this talk is that Drupal canvas might be doing something today but you know how I'm thinking about Drupal canvas is much broader broader than what it does today. It is really okay what can we do what improvements can we make to Drupal to make it easier and faster to build science. So you can see that sort of the it's not a very constrained view that I have on on what it is that we talking about here. It's a lot of things that are not necessarily specific to Drupal canvas in any way because of you know they all still impact this this mission that we have. So that's to set the context of why you can hear a lot of things that are not very specific to what we have in the campus today. So here's the timeline how everything started. So we started in 2023 and now in no November 2025 we have a release candidate of Drupal canvas. Uh so it's been a long way a lot of steps along the way to get here. Um a lot has changed since we started. So it's it's sort of a time to re-evaluate uh you know what we should be doing going forward like does what we originally thought we should do actually match what we still think we should do um especially around AI there's been like major transformation since uh we started on on um Drupal Drupal canvas in 2023 basically it was hardly part of the vision for this project at all back then and now in 2025 It's very hard to ignore complete completely the fact that you know AI is transforming the way we build websites and how I'm thinking about sort of next phase of Drupal canvas is the question like what sets us apart in this era of AI where AI is transforming a lot of the ways in in how we work uh with building web but also other other things. So I'm going to uh present you sort of three strategic pillars that we should focus on and then I will present some ideas on what I think we should do to to get there to actually sort of fulfill that strategic pillar. Uh but I'm open to feedback from you all like if you think that first if the strategic pillars that we have if they're not right if you don't actually think that those pillars are the right ones that's that's great to provide feedback on the high level strategic vision that we have. Then the second part is that if you think that are the things that we believe actually help fulfill that pillar if they are the right ones that's also where we can we can get feedback from from all of you because we're now at this point of you can see that there's a lot of items in here that are under discovery because of we now just about to get a 1.0 release and uh then essentially moving on to the next phase of this project. All right. Right. So this first pillar that I want to talk about uh which you probably can expect based on the well what the mission is and and what we've been talking in uh in keynotes and other presentations with uh trees and others. Um we have to enable building ambitious digital experiences really fast. Um and the expectation has changed from what it was 3 years ago where 3 years ago it was expected that it still takes you know months or weeks. it needs to be easy but you know there's an expectation that it can still take some time but I I believe that that's something that in in in sort of the era of AI is is about to change we're not quite there yet I don't think the tools fully exist for this today uh but it is it is definitely easy to see that that's the direction that we're going to say probably one of the first areas that is going to be disrupted is the the front-end development especially front end design phase uh of the of the development because of uh if you have a designer building a Figma and then trying to import that into front end is something that is sort of a fairly standardized process in a way to do. So I believe that that's one of the processes that will be disrupted first. Here's just a very quick demo of me building a website with Lavable. You've probably used one of these tools. Uh but it's really the design isn't the best. I'm not really even trying to build something really impressive. It's just if you imagine what it even took to get to some something like something of this quality uh back in the day it's uh mind-blowing but in in 2 minutes you can essentially have a prototype that you can now then iterate on and improve the design on. So it's clear that the direction is that things need to move faster and that's actually what we heard in the keynote as well that even even a shark um their organization expects that hey we need to be able to move faster uh given the advancements in AI it I don't think this is specific not everything that we need to do to make it fast to build sites has to actually do with AI there's other things we have to do than that but it's one part of it so there's actually three things that I think we should focus on to uh enable speed. The first one is implementing a design system mindset and fully implementing design systems in Drupal as a concept that we support. So I believe that the process uh going forward will be where we essentially built something with AI then we have to understand and refine that what was generated by AI and then we review and publish it and the review might include someone else reviewing your work and what's key here and where Drupal canvas plays role and where Drupal plays role is okay we have the AI building something for you we have to provide the right type of structure the right type of tools that help humans then understand what the AI actually did and we have to provide the right types of tools that we as humans can then tweak and actually get it to the 100% solution. So if what the AI produced is not understandable by humans, I don't think it has much of a value because of you know you can't actually get it to that 100% production quality uh uh solution. And then finally you have the tools to review and publish which means collaboration uh amongst humans. So it could be things like being able to export your your code into um GitHub so that you can have someone actually review and and and confirm what is in there. And then you have to be able to iterate on it so that when humans actually tweak uh the code, you need to be able to build on top of that still with AI so that it's not like a one time all process where you start with AI and then um tweak and then publish. You have to be able to go back to the AI step. Um so canvas already takes huge steps towards implementing design systems. We started by introducing the concept of components um in Drupal canvas. Um the how this is different from from Drupal before is that can components are completely uh agnostic from the sort of use case of how you use them within the system. So you can use the components across the system for multiple use cases. So you can build a component like let's say a card and you can use it to build a list or you can use it to build a a page or you can build it you can use it to build a display for an entity. So that's something that Drupal didn't have before as a sort of first class citizen that we would support in the system. So that will make it more efficient regardless of who builds those components. But it makes it also easier to understand how every all of it all of it works because of it's all now isolated and separated nicely um in these tinier chunks that are easy for humans to understand. Something to understand about components is that Drupal can as a concept of components but components can come from multiple uh different sources uh including ones that you already know um in Drupal like blocks and uh and layouts that layout builder uses in Drupal canvas they all just become components. So some of the upcoming capabilities on this area are site templates and marketplace that's enabled by having a design system mindset. So now uh when you have a design system mindset, you can actually build multiple different kinds of site templates easily using um the design system. I believe that this overall sort of value pillar of being able to build fast actually is one of the enablers for the site templates and marketplace because in order for us to succeed on the on the mission that Dre has set for marketplace where you would have thousands of site templates, it needs to be fast for us to build those so that we can actually get to that scale. And then we will be also implementing um other design system concept not only components uh but things like design token API so that you can uh in a structured way store your your design tokens um in the system um style API which allows you to build uh reusable styles within within the platform and I libraries that allow you to expose your icons in there. And then finally something I know a lot of you have been asking for is uh slot slot restrictions. uh so essentially being able to define within the slots that your components have what uh components can be placed in there. So a similar use case to what layout builder restrictions have. So this is actually something that is already in progress. There's a lot of work happening in uh most of these areas actually already I would say actually all five of these areas are being worked on already. So you can expect that there's going to be some good progress on these coming in 2026. The second pillar of en enabling speed is integrating AI with uh canvas. And you may have seen some demos around this. Um I have a a quick demo that I'm showing here where I'm actually using the canvas AI to build a uh list. Um this this site that I have here is essentially a tour company site where I just want to list all of the tours. I'm using um the Drupal canvas code components which is essentially a UI that allows you to create components that then allows us to essentially build some integrated AI capabilities um in there that where essentially the AI has all of the context from your from your site that it needs. So if you imagine this use case of listing tools for example it needs to know what are the components that you have in the system and it needs to know what is the content model of your site so that you can actually pull the right fields in there. So I started by by doing this this manually but then at a certain point I was like um I actually don't want to do this manually because it was just like a lot of mapping of the fields and all that. So I then went went to actually ask the AI. So AI actually took the component that I started with as the starting point and then it started refining it based on that. And now you can see that I'm actually refining what the AI had provided because it didn't get quite to the 100% solution. And now you can see we have the timer over there. In 7 minutes I was able to get to a somewhat working uh solution in here. Uh and it looks it's using the components that I have in the system. And uh and uh it it work it works. Uh on the right side you can see also I have a a prop that we can use to um change the the heading table. I'm just double checking that the code is all good, that there isn't anything else in the code that I changed because the AI had made changes in there and uh and we're done. So essentially, we built a list in 8 minutes um from scratch and and I did I did this in one take and I didn't practice at all. So in the sped up version of this uh you can see a lot of mistakes that I made because of I was just you know just trying to figure it out. Um so I was talking a lot about the context that you get from Drupal to actually help these components to be built the right way with AI. Something else that we are uh working on to add to Drupal CMS is a context control center which then actually allows your organization to add context about how you want content and components to be created within your site. So you can tell about your your preferred voice uh and other preferences that you might have and it will be used essentially then uh on all of the prompts uh that that are being used uh within the triple canvas or other AI tools in there. So that's going to make it even the results that the AI provides even higher higher quality. It's a great example of something that is um easy for us to do it here but harder to do uh outside. And then this is a new area that we haven't talked a lot about uh which is to enable external AI to work with with Drupal canvas. So this is the existing tools like lovable that I used in the in the example. So that you can actually leverage from from the improvements that are happening there as well. Um so you saw the demo that I used where where I was using the in browser demo. That's not necessarily the way that a lot of you are doing development today because this is something completely new. So I believe that Drupal canvas actually needs to also support ways in which you can use our existing tools like whether you're using cursor, PHP storm or whatever. Uh you should be able to continue to use those tools and actually use AI still to accelerate your development. So I believe that we actually need to make Drupal and Drupal canvas the best CMS to work with when you're using AI as part of your workflow to work with. I believe that actually what we've done with Drupal canvas, the way that we've built components and and and structured all of that actually makes this a really good target for this. So this is not that hard of a problem for us to us to solve because of that. Here's an example of a site that where I actually without any of the tooling that we have. I use just cursor Figma MCP without any any any additional tools that we provide. So there's basically no context whatsoever of the site or how how components are being built. I simply gave it um uh examples from an open source um uh design system library for that was built for Drupal and uh say that hey build me this design use this uh repository here as an example of how you can do it and within I would say probably four or five hours I had this full site built and this was I built this for my Drupalcon uh Vienna demo so I didn't want to spend a ton of time in it but I actually wanted to get something that looks really good uh so that's why sort of went all in. If you look at we can actually see I have things like top destinations in here. I have something like uh more destinations and I have some like pretty complex grids in here as well. This was all something I had in a Figma design and I wanted to get pretty much one to one in the in in the implementation what I had in the design. So I wanted to test what it actually takes and it worked surprisingly well. So what we're going to do uh to improve this experience is build something like development starter kit for uh using AI with Drupal canvas and and Drupal CMS and uh that essentially provides some uh MD files and uh other tools that allow the AI to work more efficiently with uh with your pool. Then you can use our existing AI tools that you're using your ID and everything and you can just the AI is will essentially work within your codebase. you can export it to git and then Drupal canvas will use it and you'll have your AI created website from there. So this is essentially how we can improve the experience of building with AI outside of the Drupal canvas AI which probably is something that will feel more familiar to people who are already accustomed to developing with Drupal. So that's the first value pillar which is the making it really fast to build uh digital experiences with uh Drupal CMS. The second pillar I have which I believe is something that actually helps us differentiate um over the um lovables and and uh replets of the world that are purely focused on AI is enabling content creation and site creation at scale and that's by enabling collaboration within here. So what that means if you go back 15 years ago I don't know how many of you have been using like uh Dreamweaver for example or front page to create websites at the time when it was introduced it was like it was a huge shift in the market. Everyone thought that okay hey you don't need web designers anymore because you know now your marketing people are just going to go to Dreamweaver and visually built all all of your pages in there. Well, that introduced a problem like when you have thousand pages, it's not that easy actually to maintain those thousand pages in Dreamweaver because you would have to go to each each page from the uh from those thousand to actually update if you made a change to the menu for example. So, it wasn't quite as transformational as we thought it would be. Um, then came the CMS uh to the rescue. So I believe this value pillar is actually just making sure that the CMS capabilities that we already have really support us to get that differentiation against the AI layers. So just really making sure that our CMS capabilities are in the best possible shape possible. Um and I believe there's three key um aspects that we have delivered to make that happen. First is providing a simple user experience. That's what enable scale. Second is content modeling capabilities and third is the right governance capabilities. So let let's look into the simple user experience. What I mean by that so the whole point of the CMS is to enable your broader team to be able to essentially work on your site like do you want your content marketers to be able to write the blog post in your site. You don't want the developer or some technical person in the team to be submitting those blog posts in your sites. Uh the whole point of the CMS is to enable those sen scenarios and that's only possible if it's easy to use if they're actually if those people are actually willing to use the system. What's been interesting uh when I've been looking at RFPs and I have uh I have some stats in here but the what I the message I wanted to give is just I've noticed in RFPs that it's actually getting more and more common that companies prioritize what is the experience of uh building with your site and there's actually been some pretty subtle losses that I've seen as well where you know the experience hasn't been as good as as it should be and and it's been one of the reasons why you know uh Drupal hasn't been selected and I I wanted to look into that like is there something into that? there's some data that actually backs that up that that is something that actually happens in the sort of broader market and I actually found some pretty compelling arguments in the in those statistics that uh it is something that actually is happening at a large scale uh within the market which is why I think that for Drupal to succeed uh uh in the CMS use case where you're trying to enable scale it needs to have a really good good experience given that that's actually something that customers put a lot of emphasis on um and I I think Drupal canvas already positions really well on that because we've we've invested heavily on UX uh when it comes to building Drupal Canvas. Um so the experience of using Drupal canvas should feel familiar when you've used when you've used other um website building tools or even something like like like a PowerPoint. Uh you hover over things, you click them and you can just edit them. So you don't have to go through like multiple steps or multiple menus to access different kinds of things. to create content to simply access your component library and uh drag content uh to the page. I believe that we have a good foundation for this. Uh there's still some quirks like we saw in the opening session where or no actually I think that was in Elliot's presentation where where he ran into some of the issues where he was trying to access the manage library instead of the add um ad menu. But it's actually interesting to see think because of that's actually a good it's a good thing that we're finding out those things because it's showing that people actually are trying to use the UI intuitively without actually putting a lot of thought into using it. And when we run into those scenarios, we just have to learn from it and then essentially improve the experience from there. So in order to identify what those um challenges are, we are going to be conducting uh user research uh and refining the UX over time. So I believe that the foundation that we have is actually already right or in the right tracks in regards in regards to this. It's just about finding those quirks, finding those pattern th those um small issues within the interface that are not intuitive to the user and then then we'll fix those things. For example, the the manage library versus app library that I mentioned is something that we are already looking into fixing. Um, so uh if you're interested in in uh helping with us, if you have any UX designers as as a colleague or if you're a UX designer, just let us know and um this is an area where it is easy for us to sort of scale the efforts and have other people run um user testing if that's something you're interested in. The next uh aspect of enabling scale is content modeling. Uh and that's that's probably something that you are pretty familiar. That's something that we we are all pretty familiar with. I'll show you how canvas already enables content modeling capabilities today to to exist. So on this site we saw I was using a tour uh I was already creating the list with this. So this is actually the content type that I have. Um this is the form that I have. Um so essentially when you when you're using these content modeling capabilities, you would be just essentially creating content using the content type just like you're doing uh today with with uh Drupal. Um I'm now entering Drupal canvas again and I'm going to create a content template for for this. So I'll create a new template and templates are essentially uh similar to what we have as displays today for the rule. So it allows you to display content from your content. Uh we can see on top there's actually a selection of the content that I have. So that's where you select what content are we using to preview uh the actual end result. So we're not generating uh um testing content or anything like that. You actually have to create content uh from the context to be able to use this. Um now you can essentially then place components on the page and then select on that right hand sidebar instead of filling in the field view select which fields you want to map those properties into. And uh we can see when we are navigating between the different uh content the um heading actually changed when we did that. And you can see that the library that we're using is the same library as we would be using for creating pages. So you can use the exact same components that you use for for creating content. You need you don't need to have a different set of components for this. So I'm just dragging some of these components to the to the page um to create sort of this basic structure in place. You can see that I'm using spots in here heavily to create those nested structures. uh the heading for example in here I'm just writing a static heading in here uh because that's same across all of the pages and then I'm selecting uh those uh individual fields to that to map into the options that you are provided in each of the uh menus they are we we will only show options that are actually relevant for that particular property that you have. So if you have a text field, it would only show you options that you can map into a text field. If you have an image field, it would only show you image fields or media fields that you can attach to a um image field in there. So it's very similar to the token system that Drupal has, but with the difference that in here we actually know what the type is and we can tell you which of these options actually are going to work well for the use case. So I can what I just did was I essentially copy pasted. So I used to use used the copy paste feature. Uh you can just use command C and command V in the system and uh essentially duplicated bunch of bunch of things in there. And now we've essentially mapped all of our fields to the right uh mappings. So that's how easily you can create a quantum template. So, of course, behind the scenes there was a little bit of work that went into actually building those components um in here, but um you can see sort of the the potential of how easy this can make the creation of of content templates. All right. So, some of the um upcoming capabilities that help content modeling. So something that probably a lot of you are interested in is translations support. So I can say that that's something that um I would say right now is uh still sort of under discovery but it is something that we are very firmly committed to work on early 2026. Um so you can expect some news on that uh probably by Chicago. Uh if you don't have translations available by then at least we should be very close to getting them done so that you can actually tell when they're going to be available. Um after translations uh we will focus on bringing in edit editing nodes inside Drupal canvas. So what you saw in the demo was creating content template. So those those that's the display of the nodes. Node editing canvas means actually editing the structured data that you have within uh your account. And what that enables is then finally the third feature which is something we call exposed slots which allows you you to create hybrid content where you have some of your content types actually using fields and then some of the content using Drupal canvas content. So let's imagine like a product page where you have a consistent display of your product at the top of the page. You want to show like the product name, maybe a product image, the price at the top and then after that you want to just tell the story about the product which is in a very unstructured format. So now that content you actually then create using your components uh in canvas. So when we allow you to edit nodes inside canvas, we can actually provide a seamless experience where in a single page you will edit both Drupal canvas content using the drag and drop interface and you can enter fields content for your fields on that right sidebar. So you don't have to navigate between the two experiences. The final pillar of the CMS basics is is governance. uh Drupal CMS uh and and um Drupal canvas provides sort of a basic uh governance models already today. Uh so you may have seen the the review uh workflow that that I that I showed uh in one of the demos earlier. I didn't talk about it too much so I'll show it here. So when you make changes you see a preview of that immediately. Uh all the changes that you do they're autosaved automatically. So I just did a refresh of the page. Now we can see the d the draft is still there. Um and now when you want you can just publish your changes uh and then they go to the actual uh published version of the page. Um we provide um sort of a basic permission model for Drupal canvas. So you can actually customize who can edit your code components, who can publish content, who can edit pages in there and so on. I would say that this is a pretty standard Drupal permission model but we've actually they simplified it a little bit from the standards because like in standard Drupal way it's a very granular set of permissions so we made it slightly less granular just so that we can provide a little bit uh simpler user experience within uh Drupal canvas as a result we might be adding some of permissions but if you find use cases where they are needed uh so far we haven't had anyone actually uh express any need for those so fingers crossed that we can actually keep it this way uh the primary feature that we are missing and and and are planning to work on uh in future is adding custom content workflows. So you can see that what we call what we have now is something we call a simple content workflows. Essentially you have that one in review one draft in progress uh uh workspace where essentially all your changes go in there. You can decide who can actually publish them. So you can have one person actually uh working on the changes and then another person can only publish them. So you can set the permissions that way. Uh but in this custom uh content workflows, you would then essentially be able to send that one uh workspace where you might have multiple changes in there through um a content workflow where essentially it would be drafted the beginning and then you might mark those changes as a review news review state and then someone could actually someone else could move it from news review to a published state from there and then you could have essentially multiple workflows going on going on at the same time. So it's not just a one uh workspace in there. So this is something we are doing discovery on uh right now to define uh what uh when and how we could deliver this one. All right, let's focus on the third pillar uh which is an ecosystem of community modules for advanced use cases. So I I I I assume that this is something we can all agree on that probably Drupal's crown jewel is the community that has built and maintained 10,000 plus. It's it's it's way more if you include all versions of Drupal. This is actually 10,000 that are actively being being maintained today. Uh community modules. So it's it's a it's a huge accomplishment actually to have a uh ecosystem like that. That's something that um the failure to create a working uh community ecosystem has led companies like uh Nokia to to fail essentially with their mobile phone uh journey. That's something that actually many of the uh leaders of of Nokia said it was the biggest issue to why Microsoft phones couldn't succeed because they completely failed to get developers to build for their marketplace. So this is a huge success for us that we've been able to build an ecosystem where we actually have a lot of people building modules and we have people consuming those modules uh in their sites. Uh so I would say that the hardest problem is already solved. Now it's more about how do we actually sort of get the most value out of this ecosystem uh so that we can actually uh be the number one the uh gold star of no code building. And I think there's essentially two areas that we should focus on in here. The first one is to focus on perfecting the most valuable modules. So making sure that we really level up them and make sure that they are really solid. And then uh providing a consistent user experience across the whole experience whether it is through the modules that uh um Drupal core includes or whether it's community provided u modules. So let's focus on first what I what I think about perfecting the most valuable modules. So something that I've seen as a sort of challenge a little bit in in our ecosystem is that we can see that the market the the broader sort of market space is moving towards uh integrated systems like we saw HR's case uh earlier today that they are using a very complex ecosystem where they have multiple systems that they then interconnect together. something that we could improve on is actually making that much easier for uh customers to realize. It's this is something you can all implement today with Drupal. It's just that sometimes it's hard. It requires developers. Um and we can at least some cases where it's very common to integrate with a certain platform. We can make it make it easier. How I would see the ecosystem looking like sort of in its ideal state is where we have a Drupal core which is then essentially built upon on Drupal CMS and then we have some third party integrations and some other advanced use cases in in contra. So how I see about Drupal core is that that's essentially the the core framework that we provide. uh we're actually moving uh product like features out from Drupal core because we don't want we don't want to maintain them as part of this core core framework. So things like layout builder others like we are looking into like moving them out from from from Drupal core. Then we have the Drupal CMS which I'm considering as sort of the baseline product. So that's what actually then realizes the CMS vision of Drupal that you get like a fully built out CMS when you download it. Then you have third party integrations. Some of them might have some foundations in Jupy CMS. Some of them might be in in in country. Um and then you have other other advanced use cases that this doesn't make sense to have in as part of Drupal CMS or Drupal core. Uh example could be like the group module like that's probably never going to be part of the Drupal CMS, but it's clearly something that's really powerful and valuable to have as part of um Drupal. So there we have this something that I I feel like we have today and put maybe um too much focus on sometimes implementing baseline functionality as community extensions. Uh so what I mean by these baseline functionality as community extensions. This is things like uh maybe path out of that was not part of Drupal core. It was not part of a product but it was it was part of Funka our community ecosystem and then it it was something you would always essentially have to download. Of course now path loss there's other examples like layout builder where if even if you want to get just the baseline version of layout builder you actually have to download a ton of modules from the community ecosystem to get just a baseline product of layout builder. And this is actually where I think we should focus as a community to sort of consolidate and and try to bring some of those extensions back into either Drupal core or Drupal CMS so that we have an easy experience as a whole for everyone to use so that we have the baseline product in there. Not necessarily I don't want to discourage people from working on those things. It's it's more of me encouraging a collaboration and a way where we adopt those things in the Drupal CMS or Drupal core so that they're not uh you know just in in contra so that we actually have a better baseline product. So that's sort of I'm just encouraging a different way of approaching it and the reason I think is this user expect those capabilities often as part of the baseline product. So that's why they should be part of it. often times the challenge that I hear the reason why I hear people is that because we can't agree on what the solution should be but well now with Drupal CMS and Drupal core we have a very well- definfined framework and and and governance model how we make decisions we have product people who can help us guide what we think that the baseline experience should be we should be able to agree what is the actual like what do we think is the best experience that we can we can provide or what and sometimes it's not about what is the best experience that we can provide sometimes it's agree what is a good enough experience like the reason why path auto even though we've all agreed that path auto is a solution the reason it's not in course because of we haven't been able to agree on whether it's a good enough solution even though everyone has adopted it so now that if we apply this product mindset to that uh we can say that since we have adoption uh for path auto it must be good enough maybe there's something we can improve but it must be good enough since it's being being utilized so the question on this one is something that I I don't think I have an answer to it's it's a question probably to myself but also if you have ideas I encourage others to think about it is like how do we guide um the development so that we can unlock specific verticals. So how could we actually have a focus on where we would look at that next year we actually want to be really strong on on enabling the healthcare market to utilize Drupal like what are the different modules and improvements that we would have to make to make us really successful there because that could help multiple agencies then succeed within that market. So how do we actually facilitate that as a community where we have multiple agencies and multiple uh you know different groups who are interested in a specific vertical identify what the gaps are for that vertical and then essentially prioritizing work because that would then essentially that focus could help us unlock Drupal for new markets that where where Drupal is not popular uh today. So that's just something for us to think about and uh if you have ideas come talk to me because I would love to hear your ideas. The second part here is uh we need to create a consistent UX with canvas. Um so users expect consistency across the the whole ecosystem. Like if you think about Apple, Shopify like they have actual gates for what the what your extension must comply with in order for your extension to exist in the um the marketplaces. uh same expectation from my users. Even if you don't have the same gates in Drupal, the same expectation from users still exist. They expect to have the same exper experience across the whole product. Um this is a this is this is a little bit of a mindset challenge we've had with uh historically. So I I just put a screenshot here of the node edited form and if you imagine how you actually extend this uh this page JS probably by form alter because of that's really how you can inject things in there and form alter isn't necessarily encouraging any type of UX pattern or consistency because of you know you can do anything with it and it's great that you have the freedom to do you that to tweak things if you need to but also when we want to create that consistent user experience having focus and having something that is a little bit more guided uh would actually be helpful uh in terms of creating a good user exper experience. So in Drupal can panels instead of providing sort of a free access to having um your your your own extension anywhere we are actually we've created this extensions panel where you can create extensions that have a bounding box where you can do that essentially whatever that you want. I don't think that this is the northstar experience. This is just an example where we've this is what we started with because this is sort of the the the easy way um almost almost a form alter way in in a little bit more constrained way. This was just an example of a web governance that we've implemented in here. If you think about this example a web governance uh is essentially fundamentally what it does it evaluates your content provides you feedback based on that. I believe that for this use case the ideal user experience would be and the ideal API would be some sort of validation API that we provide that allows you in in a in in a given place in the UI for every extension that does validations would provide their feedback in. So now if you have a web governance providing feedback you might have a broken link checker module that is checking whether your content has broken links. Now both of those um validators could then provide in a single interface that feedback on your content. Um so essentially what uh we are we are doing discovery on is identifying what those patterns are that exist within the ecosystem and then providing some APIs that then allow build that consistency for different types of extensions and then we can implement those in in different paths. This is interesting because this probably isn't actually that much development work in the end but most of it might be pretty simple. It's actually just product work in terms of identifying what those patterns are and what we should implement. So if you're interested in um getting into product management, this might be an interesting opportunity to contribute on on sort of product management uh work. So this is something where a lot of you can get involved because this involves your modules and and and work that you've done. So this is where we uh see a lot of opportunity for you to be involved. If you're interested in uh come talk to me and I'm happy to brainstorm the ideas on how you can make your module uh get to the next level. So I just want to uh reiterate what the uh three value pillars are. Enable building sites really fast uh scale with CMS capabilities and then finally uh build an ecosystem of module modules for advanced use cases. I believe that those three pillars will will differentiate Drupal against the the CMS players as well as the AI players in the in the space. Something to remember is that we should not measure what we do by the the modules or features that we delivered. We should we should measure these things by customer adoption not technical completion. Uh an example of this is that probably even if we delivered all of these features in here that I mentioned uh we would not gain any adoption in Japan because we don't I didn't mention Japanese localization in there. So we need to understand what those of what those blockers are for gaining actual adoption of our features. And I'm happy to actually mention that uh Japanese localization is something we are planning to uh uh that up is planning to accelerate in 2026 specifically. So we will be looking into both making sure that Drupal canvas can be translated and that uh we actually make provide translations for Drupal canvas. Um but this is something that we should use as a guiding principle. It's not specific to the localization in any sense. We should apply that mindset to any everything. Finally, I I wanted to provide few pointers just quickly on how can I start using Drupal canvas just to give you something concrete uh around the next steps. So, Drupal canvas uh we have a release candidate in October. Uh we are aiming to have a 1.0 by the end of November. Believe we're still on track for that to happen. And then Drupal CMS 2.0 um is to be released in early January. I think we're targeting Drupal's 25th birthday uh in January with that uh surprise surprise. We like this release on birthdays. A great way to celebrate. Um obviously Drupal CMS is a great way if you're building a new site to get started. Uh many of you probably have existing sites that you're using. Uh that's where I have a I have a very high level idea where you probably want to create a plan by trying out Drupal canvas. Then making sure that you have some components available in interpal canvas and then essentially making sure that the modules or the different business requirements that you have they can be met with Drupal canvas and then only after that you would think about migrating content because already if you have implemented all the way up until three you can start developing Drupal canvas. Um so we have a demo uh repository that is great for you to start testing uh uh Drupal canvas. Um, so I recommend uh um using that if you just want to try out how the experience is. Obviously, Drupal CMS once it's released, that's the best way just to start it, but Drupal CMS 3.0 is not out yet. So, so this is a better way with that. For the existing components, um you may want to think about how you want to utilize your blocks or paragraphs in there. If you implement those as as SDCs, that's probably the best way to to build them to get them inside um a triple can box. Actually, you can also use within within triple canvas. In terms of modules, you may want to think about things like web form and seek editor that already actually work, but there's a lot more that you may have to evaluate like CP editor, plugins, editorial tools, workflows, group module, all of those things. Uh so you want to evaluate do I need those things when when I go through canvas content and uh uh uh how do I actually get them to work in there if you need them. And then finally the final step is if you have layout builder paragraphs on them those might be ones that you want to migrate you have some work uh in progress to make it possible to migrate but I actually think that this is the least important part side of this because of I recommend just gradually adopting Drupal canvas for new content and content where it's the highest value and then only later actually start thinking about the migration to Drupal canvas. So I've provided a few pointers on how you can get involved. We do have other other things that you can do as well. So marketing um even fixing issues uh in coding uh design work and so on where we can use help. So you can come talk to talk to me during the event or you can join our Slack channels to to join the team and uh help us. I believe that we're more or less out of time. Uh so I don't think we have a ton of time for questions. I don't know if we have any burning questions. Uh one burning question that we need to answer uh before we wrap up. So how I'm not working uh so how will the use of canvas influence the role of seeing that used to exist in Drupal? The question is how will the uh introduction of Drupal canvas influence theming in in Drupal. So I think the biggest change is the design system mindset. So SDC is essentially include your CSS, HTML, JavaScript inside the component. And of course in the beginning not everything that Drupal provides is compatible with single directory components. Um but eventually as more things become compatible with single directory components then actually theming becomes less and less relevant because it's more about building your right components and utilizing those components in the right context. U something something I recommend already taking a look at uh today if you're interested in going fully all in on the component-based theming in Drupal is looking at UI suite because they provide a lot of tools today that allow you to utilize design system concepts with existing Drupal tools. So for example, you you would be already able to use with UI suite, for example, uh components to build views or to use um the existing manage display uh with um with components. And with UI suite, you can pretty much get away from most of if you use UI Suite and and Drupal canvas, you can pretty much get away from from doing any Drupal theming hardly at all. Uh because everything is just components. The great thing about components is just that that's not in any way tied into the mark markup that is provided by Drupal. You are you own all of the markup and you can control everything which makes it just so much easier then to work with. All right, thank you everyone for for coming., YouTube Video H8duBXx-YcU, YouTube, 01kabxznb1qqbybt3g78erythh.