 Hi everyone, can everyone hear me okay with this setup? Okay, awesome. Well, it's lovely to be here at Drupalcom Portland and thank you all for getting up early for the morning session. Today I'm really excited to be talking about the future of content management and how Drupal fits into this landscape. I've been using Drupal for many years now, I think almost 15 years. And so I've seen it go through many transitions and it's always fun to think about kind of how it fits in to, yeah, where we are in this digital world we live in now. So just to introduce myself, my name's Suzanne Dergacheva, I'm one of the co-founders of Evolving Web and I'm also the lead of the Promote Drupal Initiative. So I love talking about Drupal, helping market Drupal and if you're interested in getting involved in that in the Drupal community, I'd love to chat with you. So that might come through a little bit today, my interest in figuring out how we communicate what Drupal does to the people outside of this Drupal bubble we kind of live in sometimes. So in my role at Evolving Web, I get to work on strategy for all kinds of different clients in the higher ed and government space as well as lots of other types of organizations which is a lot of fun. So the type of thinking that I'm talking about today is something that we work through with for a lot of our clients. So I just wanted to start off by talking about, yeah, how Drupal fits into the digital landscape. So what does that mean? I think when we're as maybe someone who's selling Drupal to organizations, helping organizations adopt Drupal, often we have to translate Drupal's functionality, its benefits to people who are new to it and sometimes that means we start to use these buzzwords around naming things about what Drupal does or the features it has. And when I started off doing Drupal many years ago and we were doing projects for clients, we would always talk about Drupal as a content management system. And this at the time was a real selling point because the alternative was just creating pages in HTML, doing hand coding, maybe making your own homegrown PHP to create a website and it was all a lot of work and it always meant that you didn't have a way for people to easily update their content. So the selling point was really let's make it easier for people to update their content. And so we always call Drupal a CMS and it was like this revolutionary thing. And if I kind of try to map out what that looks like and I created these lovely diagrams to kind of illustrate like what is this architecture in Drupal that we're talking about when we're talking about content management? So when we're talking about Drupal as a CMS, you know, yeah, it's at its core, it's content and then it has some APIs that we use and some things like, you know, we allow people to have workflows, we handle multilingual content, we have a migrate API and search API which add a lot of power and then on the front end, we have a theme. So like in a standard content management setup, there's the content that we store in Drupal and then there's the theme system which we use to spit all this out into the browser. So we see like the content gets displayed over here in the browser and yeah, like you create a page in Drupal and it appears in the browser but there's also a lot of stuff that happens that we kind of take for granted because we, you know, we're just using Drupal Day today and we forget about these things but there's an invisible part of what Drupal does when it sends content to the browser. It creates a lot of metadata that's useful for, you know, just making sure that our pages have good SEO value and that they, when we have multilingual content that it's tagged correctly for the language that it appears in and that it's accessible and to, you know, varying degrees over the years this has become better and better and we can just rely on Drupal to do this for us. So this is kind of a visible part about what the CMS spits out and then there's this maybe more invisible part that we forget about unless we're really thinking more carefully about what Drupal's doing. So that's Drupal the CMS. So we can all kind of take that for granted. Yeah, like that's what Drupal does. And then after using Drupal for a few years I realized that, you know, I had to start selling Drupal a bit harder. Like, okay, there's other CMSs out there. There's other options people are using. Of course, you know, we were looking at WordPress projects as well and it's like, no, Drupal is doing something a little bit more. So we started to describe Drupal as a platform and that seemed to do a better job of saying that, you know, Drupal's not just about managing content but there's all these layers of functionality that we can add on top of that content. And it can also, you know, content can come in and it also can come out in more interesting ways. So we can do integrations on both sides. So just the fact that it was designed for this type of flexibility as well as all the content management features it really made it seem like calling it content management system was almost underselling it and we should try to start talking about it as something a little bit more sophisticated. And when I look at how we use Drupal as a platform and I'm really zoomed in here just to make sure we can see this. Underline it's still the same thing. It's still got the theme system. It still has content and then it still has all these different APIs we can use for managing the content, translating things. But if it's being used as a platform then we're more likely to take advantage of some of these other APIs like the Migrate API because maybe we have a whole bunch of data that we just want to synchronize to Drupal on a regular basis and we wanna make sure that that gets in there. So we're using Migrate API pretty heavily. Or maybe we're doing some interesting things with Search API and creating some really interactive JavaScript based search interfaces that are only made possible because we have a really great way to translate our complex data structure into an enterprise search index like managed by solar or elastic search. So we're still using Drupal as a content management system but we're adding some of these extra pieces in. So Drupal is a platform, for years we've all been doing this and I think it still is today. We're still using it in the same way. But then I don't know how many years ago this started to creep in this language, digital experience platform DXP. So a lot of you here, yes, hands up, it's early in the morning, stretch up. You've all used this in a pitch or heard this or written it in RFP, DXP, is this something we're hearing? And maybe you look at this and you're like DXP, like what does that even mean? This is, you might be kind of skeptical of this new term and kind of what it implies. And DXP is digital experience platform. So the word platform is still in there. And when you look at the technology, there's not like a huge difference between the before and after. But what DXP kind of implies is that there's more of a marketing purpose and that maybe the content management piece is becoming a little less important because all these other integrations are just growing in importance. And maybe they're being prioritized by the marketers who are looking at the website. And so I think the term DXP partly comes from the fact that now when we look at websites, often the owner is marketing instead of IT. And so they have a different way of thinking of things. And if I look at how this spidery architecture diagram changes a little bit, underlying technology stack, Drupal is the same. Drupal's providing the same kinds of things. I'd say in recent years, Drupal's really expanded its capacity to manage more flexible content. So when we're talking about Drupal as like a platform that marketers like, we look at things like paragraphs and layout builder and we're all using these tools now to do like page building, right? So we're providing better tools for marketers. But there's a few extra things that maybe we're doing. You know, maybe we're instead of just always using the Drupal theme system to get all the information to the browser. Maybe we have these React components that we're using for certain elements. So maybe we're harnessing a little bit more of Drupal's just ability to swap in and out different types of front-end pieces. And still relying on databases and whatnot. And then my last little diagram here is, I'm gonna zoom out a bit so we can see it. It's a way of using Drupal that I'd say, you know, decoupled, like a fully decoupled solution has come about more recently. And it's more and more something that we're talking about in the Drupal community is in like, oh, we should be doing decoupled because Drupal's really good at content management. And if you notice the decoupled solution, we're not using the theme system at all. We could just throw this theme system away in this last case because we're really taking advantage instead of, you know, the JSON API to send off our data over to another website or another app. We're not using Drupal's core theme system at all. We're really relying on both the content management features but also these integrations. And we're still relying on the fact that Drupal's a platform. So where does that kind of leave us? So we have, you know, Drupal having grown over the years. It's still like a platform you can integrate with all kinds of other things. But also now people are starting to see the value more and more in this content core, in the fact that Drupal does content management so well that maybe we don't even need other aspects of Drupal like the theme system. And I think the thing to just, yeah, maybe keep in mind about this last diagram is that we are, we're throwing away the fact that Drupal can print out information using the theme system, but we're also throwing out that really important metadata piece. So remember that the theme system was used to create these nice templates so we can view our content in a browser. But we were also using the theme system to make sure that we had metadata, which is what we were using to make sure that our content was SEO friendly and accessible and all of that. So keeping all of that context in mind of Drupal's evolving role and the different types of roles it's playing now, so many more than before. Where do we see Drupal kind of going in the future? And I think that in the Drupal community we should really be focusing on Drupal's real strength, which is as this content management system that we can customize in a way that it's really optimized for content strategy. So how many of you here do some kind of content strategy as part of your job? That all of you do. So all of us, when we're working on Drupal sites we're doing content strategy whether we think about it that way or not. If we're deciding roles and permissions for users if we're figuring out what content type should be or defining taxonomies, we're doing content strategy. We're influencing the type of content that gets into the website, the way it gets reviewed for compliance, the way that it gets published. All of that is sort of part of our purview as builders. And so I think when I think of a content strategy platform I think of a platform that's really organized around user needs, where we can really adapt the messaging of the content that we have good tooling for that and where we have content that's really integrated with the digital services. So when I talked about the DXP like we suddenly start to see more and more integrations with CRMs and maybe commerce or other features like that but a content strategy platform should mean that content is kind of at the core of that so that we can still use content to influence the functionality of the site. I think it also means that content should be portable and really structured. And that's something that Drupal does well that I see less well in other content management systems like even content that's like this amazing looking landing page that we've constructed with all these building blocks it should still have this integrity of structure behind it. And that's what allows our content to be accessible and compliant and still have all of that value that we need it to have. And we also want compliance to be built in systematically. So what does that mean? It means when we're creating content we should be as much as possible guided towards creating content that fits into our brand and that is accessible and so that content editors don't have to think about that every time they hit publish. But I think that a content strategy platform is also really tied to like the organization behind it. So it's not enough to just say, oh we built this website that makes it really easy to have a good content strategy like it has all these cool features for building structured landing pages and other structured content. And we really thought about our content and we organized it well and we did an information architecture and we did our user research like that's all great. But if you don't have the organizational kind of momentum and commitment behind it it's not going to work. It's not gonna be a successful content strategy platform because it's not gonna last. And so organizations that are using these platforms need to empower content editors. They need to have best practices around web publishing. Sometimes that can mean training or documentation. You need to be able to make improvements and not just keep things at the status quo. And you need to have a clear content governance plan which is something that I think has to really live alongside of your Drupal website. And finally, when you're building a Drupal content strategy platform you need to really prioritize your content editor needs. And that could look like many things, right? Like the awesome thing about Drupal is that every time you build a new project you can have a different interface for your content editors. And you hear more and more I'm sure you're gonna hear about it in the Drees note tomorrow. You're gonna hear about it at other sessions throughout the week. Like content editor needs are important. We need to be thinking about making a good experience for content editors. But the awesome thing about Drupal and the fact that it's a platform that you can plug and play with is that that experience doesn't have to look the same for everybody. A lot of you work at universities that have all these administrators coming onto the site to edit content. Other people have really small teams of experts or maybe you just have two content editors maybe you still need some kind of thought about what that experience is gonna look like. And I don't think it has to be complicated. We don't have to reinvent the wheel every time. But when I think about content editor experience I think about kind of this hierarchy of needs of thinking about just giving them a nice experience having some good workflow that makes sense for the org having content compliance and then thinking about what level of flexibility is needed. So some kind of thinking about this needs to go into a content strategy platform. So what does this look like? I think like when it's actually implemented I think it means that content editors are first class users and teams of communicators can actually make improvements. So they can just say, okay well this is our new strategy for the year like how do we have to adjust the website? They should have some tooling in place to do that. And I think ultimately it results in less separation between the content experts and the end users so that you can communicate more easily. And that less separation doesn't mean that like everybody just has access to edit. It could mean that there's certain content types that have a really low friction for getting content out the door. Other content types maybe have a cycle of revisiting that content every six months. But somehow you have to have like a platform that can actually be used for communication that this doesn't take long time, things don't get out of date. So Drupal is a particularly good environment for creating this because of its flexibility in part because like I said you can adapt the content editing model to fit the content governance. It doesn't have to be the other way around. And you can empower content editors in a thoughtful way. It's also a really good system when we're thinking about content strategy because it allows us to standardize so much. So many of you are probably working in environments where there's not just one channel, there's not just one website, there's not just one thing. You're working in environments where there's multiple websites or there's a website and an app or there's a desire to create more and more, to scale up maybe what you're doing online. And the fact that with Drupal that we can create standardization means that you can have documentation that works for content editors across your organization. And that's gonna help also with some consistency over that. But there's also lots of things that are hard. So with flexibility I think comes a lot of a lot of challenges. So when we think about Drupal's flexibility, Drupal allows us to create different content types, to create different workflows and different ways of creating content components. Maybe a lot of you are using already paragraphs and layout builder and you've created 20 paragraph types or 25 different block types that people can place into your layout builder. Does anyone have a situation where there's like a lot of options when you go to add content? Yeah, so I mean flexibility is really this enticing thing that we can give so much control over the layout of pages. We can give so much control over what each piece of content looks like. And it's enticing and it's also possible. We don't ever turn around to our stakeholders and say, oh yeah, we can't build that type of content in Drupal, that's not possible. So there's no limitation of like, oh we can't do that because of the technology. We have to put limitations more in terms of what should be, what the content, what we want it to look like. And so because of Drupal's flexibility, it's often tempting to just go in this direction of so much variety and not enough kind of standardization and control. Another challenge is standardization itself. So how many of you are working in an environment where you have more than one website? Yeah, lots of people, more than one website, sometimes more than one language, sometimes more than one location that you're serving, even within a single website, right? There can be a lot of variety that you're trying to handle. You can be maybe creating a website where different departments have some kind of autonomy over their section of the site. And often you come into a place where this already exists. Somebody already decided oh we're going to, we're gonna spin up a new site and for this one we're going to use React because it's the cool new thing. Or for this website we decided to take a totally different direction with the theme and do it a different way. Or we're gonna experiment over here and use Layout Builder. And when you're just coming into an environment like that or it's just kind of grown up around you, it can be hard to say oh yeah, but we should be standardizing so that it's easier for content editors to produce good content. And so coming in retroactively, you could be looking at two Drupal sites, but because of the flexibility, there's just so much variation that it's hard to rein that in and say yeah, let's create a common theme, let's create a common set of configuration that we can share. So just because standardization is possible, it doesn't mean that it's always done, right? And doing it afterwards is a hard problem. And another hard problem I think is personalization. There's this expectation now that okay, we're using Drupal as a platform and I heard that Drupal does personalization. And we're a marketing team so we just want to create these landing pages for everything and we want them to be personalized for every type of user under the sun. How many of you are using some kind of personalization on your site? Yeah, you might be doing personalization, you might be doing it a little bit, maybe you're doing translation, this is also similar to personalization, had some of the same challenges. But anytime that you're personalizing content, it's this great opportunity for marketing to do great things, but it's also this huge burden of duplication of content. So whenever you're describing database driven content management to someone, one of the selling points is that we don't duplicate content, right? You create content once and you can use it all over the place, it's fantastic. But with content personalization, what often ends up happening is we say, oh, but we could create another version of the content for this audience or that audience and you end up with more variations than you know what to do with. So that also poses a challenge just in terms of maintaining all of it and keeping it up to date. Legacy content is a huge challenge. So you go to presentations at DrupalCon and you learn about all these new things and maybe you're learning about, okay, it'd be fun to start using Layout Builder, we've been meaning to use it for years and you go back to your team and you try to implement it. And one of the things that stops us from making these types of aspirational big changes is that we're stuck with thousands of pages of legacy content. So how many of you have thousands of pages? Hundreds of pages, lots of legacy, because Drupal's great at managing a lot of content. That's probably why we're using Drupal to begin with. So almost every project you run into, there's quite a large body of content that we have to work with and morphing that into the perfect structured content that's been well thought through and works for the user and is compliant. It's, there's no magic wand that does this, but there are opportunities to clean up your legacy content that Drupal can actually help you with. Migrations are actually a great opportunity. We think of them as just being kind of like, oh, we have to migrate content from Drupal 7 to 9. This is a huge project, but it's this opportunity to clean up your content along the way. Maybe some of you are considering doing that type of migration soon. I know my colleague, Doris, is teaching in class and at this week, it's up a lot of people's minds. And when you're designing a new content structure and trying to map things over, this is such a great opportunity to transform it along the way. Okay, so lots of big ideas. You might be thinking, this sounds good. Yeah, content strategy. Let's do more of that. But what are some things you can actually go and take away and start doing at your organizations? Like what are the first steps? So one of them is getting content experts involved somehow in the process. So who are content experts? It's subject matter experts, but also content editors. I think it's both. Sometimes those are the same people. Getting them involved, if you're doing discovery for a new project, you can get them involved in user experience workshops as users. You can actually see them as like, this is an audience for the site. The content editors are an audience. You can get them involved in creating taxonomies and structured content, especially if you teach them some Drupal. So I think it's always nice if content people have some basic understanding of Drupal's capabilities when it comes to content management. And that could be basic stuff, like what are paragraphs, what are taxonomies, what are blocks, what's, what are content types and why are those used? That can really help. Documentation. So this is a, yeah, go back after DrupalCon and write some documentation. You know, a lot of the sites that you're probably thinking of when you think about the Drupal sites you work on in whatever capacity they probably already have some kind of documentation, right? You create a user manual. Here's all the content types. Here's how to create them. Probably a lot of you can think about a page somewhere on a wiki or a handbook that looks like this. But what I very rarely see, and I would love for you to mention it if you've seen examples of this, is I very rarely see such a manual that actually says here's the different types of content and here's why you would use each one. You know, if you're creating a landing page and you're gonna use this type of component, this type of paragraph or block, like here's why you would use that as opposed to something else. Here's some actual examples and not just the how, but the why behind it. And how you decide to use one over another. I think this type of documentation where you actually get the technical documentation and the content strategy documentation turn it into the same thing, this is going to be incredibly valuable for your team. And it's something that you don't have to recreate your website to do. Yes, question. The documentation, you have a well site. Oh. The sense that if I use a new documentation and the first thing happens is it goes out of date. You're gonna create your content type here as in the script you're seeing. Yeah, absolutely. So just to repeat that, this is a question about if you should just have documentation or if the actual documentation should kind of like live embedded in your site where you have good help text and good kind of guidance to users as to what to do. I think you should have both as much as possible if the interface can be self-explanatory because you have good like content type descriptions and labels for your fields that actually use the terminology that content editors would use. I think that that's a real advantage in something you should try to create. And that might mean that you need less external documentation because some things are just obvious. So that's a really good point. Content governance is often something that's like created once in a document somewhere and then nobody's looked at it. Like you might be thinking, I think we did content governance. We did that way back before we built the website and then you never looked at it. So for this to be living and breathing, it's nice if it's reflected in Drupal's roles and permissions. I shy away from making roles and permissions too restrictive and to kind of like 20 phases, 20 states that content has to go through for it to be published. But at the same time, you want it to be obvious when someone goes in, well, this is what I am allowed to do on the site and this is the content that I own and if that can be reflected, then that really helps. And having some views, just some simple views for content editors to show them like lists of content that they might live in a certain state that they have to update, like that can be super powerful. It takes you not that much time to create a view that becomes incredibly useful tool. I already mentioned cleaning up legacy content. So maybe not an easy next step, but if you're migrating your content anyway, plan some extra time and invest in that. It can be a hard sell sometimes, but I find often the accessibility card is a good one to play here. You wanna say, okay, we have all this legacy content and we could leave as is, but it's not accessible. So therefore like let's prioritize cleaning it up and then you get both benefits of more accessible content but also more structured content that's gonna just do a better job of realizing your content strategy. And so those are all things that you can do as next steps, little things to start building a more content strategy focused environment. But there's also things I think that Drupal can do. So Drupal's open source, we are all part of this community here at DrupalCon and I think there's things that we can think about doing together so that all of us can benefit from a more content strategy focused Drupal platform. So what are some examples? So I think that we can better optimize the content editor experience, it's clear. Maybe some of you, as anyone here using Drupal for the first time, kind of like just discovering it this week, oh not too many, okay. But like you maybe can think back to that moment and it is this challenge that new users have especially content editors, if the environment hasn't been kind of, the admin UI hasn't been configured if it's just been kind of left in a default state it can be quite overwhelming for new users. And so just having some better defaults could really help and using the language more of content a little bit and going away from the language of site builders and developers in the UI could help us in this way. So a lot of the interfaces, if you look at them in Drupal they're actually built for everybody. They're built for content editors but we also see them when we go into, you know, configure our content types and do our development. And so maybe having some defaults that work better for the content editors would be an advantage. There's some things like auto-save, having auto-saved content that I think content editors would just love, better previews especially in that kind of decoupled architecture and then having better practices around accessible page building tools. So right now, if you start using something like layout builder to manage your content it's very easy to get away from the default accessible markup that Drupal produces out of the box. Soon as you add like a page building tool where you get more flexibility all of a sudden, you know, the onus is on you as a site builder developer to think about, well, what's all the markup that this is creating and it does the structure make sense? Are the headings in the right order? Do I have the ARIA tags working? And it becomes this huge challenge. So if somehow we could have better defaults with this prospect, I think we'd have a good result. And then the other area on the right, this is kind of maybe less defined but I think it's a really interesting question in Drupal, this line between configuration, what's configuration and what's content. So if any of you are developers you'll be well aware of this because all the time you have to do things like oh, I'm gonna export the configuration and then you see that. Okay, export of the configuration but then the content is this other piece. So this is really clearly defined like, okay, content is all your nodes and all your taxonomy terms and configuration is like the actual content types and the taxonomy term structure, right? So we keep these things separate so that it's easier for us to make updates on our website and configuration management is fantastic. It's one of the great things in Drupal in the last few years. And yet what it kind of does is it means that Drupal is a great platform for developers and then you can go in and edit content on it but anything in between, it's kind of this zone of like, well, what if I just wanna update a web form, right? Or what if I want to make some adjustments to the information architecture but I'm not a developer? So configuration management is kind of like for people who are really interested in content and information architecture, but they're not so technical. It makes it really hard to make improvements to Drupal. So it's nice, like the line between configuration and content is great, it adds so many advantages but it also sometimes means that content strategy improvements are harder to make and people get blocked. So can we somehow remove this barrier to entry for site builders or information architecture people? I'm not sure, this is a big question. I would love to hear if people have thoughts or ideas about how to do that or like challenges that you faced and trying to make these types of changes. And just a quick shout out before we go to questions. I hope there are some questions lingering in the back of your mind. Evolving Web does training. We have lots of training coming up around Drupal, all types of topics in May and June. These are online live trainings with my colleague, Teresa here. And we also have a whole series of tracks for different types of Drupal users, including site builders, front-end developers, content creators, back-end developers. So if you're interested in any of that, we'd love to have you come and chat with us and we can tell you more. And with that, I would love to hear questions and comments and hear what you have to think about all of this. Yes. And if you wanna come, you can come up here and ask the question to the mic, otherwise I'm gonna repeat it, so it's up to you. Yeah, great question. So are there courses on content, information architecture and strategy? Yeah, we have a track for content creators that includes a course on user experience and content strategy. And the site building track also has more of the line between doing your information architecture and then how to translate that to Drupal. So it's a little bit more Drupal focused. Yes. Thanks, I don't know. I think I closed it, but yeah, I can share that. Well, come up to me afterwards and I'll make sure you can get it, yeah. Yes. Yeah, that's a great comment. So the content editor interface, there's lots of improvements to make in different ways. But if you start to use Layout Builder, if anybody's doing that now or considering it, by default, this interface is really like one of those interfaces that works well for site builders and is a little bit, well, it's quite a bit harder to use, I think, in the content editor context if you're thinking about things from, like, I wanna build a landing page. So there's a lot of things that you can do to improve that experience. So one of them, like you mentioned, is adding icons, allowing you to preview what things are gonna look like. There's Layout Builder restrictions, which I think is an essential module that allows you to limit the massive list of things that you can place into a layout. So there's quite a few optimizations you can make. Yes. Yeah, that's a great question. So it's about content publishing and how you can preview content more effectively and really get a sense of what it's gonna be like. So when you create a workflow in Drupal for use the content moderation module, one of the huge advantages is that you can have drafts of content that are already published. So that really helps you preview what it's gonna look like. Like if you've published, obviously, the About page, it's always published. If you wanna stage, like, draft some new versions, you can do that, you can have a link to the content. And there's even a module that lets you send out that link to users that aren't logged in so that they can take a look and see. So that works well on a page by page basis. And then, of course, you can have states of content approval to get it to the published state. But it's more challenging when you're looking at like, okay, we are going to launch this new campaign and it's not just one page, it's like a landing page and then all these other related nodes that are associated with it. Or we wanna launch a new section or do an update for the new year, like academic year that's coming out if it's like a university site or something like this. So in that kind of context, it's not just one page. It's like a whole set of content and maybe you also wanna preview like, how is this content gonna look like in other contexts? Like the content's gonna appear in all these views and the content's gonna appear in the menu system. So how is that all gonna look? And how does that affect the whole experience of the site to have all this updated content? And for that use case, it's the WorkSpaces module that's been developed, which I don't know if anyone here has tried it out. It's relatively new, like been kind of slowly added. And it's something that you can consider experimenting with because this is the exact thing that it's for. So basically you have multiple environments and so Drupal's actually set up in multiple places, multiple installs. And then the content itself can be staged in one install and before it's published to another. So you're kind of taking what we do with configuration management and using a little bit of the same technique behind it, but for content. Yeah, yeah, it's a really good question. So it does definitely change that workflow and it's just like configuration management which you can have conflicts but sometimes things don't conflict and you can merge things. Yeah, you might run into difficulties if you're trying to edit the content in two places at once. Yes, but this is why it's not in Drupal, like doesn't come out of the box with Drupal. It's something that you might add. It's a core module but you can enable it in experiment but you would have to look at that use case and test it out and see what type of conflicts you might run into depending on your use case. Yeah, right, yeah. Yeah, so that's great. Like I think having more information in the UI that shows the content editors here is the state so that it's a predictable process. This is really helpful and I have some blog posts if anyone's interested in some user research we've done on Drupal and kind of comparing different CMSs and that's definitely something that comes up is just the predictability and just the anxiety that comes with having drafts of content and is my content saved and what version is published. So definitely thinking through the UX of that is a great idea. Yes. Yeah, there's definitely different customer journeys around like picking what content management system are we gonna use? Oh, we actually need a platform. Oh, well, we like WordPress because we used it for our other site and it's not always purely like logical. Like I have these needs and therefore I'll pick this technology and really to be honest, like there's some use cases for which you could use one of many different platforms, right? But why do we choose Drupal? Because it gives us not just the features we need maybe on day one, but it gives us this extra flexibility. So it's often that that's driving us or maybe we have this need from marketing to create this really great like marketing kind of content and that's what's driving the decision. But actually we also have behind the scenes that everybody forgot like 30,000 informational pages that by law we have to publish and it's really structured content and it has to be searchable and like Drupal's like clearly going to be the best solution for that. So like yeah, decision making process about what platform to use technology wise versus strategies is not always like a clear line. Yes, yeah. Yeah, what's a good, I think sometimes well the project starts and you think that this is the problem that we're solving. So maybe the problem that we're solving and like if you look at pain points for websites if there was like a whole list, I think the one that would be the most often listed is like users find it hard to find content. And that's just like kind of a thing that happens when you have a website sitting around for a while and people aren't paying attention. And so the solution, there's so many different solutions to that problem and it could be like, oh, let's put a big search form on the front page or it could be like let's throw away most of the content or it could be let's rewrite everything and simplify the language or like there's just so many different solutions. So sometimes when you're figuring out like what the problem is, you need to be a little bit more specific. And so the user research you do for that, like it can be extensive, you can spend months on user research, but you have to dig into a little bit more like why does this website exist and like why are the users using it and what are their priorities? You need to have like some base knowledge of that to really understand the problem before you start trying to just throw all these solutions at it. So I mean, that's kind of a, I don't know if that's a good answer, but it's definitely possible to easily over-engineer a solution in Drupal. So I think we tend to, let me sometimes look for solutions that are a little bit more complicated than are needed to solve the problem. Yes. Oh, good question. Drupal 10, I don't know so much about Drupal 10 yet. One of the things that I'm interested in is like the CK editor is being updated. It's going to be CK editor five. I know that there's work being done on that right now. And of course that's going to impact the content editor experience. I can only assume it's going to be better. And we're talking about content strategy. I mean, a WYSIWYG editor is kind of the bane of our existence as people who want to create more structured content where we have more control and more governance. So if somehow the WYSIWYG editor facilitated this, it's an opportunity for maybe it to help us clean up content more in some way. But to be honest, I'm not sure exactly what the changes are going to result in. Well, thanks so much for joining me this morning. I really enjoyed this and feel free to come up with other questions and chat.