 Thanks everybody for being here and apologies for the mix-up in the rooms. So if you weren't planning on an AI talk, then maybe you're in the wrong room. You might need to go somewhere else. My name's Josh and today I'm going to talk to you about generative AI. And sort of in the theme of Lord of the Rings from New Zealand, Wellington, is it sort of the one UI that will kind of rule them all? A bit about me. I've been a part of the Drupal community since 2007. I joined AQUIA in 2014. And I've kind of really focused my career around working inside of that enterprise space of Drupal. So I've spent a lot of time with large organisations. They often have lots of different properties that manage data and get things. You move data in front of customers, content, that sort of thing. You've got a portfolio experience across international news and media, public sector, global sporting events and other major industries. So lots of different spaces and industries where enterprises still have these large sets of data. And so be that in mind with what I'm talking about today. It is sort of thinking about the larger problem, but there's definitely some smaller scopes that this will apply to as well. So let's get into it. Before we really start talking about AI, however, I wanted to just take a current look at the current state of the content user experience for a standard enterprise. So today, digital, when customers go into and experience your brand if you're the customer, you're often going to go across a number of different content silos inside that organisation. So here's a list of some of those things. You might find the organisation through a piece of thought leadership in a blog post. You might find your way to their website and learn about their products and solutions. You might get signed up to a newsletter or a webinar and start getting email marketing campaigns. There'll be at some point legal information, privacy information, that kind of thing. If you want to buy through them online, there's going to be an e-commerce platform. You might need to also have some security information if you're compliant with certain government standards or things like GDPR. Then there's going to be other types of content like how do I do this thing with your products? You're going to need blog posts there. You might need some training, maybe a learning management system as well. There's going to be product documentation, reference manuals. There's going to be a support portal so that you can log tickets and ask for help that way. There'll be a knowledge base system as well, which has maybe some pre-canned ways of dealing with things to prevent support tickets. Often, organizations put something like a federated search layer that sits over the top of that so that, well, maybe I don't know which of those things I need, which types of content I want to get to. But if I can search for it, maybe the search results can help me get to where I want to go. That's kind of how Google functions when you think about it. Then you can also say that the content is a part of a different part of the customer journey. So at the beginning, I'm looking for evaluation, what products might exist to help me deal with my problems. Then if I move into procurement, what sort of things I need to know before I make this purchase. And then finally, I've made the purchase, how do I go about implementing that thing. And so this content actually has a different purpose depending on where that customer is inside that customer journey. Then finally, you have different parts of the organization responsible for managing and maintaining that. So they have sales and marketing that deal with content relating to evaluation and procurement and customer success who would have some sort of role in managing content to do with procurement and implementation. So this is a very loose diagram, but it should reasonably translate between most organizations. They all have some components here and the organizational structure will sort of dictate how the content is managed. But loosely speaking, this is sort of a rough idea of how the digital landscape works for most enterprises today. And there are three UX challenges with that current state that I really want to talk about in address. Number one is that your internal governance equals your external experience. What I mean by that is, well consider this, an organization has independent business units and they have independent budgets. And they buy and build solutions according to the remit that they have inside of that business unit. And so when they go and buy and they go to market and they buy a piece of management software, they really buy within what can that tool do for them and facilitate their business. And then the user experience becomes a byproduct of that purchasing decision. So we end up with lots of different silos of managed software and the customer has to jump from one management system to another management system and the user interface that management system provides to be able to get a holistic user experience. So that's sort of problem number one. Headless applications I'll say have kind of provided an option to get around this, because you can create a headless front end and then have multiple back ends to manage that content. However, that only really works if you have a business unit that focuses on a unified front end. It won't work if that business unit stool is going to deliver within their remit, because they're not going to create the holistic journey. Challenge number two is creating an intuitive experience with sprawl. It's kind of like a pointless statement, you can't. Like sprawl is not a intentional design of user experience. Like who wants to send the user to another sub-domain? Why is that a good idea? We just do that because we have lots of different properties that we need to manage and the only way to really continue the user experience is to send them from the flagship.com to the blog.com to the support desk.com, or whatever that is. That's just a consequence of the sprawl. It's not really a user-centered or UX-centered design decision. The third challenge is getting to the fastest path from question to answer. This is obviously the thing that we've always been chasing in the market when you think about it, and the fastest path to get an answer today is always being search-based. That's why we have that federated search layer that sits over the top of it. That's why Google has been so successful in what it does, but ultimately it's not fast enough. People still end up mixed up inside of your content experience. They don't know how to find the content they want to get. There's a lot of other reasons for that. We might not be really clear on where the content is. Does it sit in product documentation, or is it in the knowledge base, or is it inside the Thought Leadership blog post? Sometimes there's some real big discrepancies between those, and we're all practicing or singing from the same songbook because often different business units are producing different contents. How do we know that we're being consistent and on message? Those are the three challenges. To quickly review them, number one, internal governance is equal to the external experience. The way we want to approach to solve that is to streamline the governance and workflow in an open publishing environment. I'll talk a little bit more about what I mean by that. Number two, that creating an intuitive experience was sprawl. The way that we can approach to solve that is to reduce the sprawl in the UI and optimize for the UX. So it's not about how many UIs you have, it's about what your user experience is. And number three, the fastest path from question to answer. The approach to solve that is through personalization, contextualization, and on-demand responses to questions, which traditionally is like the fastest way we've been able to do that is with things like support tickets, and then a little bit faster with chatbots more recently. And then of course generative AI presents a new opportunity there as well. So let's talk a little bit about generative AI. For those of you who don't know what that term means or have just heard of AI and not heard of the term generative AI, it's the thing that generates content. Things like text, images, and video from a text prompt based on a statistical modeling system and it's trained from prepared data sets. And it's generated off a randomized seed. So it's really kind of important to understand the part that it's statistical modeling. So that means it's always going to predict what has always been. It's not really like a future predictor or anything like that. If you give it a new problem that has never been statistically encountered before then it's not going to really be able to give you an accurate answer, for example. So to give you an example of how generative AI works, you might give it a text prompt, something like, Dreesbytarad is a driplicon. Give that to the generative AI. Voila. Where's the spikes? I thought that too, but then I realized there's a spike right at the top of his head, so they kind of got on point there. All right, so addressing the 3UX challenges with generative AI. So, number one, we're going to make internal governance not equal to the external experience. So organizations can optimize internally for governance without compromising the external experience. That's going to be what we want to do. Number two, we're going to remove the sprawl, access to that sprawl. So sprawl can still exist, might still have to be there, but it doesn't mean that our user experience has to be driven or delegated by it. So maybe we kind of constrain the access to that sprawl. Maybe we can surface it up under a unified UI. That's not something that organizations can just big bang, by the way. They have to work at it over time. As budget allows, as investment allows, you have to prioritize the things you're going to bring underneath that unified UI. But we're going to want to make sure that a goal is to have no cross-domain navigation. There's a lot of reasons for that. Nothing to do with cookies or anything like that, but it just means consistent branding, easy to manage, and ideally one team that is responsible for that user experience. Thirdly, the faster path to answer. Generative AI does the intent analysis, search and response to inquiries, mitigating self-service search and content analysis, reducing the time looking for an answer. It's a huge mouthful. I'll try and go into a bit more detail about that in a moment. But it also increases the availability of just-in-time learning. If you know anything about the learning services or education space, this is sort of a holy grail. Can I get the information a person needs at the time that they need it? Google does a pretty good job of that today. But Generative AI really kind of takes it to a whole other level because it adds a wealth of context based on the question you're asking, not looking for a resource that kind of looks like what you're asking for. So to look at that diagram I showed you earlier, but with a Generative AI idea plugged into it, it might look something like this. We have a user experience, a headless-based UI with a chat prompt that sits inside that UI somewhere, and the headless UI plugs into a series of APIs that connects to all those management portals that we were talking about earlier, but we're able to bring that under that single veneer. At the same time, we also have this Generative AI plugged in and it actually sits on top of the federated search for reasons I'll go into a little bit later, but it helps find the right content that the chat prompt needs to be able to surface back up to that organization and ultimately helping to answer that question. Whatever the question is, at whatever point in the customer journey they're in. You still have sales and marketing and customer service managing the content that sits in all those management silos, but you now have a new UX unit and IT are going to help manage that middle layer because it's IT infrastructure. So there are some challenges with this approach and the biggest one that's really kind of hit right now is that Generative AI can be too generic. If you've ever tried doing some testing with this, it won't take too long to realize it has these issues. So it can't really respond well in organizational contexts. For example, there's ambiguities in our language, so I might talk about something that in our organization that the nomenclature means this, but to chat GBT or whomever, that means something kind of different, more broad, more ambiguous, so that can lead to misdirection and misinformation from the AI. It also hallucinates. It can be very confident in telling you something that is actually quite incorrect and tell your user to go do something, like click in the top right hand button, but the team, product team have moved it to the left or it never was in the right in the first place. Finally, the third kind of issue here is machine learning. Machine learning actually requires really large datasets to do training off of, and it's not just the fact that you need to have the data. You need to have the data that is also with outcomes measured on it so that when you do the training, you can say, was the AI successful or not, and the prediction, and if it wasn't, you need to give that feedback back to it so that it can continue to do that learning process. So you often need quite a high volume of data with quite a high volume of measurements that say whether it was a successful or negative outcome so you can do that training. There's a conundrum in that because chances are good that if you can get, say, a million sets of data that could do this, you've probably built some tooling that has done that prediction for you. So why do you need a large language model when you've already got the business rules that would actually do this? To kind of give you a bit more of an illustration for this. So let's say you have a pool of data. We'll call that language data, but you can think of it as like domain and data, essentially. And you want to turn that into a large language model so you go through a machine learning process. So this would be, you know, I go look at it at a Twitter stream or I look at Wikipedia or I look at a really large volume of data. I can sort of refine it for some certain parameters, do some machine learning, get out that large language model. However, oh yeah, we will call that generative AI. However, a data's organization is typically a lot smaller than those sets of data that we built the large language model off of. So if we were to kind of go through that same process, it's going to maybe perhaps not be as comprehensive of a large language model, not to mention that there are compile times, delivery times, and there's sort of a state flow. So if I, it takes me, you say, a week to update my large language model and then the content team publish to change, you know, they publish some more content, well, now it's not in the large language model. So there's a latency there that sort of is of a critical issue that you can't really resolve with neural networks that are hard-coded in that nature. So instead, we often do development and produce rules engines. By rules engines, I just mean things in the business that say if this, then that. And if you have enough of them together, it actually resembles a smart capability. I mean, we might call that an AI as well. In fact, in the market, many early definitions of AI were not really machine learning. It was really just rules engines underneath the hood. Google might be a good example of that. But we can actually pull both of these two things together and it's a new type of AI, well, maybe not necessarily new or as new as generative AI is, but this is the, an alternative way of not having to do the learning but being able to, in real time, inject the information from your organization. That's called retrieval augmented generation and it's a sub capability of AI. So by being able to input the right inputs from your organization into an existing open large language model, you're able to create essentially an org level, organizational capable AI. And this addresses those AI challenges I mentioned earlier. So it has now that organizational context. So now that we have that context, we can make sure it's not going to go talk about someone else's product or some other organization that has a similar name or it is existing in a different country or something like that. It's also going to be able to regenerate information based on the content that we retrieved and gave to the AI. So it really mitigates hallucinations because we can constrain the AI to talk about the things that are actually within our content domain. Thirdly, the RAG allows existing rules engines, so things that we've already built inside of our organization, such as a search algorithm that would help determine the relevance of content based on questions asked by the end user as the resources to use to help generate that output back to the customer. So same diagram I showed you before, but with this idea of RAG now plugged in, you can see all of these digital management systems plugging up into a federated search system, tuning that so that it really does give you relative results with the query that you ask, producing those results up to the generative AI and the generative AI then being able to respond accurately based on the question that your customer asked you. So let's review. Optimizing for the external experience. We can use Headless here to help unify the experience that sort of helps with the branding aspects of things that might also help with some other things like search indexing and availability. Trying to head towards a click-less answer from a first transaction for a chat prompt kind of objective. So this means you don't have to kind of navigate through information architecture, trees and menu systems getting across the mains to try and find that information or even doing a federated search. It's just asking the question to the chat prompt and getting the right answer I have irrespective of whether it's in my thought leadership blog or in a support ticket, knowledge base article, whatever. Secondly, we're going to optimize internal governance. The AI is only going to be able to answer questions that you have content for. So do you have the answers for all of your customers' questions? It becomes the next immediate question because you'll start using the AI and you'll test it out and it won't answer things properly. And so you go, why did it do that? You go, oh, it's a content problem. We don't have content for that. We really do need to have content for that. And so we need to start optimizing for a faster content publishing system and a more effective one internally. And if we're taking away the UI for each of those management systems that previously held that responsibility, you really kind of need to double down on why are they still in the organization. So they really ought to provide some level of governance value and streamlined effectiveness in getting the content up to the AI to make that response. Finally, we can integrate large language models with org-level algorithms. So this is the generative AI plus federated search and creating that RAG-based generative AI. And greater content quality is going to equal greater AI responses. So, you know, the content quality is still there. That's not going to go away. In fact, you might need to have more of it, which means you're going to need a content management system, knowledge that will help you keep a management of all of it. All right. So that's the, how are we doing for time? We've got 10 minutes. All right. So that's the general premise of open AI, well, using AI in general as a generative context. And this is a journey that we've been on at Acquia. So my job at Acquia currently is to sort of look at our current enterprise stack and sort of apply the same principles. So, you know, lo and behold, we have a very much, you know, very, very similar kind of content problem. We've acquired a number of companies and over the years, and we've got a number of different places where content resides and it's sending lots of different information. And so we need to kind of improve this and make the experience a lot better and more intuitive. We need to do that across multiple products inside of our organization. So we've kind of decided to start with the customer experience side. So right now, I'm not thinking too much about evaluation. In fact, the last sort of major phase of market business is really focusing on marketing, right? Like a lot of businesses have been investing heavily in marketing capabilities. It makes sure that digital experience for marketing is pretty good at the moment. So we don't really need to touch that too much. So we're going to actually go and look back to the customer experience side of the equation and look to make that better first. So the way that we did is we started with our product documentation site. So Valentine's Day this year, we launched the new docs.acquia.com and we are taking these sort of three steps in this direction. So that launch was phase one or the first step towards this direction. So we're starting to consolidate our content. We have product documentation existing in multiple silos. So we're going to start migrating that all underneath a single Drupal CMS and we're having a headless front end powered by Next.js. The next thing we're doing is removing the barriers to publish content. So today we had, well previously, we were actually publishing content through GitHub. So we were doing static site generation and that was difficult because, let me tell you a couple of problems we had. For one thing, if you wanted to be a content contributor to the doc site, you needed to have a GitHub account. You'd be a part of the Acquia organization to be able to do that. So for someone like a product manager, who's got a managed, let's say, their product, they weren't able to necessarily do that because they weren't technical folks to have GitHub accounts to do that. Even if you did have a GitHub account, someone who's non-technical could do that, you still have to learn a markup language called RST, Restructured Text. And so that wasn't easy, and then if you did learn that, you'd have to go and do an edit and something called VS Code and then if you could do that, you couldn't actually preview your change. Unless you knew Git so you could look at a revision and then you'd have to learn Python to be able to compile the thing. So this was like not a good publishing system. It was for a time, but we'd definitely outgrown it by that stage. And so we decided to move it back to Drupal. We decided to use Next.js. We'd be able to use Next.js as preview mode. But one of the foundational things we decided was to use Jira. How many people don't like Jira? Right? Not quite everyone. Some people like it here. But Jira is foundational to the organization as it turns out. I think almost every team doesn't matter whether you're in development or some other type of business function, they use Jira for their process management. And so I wouldn't have to teach Drupal to everybody if I could, and everybody already knew Jira. I wasn't going to go and rebuild workflow functionality in Drupal since the workflow functionality in Jira was kind of superior. I mean, there, for example, I can have a conversation call to comment. I can't do that if I'm in a revision inside of Drupal. So we built some tight integration here. When I create a revision in Drupal, I automatically create a ticket in Jira. And that Jira then kicks off a workflow that means that we can get editorial review if we need technical review, we can assign somebody to that. If we need legal review, we can assign somebody to that. And all of the links for that content change exist inside of that Jira ticket. So if I'm a lawyer, for example, or our counsel, they can get assigned a ticket. They get an email notification from Jira. It has the preview link inside it. They click it, Google SSO logs them and they see the preview change and they can approve it back on the ticket. The editor comes along, closes the ticket. The change just publishes live in the site. So we really kind of removed the barriers from not even being able to preview something because it was sitting inside of a GitHub pull request to now being able to let the organization move more autonomously. And that means that now with those barriers lowered, people are able to have more freedom in publishing. So someone could be inside of support the organization or in the product organization, whatever they are, they can see a problem with our product documentation. They can just go and make the change. They don't have to report it. And then it will just go through a workflow that will then result in the publishing of that change if that change was good enough. Thirdly, we entered into some search optimization. So as I mentioned earlier, if we're going to put an AI layer on top of the search system, then the search really needs to find the resources that are going to help with the queries that you're sending to it. So we went through some performance improvements. We upgraded search, and we also had to reindex the new side and then follow that through to search trainings, which is still an ongoing journey. But all of this is sort of like foundational work that's going to help us move forward into that next era of being able to introduce a generative AI to our customers. This is what the site looks like today. So I know this is a really small version, but you can open up your phones and go docs.quare.com. It's mobile responsive. There's a different page there, and there's an example of a product page. This is the Drupal backend. So you can see it's the GIN theme. It's got on the right-hand side there the access to Jira tickets. You can see that. Just below the revision log message, there's a Jira issues drop-down. If there's an existing issue open, it'll let you select that. If there's no issue that's related to that node, it'll just say we'll create a new one for you. We also use Tailwind CSS and CK Editor styles inside of the WYSIWYG editor. Because we built with Tailwind on the front end, and because Tailwind is also available from the CDN on the back end, I don't have to pull in a CSS library from the front end to make my WYSIWYG editor look and feel like it is in the front end, because with Tailwind it just kind of works. So I just loaded it in from the CDN, then there's no dependencies on Drupal to have access to the front end site, which is really handy. And no layout management is something worth kind of mentioning here. So even though it's a headless build, layout management in headless is definitely something of interest for developers, but because we're a product documentation site and not a marketing site, the need to control layout is not really a requirement of what we're doing. There is obviously the desire to control content as you're reading the flow of content, but it's not the same as like I need to have a row of three cards here and like a row of four cards in a hero gallery. We don't have that sort of requirement, so it's not really kind of built in here. If it were, I think we'd just use CK editor and something called the embedded content, CK editor embedded content module, which allows you to build sort of paragraph type widgets that you can embed through CK editor instead of having to do that in a structured way. And that turns out to be a pretty good approach. It means from the React side we're just having to deal with a blob of text, a blog of rendered HTML, and we put that through a parsing system and that parsing system allows us to adjust to any conventions we want to write inside of the content and we don't have to worry about like traversing, for example, adjacent structure of data and figuring out how to render it at each point along the way. We don't have to worry about any of those things, so it allows the CMS to be kind of concerned with those things more. We also have preview mode, so there's a yellow bar at the top of the next page here, I'm logged in and now I can see a revision, the revision will change, you see it's sort of orange, and then I've toggled the switch and now it's showing me the diff so I can see what changed between the old state and the new state and then I've also got this options drop down button, so I've got an edit option to go back to the Drupal edit page and I've got the discuss option which would take me to the Jira ticket to post comments or change, transition to workflow or whatever. So from a user experience standpoint, I can go from preview to edit or preview to the Jira ticket and likewise with Jira we have the same thing, so we created three fields, the preview URL field, the edit URL field and the publish URL field is our key so we kind of look up Jira and say is there a node here by this URL that we kind of link things through and then we use the edit URL to get through to the CMS side and then the preview URL which preview is initiated using the next Drupal module integration and so when preview is initiated through the Drupal CMS but lands you on the front end site in a preview or draft mode as it's called in next 14 so we use that and you'll also notice there's a field that might be hard to read especially for the folks in the back but there's a field called publishing actions and set by default to cascade what that means is you can kind of make a group of changes to a group of pages and sort of link them up as you can in Jira to things like epics or some create issue links of some form and then you can say close the parent ticket and then there's a cascading effect that all the other tickets get closed and that has a cascading effect of publishing all the content inside a Drupal so we can sort of bulk publish inside a Drupal as an outcome of doing this through Jira as well and then as I mentioned earlier before there's a lot of different content teams that manage different types of content so we're starting to map a different type of content type to a team to a Jira project and then the underlying management system that runs that and then thinking about how that can then surface up through the UI and it's kind of of notes to mention here that not all systems will use Drupal to manage their content although given the Jira integration we have it's sort of like a great foundational governance system so now I can ask the question why wouldn't we use Drupal because it has a superior governance system for publishing content for our organization and so then we can actually open up multiple business units to use the common platform which you know executive is pretty happy about because then they don't have to spend their budget on it alright so I know we can't how much time is it like at time okay we're over alright so I'm just going to skip through I had some like findings here that we did a whole bunch of like AI research last year so I'll just share one thing here which was we tested a GPT service to see if it could answer support questions that came to Acquia our support desk so as an assistive tool for this was the sort of executive findings as an assistive tool for support engineers a direct GPT tool could surface new and useful insights on Drupal related to support cases 40% of the time likely reducing our response times as a support organization however the competence of the GPT to answer support tickets would likely have a negative impact if we introduced it directly to customers because it couldn't solve the issues 82% of the time so they kind of told us back then they were like oh we still need support engineers it's some good some good job security there but there was there was still much more needed need to kind of really leverage the AI tools down to something more specific organizationally specific I don't have time to go through all of this stuff so what I will do instead is just kind of leave you with these final for takeaways so it's AI and the one UI to rule them all provides better information to users when it gets the context right and that's the key part so you know one example we did some testing asked it how do I reset my password well we haven't have multiple products in that process is different for each product it's going to come back and tell you an answer every time but actually they needed to have the product context before we could properly answer that question Genre of AI is augments existing content today but does not replace them so for a lot of companies who are looking to introduce AI in this way it's going to be in addition to what they already have not something that replaces what they already have user will adjust from 25 years of keyword search to asking for questions we are a generation of people that use keywords to figure out what we want to do on the internet the next generation is not going to be like that and we're going to become more conversational with these AIs for sure and one thing you can know for sure is that definitely coming in their roadmap is transactional features and chat prompts the ability to improve on that in the near future so thank you very much for your time I don't think I've got any time here for questions but come and find me later on