 All right, well, this is actually the third time I'm up on the stage this week. But I just want to get a sense of who all is here. And when I was thinking about this proposal and submitted it for approval, one of the things that I thought about was, let's put this in the context of site building. But site building is really intertwined and very much part and parcel to the nature of content editing as well. It's a very kind of inextricable relationship between those two. And so as a result, I'm going to be talking today about both the notion of site building, this notion of what site building means in a decoupled context and also content editing. But first, before I start, I just wanted to get a sense of the room here. How many people here are developers through and through? Wow, OK. How many people here are site builders? All right, good, good. And how many people here are content editors or people who are wordsmiths and use the written word? OK, we've got a few of those as well. So this presentation will hopefully have a little bit of something for all of you. And I would like to end this presentation a little bit early so we can have a bit of discussion. And I do hope that we can end a bit early. So one final question I wanted to ask is how many people were at my intro to decoupled Drupal session on Tuesday? So one of the things that I talked about at the very end of that presentation was this new incongruity in Drupal. And if you were thinking about that issue and really kind of delving into that, I'm going to revisit that at the very start of this presentation. So let's go ahead and get started. Heads to this video callman, welcome to everybody. My name is Preston So. I am the director of research and innovation at Acquia, where I lead our Acquia Labs team. And I'm also responsible for open source initiatives and research initiatives. So a lot of the kind of omnichannel or decoupled Drupal stuff that you've been hearing about that's been coming from Acquia, I am unfortunately responsible for. So I apologize for that. Here's what we're going to cover today. I would love to start by talking about this thing that I ended that presentation with on Tuesday, which is what we have been increasingly seeing as the widening gap between developer and marketer. I want to talk about this notion that a lot of people have in this omnichannel marketing context, in the new digital marketing world, about this conflict between the notion of being able to edit everywhere in any context and also being able to edit everything, any piece of content. I want to talk about two of the approaches that have been really prominent in the decoupled landscape. How many people have heard of progressive decoupling in this room? OK, some of you. And I want to talk a little bit about what implications that has on the way that we are able to serve our editors and serve our marketers who are actually going to be using these interfaces. And then I want to dig in a little bit into fully decoupled front ends and what that actually entails. I'm going to dig into a couple of case studies. The first is the case of Prismic CMS, which is a headless CMS. And I want to talk briefly about the implications of what they're doing, as well as something a little bit closer to home, namely, decoupled layout in the form of restful panels. And then finally, I want to end on a bit of a different tack. When I first started giving this presentation or things similar to this presentation, I really focused on this notion of being able to edit anything anywhere. But increasingly, what I've come to realize and what I hope you'll help me to meditate on and ponder together in this room is the notion of what content strategy means in this kind of decoupled context. So let's go ahead and get started with what it means to be a developer today and what it means to be a marketer today. For those of you who are at my session on Tuesday, you'll remember this slide, which is let's think a little bit about how we're using Drupal today. Increasingly, all of us developers who love Drupal and love it for what it does on the back end are beginning to see a lot more of our implementations become decoupled. We're beginning to do a lot more headless implementations with server-side JavaScript and a lot of these really interesting approaches. So Drupal's value proposition has always been threefold. First is that the developer is one of the most prized people in Drupal. They benefit from a flexible experience, high extensibility, a lot of modules available. You can do whatever you want to with hooks in Drupal. The marketer, though, the editor, the site builder, the publisher benefits from contextualized administration tools and access to all of these editorial interfaces. And I'll explain a little bit more about what I mean by those two things. And finally, there's the user who benefits from whatever user experiences are built by the combination of those two. So it's this really delicate and tenuous balance between the developer and the marketer. Now, my question that I want to ask today is, is the CMS, as we know it today, dead? And my answer is yes, because in an omnichannel world, the traditional web-based CMS doesn't actually make a whole lot of sense. When you think about conversational interfaces, when you think about augmented reality, these kinds of ideas that we've been used to, these kinds of concepts that we've been really drilling into our heads as far as what a CMS can do and what a CMS should do and what it should accomplish are no longer relevant in this landscape. So how can we keep up with this widening wilderness of all of these experiences that are really coming about in the last couple of years or the last six months and even in the next 24 months? And how do we keep up with these CMSs that are coming out? There seems to be one every single month that's coming out that purports to be the new replacement for Drupal or the new replacement for WordPress. And how do we keep up with those CMSs that don't even exist yet? So what is the ideal CMS? Well, here's one suggestion, and this is subjective. It's just a matter of opinion on my part. But for me, I think the developer has to remain really able to enjoy that amazing experience that they have right now in Drupal. And what that means is obviously up for interpretation. The marketer should be able to use an editorial experience that is accessible and easy to use. And the user should be able to experience that content that both of those people are working with on any possible channel that they can imagine. So decoupled Drupal does this because it's the underlying approach. It's the foundation. It's the underpinnings that allows for cross communication between Drupal and other systems. How many people already know about decoupled Drupal and already know what decoupled Drupal involves? OK, great. So if you are a little bit confused, I encourage you to go after this session and check out my intro session on Tuesday, which will give you kind of the most comprehensive look at what exactly is this word, this buzzword, that people have been using. Decoupled Drupal fundamentally allows anybody else, any other developer, to speak Drupal. But only having robust APIs is not enough. And I want to take a moment in this session to really dig deep into what a CMS is supposed to do. What are things like in-place editing? And what are things like layout management and display management in this kind of context? So here's a quick diagram of what decoupled Drupal looks like just to refresh your memories. And I'll just go back really quickly if you want to take a picture or if you want to see that for a little bit longer. And I'll use that opportunity to take a drink of water, because I'm a little sick. How many people have the Drupal conflu? All right, OK, all right. Me too. I'm surprised I still have my voice. So in the editorial experience, what we've been noticing is that what developers want and the flexibility that they want in their experience is oftentimes in complete opposition to what the marketer wants or the editor wants. One example of this is one thing that we've done in Drupal for the last couple of years, ever since I started that issue in Drupal Core's issue queue about adopting a JavaScript framework. We see a lot of insights that we've gained recently from people using Drupal in various ways with various frameworks. But the problem is, how does that jibe with contextualized front-end tools? How does that jibe with in-place editing and some of these things that a lot of our editors are used to and some of the features that we really touted as being the most important and most amazing features available when Drupal 8 was released just a couple of short years ago? I want to consider today a couple of different cases. I'm going to focus primarily on Calypso and React and WordPress as well as Prismic just to kind of expand this discussion a little bit beyond the Drupal context. And I want to also pose these questions as well. They're a little bit less relevant to this session, but they really do kind of call into question how we should be able to think about these issues. If you were at my session yesterday about augmented reality and Beacons on Drupal, I raised these very same questions about how site builders and how content editors actually work in this landscape. So there's a new problem in Drupal. There's a new tension in Drupal, which is that our value proposition that I just mentioned that was threefold, this tenuous balance that we've forged between the developer and the user and the marketer is endangered. And the reason why is because if you think about it, Drupal's really great at doing two things, especially with the release of Drupal 8. Number one is building a website. And number two is building a responsive website. And if you are somebody who is a marketer or a content editor or a site builder, you can use Drupal to do these two things without ever having to tap on the shoulder of a developer. And that's a really great thing. That's one of the most important opportunities that Drupal has provided in the history of our CMS. But all of these emerging channels, all of these new technologies that are now surfacing, what is our answer to the editors and site builders who have followed along Drupal's trajectory up until this moment? Only developers really have the expertise and the ability to do and build and create these experiences that really we want to also enable content editors and site builders and publishers and marketers to be able to use without having to tap on the shoulder of a developer. So these are just some of the issues that I'm gonna touch on today. Better for users today increasingly means that in an omnichannel context, you're gonna have more and more capabilities on more and more devices. So if you think about this kind of graph that I'm gonna illustrate here, you've got the y-axis which represents something that's better for developers, a better developer experience. On the x-axis, you've got the marketer experience which is the site builder, the content editor, and so on and so forth. Drupal has always been in this sweet spot of being right in the middle of that. And as a result, we've been really good for end users because what happens is when you have this nice equilibrium between developers and marketers, you get to achieve that dream of having users be happy as well. Your clients are happy as well. And those who come to your site and are your customers of that brand are happy as well. But increasingly what we're seeing is this kind of a transition where a better outcome for all of our users in an omnichannel context in more and more channels actually relies on more custom work by developers. And this is exactly what we're seeing right now in JavaScript. If you're building single page applications in Angular or Ember or React, you're noticing this exact problem right now. So let's talk about a couple of different approaches that have been touted in various places in various ways by different people to really confront this problem, this unique issue, which is what if we were to be able to edit everywhere on every device, whether it's a mobile device or something else. And what if we were able to edit everything in the context of Drupal? Let me just explain what I mean by that. About five years ago, there was a project and initiative that was started in the Drupal community that was called Spark. How many people remember Spark? So Spark was a really interesting initiative because it really sought to introduce these ideas of contextual administration, these ideas of more unique tools and more interactive tools for editors in this way. Drupal actually, before then, in Drupal 5 and Drupal 6 already had contextual administration in terms of the local action tasks. You know, those view, edit, tabs up on the top. Those kinds of things are contextualized. Those kinds of things are part of the administrative experience that is also part and parcel to the end user-facing experience. So as part of the Spark distribution, we actually tried something new. We said, what if we could figure out a way to do responsive editing where you can do mobile-first editing? And this is actually possible right now on Drupal 8. But what we learned in the process of doing user testing and conducting a lot of usability studies is that most people are gonna resort to the desktop instead because can you imagine adding a table to this? Can you imagine administering a table in this? I mean, I'm already seeing some shocked looks on the faces of some of the editors in the room because that's kind of hard to do on a mobile device and it's not really an easy proposition. The full breadth of functionality isn't really available. I mean, as you can see, there's limited real estate for this toolbar. And the user experience on certain devices will eventually deteriorate considerably. So this idea of editing everywhere, if we take it out to its logical conclusion, considers the idea of what if we can administer these things on an Apple Watch or an Amazon Echo, which has been built by the way, I've actually seen experiments where people can update content using their Alexa device, which is pretty cool. But you don't wanna do that on a daily basis as a content editor or a site builder or a publisher. It's just not a very good thing to do. And there's this problem which is that better usability on fewer devices, right? We're really good at allowing you to use Drupal on a mobile device and on your desktop. But the benefit of that is that we have fewer stacks to maintain, there's fewer devices that need to have their own unique UIs and their own unique approaches to usability and interaction patterns. As we introduce more channels, those things really worsen. And as you can see, if we take this out to its logical extreme, there's absolutely no way that we can accomplish this dream of edit everything, sorry, edit everywhere, no matter how much we wanna try. So what's the alternative? Well, there is one which is editing everything. What if we could take the existing Drupal interface as it is right now and put all of our channels into that and share a single user experience across all of these different channels and just have Drupal be the context in which all of those channels lie. And now I'm seeing the shock from a lot of the developers in the room because they're thinking stuff like emulators and they're thinking stuff like iframes. And that's pretty scary stuff. But if you just humor me for a moment, editing every channel on quote unquote Drupal can be done right now. If you think about the outside in paradigm that was introduced in the last 12 to 24 months, this idea of being able to see your live preview, your existing visual experience that you've been working on and then also having a sidebar that's off canvas that you can use to do things quote unquote in context. So my belief is that if you were to do this, you would want to have Drupal for other experiences be indistinguishable from Drupal for web experiences. Which means that if I want to administer a menu in a native mobile app, it should be the exact same process as you see up here on the screen. And I should see my native mobile app being previewed in this left hand content area. And now the developers are really getting ready with their rotten tomatoes to throw them at me on stage. What about adding a block? It's the same kind of issue, right? You know, what if you want to do this kind of site building on a mobile device or on an Apple watch? And as you can see, this breaks down too. If we take this idea of editing everything in Drupal to its logical extreme, it falls apart as well. So this is now another problem. This is now another tension in Drupal, which is that as we increase the number of channels, we have worse usability as well. And either we're gonna have to make a bunch of emulators, we're gonna have to create some kind of low fidelity preview mechanism using emulators, which is crazy talk. Or we're gonna need to have developers be involved in every step of the way to set up the infrastructural requirements, such as a staging environment, such as that separate API endpoint for previewing, that allow for editors to have the exact same access to preview that they had in Drupal for the web. So as you can see, the omnichannel evolution and the way in which content is really evolving and changing in terms of its destinations is completely changing the calculus and completely moving the chess pieces of what it is that we need to accomplish if we're gonna succeed as a CMS in the same way that we have for the website and for the responsive website. So there's no silver bullet. There's no single holy grail. There's no way to actually make this work. As people have tried though, and I'm gonna talk a little bit about some of those approaches just to kind of think about these ideas. Because what we see is that editing everywhere requires us to eventually have to build editorial interfaces for every device. If you wanna edit content on a native mobile app, you're gonna have to build an Android editorial application. If you want to edit everything, you're gonna have to either accept low fidelity previews with emulators or iframes or some Kluge technology. Or we're gonna have to have a lot of infrastructure and a lot of developers are gonna be tapped on the shoulder by editors and site builders. As the number of channels grows, Drupal right now is stuck between a rock and a hard place. And we're already seeing this coming into form with regards to the JavaScript framework kind of explosion happening in our community. The decoupled Drupal explosion happening in our community. And of course, a lot of the ways in which other CMSs are trying to tackle this problem. And Drupal already right now has examples where this tension is already evident. And so let's take a little bit of a step back and talk a little bit about contextual administration. What I mean by contextual administration is in context editorial and site building operations that are present on the front end while you're viewing it. And once again, this is something that Drupal has had for a very long time, the local tasks. And if you think about what this means, these examples, there's stuff like in place editing, contextual links, the toolbar, layout management in context, theoretically, if we were to have that, for instance. And these are all tools that some of us may or may not use, but might be important to our editors or our site builders. So let's talk a little about progressive decoupling. As many of you know, progressive decoupling involves the interpolation of a JavaScript framework which is totally divorced from the approach of Drupal's front end. Into the Drupal front end, which means that you have two very different approaches coinciding on a single Drupal front end layer. And as you can see on the right side, what happens in this case is that Drupal provides that initial application state and hands off the responsibility over client side state and client side actions over to the JavaScript framework. There's a bit of a spectrum of approaches that we've seen in the wild. A lot of people use progressive decoupling to allow them to provide Angular components in single blocks, in single Drupal blocks. Some people, instead, want to be able to allow for the main content area in the middle of the site to be something that is client side rendered and is dynamic. So when you click on a link, you don't actually get that full page refresh and that momentarily blank page. The header and footer are still there. It's just the middle area that's changing. And still others, including our very own, at Acquia, our very own Acquia Cloud UI, actually decouples the entire page body because they want to take advantage of certain settings that are passed in the head tag. And so what this means is that Drupal does provide that initial state, but everything else is handed over to the framework. So these are all different approaches that we've seen. And if you think about it, though, when you're an editor and you're a site builder, these things might as well just be black boxes. Because fundamentally, if you have progressively coupled blocks, the best you can do is drag it around into different portions of the layout. You can't actually really introspect into those and dig into what's happening inside unless you're a developer because there is no CMS. There is no content editing available for a React component or an Ember component inside the Drupal front end. So this becomes a really important issue because when I see this black box on the right side, I get really scared as an editor because I don't know what my content is ultimately going to look like. There's a module called Decoupled Blocks, which is built by Matt Davis. Is he here in the room? Matt? All right. It's a really amazing project because it forges this balance between site builders who need to manage these layouts and front-end developers who want to be able to actually manipulate page behavior and application-like interfaces. So it's actually a really interesting compromise, and it's very similar to the compromise that we've built up over the course of years between those personas in Drupal. And it's a framework agnostic module that allows you to inject Ember components onto a page or Angular components onto a page, and then you, as the site builder, can go ahead and take that block and move it around on the page. It's a really amazing approach, and if you haven't checked this out yet, I highly encourage you to do so. So the problem, though, is that if I'm a site builder, I'm gonna drag one of these blocks. Let's say that this right here is a React block in orange. I'm gonna drag that block over to the right sidebar. But the thing is that these components are really frustrating for editors because there's no longer any form of in-place editing. If I drag that over and client-side re-rendering happens and there's dynamic changes to the page because the framework has touched it, there's a very good chance I'm gonna lose in-place editing unless I've somehow architected it, and it's a very kind of hard thing to reconcile the Drupal front-end approaches and those in JavaScript. So really, those are black boxes for editors, even though site builders can really benefit from it. So this is also not really a silver bullet. Progressive decoupling isn't really a silver bullet because Drupal and JavaScript are so different. Twig and the templating languages used in JavaScript are so different. And also, these frameworks and libraries in JavaScript presume that front-end developers are gonna want to wield that full control. And so there's a kind of lack of harmony, and fundamentally, progressive decoupling is a really challenging prospect, and there's a lot of concerns. There's templating, routing, rendering, all of these things are disparate. They're dichotomous, they're divergent in terms of where Drupal and JavaScript are. And this bifurcation actually reveals itself in very interesting ways. A very large website, a very large site that I've had the opportunity to look at has this interesting approach where they have Drupal routes as a super set of JavaScript routes. So when you as a user navigate to the home page, Drupal renders that route out, Drupal renders that page and flushes it to the browser. Then the client-side JavaScript takes over. This is progressive decoupling. And what happens is when I click on a link as opposed to navigating to the about page, right, if I navigate to the about page by going to the URL bar, Drupal's gonna go ahead and render the route again, assuming of course that you're hitting the origin. But if I am gonna click on the link instead, the framework takes over and JavaScript re-renders within that content area, which is a really interesting idea because this actually saves a lot of kind of that user experience drawback that you see. But the issue here is template duplication, right? So if I have an Angular application that's doing all of this, I'm rendering things using Twig. But if I'm going to re-render things on the client-side when I click on a link because I want that application-like interactive seamless experience, now I have to go and use my Angular templates instead. Same thing with React. I'm gonna have to go over and use JSX instead. And while there is an equivalent of Twig in JavaScript, namely Twig.js, a lot of issues remain in terms of the ability for people to use Twig.js in a very easy way, and also the uniqueness of our implementation of Twig in Drupal. So progressive decoupling comes with expensive trade-offs, and it might be more trouble than it's worth. What about fully decoupled? What if we just say, all right, well, let's not put the two together because they're not really good bedfellows anyway, Drupal and JavaScript, in this traditional sense. So for those of you who don't know fully decoupled Drupal is basically what many people call kind of headless Drupal or completely headless Drupal, which is basically Drupal only serves as the content store, the content repository. And the front end is actually entirely controlled by JavaScript, and you have a Node.js stack which operates the server-side rendering process. Now if you're very confused, just think about the fact that if you go to a website and you can't do in-place editing and things of that nature, it might be because it's being driven by a JavaScript framework. And the reason for that is because of oftentimes more flexibility. So fully decoupled front ends are an interesting idea because there's two kinds. You have this idea of a public-facing front end and a lot of people, how many people have built for a client a fully decoupled application like an Angular React Ember? Okay, so a lot of people have done that. They're an approach that's typically used to actually allow for development to go faster and require that strong understanding of the client of those trade-offs. Then there's also those administrative front ends, those editorial front ends, the replacements for the editorial interface. And I know there are quite a few people here who have experimented with replacing the editorial interface in Drupal with something a little bit simpler or something more usable or something more rich in terms of what features they want to include. And so maybe they provide the same functionality or a subset of the functionality or even a superset of the functionality as a traditional backend that we have in Drupal. Now how many people have heard of WordPress Calypso? Interesting, okay. WordPress Calypso is exactly what I just said, which is a replacement for the existing WordPress editorial interface. It's written in React. It's a completely separate application. It's a single-page application that boasts a much better user experience, subjectively speaking, than the existing WordPress user interface. So if we think about these kinds of architectures from the standpoint of WordPress, traditional WordPress is just like Drupal in terms of being a monolith. The WordPress administrative layer, the WordPress administrative front-end is part and parcel to WordPress, which means that they're inextricable. And of course, they benefit from being able to interchange ideas. WordPress Calypso, however, uses Node.js and uses React to provide a completely separate interface that's completely divorced from the WordPress front-end because the WordPress front-end is still written in PHP, but Calypso is written in JavaScript. As a result, WordPress Calypso has no contextual administration, has no in-place editing, has no ability to allow for people to take advantage of these tools that we have in Drupal. Because fundamentally, the WordPress front-end is still written in PHP. It's still a completely different language from that admin front-end, from that administrative experience. So Calypso actually, I believe, made a decision not to tackle that problem. They said, we just wanna create a better editorial interface for our users and our editors and people who are gonna be working with content. Because maybe they don't have to worry as much about site building. And a similar editorial interface for Drupal would have the exact same set of issues. Let's just say, for the sake of argument, that we decide to build our own React application to compete against Calypso. And maybe we want to make that something that is also serving content out to that Drupal front-end. Maybe we can call it Poseidon or something just to keep the deity kind of thing going. But the problem now is, can you contextually administer those fully decoupled front-ends? You really actually can't. Because when you think about it, you have to combine those two in order for these things to be possible. That's how Drupal made this possible in the first place. Stuff like layout management that immediately updates or in-place editing or things of that nature. So one option is to make some tools that are native to Drupal's public-facing front-end and make those available to that fully decoupled user experience. But as many people have said, this would probably require us to include Node.js as a dependency for Drupal and it might require a complete front-end rewrite. Let me just illustrate really quickly what that looks like. We would probably need to use Drupal solely as that single content store, solely as that single source of truth, as opposed to allowing for that bifurcation between the administrative front-end and the public-facing front-end, right? And what would happen in this hypothetical world is that Drupal is something that really still has all of the power, but fundamentally, if we're going to still do things like in-place editing and display management and a lot of these ideas that are very important to a lot of people, we're going to need to combine the two together because that's the easiest way to accomplish that. Is that true? Well, let's think about the history, right? There are concerns right now about including an entire JavaScript framework for authenticated users who are just viewing a page, like putting in a toolbar or doing all this stuff, right? But there were the same concerns about putting in jQuery and Backbone in the same pages to provide for in-place editing and for the toolbar. And we until recently actually had jQuery loaded on every single page in Drupal regardless of who you were, which is pretty funny. So when these two things are divergent, when the Drupal front-end and Drupal administration are divergent, this idea of in-place editing, of contextualized administration is much more difficult. But when they're one and the same, you can take advantage of these shared tools. You might even potentially be able to have the same kinds of user interfaces and the same design across both of those kinds of experiences. But divergent is dangerous, right? Imagine building an in-place editing feature in the same tool set, developer workflow, that you built the content editing form in. That's a really nice proposition. Or a layout manager feature directly in the front-end that allows you to manipulate the layout on the front-end as you're viewing it as a user, that you had that you built maybe panelizer in, right? These are interesting questions. But it's clear that a rewrite in JavaScript will be your monumental effort. And it's really the elephant in the room. We don't want to rewrite everything. It's going to take a colossal amount of time. I don't think that any of us really wants to do that. So approximately contextual administration in these divergent front-ends is possible. Actually, it's possible. But are the available solutions actually adequate? So let's talk about a couple of examples here. And I want to bring in some inspiration from other CMSs. I want to start with a little bit of an anecdote. So recently, I had the chance to meet with a Drupal customer who had contracted an agency. And this agency built for them a fully decoupled React application on top of a Drupal content repository. They decided to build this site. Ostensibly, that was a Drupal site. But actually, they built a React application on top of it that didn't have any of the tools that they were used to. Six months after the project launched, the client called this agency in alarm and angst and anger and said, where is my in-place editing? Where are my contextual links? Where's my toolbar? And what actually ended up happening is the agency promised to this client that they would re-implement the Drupal toolbar in React so that they would be able to dip deep link all the way back to Drupal's administration. That's a lot of duplication. That's a lot of duplicated effort. That's not really necessarily what we want to have to do. But our clients want to be able to have access to that toolbar, want to be able to have access to those contextual links. So there's these new headless CMSs coming out, like Contentful and Cloud CMS, that have really nice editorial interfaces that are just like Calypso and Drupal's edit forms in that they're just a series of forms. They're just a series of text fields. But just like WordPress Calypso, they don't have stuff like in-place editing. They don't have to worry about deep linking or contextual links with a couple of exceptions. How many people have heard of Prismic? It's one of those kind of big names that comes about in headless CMS land. Prismic and Simplaw are two CMSs that are among the first to try it. And I think it'd be a very good idea for all of us to take a look at how they're actually accomplishing this. Prismic allows you to inject an edit button. If you have content that's being served out from Prismic out to your React application or your Angular application or what have you, Prismic allows those JS developers to include a script that will render in an edit button that deep links you and takes you all the way back to the Prismic editorial interface. So it's just like what we have in Drupal with contextual links. And these client-side edit buttons allow for these editors to be able to go back all the way to the back end. Just to give you a quick idea of what this looks like, you have a script that you have to inject and you have to identify the correct ID in that content. This is a lot of work for developers as well. This is something that isn't really that easy. And then once you actually have that, inside that article, quote unquote, you're gonna have an edit button that takes you back. So that's one option, right? And Drupal could very easily do the same kind of thing. But Prismic also has this idea of contextualized preview, which allows editors to preview by providing a series of steps that developers have to follow and also involves some infrastructure. So this goes back to the problem that I was talking about in terms of high fidelity preview of decoupled interfaces that have unpublished content that you want to see as an editor. There's a really complicated workflow to do this, as you can see. Simbla is a little bit different. Simbla has the same idea. It has the same headless CMS. It has the same API provider. And it says, we have in-place editing. We have contextualized formatting tools. We have content modeling. We have a JSON API and API and JSON. And it advertises itself very ambitiously as a replacement for the CMS. It's built in polymer web components and that enables the separation of concerns between the contextual administration and the public-facing front-end. But it might not be such a good fit for things like React. But as you can see, if you go to the website, you'll actually be able to edit in place this headline on that site. And as you can see, you can also have a little bit of a formatting toolbar as well. But in order to take advantage of these features, the easiest way to do it is to use an HTML-based front-end to write your front-end in HTML. So can Drupal stack up with these on contextual editing? Let's talk about decoupled layout. So actually, one of the more prominent Drupal agencies, Accelerant, built a module known as RESTfulPanels, which theoretically would give you the idea to manage layouts for consumptions by those front-end applications. So if you're building a React application or an Angular application, you would be able to offer your site builders the chance, that holy grail of manipulating layout and being able to see that take effect on the Angular front-end. And this can be a layout manager that has no transparency. That is just like panelizer. You make the layout, but then you finally see it when you actually view the page. Or it could be something that you actually interactively see change, and that would be really good for things like A-B testing. RESTfulPanels is a really interesting approach. It exports panel's configuration data into these consumable JSON data structures. One of the things that is a really hard problem in decoupled layout, however, is the separation of concerns between content and its presentation. As a developer, I don't know if I want my data structure that I'm consuming from Drupal to be wrapped up in this structured thing that is basically mirroring the presentation of that content. And one of the things that you'll see if you work with a lot of panel's layouts is that some people label them stuff like left and right, and you don't wanna encode that stuff in your data. You don't want that to be part of your content necessarily. Maybe you want it to be alongside or auxiliary, but you don't want that to be the way that you consume that content. Nonetheless, RestfulPanels is a really interesting and fast and example of how we can begin to think about these solutions, and it's a really compelling solution that works for a lot of people. So decoupled layout can be really brittle because developers don't want chunks of markup. We know that. Developers don't wanna have these chunks of markup that are all Drupal rendered. They wanna have pure data structures. But the problem with that is that that means that the editors have less control over layout management. And so you can see it's always a series of trade-offs. Decoupled Drupal is always about making compromises. And giving these developers chunks of markup once again resurfaces the flaws of progressive decoupling. If you think about these black boxes that I showed earlier that are really hard for editors and really hard for site builders, as a React developer, if I get a chunk of markup coming out from Drupal, that is a bunch of HTML that has those Drupal classes, that's basically the same thing. There are black boxes in both directions. So we need a better separation of concerns potentially, providing both layout and content in a really sane way, providing it potentially as a related entity or as a field, such that you can process both independently and combine them as you want to. This is mere speculation, of course. So before we open up for questions and discussion, and I hope this was really good food for thought, I wanna dive into some more of this conflict, which is that we might need to make some really difficult decisions when it comes to the future of Drupal, when it comes to the way Drupal is gonna serve the site builder persona and the content editor persona. Maybe it means that we have to break that balance, that we have to break that equilibrium that we've had for such a long time. We have to say that the editor and marketer are more important than the developer. And that's a calculation WordPress has made. Or maybe it means that we prestige the developer over the editor and marketer. Maybe it means that actually the developer is who is king in Drupal and should be. Or maybe it means that we try to keep the status quo and see how much success we have with that. If we want to really focus on the editor and marketer, maybe that means that we adopt a JavaScript framework such as React for a decoupled frontend that allows that marketer to have that really nice experience and focus our energies only on the web as opposed to conversational interfaces or augmented reality. Maybe it means that we have to do things like emulation or try to approximate other devices inside a Drupal user interface. And for the developer, maybe it means that we have to adopt an agnostic approach and provide these kinds of components, just like those simple components that allow the developer to have that flexibility, but they have to finish the job. Or maybe it means, as many people have suggested in the past, that Drupal becomes solely an API first backend and developers can do the heavy lifting on the front. If there's one slide I want you to take away from this session, it's this one. Because the marketer experience is something that we've always treasured in Drupal. The editor experience, the site builder experience, these are things that we've always treasured in Drupal. What is our answer to JavaScript? What is our answer for people who are now saddled with these other channels and are forced to be able to do the same things that they were used to doing in Drupal in these other channels? It's a really interesting food for thought because it's a really interesting question because we are constantly seeing new channels surface every single day. There's new things coming about every single day. There's new, I mean, you're gonna see a lot more IoT happening. And there's also things that we've never heard of yet. In the next 12 to 24 months, I guarantee you we'll see at least one new technology that no one will have anticipated and that will be completely new. Web is increasingly just a single facet of all these editorial concerns, of all these site building concerns and publishing concerns. An editorial preview is something that's really hard right now. Developers still have to be consulted if you, as an editor, want to be able to preview unpublished content on a single page application like React or on a native mobile application or on something like a conversational interface or on something like augmented reality. Is this idea of contextual administration dead? One of the things that I've done recently is every single time I get an opportunity to stand in front of a group of people, I ask the question, do you yourself and do you have customers? Do you have clients that use in-place editing, that use that feature in Drupal 8? And I want to ask that now. How many people in this room use in-place editing or have customers that use in-place editing on a regular basis? We've got about maybe 10 in the room. Every time I ask this question, the number goes down. On Monday I asked the question and I got only two people who raised their hands. And this really presents the idea, this really presents the problem because so many people are not using in-place editing and because they prefer to work in that decontextualized experience. Maybe this idea of contextual administration, maybe that's actually not such a good idea. Maybe it should actually, in terms of preview especially, be more of a platform or infrastructural or an orchestrated consideration. Because as we've noticed, fewer people are using these kinds of tools. But we ultimately still need that seamless preview. What's really interesting is that at the same time that we are seeing these tools used less and less, we see the expectations of editors and site builders increase all the while in terms of what they can do. And a decoupled context challenges all of those notions. If contextual administration is dead indeed, if in-place editing is something that people don't want indeed and edit everything and edit everywhere are actually really not good ideas, then what really needs to happen is we have to think very deliberately and very carefully about decoupled content strategy. For example, what does content editing look like if I want to edit content sanely and simply and useably for a conversational interface? Does it look like a decision tree, a field? What if I want to edit content for an augmented reality experience? Is that a geospatial map with text fields superimposed on that map? What if I want to provide some kind of content editorial interface for something like an Apple Watch, right? Is that something that I now have to administer in a decontextualized way? Something but some usable way because as editors and site builders we still have to have the ability to see these things in action and actually know that what we're changing is being reflected correctly on the other side. Because the danger is that we're not just creating black boxes across the page or in certain areas or for developers or for editors. We're actually unintentionally creating a black box entirely on the other side. And this is a big danger for us. We have this big conflict between channel diversity and channel agnosticism. Drupal wants to be that single source of truth for all of these different channels. But we also want to make sure that you as a content editor are able to differentiate content somehow in a sane way across different channels because conversational content is not the same as web-based content. Apple Watch content is not the same as Roku application content. And these are the kinds of things that we have to think about as a community. Recently, my team, Aquaelabs, we completed a project for the state of Georgia in the US which is an Alexa skill that basically takes the FAQs available about the state of Georgia into a conversational interface. We had two criteria. The first was the editorial workflow cannot change. So the way that the editors use Drupal cannot change which means that we can't add additional fields for saying this is the way that the text should be for Amazon Echo. The second criterion was we cannot hire additional editors which meant that we had to use the existing content team because this is public sector, because this is a government website. We had to use the existing resources. And so rather than try to build a technical solution where we provided new fields, new text fields that would provide two different versions of content, one for the website, one for Amazon Echo, instead of doing that, instead of taking that approach, instead of going in the direction of, well, you know, let's try to differentiate. We went in the direction of the right side which is let's write content in the right way for both Amazon Echo and the web at the same time which means let's make links more interpretable and less necessary to click on in order for you to understand what they're about. Let's make sure that our paragraphs and our responses are in short chunks. Let's make sure that our content is readable and legible, not just for a website but readable and legible also on your Amazon Echo device. So this idea of decoupled content strategy is very important and I've been talking recently quite a bit about this idea of conversational content strategy as well because in this omnichannel age, maybe it's true that we need to tell our editors that actually the way that you write content and manage it visually has to be channel agnostic and we have to stop thinking that we can actually visually assemble everything. So maybe it means that we have to focus on assembly of just websites as Drupal and say let's just make everyone else use a decoupled content strategy and decontextualize that content. Get rid of this idea that you can visually assemble everything. Maybe that is the way to go in the future. We have to think about this because it's very important for the ways in which we're gonna be able to handle all of these new channels in the future. In five years when we have five new devices, is it gonna be a good idea for us to stick to this idea of visual assembly? Because fundamentally, maybe it's a good idea for us to move away from this idea of visual control of everything. I as a site builder can drag things around the page and lay out my page and in place at it and do all these things. To this idea that maybe everything visual and actually also non-visual in the case of conversational interfaces is actually uncontrollable. What I do believe 100% though and I hope that you do too is that this problem, this friction, this really interesting set of issues that honestly is one of the most interesting challenges that I think our industry and we as a community have ever faced. This is gonna be the great test. This is gonna be the great challenge, the next challenge that will dictate the next decade of Drupal. That will dictate how the next, how the years 10 to 20 of Drupal will look. But I believe 100% and I believe very strongly that a multifaceted Drupal, one that is diverse, one that includes different views and different approaches and different ideas and a lot of these kinds of problems being addressed in multiple different ways. A multifaceted Drupal is fundamentally a more future-proof Drupal. And thanks to all of you in this room, regardless of whatever you're doing, whether you're a site builder or whether you're an editor or whether you're a developer or whether you're building JavaScript applications. Thanks to you, Drupal story has only just begun. Thank you. So we have a mic here for questions. In the meantime, I just wanna remind everybody about the sprints that are happening on Friday or tomorrow, actually. And they're a really great opportunity to talk about these issues, think about these issues, work on some of the ideas that can further Drupal in this space. And please, I do request, I don't get better at this kind of stuff without feedback. So if there's something that you want to say, if you wanna throw virtual tomatoes at me or if you wanna talk about how my hair is really ugly, please feel free to submit an evaluation on the DrupalCon website. And now I'll go ahead and take questions if anyone would like to come up to the mic or have a little bit of a discussion. We have a mic here that's open and I'd love to hear your thoughts about some of these issues. And I hope this was thought-provoking. Hi. Hi. If there is, if decoupled is a future, multi-channel is a future. Why is there so much effort right now to have things like the layout builder and inline editing? I think it's a bit of a contradiction to me. That's a very good kind of point. You know, the idea that, yes, we're focusing on these kinds of visual tools, these contextualized tools, as you said, like in-place editing and layout management, when we maybe should be focusing more on the channel. The good thing is that we're doing both, right? The good thing is there's the API-first initiative that has had a great deal of success in the last couple of years, in the last year. And one of the things that I think is very important is that, as I said in that slide about 10 slides ago, you know, we have the opportunity to be divergent if we want to or convergent if we want to. If we want to provide the best, the most amazing tool to assemble websites and also a really nice decontextualized content store for all of this omnichannel content, that's actually a possibility for Drupal and certainly a possible trajectory forward. But fundamentally, if we want to provide an equal experience, that kind of democratic experience for everyone across every channel, we have to reduce and we have to think about the notion that some of these tools are not really gonna be that useful in this context. However, things like the Layout Builder are very interesting, right? Because there's gonna be a Layout Builder in-core, as you saw on the Jerry Snow. And this is interesting because one of the things that I think is gonna be very important for the success of that approach is that it's available in an API first way, which means that you can take that Layout Builder and consume whatever result you make in that Layout Builder, make that available to any application. Like for example, if I'm someone who's designing a UI in Android or in iOS, I might potentially want to be able to use that Layout Builder and allow my editors to manage that Layout and then consume that for my iPad application, right? Maybe that is something that is important to people. So if we think about stuff like the Layout Builder, not in the context of just being important to websites, but also in the context of being important to other channels because developers can use them in a really interesting way through APIs, through web services, that could be a very interesting prospect. And that could be one way, once again, to provide that divergent approach because obviously you can't have conversate, you can't have layout, you can't consume that Layout Manager in a conversational interface. You can't consume that Layout Builder in an Apple Watch. It's just not possible. So I think we have to think about these ideas and say, where are our priorities? Is it, if we're gonna build these visual tools, I think moving forward, we have to make sure that they also have the ability for other developers to take that same information that's being used by Drupal to render out those layouts and use that information to render layouts in other technologies as well. If not, then I think that we really should think about decontextualizing content and removing this idea of visual assembly. But that's really kind of something that I really want to leave as a question for you all. I hope that was somewhat of a helpful answer. Thank you. I was one of the people who say that I've been using in line editing. I actually haven't been using it for the marketers, but I find it extremely useful if you have to provide possibilities for the end users to edit something. And that's where the Drupal's capabilities for inline editing actually starts shining. I've never seen any marketers want to edit their content using inline editing. But if you have to do something like that for the end users, then it actually makes sense. And I think maybe not so much for the layout builder potentially yes as well, but at least the inline editing is useful for that use case as well. And it's something that we don't actually talk about so much. But yeah. Exactly. That's actually a very good point, Lauri. I think one of the things that would be really interesting is what if we could provide in-place editing capabilities in the same way that Simpla does, right? To any technology that exists. I mean, Simpla obviously is kind of restricted to HTML and kind of web components stuff and might not work in a very complex JavaScript environment. But if you think about the fact that in-place editing is something that should be democratic, right? Should be something that's available to JavaScript frameworks as well. Maybe what that means is, as I said, providing a web services approach to that as well. Maybe we as Drupal provide a single interface as a web component that uses the Shadow DOM and kind of is agnostic to the rest of the appearance of the page and actually allow for, well, all right. Oh, thank you. And actually allow for that content to be editable in any kind of setting. But also have the same UX, right? Because ideally, if I'm editing my Drupal site content and I'm editing the home page with all the paragraphs of text up there through in-place editing, I don't want the UX necessarily to be different from that when I'm editing my React applications content or editing my Ember applications content. I'd like that to kind of look the same. And so web components does provide a little bit of that promise. And I'd love to talk more about what that would involve. But I do think that if we do want to provide stuff like in-place editing, which is important obviously to some people and I don't, by any means, want to discount those who find it very useful, regardless of who you are or what your responsibilities are, the fact of the matter is that if we want to be able to provide a visual experience, a contextualized administration experience, we have to be willing to provide those for other channels as well. Or we have to figure out some way. The thing is none of this is absolute, by the way. This is all relative. We could certainly, there's any manner of directions that this could go and I think any one of those could be a good move as long as we think it through and realize that all of these approaches indicate that we're actually doing the debate. For me, one of the biggest things that I concluded after two years ago, we had the debate to adopt a JavaScript framework in Drupal and I led that effort. I posted on the issue, I said, actually I think the debate and the discourse and the ideas that we're proposing and the things that we're talking about here, the discussion is more important than the end result. So regardless of wherever we end up, I think it's very important that we do have those discussions. Do we want to have in-place editing available to decouple JavaScript frontends or do we not? I think this will have to be the last question. I see the zero zeros pointing at me here. I'll try to be quick then. My question is about something that seems to be, to me to be an open question, which is, so I think we are used to thinking about the web as kind of an hypertext, so the question of links. If we imagine to have Drupal as a content repository, then I'm just wondering how we can keep that functionality that says, okay, this content is connected to something else. Very simply, if you have inside the body text, for example, a link to something else, and then that content is used in a phone application, or it seems to me that we might risk missing a big part of what the web has been. So I just wonder if there's any answers to that, or if it's a concern that has been taken into account. That's a very good question. Thank you. That's a very, very good question. And I think that's one of the issues that we came up on when we built this Alexa skill in Acquia Labs, which is that there is no way to follow links in a sane way on an Amazon Echo. Certainly in a screen reader you can, but Amazon Echo is not meant to be a replacement for a screen reader. And when you think about links, oftentimes you click on links because you know that they're gonna take you to information that's related. So I think maybe rather than thinking about, and I think this also ties into related content, relationships between content, where you have references to other content, referential content. The fact of the matter is that unfortunately all of these channels have very different approaches to how they handle these sorts of content relationships. If you're talking about Drupal and you're talking about websites and you're talking about hypertext links and you're talking about these relationships between pages and different pieces of content, that's a web. That's like literally a vast lattice of all of these different relationships that are forged by these links and by these references to other pieces of content. However, if you think about this from the context of a conversational interface like Amazon Echo, right, those links are actually really not links, those relationships are not relationships anymore, they're unidirectional. You have to follow a very predetermined path in various ways or various trajectories to get to where you want to. It's usually like a tree. It's not so much something where I have one single piece of content that has 50 links in every which way because that's not how a conversational interface works from a usability perspective. And it's the same way when you think about things like augmented reality, right? I mean, augmented reality is something where there is really not a very easy way when you have locational content or situational content to take that content elsewhere or to allow for you to follow links from that content to other places. Certainly you can get more information about that same situation of content, but if I'm over here and I'm getting a certain piece of content from holding up my device to something and I hit a link, that.