 maybe experiencing some symptoms of the pulmonite last night. It's one of the big reasons I wasn't there. It's a real pleasure to be here at Triple Camp London. I want to thank all of the organizers and the sponsors of this event. Let's give them all a big round of applause. So this is actually only my third time in the city of London. But I've been to the UK many other times. I actually, while at university, spent a good amount of time living in north Wales. Can anyone tell me what the name of London is in Welsh? Llynda. Llynda. That's exactly right. How about Manchester? Anyone? Can you make your hands in here? Yeah, got some people from Manchester. What about Manchester in Welsh? My opinion, back in the UK, because a lot of my studies were here. Actually, at university, I did my research in Welsh language policy. So all of the things that I've been hearing about in terms of Brexit have been very interesting in the Welsh society. That's for sure. So today, a bit of a zoomed-out perspective of true role. And I'm calling this section de-contextualizer content because there's a little bit of too much context in true role. And I want to talk a little bit about that in just a little bit. But first, let me just get a sense of the room here. How many people are new to true role? A few of us. How many people are copywriters or content strategists or content marketers in the room? Okay, got a few of us there. How many people have worked with de-contextualizer role? All right, great, perfect. Well, I hope this session has something for everybody. But please don't hesitate to give me feedback afterwards. And I'll be happy, of course, to answer questions. Just to introduce myself, my name is Preston. I have been involved in the true role community for about 11 years. And I was, until yesterday, the director of research and innovation at AQUI. Actually, though, briefly about my book. If you haven't looked at de-coupled Drupal before or if you're getting into de-coupled Drupal, I have a book out with a forward by Dries. It's called De-coupled Drupal in Practice. And I'm very happy to talk about that book with you afterwards if you'd like. There's a lot of really good information in there about de-coupled approaches, architectures, and builds. How many people have read the book or wrote the book? Okay, great. Thank you. Thank you for your support. As a commander, I just recently announced on Twitter that I'm moving to a company called Gatsby. For those of you who haven't heard of Gatsby, Gatsby is a static site generator that works really well with Drupal and is built in a react. I'm happy to talk more about that a little bit as well. It would be nice to put this up. I was actually in Cluj-Napalpa last year on the heels of Drupal Hack Camp in Bucharest. Wonderful place. I think it's gonna be a great event. I'm very excited for it. Also, I would be remiss if I didn't mention our conference that we've got in New York City. De-coupled days. We took Drupal out of the name this year. We've got a bunch of new tracks, including JavaScript and Jamstack, as well as different headless CMS approaches besides Drupal. It'll be held July 17th through 18th. We'd love to see all of you there. It's just a short talk across the pond. And one of the things that we have open right now is our call for papers. So if you'd like to submit a session, please feel free. We're gonna have that open until the end of DrupalCon in Seattle. Also, we have sponsorships still available. If you're interested in sponsoring the event and want to be noticed by decoupled practitioners, we've got a lot of interest from sponsors and we actually only have one of the diamond sponsorships remaining. So please, if you'd like to talk to me about that afterwards, please feel free. Okay, that's it for the ads. Had to put in all those blocks. Let me talk about, very briefly, what we're gonna cover today. And first, I wanna talk about what is, one of the things that I've been thinking a lot about in Drupal, which is what I call the complexity chain. And this is something that Jerry's recently posted about and his blog post about how to decouple Drupal in 2019. I also wanna talk about the Diffusions of Innovation Theory and how Drupal has played into this theory and how it's not over the last few years. I also wanna talk about how people have thought about and conceived about actually harmonizing the various experiences that we have, whether they're built in Alexa or in the reality, all of these different experiences that I've worked with on a daily basis. And then I wanna talk about what I mean by a decontextualized content strategy and what that means for Drupal itself. First, let's talk about the complexity chain and crossing the cast. And I think this is a little bit of a big picture perspective of Drupal, but I think it's very helpful for us to map out how exactly Drupal's history has been impacted by a lot of the trends that we've seen in web development over the last few decades. Drees by Tom Reese has been posted this blog post about how to decouple Drupal in 2019. There's a flow chart that's very helpful in there and it gives you a lot of information about how to decouple Drupal. But later in the blog post, there's a figure that looks like this. And this figure generated quite a bit of discussion at Acquia among our team because one of the things that we've noticed quite a bit over the last couple of years, especially over the last 12 months, is what I call motion along the complexity chain. If you consider the fact that on the left side, we have a build or a technology that's very easy to use for people who are not developers. On the right side, we have technologies that are more difficult to use and require more development experience. One of the things that we've noticed over the last 12 months is that many of the JavaScript developers who are using large scale frameworks like AngularNumber is that these frameworks have become extremely complex for more than just simple static sites. They become very complex and they should really only be used for highly interactive complex applications and they should really be used for static sites. So while this realm of technology has really moved up in terms of complexity, we also have a corresponding motion down where technologies like Gatsby and static site generators are now beginning to take the lead in adopting more of this middle ground for people of various scale levels. But I want to note here that what I'm talking about here is not actually real complexity, right? Because it's not necessarily true per se that these JavaScript frameworks are more difficult. Rather it's the perceived complexity. It's what we actually think about when we think about building an entire application and we act, or we think about building an entire application in Drupal. And we see this right now in Drupal today. Just this morning I was having conversations with a few of you and learning that many people in this room are already thinking about replacements or substituting different technologies for Drupal front end. So for us in Drupal, this is what this looks like to us, is that as Drupal theming and Ajax and all the things that we're used to in building interactive features into our Drupal sites, has those things become more complex for novice developers or those who don't write DHP or don't write Twig? At the same time, a lot of the new approaches that we're seeing in JavaScript are becoming less complex for us. And some very good examples of this are Vue and of course, Gatsby. Now one of the biggest issues with this whole trend is that we're losing the ability to hire Drupal talent very easily. Front end Drupal talent, especially nowadays, is very difficult to come by. It tends to be very expensive. Consider for example, these current trends that are occurring in decoupled rule. If you consider the fact that in JavaScript we're now seeing a motion towards the more novice developer where people are saying maybe we need to make things a little bit easier for people who are just entering into web development. If you consider the fact that there's now the Create React app projects, for example, in the React community, or also projects like Vue that have really taken on this idea of incremental adaptability and ease of use. We also know, as mentioned by Drees, that these static site generators like Gatsby are actually simpler limitations for a lot of people and have actually helped to offload a lot of these responsibilities that we formerly had to worry about off to different services such as Neverbot. And we also see, as I just mentioned, that Drupal front end developers are turning to these technologies because they do tend to be a little bit easier to use. Because Twig can be very complicated, as I think we all know for those of us who have worked with Twig. And as we said, one of the biggest challenges that people are finding is actually resourcing and staffing their teams. And this is not just a technological issue. This is now a resourcing and a human issue and a business issue that affects each and every one of us. As an example, many organizations are finding it difficult to find affordable front end Drupal developers experienced in Twig. And moving to a job from the front end can resolve some of these resourcing challenges. How many folks in here work at agencies that have had trouble hiring Drupal talent? A lot of us in the room. So today I wanna propose a different approach. And I wanna talk about this and couch this first and foremost in content strategy. So once again, we know why people want to use decoupling and decouple Drupal over Twig. It's because it's the perceived complexity. And it's the fact that we're not really seeing a whole lot of people excited about Twig these days. It is a PHP technology. It is something that's not necessarily something that is very enticing to people who are just entering the development today. And Drupal's complexity, perceived complexity, and this sea-coupled movement that we're seeing right now in the community is leading to these questions. Like, oh, why should we use Drupal at all in the first place? Why should we even bother if we're gonna be using these other technologies? But the thing we have to remember is that these same tendencies, these same trends, these same paradigm shifts, these same sea changes that we're seeing right now in decoupled Drupal are actually very similar to the trends that we saw throughout Drupal's history as well. Consider the other big complexity chain that we see in the CMS world. And I know that I'm using Drupal Type here. It's a very old example. I probably should have used some other CMSes, but this is just to illustrate very simply. The fact that in the early 2000s, we had this very large trend of dissemination of these blog publishing systems, right? These don't really exist anymore. They don't really exist anymore. They've been replaced by CMSes. And what happened is that people said, well, you know, I want to be able to use something that's more powerful. And I acknowledge that it's gonna be more complex. But in order for me to get to that functionality that I know that people want and that people are demanding among my customer base, I have to move up this chain and I have to move up to a more complex technology. And this first way to see a mass adoption that occurred in the early 2000s to mid 2000s and also late 2000s really shows that we actually had a big gap between what people wanted and what we as developers wanted and what was actually out there on the market. So the big question is, if we consider Moveable Type, a legacy CMS, how do we keep Drupal from falling into that same trap? There's a book by a gentleman called Jeffrey Moore. It's a very popular book that you find in business schools and it's called Crossing the Chasm. Has anyone read the book? Yes, it's a very good book. And it's actually held up remarkably well over the last 20 years. What this book states is it articulates this theory called the Diffusions of Innovation Theory by Everett Rogers. And this theory states that there's a big of this, not the one on the ground type gap, but a large gap between early adopters of the technology, people like us, people who are going to look at things like Gatsby, going to look at things like you and those who are the early majority, the pragmatists, the realists, those who are going to adopt the technology because it really makes sense and has penetrated the market to a larger extent. And more in this book states that marketers who want to actually pitch this technology and sell this technology should target one market at a time amassing just enough buy-in to move on to the next phase. But the most problematic chasm, the most problematic of this is between those two personas, those early adopters and the early majority. And what's interesting is that Drupal has actually already done this, really successful. If you look, for example, at the history of Acquia, you see this. In Acquia's early history, we were very focused on cloud solutions and developer support and all the things that many of us are doing today for our clients. And this was kind of the initial phase. We need to have a CMS that's for developers that works for developers who are building client sites. But we crossed into different personas and different markets that actually worked for a large number of people beyond just those technical developers like us. And those editors who came in and said, well, I need to have workflow, I need to have preview, I need to have all this stuff that we're used to in block publishing systems and in CMS. And then finally today, Acquia has really focused on the market of persona. And many Drupal companies as well have focused on the market of persona because now we want to have more visual control over what's going on and really have a very deep amount of authority over how content is placed on the page and how it appears to the user. But here's the question I want to pose today. Are we now facing a new cast? Are we now losing the developers that made Drupal so successful in the first place? And if so, is it a problem? What do we do about it? Or is it not a problem at all? That's the question I want to toy with a little bit today during the session. So the question I want to ask you all today and I want you all to think about is, is Drupal in trouble? Does Drupal need to win back developers or win new developers? And does Drupal need to cross that cast once again? Do we need to evolve once more into the future and leap into the future? Now let me move to a little bit of a different topic which focuses more on how agencies and how people in the Drupal landscape today have looked at harmonizing these discreet experiences that we see today that many agencies are building. Because the fundamental question we have to ask ourselves in conjunction with those questions I just posed is what will Drupal be for in 10 years? Will it be just for websites? Or is it going to be something that is truly for all digital experiences and what does that actually mean and entail? It all depends on whom you ask. One of the big questions that's happening right now at many large organizations across the world today is whether to centralize data or not. Should we put every single piece of data that we own and every single piece of content that we own into a single bucket that we can distribute out whenever we want to and hand out? There's this concept of right once published everywhere and a single source of truth. But recently we're seeing different trends emerge as well. If you look at Gatsby, for example, Gatsby adopts a strictly data-agnostic approach which means you can bring your own data sources, you can bring your own data, and Gatsby has no need to care about where that data is necessarily from. But one of the things that we're also seeing is that many large companies are saying, well, we're doing this because we see an institutional importance within our company to do this, to centralize all of our content, centralize all of our data in one place. So what I mean by this is that harmonizing with ecosystems, these ideas that organizations are needing to have a complete sense of harmony across all of these experiences and understand where they are and what they're doing is becoming a lot more common as a concern throughout some of the largest companies today. And some of you might have seen some of these figures before, but what I want to do with these illustrations is to demonstrate that we as developers have a great amount of control over what we can do in terms of these experiences that we build. We can build a JavaScript single page application, we can build a mobile app in Swift, we can build any other thing that we can conceive of. But the problem is that once we give this off to our clients, once we give this off to people who are actually going to be editing and working with this solution that we build, we actually have some problems begin to emerge. Editors, for example, can't necessarily preview unpublished content as easily on a mobile app or on an AR mobile app or on a JavaScript single page app, although there are solutions out there. They're heavily developer oriented. Then we think about the fact that marketers and those who really want to have visual control over the presentation of their content have absolutely no control over layout and over some of the things that they want to see happen on a mobile app or on a single page app. So if we want to serve all these experiences in a robust way, we have to think about how our choices that we make in Drupal and the choices that we make during the evolution of Drupal actually impact these other channels that we're building today. So I would like to venture a little bit into why Drupal is possibly in trouble today. And I don't want to be pessimistic about Drupal, but I do want to be realistic. And there's a fundamental problem in Drupal today. And for those of you who follow my talks, this upcoming graph is going to be very familiar to you. One of the things that we're seeing is that what's better for developers is not necessarily what's better for marketers and better for users. We're seeing a change where more custom work by developers is needed to actually make these editors and marketers happy. And we see this today in Decomple Drupal. If you build an application in JavaScript and you serve Drupal data to that application, that leads to a loss of critical functionality. You're losing, quick edit, you're losing contextual links, you're losing some of these contextual features that many of the people in our user base have considered very important for a long time, even if many of us in the community have thought that they're not as important. And so today, if you want to make preview happen, if you want to make in-place editing happen, if you want to make some of these things happen, layout management happen on a single page app, that's impossible without the help of a developer. So the biggest issue is that we have now crossed this chasm and we can't go back in some ways because the editors and marketers are now using Drupal and they expect to have the exacting functionality that they've had for it since day one. And for us, some of us who are architectural carriers, some of us who are really deeply involved in separation of concerns and software, we've always had a problem with the fact that there's this linkage and this coupling between structured data and the presentation of that data because this leads, as we all know, to Drupalisms and oftentimes a negative developer experience. I'm sure many of us have onboarded or worked with new developers who are used to other paradigms who have faced a lot of frustration when learning about how Drupal works and how it does things. So the hard truth is that Drupal itself has become far too coupled between three things. Number one, the presentation layer, the theme layer, the twin, the theme engine, the website itself, the idea of website, the idea that Drupal is for the website and only the website. And of course the underlying web content itself, the content that we all write on a daily basis, the content that we pump into Drupal that is written for a website but not necessarily written for anything else. And if you think about it, the vast majority of all the content we have right now in Drupal is web only content. It's not really meant to be used on other devices. It's not really meant to be something that we put elsewhere. And we know also that from our experiences helping people learn Drupal, helping people understand Drupal, especially people who are using JavaScript or people who are asked to do so by their employers, these Drupalisms can be very, very confusing. For example, one of the things that I've been seeing a lot on the Drupal Slack is a lot of questions about course configuration in decoupled Drupal which has become a little bit more difficult over the last few minor versions just because it's a little bit less successful to the novice developer. You have to go into your services.yaml file and understand Hamel and understand how that file works in order for you to be able to enable cores on the decoupled Drupal implementation. That's just one example. And we also see when we look at API responses in JSON API or GraphQL for those of you who work with decoupled Drupal that sometimes we see a lot of Drupal information leak through. We see stuff like field underscore blank leak through. We see all of these things leak through that are really unfavorable for those developers building these experiences. Everyone scratches their heads. Not only are new developers who are new Drupal who are really confused about some of these ideas but also clients because they're losing some of their functionality. I remember I once spoke to a customer who had been asked to work on a decoupled Drupal with React implementation. And this React app was wonderful. It was performance, it was great. It served content from Drupal effectively. But the client called back six months later and said, hang on, how do I get to my in-place editing feature? How do I get to the quick end? And the agency unfortunately had to tell them, yeah, sorry about that. Yeah, it's not available anymore. And the client was not available. So this is what I want to say when I say that we have a big problem, is that Drupal's biggest challenge today, biggest thing that we face right now at Drupal is that we have to decontextualize Drupal away from the website and from the Drupal website that is what Drupal traffic's in today. We have to get rid of this notion that Drupal is only about the website that it renders because it's not. We know this today. We know this from the presentations yesterday about Gatsby and React. We know this about today's community. We know this about today's evolution of Drupal. And we know also though that context matters. I love this image because it really illustrates some of the challenges that we face. If you think about each of these different screens as a different channel, like augmented reality or mobile apps or JavaScript, you can see that really one of the biggest challenges we face is the fact that only the person looking at the web context sees Drupal as an end-to-end system that works really beautifully for them. But we have to think about contextlessness and how many people have heard of the R.C. Wood message. So the R.C. Wood message is a message that is broadcast regularly by saying. That's the group of scientists who are working on extraterrestrial intelligence and want to tell extraterrestrials about Earth and tell them about humanity. And what this message actually contains is a lot of information about who we are as the human species without any context at all, without any need to understand the English language, without any need to understand, you know, necessarily the way that we use numbers and mathematics. And a lot is communicated here. A lot of this actually contains things like the population of Earth, things like number of days of the year, for example, so on and so forth. And it communicates a lot of information about Earth without necessarily requiring the context of our own understanding of language and mathematics. There's also a concept of contextualization and social linguistics, which is, linguistics is my background, by the way. And contextualization is really interesting because when you think about content and you think about the fact that we really communicate these ideas and the surroundings of our content through this idea of how we communicate and how we actually express ourselves. Consider, for example, how things evolve when you have a new scientific finding that's published in a scholarly journal versus popular science magazine or quantum, versus a Wikipedia article or a college textbook. These different contexts really give a lot of different meaning to the content itself and change the way that we envision how we want to write content and how we want to manage that content. The fact of the matter is that today all CMSs have fallen to this trap, every single one, including even the headless ones, have fallen to the trap of focusing on contextualizing themselves on the web. They assume that the context you wanna display all of your content in is the web and that is today the fundamental flaw of CMSs across the board. So what I talk about a de-contextualized content strategy, what I really mean is that we as content writers, we as content managers, we as content strategists really have to move away from the notion of the web as being the only place that our content will appear. Brett Hanwood is one of, he was a context strategist at Second Life, worked on Second Life again, and worked on marketing communications for Second Life. And he has this to say back in 2013, which is that it's not just a traditional editor role. It's not just a written word and it's not just the web. I have to consider how it might be repurposed and redistributed and actually reoriented on other channels of delivery. And in this article he talks primarily about Facebook, but you can also see in his head that he's thinking about things like the new channels that we're seeing emerge today. So the ideal piece of content that we can write today, and this is a really good exercise in copyright, maps neatly onto any context at all. Consider this brief paragraph, which is the first paragraph of the Wikipedia article about Islington, here at London. If we think about the fact that, okay, this paragraph makes a lot of sense, where can we see it end up? It could end up in a website with a heading and a read more link. This is something Drupal already does very well, for example. We don't necessarily need to add that read more link to every single content block. But it could also be something that appears in a voice assistant, like Alexa. It could be something that we ask Alexa for in terms of information. Is this paragraph something that is okay to listen to as a user of Alexa? These are all things that we have to think about. And of course, in the future, one of the things that we'll see more and more is situational interfaces and in-context interfaces like Avenger reality. So that when you're walking around Islington, you actually get information displayed right on that iPad that you are carrying around and just waiting to be mugged with that iPad. So here's an exercise I would encourage all of you to do with your website or your content. Today or tomorrow, take just one piece of content on the website. It could be a block of content that's reused across the site. It could be a single page of text that you've got when you're doing a site in a node. Consider these questions. If I were to display this piece of content as a card on a mobile app out of context of a website, would it still make sense to the user? If I were to take this piece of content and read it out to a voice assistant, would that make sense to the user? And if I was to situationally display it so that it was in context of it on the reality of the face, would it still make sense? Because the website is not enough anymore today and we can't think about content from the web perspective anymore at all. So, decontextualized content strategy involves from the very beginning enforcing a need, a lack of a need for context in your content. It means actually saying I'm gonna make my content so context less that it makes sense anywhere it goes, regardless of where it ends up. Now, why should we do this? Why is this so important? Well, there's a lot of reasons why. The first is that a lot of us have very small editorial teams. A lot of the organizations that we work with, a lot of our clients don't have large teams. They can't manage 15 different pieces of content based on each channel that that content is going to. Now, what we know of course that sometimes, a large paragraph, a lot of text is not something that's really favorable for certain channels. And that does lead to increased complexity, which is a flaw of this word approach. But if we think about content as a sweet object, as Drupal has trained us to do with its unique approach to structured content, one of the things that we can do is to really anticipate any particular channel that might emerge in the future, whether it exists today or not. So here's some things to think about when you're thinking about writing content and writing content for this kind of approach. The first is that, for example, headings might not make as much sense in a voice assistant. Or a sidebar block might not be something that really displays in a mobile app. And how does that change the way that your user experiences this content? Also calls to action are pretty much meaningless and useless in most other channels unless there's a capability in that interface to navigate to that link or navigate to that different state of your application or screen. And so overly contextualized content really in the future will become a maintenance burden. And we're already seeing this emerge more and more. And I'll talk about an example shortly that I've worked with in the recent past. So when you think about the fact that we have a focus on the web here, if you consider the fact, for example, that we want to be able to display this content anywhere, we have to think about how this content is going to change for each of these cases. And we know that if we can take this paragraph about just totally anywhere, that we can actually display that content really easily anywhere that we go, including on it on the reality of overlay. Once again as we're walking around with our iPad in front of that just totally implication. So this is a possible approach. And I think this is something that has worked for a lot of people, but it might not work for everybody because one of the key critiques of this approach is that there's very little variation between the content. And for those of us who have worked with voice assistants, for example, or chatbots, we know that the mode of conversation, the manner in which people like to interact with a chatbot is very informal. And how does that contrast with something like the government website of the United Kingdom, which has to portray a more formal approach? How do they write a chatbot? Is it the same? Is it written in a different tone? Those are the questions we have to answer as well. So the exceptions rule about, the exceptions where we have to think about, okay, well, this content's gonna be in a different scenario. We have to adjust it in a different way. And so this does leave, if you do write content that is particularly oriented to the channel, that does mean that it's channel optimized. But the problem with that is you have to trade off the maintainability. So that's what you have to consider as a content strategist, as a developer, as an architect, is what are the trade-offs between maintainability and between having that harmony across all of your content? Because our notions of content strategy up until now have primarily revolved around the web. Most of us have probably read content strategy articles that are focused on the web, by folks like, folks, excuse me, folks like, psychosis for example, and others are written on this topic. So we need a different model to conceive of our content. And if we think about content as discrete objects and not as pages and not as blocks and not as visual elements, they can help us to really re-task our approach to content. And as I mentioned earlier, Truthful already has this with structured content. But we have to move off of this web-first mindset. So there's one approach that I would recommend for all of you who are looking at content strategy and looking at how your content performs on different devices. And that is performing a content audit. I used to work on the Acquia Labs team and we built a project for the state of Georgia in the US called AskGeorgia, which was a Alexa skill for citizens of the state of Georgia to ask certain questions. One of the things we did during that project was a content audit, where we looked at every single piece of content that we wanted to adapt to be made conversational and experimented with what are some of the ways that we can fix this content so that it's actually completely context-less and decontextualized. AskGeorgia was a very interesting case study. It was actually a very early adopter of Alexa and Drupal. To this date, I actually believe AskGeorgia might be one of the only Alexa skills publicly available right now that engages in a search on a Drupal site as opposed to kind of written-in interactions that are actually custom. And so some of the things that we did for this project are to rewrite content so that there was less of the calls to action, less of those things that are impossible on a voice assistant. And we wanted to prepare the state of Georgia to be able to actually work with this content in a way that meant they could use it across any channel, including a mobile app, including a chat bot, including SMS messaging file, and a voice assistant. And as you can see, some of the things that we did were to reduce those calls to action and reduce the amount of links that will distract the user or make them confused if they're hearing learn more on a voice assistant, for example. This is a really good example of this. If you're on an Alexa device and you ask a question and you get more about this, that makes absolutely no sense to you as a user of that interface. And that's why we had to add a whole bunch of content here to give the user that ability to say, well, I don't need to go to another link on a website. I can just have the content right there. And this is one of the key problems that we have to resolve in all of our content because up until this point, all of us have written content or have managed content that's oriented solely for the web. So I talked a lot about what it means for content, this idea of decontextualization, this idea of taking away the need for context from our content. Now what does that mean for Drupal? About four months ago, I gave a talk at Drupal Camp Belgium called The Drupal Frontend in 2024. And this is a little bit of a, kind of a culmination of those ideas in a single place. I believe, and this is my opinion, by the way, I believe, I don't know if you agree with this. We'll see. I believe that our aspiration should be to create a CMS that isn't just for websites. I believe that our mission should be to create a CMS and foster an atmosphere for us to build a CMS that is truly for all digital experiences and ecosystems in every single sense of the phrase. And what does that exactly mean? It means that we have to move away from this web-based idea of what Drupal can be. Consider where Drupal is right now. And this is an extremely simplified diagram, but what I want to illustrate with this is to show two things. The first is that there's a very big difference between what I call non-render channels and what I call render channels. If you consider the fact that we have things like JavaScript applications and static sites, which all have some operation of rendering taking place. And then we also have things like voice assistance and chat bots and push notifications, which we have much less control over in terms of presentation. Right now, we can see that Drupal is kind of this single backend. And this backend is coupled with a website, this Drupal frontend, which includes two things. Number one, the theme layer that we all know and love, PHP template or twig. And second, contextual features. As I just mentioned before, contextual features include things like in-place editing, they include things like contextual links, layout management, things that require an understanding from the perspective of the CMS of the presentation layer for. But I want to challenge this a little bit because one of the fundamental issues that I think we face today is how people conceive a Drupal when we say the word Drupal. When we say the word Drupal, people immediately think about websites and PHP. I don't necessarily think that that has to be the case. In fact, right now, we have something that looks a little bit more like this for many of us. If we are working with a large organization, chances are you have an architecture that looks somewhat like this. And yes, the website, the Drupal front, and it's still coupled to Drupal and it still has all these features, but we're also serving all of this data to other places like Angular, Gatsby, to an AR overlay potentially, and all of these things that we're building custom as developers today. In November, I proposed in an argument there that we actually should really redefine Drupal and that Drupal can be more than just a website. And Drupal can be more than just a web rendering layer and a web-based content management system. And an aspirational state for us to end up in is something like this, where we can conceive of Drupal as being the sum of all of its parts of the architecture. Drupal is also the front-end that Drupal itself is not actually rendering. And I'll talk about why in just a second. But first, I wanted to say that one of the things that has come about recently and a lot of conversations I've had with folks in the Drupal community is the notion that we have to move away from this idea of Drupal as a single piece of software. Drupal is much more than that. Drupal is an ecosystem, it's a community. It's actually more than just a single system of software. And we can move from this kind of approach and this kind of idealization of our architecture to something like this. And this is something that is an idea I've toyed with for many years and I've really tried to refine over the course of the times I've given talks about Drupal. But one of the things that is really interesting today that we're seeing is companies like Startups, like Simpla or Prismic, really trying to control a little bit more of the presentation that happens on those Drupal front-ends. Prismic, for example, allows you to actually inject edit buttons into whatever application framework you're using, whether it's React or Angular or Ember, jQuery, they actually allow you to put in edit buttons where every single piece of content controlled by Prismic is located on your single page application. Why can't we do that for Drupal? Why can't we do that for all of the things that we actually see in decoupled Drupal? There could be, for example, an in-place editing feature that we create or that Gatsby creates that integrates beautifully with Drupal. There could be a layout management tool that integrates beautifully with Angular or a contextual links widget that could operate even in an AR overlay as we are editing content on our iPad, walking around the Angular station. So if we think about this as Drupal, we completely reinvent how people think about Drupal. If we say that actually what's available on the Drupal front-end is in-place editing, but you can have that on Gatsby too and you can have that on Angular too and you can have that on Vue too and they all work in an engraving fashion with Drupal. Because that is what will ultimately lead to people understanding, especially those of us who have clients who want to go into these technologies, who want to go into this realm but don't have the ability to give up the features that their editors and their marketers use so on a daily basis. So it may seem counterintuitive because I've been talking a lot about reducing context and contextualization, rather than reintroducing contextual features. And I do agree. It is something that perhaps is a little bit hair-brained and a little bit unrealistic. But the key distinction here is that in a de-contextualized Drupal, all of these different channels that we're working with, whether it's Gatsby or Vue or Unreality or Mobile Apps, they own their contexts, they own their presentation, they own how they display themselves. And that's a totally different idea from what we have been used to in Drupal in the entirety of our history since Drupal's founding. So what does a de-contextual actually mean? The first thing that means is that channels own their presentation. It means that we leave all the issues of reverberating presentation and contextual features up to these channels themselves. This is an idea that we've already been dealing with over the course of the last few years. But also, crucially, as I mentioned last year in Lisbon, it means APIs for everything. It means that every single operation that we can conceive of in Drupal that we do today in the interface or that we do today programmatically has to be something that we can do through API or a remote procedural call. And finally, we have to refocus on developers. And this brings me back to discussing project accounting again. Because in order to attract these developers today who are not using PHP, who will not discover PHP, who are only turning to Drupal because their employers asked them to, we have to keep their interests as well in Drupal. Many people today have never even heard of Drupal. Many people today who are entering into the tech market and the web dev market have never even heard of PHP solutions or of Sydney. How do we bring them into the fold? So this might be an instrument of a task and it might be impossible. But I think we do have a shot of getting it right. And there are several things that we can do to get this going. One of which is working very closely with some of these other communities that are out there, like Gatsby, for instance. But we need to do three things. And the first is we have to recalibrate our priorities. We have to keep thinking about what it is that Drupal needs to focus on. We have to integrate more closely with other technologies. We have to work very closely with these other teams to actually be able to work with these new technologies that are emerging. And I believe that we need a new API-first initiative. Many people are saying that the API-first initiative is now complete because of JSON API and Drupal Core as of the upcoming release. But I actually think there's a lot more work to be done. And I would love to work on this with all of you as well. We have to retrain our customers as well. All of our customers, most of our customers who have gone their digital transformation journeys to borrow business parlance, are actually writing web-only content without realizing it in the first place. So we have to educate our clients on channel agnosticism, educate them on this idea of writing decontextualized content. And we have to educate them also on digital ecosystems and help them understand that they're not just dealing with one single facet of their organization. Third, we have to realign Drupal's mission. And what that means is we have to focus once again on the developer experience. I think we've done some amazing work on Layout Builder, amazing work as of late on some of the modules that have really gained a lot of steam in the editorial and marketer personas. But the problem with that is that we actually are losing those who are coming into the web dev landscape today. And most entrants to Drupal are today actually obligated to learn Drupal because of their jobs, not learning Drupal organically. And that is a big problem that we have to address. And finally, we need to cultivate a new generation of Drupalists. We have to bring those new learners, those people who are taking those coding boot camps by the horns, those people who are actually going into university saying, I wanna learn JavaScript and I wanna learn React. I don't know what this Drupal PHP business is. And we have to learn from them and attract them to work with Drupal in a new way that has never been done before in our community. So just to end with a few final words here and I'll take questions afterwards and open up for discussion. We have to traverse the new CASM. There is another CASM in front of us and it is the CASM that we have left behind a little bit because we wanted to focus on the personas that we focused on today. We have to win more developers and we have to win them with the right approach. Secondly, we have to decide once and for all whether or not we're going to make Drupal something that is optimized for more than just websites because I guarantee you in 10 years that will be the case of every single new CMS that comes on the content management market today in 10 years. And we have to decontextualize our content to prepare for this future in a channel-logistic way. We have to move content out of its context and move it into an idea of the sweet objects. And then finally, we need to decontextualize Drupal to win over those developers that we've lost and win developers that have never considered Drupal before in the first place. And that means that we have to redefine the what Drupal means and what Drupal actually does for all of these data. We need a new vision for Drupal that aims to harmonize across these experiences and really aims to focus on these ideas. So let's cross the catamac again. Let's focus on these other islands. Let's focus on these developers who are integrating with Drupal who want to have a content management solution that works for them and still enable our other personas because as we learn from our history in Drupal, it was developers who started out building the features that the editors and the marketers want. And here, it will happen again. I promise it and I guarantee it. Thank you very much. I have a really good question. I saw a new book, I thought this was a new book. And I think a small map is a small position. We do things in the last few weeks, the last few weeks, but it shouldn't change easily. And it all sorts out the way to defend against that. And in Drupal, one of the things we did was we seeded that ground. We just didn't bother writing WordPress. We said WordPress is a small site, so we lose a lot of sites. And those are crazy, but you know, we're good to go. And we're moving now to, this is to find a different area to gain that. But I think we still need to seed, we seeded to find a way of our action and make Drupal easy for people, like really easy. At least it's WordPress, because we always give our ground, if we don't. What are your thoughts in this, this completed role as an editor that you should take to undertake? Yes, it's a very good point. And you know, there is something to be excited about, I mentioned the other total experience and the market experience in terms of using the word being in and just getting people to feel that their features are still intact. And that was because of two things. The first is that when we look at how Drupal sits, we really started out. We look at, you know, the fact that really a lot of these people who started to do Drupal in the first place were people who were engineers or engineers or clients. If you look at, for example, like CZK and Muse, those were projects built for clients by those. And they weren't really so bad then. And some of them, some of those people are not silly with that as a whole day, as we would like. I believe that we should still look at some of those, some of those absolutely. And I think that for all the big lies that we have in Drupal, there's a lot of improvement that needs to happen. Nonetheless, I think that we have a finite in terms of ensuring that Drupal stays rather than practically in addition to editoriality and in the market in the States. It's a hard problem. I don't have the answer. And I think that, you know, one of the things that it has come about, for example, is I had a discussion with 10-12 years, one of the maintenance of the layout holder. You know, basically kind of playing with what's happening and saying, why are we doing the layout holder in the first place? It's only going to be relevant as a website. And I think it's true and I think it really illustrates the fact that we have two very different beasts that are trying to serve Drupal community and Drupal business landscape in particular, which are, number one, those clients who need the layout holder right now in yesterday. And then also those clients who are moving into this, and also ages and adults in the real community who are moving into a landscape where we're having a lot of trouble getting into the town. And we have to figure out how to harness both of these in a way that pushes us all the forward. I think really some of the jobs here focusing pretty much all of the attention of the Drupal acceleration team at Apguya on the layout holder and on the API acquisition. And so I think by pushing these two products forward, we can make products happen, product of the products. I do use all of the Drupal DCDs I do with that. But I think this is kind of in conjunction because what I'm probably hearing is not that we wash away back in Drupal, right? I'm not arguing that we should take away all the differences that we currently have in Drupal way. I'm really saying that we need to take that when the product that we have in Drupal and just think of one of a variety of different things that we provide to customers. Let's talk about this. I think there's a lot of discussion that we can have. Any other comments or questions? I'm going to say one more one. So how do you defend such, when that's planned, that's what that all happens, is when it's planned content, I argue that we need it early other way and my lots of contents or contents to be able to have a centralized core. So imagine the way that language is done. There's a core such that actually there's all shared artists with different languages. That's sort of appropriate but there's an intersection of content so that you can have long-form content which is planned and short-form content and have the same core part of it. So what does that do for the small, one of the newspaper that only has five years of that? Yeah, but they don't, they do long-form content. They don't do short content. They don't do flash parts. They're not ever going to move to a system where they're doing AR. That's so interesting. Just to repeat the point, sorry. I think most of it's written in one language, not in five. We can deal with five and deal with 20. But most languages, most of it's like get written in one language. I don't believe that actually. I don't think that's the same word. But you know, so let me just repeat the point because it's not right. The point was that, you know, people write, people should be able to write content for a variety of contexts, right? And have context with the content. And my argument in response to that was, well, what does that do for the small newspaper who only has five years of that? I can't manage 15 different, you know, contexts. I think that's a very important point. No one can possibly employ 50 different editors to write content for mobile, to write content for web, to write content for whatever else exists, voice assistant, whatever else. That's just not a possibility. And we see this with the state of Georgia. The state of Georgia told us, they said, we don't have a team that can manage more than one single piece of content at a time. So we need you to keep it unified. And I'd be curious actually, you know, how many people have had that experience with a client who said, you know, we're not gonna be able to do more than just one single piece of content at a time because we have a small team. Okay, a few people here and there. So yeah, you know, I agree. The second point we just raised was the fact that there's something that we only have written that's, you know, only one language is the right one, for instance. So I'd be curious to know if you're sure what you mean now. In one language, and you have to get it to have multiple languages for a website, but people, that's actually a fantastic thing. Oh, I see, you mean human languages, not programming languages. Oh, okay, I understand, I understand now, sorry. Okay, yes, okay, now I understand what you're saying, not programming languages. Yes, absolutely, I agree. But the points I need here have absolutely no bearing on the language. If you want to do multi-lingual, you can totally do that. And that should still be something that the Asian guys need to do. Now I'm using multi-lingual as a metaphor for what is both contextual and non-contextual. But if you have a, if you did multi-lingual in a non-contextual, what's on the way, which you'd have, what you'd have to do is have a translator ready between the two, an automatic translator. But what we do with multi-lingual is we have more than one, you know, we have English and Chinese. Right. And there's no real crossover between the two. I mean, there's crossover in terms of structure, but there's not crossover in terms of the actual language. And I think that, I think that this sort of thing with the non-contextual stuff, what you're trying to do is try to bring everything to one context, which destroys the, which destroys the, I don't know, the readability that the, the, I think its interest is of, of each. So just to be clear, I'm not arguing that every single piece of content should be in one language. That's definitely not what I'm arguing for. I'm arguing for, yes, but, but channels are different from languages. We can't have, we can't have any comparison between human languages and context in terms of channels. Like, you can't say that an English language content is like, you know, okay, yeah, I'll, go ahead. Talking about removing the context, again, you don't explain the cost of that. It's just incredible that the, the focus, if you talk about a small newspaper with five content editors, well, they need to focus on the bits of the channel that are important for them, and then deliver them in the same way as if their market was in Chinese, it'll be right in Chinese, if the market is in English. You have one specific case of the Georgia State Council people, and they have, I would suggest a, an unusual case where they wanted to deliver a lecture, for example, as well as a lecture. But it comes with some incredible cost. Okay, so to repeat the point, the argument was that, you know, if you decontextualize content, and, you know, don't, and allow for a single piece of content to govern, and that content could be multi-lingual, just to clarify. But that single piece of content to govern across all channels, that comes at a huge cost. And I do agree, that's one of the things I stated up there was that there are weaknesses to that approach. But the issue is that as we work with larger and larger organizations that have more and more channels that they have to deliver to, that becomes a huge concern. Who's gonna manage all of that content? You can't have thousands of people managing 50 different, you know, ideas of content. We do have this already multi-lingual. I think that's absolutely something that's just the same place. I don't think there is any sort of issue with having, let's say, English, AR overlay versus Spanish AR overlay in the same exact concept of content. And I do agree that there are definitely people who are not as far along this journey who still need to, you know, have channels because of the content. And that's one of the things I raised there, which is that it does come at a huge cost in terms of complexity. And it's a trade-off between complexity and maintenance, I think, is what it comes down to. Yes, can you get a mic for us? We're running out of time. Yeah, last one. Off on one. Is the argument of who is Drupal 4? Is Drupal 4 the smaller sites where, you know, I started as a hobbyist. I started my own Drupal site, or is it for the larger organizations, the ambitious sites? And for most people, I would assume like probably 80% of the websites aren't going to do single-channel publishing. You know, that's what Drupal does, that's what Drupal does really well. And I think, I don't know, maybe I don't have a question here, but I think the trick is just predicting the future. You know, and I think Drupal is predicting that everything is going to go multi-channel, at least for the market that Drupal wants to be. You agree with that, or do you have any thoughts? Well, I think what we're seeing right now is an extreme proliferation in channels that are not necessarily non-webbing, right? So if you consider the fact that many of us today in this room are working with Gatsby, and are working with Vue, and are working with Weat, those are different channels. If you think about them from the perspective of how Drupal communicates with them, they are fundamentally different channels. And so right now we already see that complexity emerging. And I think for those of us who have simple websites that are just Gatsby, that is still a big consideration for us as well. How do we eventually get to the point where if we build that kind of an implementation for one of our clients, that they don't come back to us in six months and say, well, you just got to work on my features, now you need to refund me all my money. That's a big concern I think as well. Anyways, I know we're out of time. This is a very spirit discussion. I really appreciate all of the comments. I think that was very, very good. I'd love to talk with everybody afterwards. I'll be right outside. Thank you.