From Insights to Innovation: How UX Research is driving the future of Drupal CMS

Okay, thank you everybody. I'm sorry for the delay. We are we're back. We have slides. We don't have recording, but we're going to sort that out afterwards. Um I'm going to talk this morning about Drupal CMS and the evolution of Drupal CMS and talk to you about the role that UX research is playing in that and how that's helping us to keep um innovating. So, here's what I'm going to cover. I'm going to talk a little bit about me, a bit of introduction, talk a bit about what UX is and how that relates to Drupal, and I'm then going to talk about how UX can drive innovation. Going to then come down to talk about some UX research within Drupal CMS and how UX research how those work together, right? How um the UX research plan and the priorities for Drupal CMS, what we want to learn and how that's going to help us make it better. And then the bulk of my talk, I'm going to talk through some broad research areas uh for Drupal CMS. I'm going to talk about terminology, the installation process, the way that content options are presented. Going to talk about extending um I'm also going to talk about the AI features. And these are big areas of research, so I'm going to gloss over them, but I've got a link to my slides at the end and please uh contact me for the rest of the con if you're interested. I can give you some more detail. And then we'll hopefully have some time for questions and feedback. Okay. Um so, who am I? I'm Emma Horrell. Um I think I've met some of you yesterday at the Higher Ed Summit and uh some of you in other areas of Drupal. I have a couple of uh UX roles in Drupal. I'm the UX research lead for Drupal CMS. I'm the UX manager for Drupal core, which I share with Cristina Chumillas. Um I also do UX advisory stuff on the uh Drupal AI initiative. And like at the heart, I'm a contributor. And so, some of the areas I've worked on and like pretty proud of working on is um ECA uh next generation. I've worked on Drupalisms, which is an issue all about terminology and I started out working on promote Drupal a couple of years ago looking at the restructure of the Drupal.org website. My day job, I work in UX in higher education back in the UK and I like to meet people who do the similar job to me so I set up a community of practice back in the UK to to learn from other people. I'm also passionate about digital sustainability so if that's your jam come and find me I'd love to talk about that. I contribute to W3C on the special interest group. Okay, so that's me. So what's UX? I'm sure people have heard about UX and they know what UX is. And like sometimes I have an existential crisis when I'm working in UX and I'm like what is it again? What do I do? I'm really pleased that this definition exists from the international standards organization because it sets out this is what UX is all about is a person's perceptions and responses that result from the use and or anticipated use of a product system or service. I love the fact that this definition is there it makes UX a real-life thing but for me it's a more active process and so when I wake up in the morning I'm thinking okay, what am I going to do today that's going to make somebody's digital experience using a product system or service better as good as it possibly can be in a given context. So for me UX work on the daily looks like screenshots here. I'm always watching people using Drupal. I'm watching her listening to what they're saying about how they're using Drupal testing out some assumptions if I change this thing in Drupal how will people react listening always watching and just yeah kind of getting a vibe of how people are using it and then looking for opportunities to make it better to align with what people are expecting. And the way that UX works in a community such as Drupal and you might be familiar with is it can work in quite a reactive way. So this community is phenomenal for development and software engineering expertise. So, there are solutions and creative opportunities being generated all the time. And developers will very routinely contact me and say, "I made something. I want to make it really good for the users that it's intended for. So, can you help us with that?" And UX is kind of small in comparison to the size of the development community within Drupal. And somebody like me will go, "Yeah, sure. Let me have a look at that thing, but I'll ask a lot of awkward questions and I'll ask who it's for, when are they going to use it, what task does it help them achieve?" And this kind of leads to you can get some UX work done here, you can get some improvements done, but it's not the best way of working. And it can lead to a kind of awkward standoff between those two sides. So, a better way to work and where UX can really come into its own and drive innovation is for people like me to from all that watching people interacting with Drupal come up with loads of things that I can see that need to be made better. So, users are getting stuck doing this thing. Developers, with all your expertise, can you help us come up with solutions to make that better? Then you can move into reactive UX where the thing gets made and I can come in and do some testing to check if it actually solve the problem. This formalizes the UX design cycle. So, we do some learning, we build something, and then we measure it. And when it comes to Drupal CMS, this is a new product. We've had a huge emphasis on the learning, understanding what it means to people, what they want from it, and how we as a community can deliver that. So, here's the Drupal CMS mission statement. This one I believe came out in 2024. So, when Drupal CMS was in initially announced the Starshot initiative, I think it was in Portland, and it set out to to give an intuitive marketer friendly interface. There were aspects like lowering the learning curve to Drupal, which we knew was a reason people were maybe choosing other CMSs to build their websites and their um their digital um stuff, basically. Um it would feature uh common defaults for marketing task, AI-powered tools to help marketers achieve their their goals. So, the way that UX research can help with that is understanding well, what does that actually mean? So, when we set out to achieve an intuitive marketer-friendly interface, what does that actually look like? We need to know because we need to do research with marketers and that'll help us actually learn what we're building. When we're talking about lowering the learning curve, well, we need to know how steep is the learning curve now? Where are people getting snagged so that we can smooth that out? What's What smart default faults will they expect? How can AI-powered tools help them if we know their tasks? What marketing technologies um are they looking to to integrate with Drupal and so on? Another way of thinking about this is this uh product value canvas. So, for a product like Drupal CMS to add value and to to resonate with the people it's aimed at, it needs to provide gains and it needs to relieve pains through its capabilities. And again, UX research can help put weight into that to understand what those wants and needs are from the target audience, what pain points they have, what tasks they want to achieve, and then work out where a Drupal CMS can fit the bill. So, looking at the stretch goals for Drupal CMS over time, um and Drupal CMS is now in uh version 2.0, um but over time our stretch goals is to make tasks in Drupal easier and easier and keep chipping away at that. All the while opening up Drupal's capabilities and this really speaks to be Drupal being the differentiator over other CMS products, um where you would traditionally plateau, get to a stage where you were stuck with something like Wix or Squarespace, and then to avoid having to start again with Drupal, the idea with Drupal CMS is that we give this up front, but we do it in a way that's kind of gradual to to avoid the overwhelm. So, we're going to talk about what we learned from version 1.0 and how that's fed into the research that we've done since then and how that's kind of formed the plan um and talk about some of the techniques um that I've used working with others uh to to do more research to make things better for version 2.0. So, one version 1.0 included a lot. It was a kind of we needed to put something out into the world to learn what people wanted from it. So, it included things like the admin UI, which was Gin. We made decisions about privacy. We included forms, Google Analytics. We thought through about that market of audience and thought what would they need from a CMS and we put a bunch of things together. Um but really we collected these things together based on our best knowledge and the research that we'd done until people started actually using it, we weren't really in a position where we could like fine-tune to make these features better. But happily when we put Drupal CMS uh 1.0 out into the world, there were a number of ways people could use it. You could download it, you could install it, but there was also a trial that people could do just signing up through the Acquia website. And the good thing about that trial was we were able to attach a telemetry um mechanism a product to it to find out, "Okay, so people are are trying this out. What are they actually doing? What's their first port of call when they go in uh to try Drupal CMS?" And two like events stood out really um in terms of what people were doing. They were creating content and they were looking to extend to add extra functionality in. So, this gave us a steer as to, "Okay, this is what the the this the target audience want to do with this product. We need to focus our research efforts there." That broadened out it into kind of five like main areas, I guess. Um and these are all massive areas. If you like, the kind of ethics if you work in Agile, that's how you'd kind of class them. So, we understand that the way people make sense through CMS is by the words that are in the interface and how they speak to what they want to achieve. So, the terminology, the words we use, the labels are absolutely crucial. The installation process, that's the first impression piece when people decide to use a CMS provider, they're going to give it a certain amount of time trying it out at the installation process to make their decision. So, we really need to get that right. Content options, we know from that trial data that that's important to people. And I've class kind of doing more with Drupal to talk about extending and also adding uh Drupal functionality in. That piece of kind of opening up Drupal's capabilities, that's something we want to focus on. Drupal's its superpower right now is AI and the work that we're doing is kind of ahead of the game in the CMS world. So, we really want to harness that and use uh like think intelligently about the AI features we're developing and think which ones are suitable for Drupal CMS. Going to talk about each of these in turn. So, I'm going to start with terminology. So, way back when in 2023, a group of us got together um with a kind of common goal in mind thinking, you know, Drupal people shouldn't have to learn how to speak Drupal to be able to use Drupal. What can we do about that? We have a lot of terminology in our um realm um and some of it's confusing and it can alienate people. But we don't want to just change terms for the sake of it. That's a very knee-jerk reaction. So, we needed like a kind of standardized approach to this. So, myself, Ralph Keller, Luke, um going to forget everybody's names, Thomas Howell, and others, some of whom I'll forget, we came up with a plan. So, we thought, well, let's like how how can we address this issue? So, 2023 we set up an issue and we set out to collect the terms in the admin UI. Like, let's have a look at what terms we're actually using. Once we've got that, we can start evaluating, okay, well, which are the most confusing? How do How How do people understand these? How easy is it to define them? That's also going to give us a measure of which ones are most confusing. Once we've gone through that process, we can work out, okay, these ones are the ones that stay in a controlled vocabulary, and maybe there's ones that we can try and phase out in a words we don't say list. We can think about translations, again, thinking of Drupal's multilingual strength and how terminology plays into that. And then we need to establish a process to maintain this vocabulary. So, this is a huge piece of work. Um but we were super keen, and we're a small but mighty group, and we made a start. Um and where we started out, we got to 700 terms okay in this huge spreadsheet of terms uh for the admin UI, and we thought, you know, that's enough terms to maybe think about we putting something out into the community to gauge how confusing do people find these? Which things are um you know, which terms make sense to people? Which terms don't make sense to people? So, we launched a quiz. We're going to going to talk about that in a sec. Um we haven't started working out which terms stay and which terms go. That's kind of further down the line. Multilingual research in Drupal CMS, thinking about how terms map between different languages in a symmetrical and an asymmetrical way, um has begun. Again, kind of recognizing that this is something that Drupal does really well, and that we want to include in Drupal CMS. And we also started monitoring the terms. Crucially, we started really thinking about the terms that were on Drupal CMS interfaces um to keep it simple. I'm going to talk about the insights from the quiz um from that. But if you're interested in terminology, come find me. I can talk some more about it. And this is just a kind of snapshot of of what came out of it. So, the quiz included 20 questions. Some of you may have completed it. Um and each of the questions were kind of aligned as you can see as the in the examples in the boxes. Um and people were given a choice to answer true, false, or I don't know to those questions. 418 people responded and we gave them the option to disclose what their level of Drupal expertise was. And it was interesting that like the majority of people who responded were advanced. And what we found from some of the questions is that the community was aligned on particular areas and not so aligned on others. And this was interesting because it it really reinforced, okay, there is a division here. We really do need to think about how we use words and how many different meanings particular words have. Um and let's be really selective when we think about what's in our interfaces in Drupal CMS. As well as the responses to the actual questions, the community quiz collected some comments which are always good for my survey because you kind of feel that the kind of beat of what the community cares about. Um people looked at some of the questions and thought, well, do you know, I can't answer those. This is all about context. This is all about a task. I wish there had been a an option for it depends. And people are recognizing that, you know, words get out what words are created to mean things but people then adopt them to mean other things and that's kind of out of your control. And on that basis, there were a lot of comments um These two are just a kind of selection. Um but there was no, you know, there was a kind of recognition that this is something we need to accept that the language in Drupal will be complex, but how can we then think about solutions to address that? How can we think of ways to open it out to people? Um so could there be a simple guide? Could there be tools that we could use to leverage um you know, how could we use what the technology within Drupal to help people understand what the terminology means. And interestingly, this led to a pilot, one of the earliest AI um chatbot pilots um was a kind of learning assistant that helped people translate a natural language question into something that they could do in Drupal. So, it kind of um took that away from them. So, it's a big piece of work and really that the principle, I guess, to take away from this piece of work is that we're keeping, simplifying, and we're not losing sight of of that goal for for Drupal CMS. And this will manifest in a couple of things I'll talk about going forward. Choosing the labels carefully, thinking about every word that's in Drupal CMS interfaces, and thinking it where's the ambiguity? How how can we make sure it's concise but not complex? Things you could to standardize as well, thinking about how those marketers in their world, what else they're encountering, and what patterns and what standardizations are they familiar with, and how can we borrow for that? This has manifested with the AI um dashboard, which I spoke about a bit later. And also being very, very mindful of context, connecting with the use cases, and trying where possible to remove abstraction, um which leads to ambiguity, so that people are clear on what they can do um and and we're kind of on their wavelength, if you like. Going to talk about installation, this first impression piece. Um and the the research method I'm going to focus on here was some interviews that I did um last year. So, Drupal CMS version 1.0, we put people through an installation process, and they landed on a dashboard. So, the classic gin dashboard, they could do things once they'd arrived there. But for the the kind of visual marketer content editor type persona, it didn't really look much like a website. So, if they had a goal of what their website would look like, what we wanted from the installation process was how do we get them into that quicker? And site templates were the the solution to that. So, these were announced as a concept at DrupalCon Atlanta last year. And a site template would include uh single directory component based theme. It would be compatible with Drupal Canvas. It would have default content and features based on um use case so kind of thought through. And collecting a bunch of these uh templates together, they would be available in a marketplace so people could kind of browse in a very visual way to see sites that they like the look So, for that to work um from my side thinking about okay, what research can I do here to learn about how this might work? For me, it kind of there were a couple of dependencies. It depended on people building site templates and adding those uh to be available in the installation process and then also in the marketplace. And it also relied on people actually wanting to you know, us supplying what people wanted um from site templates for the people that would be using them. So, I did some interviews. There were a couple of surveys that went out that Tiffany and the the team working on Drupal um marketplace um put out and I added a a question on there to see if people would talk to me about this. So, I did some interviews with people that would build site templates and typically learned that the kind of what these people, you know, where these people were coming from. They're front end designers and developers. They might work for an agency. They might be freelance. But they would have a familiarity with Drupal and ways of working themes um and theming and and such. And what would motivate them to build a site template? Well, make money from them number one, but also seeing the marketplace as a way, seeing how their site templates that they would contribute could actually help them respond to you know, it could generate business for them. It could generate repeat business. It could also generate requests from new clients. Showcase their work as a good example where people would you know there would be a collective audience coming to to view these templates. Um and putting them out into the community um one of the things that people that I interviewed said um with that they would really like to put site templates out there and see how people then adapted them in for their own use cases and to understand like how people wanted to stretch them. So that was interesting to learn about the kind of motive the motivations behind it. In terms of the people that would use the site templates it was important to understand well what are they going to expect when they pitch up to when they see these site templates in the installer or if they go to a marketplace. So again who are these people? They tend to be content professionals sometimes front-end designers but the kind of people that were not as familiar with Drupal that didn't want to go through building a site template from scratch. They wanted a visual template to get them started a way in um so that they could then look to how they could customize it and extend it to get the look and feel or to respond to what their clients wanted. They would want to be able to browse different site templates have a choice and also to understand the provenance behind them so perhaps look at the builders um to understand like where their reputation came from how they could get support if they needed to. So the the insights that I learned from those interviews went towards the Drupal marketplace initiative but also bringing it back to Drupal CMS helped to shape okay how how do we present site templates um in 2.0. So going through the um installation process in version 2.0 instead of getting landed on the the dashboard screen you have an option of a starter site template or a byte site template. So the starter in fact both of the the site and the byte um sorry the starter and the byte site templates are Drupal CMS they're based on the Mercury design system uh, which was initiated by a company called Media Current and then taken over by the the the Drupal CMS team. Um, both include Drupal Canvas pages. Um, the Bite one is more styled, um, and it's aimed at a SaaS product use case. Um, and so it has it's like more styled content. The starter is is very kind of plain as a as a way in. Um, so once people have then installed Drupal CMS and they've picked the Bite site template, they're directly parachuted into something that looks like a site that they can edit. So they haven't got, you know, so it's bringing them closer to to a real site, um, which was the goal. When they go to edit, their default is to edit in Drupal Canvas. There are sessions about Drupal Canvas if you've not experienced it before. Um, and I've got some links to, um, in fact I've kind of done a bit of a timetable of sessions that you might be interested in after this one. Um, but basically you you're editing uh canvas editing within Drupal Canvas. You make your selection on the left-hand side and your editor appears on the right-hand side. So you're very There's no preview, there's no forms and kind of publish it and guess what it looks like. It's very visual and direct, um. Thinking about how we learned what we learned from those, um, interviews and putting that into a market, like making the marketplace a reality, um, in August there was a proposal for site templates, um, for people to contribute them, uh, to grow the number that are available and there'll be more about that throughout uh DrupalCon. Um, we've also started to think about how paid site templates might work in the installer. There's an issue about this if you're interested. These are emergent pieces of work, but again, still learning and going back to what we learned from those interviews, um, to help shape how the marketplace comes about. Going to talk about the content options, um, and I found that concept testing is my friend when it comes to learning about what people expect from interfaces. One thing I've learned in my not so many years of working with Drupal is that an interface looks one way and then the next day it looks slightly different. So, I've learned to screenshot things and and test um to get a gauge of how people um react to interfaces. And this is the approach I've used. I talked about content creation and editing being important to people who use Drupal CMS. And what Drupal CMS is an emerging product. So, you can edit your content with Drupal Canvas, but you can also use the node edit forms that you'd be familiar with. And because it's changing, there isn't one default mode over the other. So, both are available. And this can be a bit confusing for people when they've gone through that installation process to know, okay, what's the difference? Why would I choose one? And the answer is it's a moving picture and it is something that we need to communicate in the interim until things have settled down. Um you know, and and as like this is an iterative development process. Um but we need some way of explaining this to people um in the shorter term, I guess. So, I did some very basic concept tests and what you can see here is just two menu items um with top level like labels. And I asked people, have a look at those and showed them what they would get afterwards and kind of compared what they thought they would get to what they actually would get if they selected those items. So, I got them to look at create and asked them, you know, if you chose create, what would you expect to find? Pages, what would you expect to find? CMS, what would you expect to find? The way that we packaged it with pages took you to the Drupal uh Canvas editing and when you pick CMS, that took you to the node edit form. Create was having a bit of an identity crisis. It contained a bunch of things. You could create uh content types there. You could also create users. You could create documents. And when I did these tests with people, one of the things that came out was the stuff that was in the create option didn't really resonate. They weren't really sure why they would pick that. When they looked at canvas and they looked at pages, that became more apparent as to what they would expect. So, we made a decision in the short term, let's take away create until we have real like defined set of things to go in there and it stands alone from pages and CMS. Let's take it out. We might put it back in again, but this is an emergent picture. For now, let's keep it simple. Let's remove extra choices um where possible. The other thing we were keen to do was include icons to try and help people understand this is what pages does. This is what CMS does. So, we experimented with different icons. And picking icons is really tricky um because they mean different things to different people. Um and that certainly is what came out of the concept test I did around this. So, when I tried different icons, people commented one looked like a credit card, one looked like a file. Is this like an app um that the the kind of database symbol for CMS? Basically, there wasn't much alignment and people didn't really understand. So, the solution was to remove the icons in the interim. Again, very much in the spirit of keeping things simple, take out um any ambiguity or extra icons um in an interface to keep it simple. Doing more with Drupal. This is a kind of catch-all term for thinking about how people extend functionality within their site, but also how they set up um their sites to do more complex tasks. Um and this was a research that the research method for this has been mixed. So, starting with extensions, we appreciated that people would want to get set up with Drupal CMS and then they want to add extra functionality in. And these screens are probably familiar as to to how we present like kind of project browser, how we present modules, and how we present recipes. They can be in a list, they can be in icons. I'm thinking about how do we how do we make this as straightforward for people as possible. One idea we wanted to try out was well, let's separate extension from add-ons. So, let's separate the action of how you update the stuff that's in your site already to adding new stuff into your site. And again, the concepts tested around this was asking showing people a kind of screenshot of a menu and asking them to have a think about okay, if you wanted to check your site imagine you're a site owner, you want to check what's in your site to see what needs updating, which of these would you pick? Would you go to extend? Would you go to my add-ons? Similar question, if you wanted to add extra functionality in, which would you pick? Um and people basically who went when presented with this in a test, they wanted if they wanted to check what was in their site and update it, my add-ons made more sense to them. If you wanted to add new functionality in, that even though the word add was there, interestingly they picked extend as the kind of that was a familiar term to them to add extra functionality in. Going further, we've mocked up some wireframes of how that add-ons page would look like thinking about how that could how we could present the items to them. Um and we set it out as a kind of at the top there was like the core updates for Drupal that you need to update and then the things that had optional updates represented further down and further down. And these are some of the comments that came out of the testing. So, people got it basically. They liked how the kind of the important stuff that had to be updated was positioned at the top of this page and then stuff that they need to make a choice about was sort of further down, so that kind of followed their expectation. How we mapped out the extend page, we thought that it would be kind of logical to group integrations, so extensions that we're dealing with third party to to kind of group them together, so they would be like a bunch of company names um for third party um integrations. Add-ons we were using this still as a catch-all term to include recipes and modules. And then we also thought, well, you know, should we include templates here as well because it does this fit with the extension what people would understand. And again, showing people these wireframes, we learned a lot. Um people got what integrations were. They didn't get what my add-ons were. They were looking for modules. So again, a lesson to us, don't try and call something something else if people are already have a term that that's familiar to them. So, you know, that was a learning curve. They liked the templates being available, but thinking about where they were in the process having installed um Drupal CMS and having kind of functioning as a system, templates would have come earlier on. Why are you presenting me templates now? I will have already made that choice. So again, a way to kind of learn how to keep things simple and keep them aligned with the the kind of flow that's going through uh the minds of people working on this. Going to talk about ECA Ergün's here, and I'm not going to steal his thunder, but one thing for those of you who are not familiar with ECA, it's a really powerful way of adding um functional flows into your site. So, if you want to link ECA stands for events, conditions, actions. So, if you want to link something that then leads on to something else and something else, and you kind of want to store that as a this is a repeat action or a repeat flow that I know I'm going to do with my site over and over again, and I don't want to have to manually uh create this. ECA is your superpower, basically. Um and this is something thinking about opening up Drupal uh to people who are unfamiliar with it. This was like really at the top of the list to try and include this in in Drupal CMS. Um but we need to make it aligned with what the the marketer community would expect. So Juergen did some work thinking about the use cases. Why might you use um ECA? How could that be helpful to people? And I encourage you to to have a look at the the use cases on the blog um that he's written there. Where we came in was thinking, "Okay, we've mapped out the use cases for ECA. How can we kind of initially make ECA present itself in a way that is intuitive uh for these audiences to to use?" And that came down to the UI. Uh so ECA traditionally is is built on BPMN, and that's how it looks at the kind of um at the far um left of that slide there. And working with Juergen, we experimented with different ways um of improving this and making it more intuitive. And this is just a a couple of screenshots of a progression here, but I would encourage you to go to Juergen's talk uh later today uh to learn more about the the evolution um of ECA and how it it's kind of being positioned um to be a lot more contextual so that people can understand how they can add extra functionality and um using it. Um going to talk about AI features. How am I doing for time? Not too bad. Um I have been involved in the AI initiative for about a year. Um and what that involves is attending lots of meetings and seeing a ton of cool stuff being produced. Anybody that went to the AI summit um yesterday will be familiar with that. The question for Drupal CMS is how do we be selective of all of these things I've just kind of plastered on the slide there in screenshots. How do we choose what goes into Drupal CMS? Because it has to be useful and usable um for for to actually elect to use it, um thinking of that target audience. And that came back to going back to the sort of initial work with Drupal CMS and working out who it's for and what that value proposition was. Um so thinking of the kind of content editor, the marketer, the designer, creative, what are the jobs that they are trying to get done with their site and where can AI come in and help them with that? So consistent application of brand, compliance with accessibility, inclusivity, organizing and architecting content, grouping it for different audiences, running publishing workflows, structuring content. These are all kind of real-life use cases that AI could step in and help with. Another way of focusing, um like choosing which parts of the AI initiative to bring to Drupal CMS was the survey. This was a really interesting piece of work run by uh 1X uh last year. Uh they put out a survey and the survey included lots of different use cases for AI, lots of different options to apply it, and basically asked the community to to kind of vote up their their most favored. So the search optimizer, the audit trail agent, accessibility advocate, content librarian, approval architect, these are all areas that that people want to see AI helping in. And this has been a useful steer, again, working with the the AI initiative to think about which parts, where do my ears prick up when I'm in those meetings to think how do we apply this um for Drupal CMS. I think the other thing to bear in mind about AI adoption, um it's an emerging technology and the Gartner hype cycle, you know, any new technology, the adoption is going to follow this curve. Um so accepting that and then trying to work well how how do we work with this, knowing that this is how, you know, people's attitudes are going to change to this technology, how do we position the work we're doing with the CMS to make sure that the AI um resonates with them, I guess. And it comes down to, like, thinking of where we are in this space, thinking about how um we position it in a way that it's easy to get started. And that's come down to looking at things like dashboards, looking at interfaces, looking at the kind of step-by-step flow to get people started with implementing AI, um making it appear logical so that they feel in control of it, and and thinking about tools to support them doing the jobs that we know that they want to create. So, with that in mind, I'm just going to talk about some work with the dashboards. So, um Angulo and Bruno from uh 1x Internet, along with Aidan, um um and I worked on designing a dashboard. And the idea with this dashboard is everything is in one place. So, when somebody looks to install AI and use its functionalities, let's make it super easy for them to get started. So, they're first of all going to have a provider that they have in mind, so whether that's Anthropic, whether that's OpenAI, let's guide them through that process. Then let's take them towards the model that they're going to select based on the use cases that they have in their mind. Let's keep the more complex stuff further down, so we're taking them through a step-by-step process. They're looking to implement vector databases and such, that comes later. Um and thinking about how we standardize the layout. So, let's not make them learn a new layout in Drupal. Let's think about how they're, you know, what they're familiar with, what's out there in the world already. Let's use those patterns. So, using that pattern for the picking a provider screen and for the picking a model um screen as well, um so that it's familiar, so that we're we're you encouraging adoption by, like, removing any friction at that start process. Not going to talk too much about um the Context Control Center, because there's a whole session this afternoon at 3:00 uh that Aiden and Kristen are doing. Um but just suffice to say that a lot of UX work has gone into uh the context control center. Anybody that's worked with AI knows that how you give it context to deal with so that it knows what you want is super important. It's like if you onboard a new employee, you know, it's like there are do this if this or, you know, here's how you I want you to work in this instance, but I don't want you to do that in this instance and so on. There's a lot of complexity to it. So, thinking all of that through, thinking about use cases, thinking about workflows, again thinking about terminology, permissions, what the context sources are, what the scope of those, and how they all architect together um is really critical to get people from trusting AI and seeing how it can actually help them achieve their tasks. So, um the context control center is a fabulous piece of work, and you'll learn a lot more about it um throughout the con. And here are some sessions if you want to learn some more about some of the things I've talked about. So, there are a couple of sessions about site templates. There's one about marketplace, um context control center I've talked about, canvas, Drupal canvas, ECA, um and yeah, the site template one as well tomorrow um from Fina Proxauf and Andy um on yeah, Wednesday afternoon. If you haven't already tried Drupal CMS, um you can do so. Here are a couple of links to do that. So, you can either like install it yourself or you can go to Drupal Forge if you want to play around with Drupal CMS or Drupal canvas uh to to get the feel of it. And yeah, I My slides are available through the right QR code. I also have a five-question survey about Drupal CMS. If you would like to fill it in, I'd be very grateful for feedback. Whether you've used it, whether you've not used it, or I'm just interested in how it's landed in the community. And yeah, that's me. So, I'll stop for questions. Thank you. Hi. Here's if there's any areas of the the interface that you think are need more refinement than others. So, the question was about areas of the interface that need more refinement than others. I think the whole content options piece is something that maybe I'm quite close to it, but I feel it it needs a lot more refinement um to understand like for example, how people go in and collect select content types. There's a difference between how they add in a content type to how they actually use a content type to build out a piece of content. Designing that in an intuitive way is quite difficult because people expect to come to it from different um different ways. I've been doing some research thinking about how we package pieces of content to reuse as well because this is something that that's a real like a strength of Drupal having structured data. So, for example, if you want to send a set up um an event and you want it to occur at the same location, you want to store that location information somewhere. How do you do that in a way that doesn't involve people having to go to, you know, various menu items to find it and and all of that piece. Um so, doing a lot of work watching how people do it now, looking at how other CMSs um handle that, and and trying to like I think the guiding principle is trying to reduce the number of steps and interfaces um to that people have to go through to achieve stuff. So, yeah. I think there's still a lot to be done um on on that side of things. Any other questions? No? Okay. Thank you.