[Music] [Martin Noble] Good morning, everybody. Thank you for coming. Yeah. So my session is on Unlocking the Power of Universal Editor, particularly focusing on the universal part of that name. So the fact that it doesn't matter what CMS you're on, whether you're on Cloud or M65, you can now use Universal Editor. So first off, probably, who am I? Some of you might know me, but, if not, my name is Martin Noble. I'm the CTO of ecx.io in the UK. We're wholly owned by IBM.
And I'm responsible for a team of solution architects and developers. We particularly focus on AEM and then the surrounding technologies like AEP and Target and things like that.
As I said, a lot of my work is in solution architecture. So I particularly focus on AEM, but now broadening out into like AEP and the surrounding things. I'm a lead architect for the MarTech Solutions at Riyadh Air. And we are actually using Universal Editor with managed services in AEM 6.5. And this is how I got into it and why I wanted to talk to people today and give you a bit of an intro.
I'm also a three times Adobe champion. Here I am with some of my fellow champs. I think some of them are in the room today. Over at the Champion Forum in San Jose, I'm also just recently joined the Community Advisors Program. I'm a dad of an almost eight-year-old child and two cats.
And I am a self-professed geek. You can see here the breadboard computer that I built during lockdown.
And I'm also a maker. I love to spend time in the shed making things. That includes things like lightsabers and jewelry for my family, and we'll actually see some more examples of the jewelry that I've made later on throughout the things. I've built a little website to demo this using some of that content.
So enough about me. Let's talk about what we're going to cover today. So we're going to first talk about what is the Universal Editor, then drill into authoring with Universal Editor and how that actually works.
We'll look at the Component Properties Panel, so how we actually configure components. And then we'll actually look at some of the limitations, so where you may not be able to do things exactly the same way as you would normally do things.
Then we'll go a little bit deeper, look at actually how does Universal Editor work, what's the architecture, and why is it actually universal, and then how you would go about integrating that into your applications. And then we'll look a little bit at the extensibility.
And then I'm going to talk a little bit about how I ended up getting here and what my journey with Universal Editor is, give you an idea of actually just how easy it is to get on-boarded. And then we'll open up the questions at the end.
So what is the Universal Editor? So it is the newest editor option that you have. It's a ground up build.
The idea being that you can have different back-ends, different front-ends. It doesn't really matter what technology you're on. You can use Universal Editor to edit your content in a visual way. And the idea of it is also been-- Because of that, built from the ground up, it avoids a lot of the historic issues we've had, particularly with headless content management, being able to do WYSIWYG editing. There's always been limitations and issues or technology impacts. So let's start by comparing Universal Editor to the other editors that we have in AEM. So first up is the Content Fragment Editor. So this is usually supporting our traditional headless approach. So we can see here we're opening up Content Fragment, switching to Preview, going and then editing our Content Fragment, and then switching back to previewing. So it's disjointed a little bit process. But you are storing your data and content fragments in a structured way. They get combined and exposed and then read by your frontend. And in this case, your frontend then tends to very much own the layout and control and the CMS owns the data. So it's great if you've got pure separation of the data. But it's a bit more limited from a content authoring perspective. Next up is the Sites Editor. So, much more focused on your headful implementations. So here's an example of the weekend site. You can see here nice WYSIWYG authoring experience. We can do inline editing or we can use dialogs and things like that.
Historically, we have been able to do SPA editing in the site's editor, but actually with the release of 6.5 long term support version, that's now deprecated. So that's no longer a recommended approach. And actually the recommended alternative is to go to Universal Editor. And this is actually why we ended up at Riyadh Air, moving to Universal Editor because we explored all these options and actually came to the conclusion that Universal Editor was the way forward for us.
Last but not least then is the Universal Editor itself. Just for all of these demos, what I've done is I've built a little Next.js based headless website, just to show off some of my jewelry designs to you and just give you a feel for, actually how simply easy it is to do content authoring and just demonstrate all the different functionality that we've got in the editor.
So Universal Editor is designed to be universal. The idea is you have any content from any backend and any frontend technology, it doesn't matter. You get WYSIWYG authoring, both for content fragments, page content, even Edge Delivery Services content or, in theory, any other custom backend that you might have. Wherever the content is stored, the content authors effectively, don't need to know or care because for them it's just editing content, right? They're seeing a visual representation of their content. They can select it. They can edit it, and on they go. We'll drill into a lot more how it works in the later part of the session.
So a bit of a comparison of the editors.
So the Content Fragment Editor is built into AEM.
It's form-based, tends to be a bit more decoupled from your UI, and primarily really focused on those headless implementations. We've then got the Sites Editor, also built into AEM. It's very much page based. You get the great advantage of like WYSIWYG and inline editing. So you're seeing the content as it's going to look when it's published out. But it's much more tightly coupled between the CMS and the frontend.
And it really does focus on those headful implementations where the CMS is actually outputting the HTML, writing the content directly to the end users.
And for headless setups, historically, it's always been a very complex technical thing to implement. And then finally, we've got the Universal Editor. It's separate from AEM, so it lives in the Experience Cloud.
We've got WYSIWYG and inline editing of both sites and content fragment, content. We've also got support for any backend, including edge delivery services. And as we'll see a bit later on, the integration approach is really simple. It's so much simpler than what we have with things like SPA Editor. So it really is built for being used and built for the developers as well.
So we'll now jump into actually authoring with the Universal Editor. So as I said, I built a demo site for this. My site makes use of both content fragments and page data. It doesn't include Edge Delivery Services. That's not one of my particular capabilities. But, obviously, if you're interested in that, there's people down on the Adobe booth who can really drill into Edge Delivery and how that works with Universal Editor. As I said before, it's built on Next.js, which is the latest flavor of React.
And I will just say, you might spot some little error things popping up. That's just because this is a dev environment. Also, I really apologize. I'm a backend developer. I'm not a frontend dev or designer. So I really do apologize to any designers or frontend devs out there if you're offended by the look and feel of my site. I'm a backend dev who knows enough about frontend to be dangerous.
Okay. So start off with page templates. So obviously we need to create pages in our site.
One of the big things about Universal Editor is we don't use most of the functionality of editable templates in AEM. So a lot of things like policies and configuring, like, allowed components on pages, all those things, they don't apply in the Universal Editor world. But we still need a page template to define the different types of pages we can create and to own the initial content. So we can actually go about creating our pages. But all of the rules and the control about what components we place, that's much more handed off to the frontend and to Universal Editor itself.
So we're going to see here, I'm actually going to create a page. So we go into our sites view. As normal, nothing different here. We click, create a page, select our template.
I'm going to go in, give it a name...
Hit Create. This is all familiar to anyone who creates pages. Hit Done, and everything's done. Then we hit on a page. This is where it gets different. The moment we click Edit, AEM's been configured here that for pages within this site, it should trigger the Universal Editor and should open up that on my headless site rather than opening up the Sites Editor. Now you can also do it different pages within your site or different sites, you can continue to use Sites Editor or use Universal Editor so you're not locked into one or the other. You could have it, initially your main site remains on Sites Editor, but some microsites, you switch over to Universal Editor and things like that. So you've got flexibility and configuration there to set it up however you want.
So next, we're going to look at actually how we go about authoring content fragment data. Now the beauty of this is that, as far as a content author is concerned, it's no different to authoring any other content in Universal Editor. So we're going to start off just to show you how it's working. This isn't necessary, but we're going to drill into the DAM and find the content fragment for our footer, just so you can see what the data looks like currently. Then we switch over to Universal Editor. We're going to scroll down to the footer. And we're going to edit and do a bit of inline edit on the footer.
So we make our changes in there.
The moment we click out of there, the content fragment's been updated in the backend for us. We can switch back to our content fragment and refresh it, and it's as easy as that. So as far as the content editor is concerned, they don't need to know that that's a content fragment, it's just content in the page. And that fragment's been updated. If we publish the page, it's going to publish the page in the related fragment because standard publishing rules apply.
We can also go and do more complicated editing. So we can use the Properties panel. So again, if we select the Footer, open up the Properties Panel. We've got a list of fields there. And those have been automatically generated based on the content fragment model in AEM. So Universal Editor's able to pick up all of the fields there and just make them available to us for editing. As soon as we edit any of those fields, it's immediately writing that data back into the content fragment. And we can go and refresh it and look at it. Now I just will say, none of these are real addresses, so don't bother trying to follow me on the socials on those because I just made them up. If they do exist, it's someone else.
Next up is Page Components. So again, just like content fragments, we can do inline editing and properties panel editing. So we'll start off by going actually adding a new component to our page. So we're going to scroll up, open up the tree view on the right hand side and select our Container, and hit the plus button, we can then go and add a component. In this case, we're going to add a hero, and it appears in the list. And then we can rearrange them. We can just drag and drop them into different locations. We can scroll down to it. In fact, if you click them in the sidebar, it also scrolls to the component, takes you straight to it. And then we can just inline edit it. So we can put in a title.
And then we can go and actually say we're going to go open up the Properties panel. And we've got all of the other properties in here. So we can fill in a subtitle. We've got images and any other configurations that are specific to this component. The difference with this one, as we'll see a little bit later on, is, for the page components, it's using a model to define those fields rather than getting it directly from the content fragment model. And as we saw there, we're adding an image, pops up a dialog. As we'd normally see, just go and pick stuff from our DAM, directly integrated into AEM so we can go and pull our assets and select those.
So we saw adding items to a container. The other thing we can do is add components, child components of another component. In this case, we're going to add something to our featured designs. So in this case, you saw when we press the Add button, it only showed jewelry card as an option. So this is using what's called a filter to control which components could be added where. It's very similar to the policies you'd have in your editable templates. You can define at the component level to say this component, only jewelry card is a valid child of that. And actually jewelry card wasn't in the main container because it's not something you want to be able to place there. After that, it's just a component. As far as Universal Editor is concerned, it sees a new component been added to the page. It's now bringing up the authoring on there. We can go and configure all our fields, add an image to it, and we've immediately got a new item in our jewelry featured set.
Again, you can see we're opening up into our Assets View and selecting our image, and then the content reloads. The other thing we can do, obviously, is reorder it. So in this case, I want that one to appear a little bit higher, so we drag it slightly further up the list. And then, actually, if we do something wrong, for instance, maybe we try and drag it somewhere it's not allowed. Universal Editor takes care of that for us as well. It's not going to let us do that because the jewelry card component isn't allowed in our main container, so we just get a little error popping up at the bottom.
Now next up is Experience Fragments. This is something particularly in sites we tend to make a lot of use of for those reusable chunks of content that we want sets of teasers or pieces of text that want to appear across lots of places in the site, but we want to still edit them in an experienced way. We want to do the UI. And in the site's editor, it tends to be a bit disjointed because you place an experience fragment on a page, but then you have to go to the experience fragment editor to actually edit it. And you're not editing it fully in context. You're still in context of the experience fragment but not in the page. Now in Universal Editor, if you set it up the way I've got it set up here, as far as Universal Editor is concerned, there's an experience fragment on this page, but the experience fragment contains child components. Universal Editor doesn't differentiate the fact that they live somewhere else. They're marked up and they've got the right data on them, so Universal Editor can see there's an editable item there. And when we make those changes, it's actually saving the data into the experience fragment rather than the page and just directly editing it. So we have that true in context edit view. We can go and switch into a different page, and we can see the experience fragments there on the page. It's already updated. And again, when we do the publishing, it's going to pick up the fact, it's referencing experience fragment that's been modified, and that'll get published along with our page.
So we've looked at actually how we author content. We've seen the Properties panel. Now I want to just run through what the options we have for making those properties panel. So what fields can we configure? So this is essentially what you would have had in your AEM sites component dialogs. These are all the different field types we have. So first up is a set of AEM specific ones. So these are ones where we're referencing content from the CMS. So we've got things like tags. We've got the reference field, which is for assets. So we saw that where I was selecting images. We've got AEM Content, which is for links to other pages or piece of content within the site. And then we've got the Content Fragment and Experience Fragment reference fields, which allow us to pick those types of content and reference them in our components. And all of those then end up basically showing these picker dialogs, which are going to take you to the relevant location within the CMS, let you select whichever content. And you can also configure them to start at a particular location. So for instance if, for all of your assets, you always want to start within a particular folder, you can limit that and configure for that particular image picker.
Next up are the general content types. So these are things like your radio buttons, your checkboxes, dropdown lists, standard form fields that you might want to configure, and also things like date and time fields.
Next up, you've got your text fields. So basic text. You can also do validation on these. So if you want to turn it into like a phone number field or some specific format of data, you can apply formatting validation and then the properties panel won't let you save the data if it doesn't match the required format. You can also have number fields. You can set minimum and maximum, all those things. And then you've got the rich text editor. And this allows you to do your standard, essentially HTML content with styling, all those things and store that within your components.
Then last up are ones which are for grouping. So they don't actually store data themselves, but they're useful if you have a complicated component to be able to group together a set of fields that might have a similar purpose. So for instance, if it's a link or some subset of the properties that you want to group them together, you can either put them in a container, which is then collapsible, or you can put them in tabs so then you can switch between them. And you've also got the option to do some logic within your dialogs. For instance, if I turn on this Show Link option, we can make it so that the link text and the link itself, they're only shown in the properties panel if we need them. So therefore, it's much easier for the content authors then to know, I fill in the fields I can see. If I don't turn on the link, I don't have to give a link text, don't have to give a URL because they're not going to get used. And so it gives you that flexibility to build your panel and to make it as simple as possible for the content authors to know which properties they actually need to define.
So now we're going to look at, actually go, okay, how do we break down a component? We've got a design for a component. How do we break that down into fields and properties? It's essentially the same process we would have had if we were doing it for a site's dialog, but there's just some specific ways of working we need to think about when we're interacting with Universal Editor.
So here's an example of a component. I've broken it down. Obviously, these are just mapping directly to these base fields. So we've got a text field, a rich text field, and an image.
The biggest thing you have to be aware of and the biggest change between sites components and Universal Editor is the fact that, the Universal Editor expects a very flat data structure. So you don't get things like relative paths. So you can't have a piece of data stored as a child node within your component, right? So everything's stored at the top level. And you can have multi value fields. So you can see here the image field's got a little add button. If I enabled multi, you could have multi images, but they're just stored as an array, right? Just a list of values for that field and that then the component can interpret that however it wants to.
And the reason behind this is that flat structure really is necessary for the universal bit of Universal Editor, right? It needs to be consistent and simplified effectively so that then it can be backend diagnostic. But that is also the biggest change we have to make when we're thinking about how we actually define our components. So you basically-- This is what the big thing you can't do, right? This is an example from the core components, teaser. This is our call to action section. Where if you add a call to action, it's adding, essentially a complex multi field, where it's adding each time you add a piece of text, a checkbox, and a link. And those can be reordered and deleted. But that's actually quite a complex data structure because it's storing multiple pieces of data together and they've got to be reorganized together all those things. And so that isn't directly possible in Universal Editor, but you could do that with a custom field type. So if you had a very specific piece of data you want, you could build a custom field, store the data how you need to, but then that becomes very specific to your implementation. You potentially also then means that migrating, if you wanted to shift from one backend to another, it's going to be more complex. So the alternative to that is to make use of child components. So rather than thinking of the CTA as being part of the teaser itself, we think, well, the CTA can just be a button component, right? It's just another component that can live inside our parent component.
So any component as we saw before can be a container. So in this case, my hero here has a filter on it that says you can add CTAs to it. So we're just going to add a couple of CTAs and then they just appear in the list as editable components. As far as the UI is concerned, they're part of my hero. But as far as the editor is concerned, they're just child components. They sit underneath it. We can reorganize them. We can delete them. We can do whatever we want. And they're being stored within the CMS, essentially, as children of that component. But we're just breaking it down from authoring a component perspective to just separate it out.
The next option for that is rather than explicitly adding them as child components, you could do it where within the component itself, you have some configuration field. In this case, I've just got a number field, to say how many CTAs do I want. And then when I change that number to two, the frontend of my component is displaying two CTAs that are then editable items. Universal Editor just sees new components on the page and makes them editable for me. So this gives you-- If you've got a specific use case, for instance, if you've got different configurations for your component, you want to be able to say, okay, in this configuration it's always got to have one CTA. In a different configuration, it's always got three CTAs, but we can never have two. That's not something you'd be able to do by using the add method because there's always the possibility of content also is going to add two and then that doesn't meet your design. With this option, you could just have a dropdown list that says, okay, it's mode one or mode two, and that's going to define how many CTAs are going to get rendered. So it's up to you how you specifically implement it, but in the end, it's just a child component as far as the Universal Editor is concerned. It doesn't see any difference with the way we do that.
So we've looked at all of the functionality, how it works. Next up is, actually, let's think about what's the limitations of Universal Editor.
So the first one is no inheritance management. So this is a big issue for some people because the whole point of Universal Editor is to be universal. But things like multi site management and the way AEM does it is very AEM specific. And Universal Editor isn't targeting AEM as the only CMS. So multi-site management doesn't make sense to be a core function of Universal Editor itself. But you'll be glad to know that, actually, the Universal Editor team have released an extension for Universal Editor literally about a week and a half ago, which allows you to do multi-site management and inheritance management. So it's literally just a button that appears at the top. You can break or reinstate inheritance, and that basically brings that piece of functionality, that's very AEM specific into Universal Editor, and therefore means you can do that multilingual, multi-site management configuration within your Universal Editor setup.
The next one is no layout mode. This is actually common to a lot of the newer ways of doing things. For instance, Edge Delivery Services, we have the same thing, right? We no longer have editing where authors can go in and say, I want this component to be four columns wide on this breakpoint. I want it to be eight columns wide on that breakpoint, right? The UI essentially takes over control of that, and we can either completely hand over control to the frontend, like I did in my featured designs component. That component just defines that there will be three teasers on each row and desktop. There's going to be one on mobile. So the UI just controls it. Or you could have configurations, some like column control to say, actually, in this mode, I want to have one column. Now I want to have two columns in this section, that kind of thing. So again, you can effectively implement that just by defining the way your components work and working between the frontend and the backend to implement the relevant layouts that you need to build.
As we just touched on, we don't get any complex multi fields, but we know we can fix that by just using child components. And right now we saw the rich text editor. You don't have the ability to customize the rich text editor configuration. So you can't like you can in a site's dialog, you can say, "In this component, I only want to allow simple things like bold, italic and things like that, no links or no heading styles." That's not currently possible in the rich text editor, but I'm told by the Universal Editor team that within the next few months, they're doing some work there to make it, so we can actually apply a filter and configure those editors and make it more flexible.
So now we know how to use it, we're going to look at actually how does it work. So I'm going to go down into the architecture. I promise I won't go too deep. I am an architect, so I have to show you a three level diagram, right? So top of this, we've got our frontend. So this is where our web application actually lives, whether that's a headless app or headful, it doesn't matter. And it's also where Universal Editor's UI lives. In the middle layer, we've got APIs. So there's a Universal Editor service, which is the integration piece for Universal Editor itself. And then we've got whatever APIs our backend is exposing, whether that's rest APIs, it could just be HTML, it could be JSON, GraphQL, whatever. And then right down the bottom, we've got persistence. So this is where, in most of our cases right now is going to be AEM, right? But it could be some other backend, and that's just where we're going to store our data and it's actually going to get written.
So that brings a question like, just how universal is it, right? And that's where that architecture really comes in and why it's built-in this way.
So we have the Universal Editor at the top. What it's doing when you make a change is it's sending a standardized message from the Universal Editor to the Universal Editor service to say, change this piece of content in this location to this value. And that's all it's doing. Universal Editor Service's job then is to work out actually how to make that change in our backend. And what it does is it makes use of these backend plugins to understand how to translate between a change from the frontend into a backend change. So whether that's an edit in the JCR in AEM or it could be a commit on a database in some database backend. It could be a git commit or an edit to a Word document. It doesn't matter as far as the frontend is concerned. As long as we have a way to translate between the simple message from the frontend into the more complex backend specific message, we can make that change.
And this kind of is then, the flow that's going on. We've got our frontend HTML marked up with some special attributes to allow Universal Edits to understand what's editable, where the content's stored. It passes that to Universal Editor Service, uses the plugin to make the change, that updates our backend data store, and that's going to then send new data back to our frontend to re-render the website. And we just go around this loop continuously. And actually, every time you edit anything, it's making that change and every change is made immediately. So even when you go between fields in the properties dialog, each change you make is committed directly into the data store. So it isn't the case of when you click Okay on your dialog, it saves this literally every time you make a change in one of those things. So you don't have to confirm and commit your change in the dialog. Now this was originally only available on cloud service, as a lot of things are. But actually, the Universe Editor team, back in middle of last year, they built a backend plugin to spot AEM 6.5. And that's actually how we're able to use that in Riyadh Air because previously, it wasn't possibility for us. But now, actually, whatever version of AEM you're on, Universal Editor's there for you.
So we'll now drill even deeper into-- Actually okay, at the HTML level what are we doing? So there's three files that, actually, I used to configure the Universal Editor. We've got our component definition. So this tells it what components exist and what the structure of that component is when we add one to the page. So if we need to have template data, default values, those kind of things, that's where we define it in our component definition. We then have a filter definition, which controls essentially those rules about what components can be child of other components and all those kind of things. And then we have a model definition which defines these are the different properties of each of the components that we can place on the page. So when we open up the Properties panel, it knows how to render all of those fields. And those are just output into the page as script tags. Universal Editor loads those JSON files in and is able to configure itself.
And this is then actually right down in the HTML level. What does the component look like when it's marked up for Universal Editor? So the orange one at the top is the absolutely critical, right? This is data-aue-resource. This tells the system, this is where this data actually lives. And for this case, it's a content fragment. It's able to detect the fact there's a content fragment, and we don't need to give it the model. We don't need to tell it what the properties are because it can read that from the CMS. We do need to give it the prop and the type if we want to enable inline editing, so it knows actually which property of the fragment it's editing. And then the last one is, then pink is nice to have, nice for authors to give it a nice label. So that in the blue borders that appear, it'll actually give you a meaningful label rather than just the name of the property that's being edited. If we then go to a page component, it's pretty much identical. The only difference is, we have another mandatory thing, which is the model. So this is telling Universal Editor if someone selects this component and you show the properties dialog, use that model ID to look up the set of fields to populate the properties panel.
So next up is Extensibility. That's one of the lovely things about Universal Editor is that it's got a base set of functionality, which meets a lot of our needs. But actually, there's always going to be specific use cases where our business is different to everybody else's business and that we need to implement some custom piece of functionality. So we've got multiple extension points. I will just say these are all POC and non-production examples, but they give you an idea of the different ways in which you can kind of extend the UI. They're all just deployed as Adobe I/O applications, just little micro react apps that add a little piece of functionality and interact either with the Universal Editor, with our application or with some backend. So first up is the top rail. So I've got two things in here. One is a simple reload component. So this is actually demonstrating, sending events from the Universal Editor into our web app to tell it to do something. In this case, it's a simple reload, which is particularly useful for me because my frontend skills aren't so great. So sometimes I just need to force the page to reload itself. But you could also implement other things. Like, for instance, we have the MSM inheritance plugin. So this is a different version of this page, a live copy of it. You can see here it shows the inheritance is enabled. Go and edit the content. And that's actually just going to break the inheritance automatically because I edited the live copy. And you'll see the little button automatically updates to show the link is broken. If I want to reinstate that thing, actually my version of the content is no good. I'll go back to the original. Hit the button, re-enable the inheritance. And obviously, it's a dev system, so it's a bit slow. So I'm just going to hit the Reload button.
And when it reloads, we've got back to our source content. So we're able to very easily reestablish that inheritance pattern within our content.
Next up is custom field types. You might have spotted this actually when we were editing the CTAs. When we click on our CTAs and open up the Properties panel down, the bottom we've got this special field where it's a little edit button. This is actually showing all the Google materials icons. This is something that our frontend devs want to use because it's a great icon library, but it's a bit of a pain for content authors to be able to pick from because you can't see them. You need to know the exact name of the icon. You've got to go to the Google material site, copy and paste, and it's a painful setup. So what we've done is made it so that when you hit the Edit button, it pops up that dialog, it shows you every single possible icon, lets you search for them, see them for real, select the one you want, and it just writes that back into the thing. And as far as the data is concerned, it's just stored as text. So Universal Editor doesn't care about the fact that it's a special field. Our frontend component doesn't know that it's a special field. It's just receiving a text value for that icon ID.
And then finally, we can add entire custom side panels. So this is essentially how things like the properties panel and the tree view set up. I've built this thing I've called component X-ray. You click on a Component, hit the button, and it shows you some technical details about the component. This is just experimenting with, interacting with the Universal Editor's interface to actually retrieve information about the location and size of a component. If you want to make some custom editing functionality or be able to retrieve data out of the component itself and then make some specific functionality that you need for your specific use case.
Okay. So last up, we're going to talk a little bit about my journey with Universal Editor, right? How I ended up on stage here talking about it to you guys today. So obviously, I work for ecx.io, which is part of IBM, and I'm working with Riyadh Air. And we started off...
On our journey looking at the technology and architecture that we wanted to build out for the site.
From a delivery side, it's a Next.js web application to build, to deliver the transactional website.
And from an architecture perspective, they want to be headless, have that data available to other sources. And so we looked at-- Okay, we're on AEM 6.5, on managed services for complicated reasons. And that means we've basically got two options, Content Fragments or SPA Editor. Content fragments, the business don't like because they don't get WYSIWYG in context editing. SPA Editor, the devs hate because it's really painful to work with. It doesn't natively support Next.js. There's a whole load of customization we'd have to do there to do that. And so we were in bit of an impasse there. And then Adobe kind of came to the rescue, and they suggested, well, why don't you use Universal Editor? And we haven't actually even considered Universal Editor because obviously we're on 6.5, Universal Editor is only cloud. But they gave us a little hint that there was an early adopters program available that it was going to come to 6.5. It has now I think since January been in GA for 6.5 customers both on prem and on managed services. So I did a bit of a proof of concept. So I took then early stages Next.js web app, hacked it about a bit, inserted some code in there to make it so it could interact with AEM, retrieve content and render those components. And within about a week working with MAX and the team from the Universal Editor team, we had it up and running just to demonstrate, it's possible to take our existing web app with minimal changes and inject our AEM content into it and doing context editing in Universal Editor. And to be honest, I fell in love with it a little bit. It's what I wanted SPA Editor to be years ago. I've used SPA Editor so long ago and it's the dream of what I wanted that interaction to be like and it never quite lived up to it. And Universal Editor, I think, has won me over. And so we did that POC, we worked out, and then we were like, okay, we're onboard. We're going to go with it. We've been working with the Universal Editor team. There's a few little bits and bobs I've had to fix up, particularly to do with how things like loading assets and things out of the UI, which is slightly different because you're on 6.5 rather than cloud. But all of that has been resolved and now we've got a super clean, nice, simple integration. So let's summarize what we've been talking about.
So Universal Editor is essentially frontend technology agnostic. You don't have to be on a specific frontend technology. It could be headless. It could be headful. It could be something new that doesn't even exist yet. As long as it outputs HTML, Universal Editor can read that HTML and interpret the attributes we apply to it, and it's going to be able to make things editable. It's got a pluggable backend support. So AEM 6.5, Cloud supported now. In theory, any backend it could be supported. You can also have mixed backend. So you can have the same page with content coming from multiple different back-ends at the same time to render that final overall UI to end users. So you don't have to be switching between-- If you've got some custom backend system that's in Oracle or something that's providing one piece of data, you don't necessarily have to have the people go and edit that database. You could actually augment it so that Universal Editor can also edit that content.
We've got out-of-the-box support for WYSIWYG and inline editing, of our AEM content, whether you're on Cloud or 6.5, and obviously support for Edge delivery services. And obviously, as we looked at, it's nicely extensible. We can customize it to our own specific use case. And the main thing is to be aware of those simplified data structures. We have to slightly rethink the way we want to define and design our components. But actually, that's it. That can be a good thing as well just to think about, okay, how do we break down and structure things to take our UI and convert that into authorable things rather than having historically what we sometimes ended up with the dialog of death that's just got a hundreds of tabs and so many fields. Actually, we can break that down, force ourselves to simplify a little bit.
And obviously, Adobe are actively developing new features. So they are bringing extensions, they're bringing new functionality to Universal Editor itself. And it is the new primary editor and it's the recommended way forwards. And so I hope, to quote myself, that you'll feel Universal Editor is well on the way to living up to its name. And whether you're on headless, using content fragments, whatever your implementation, it's worth exploring and drilling in and getting to know it and add it as a tool in your bag. It might not be for the implementation that you're working. It might still be pure sites or pure content fragments, but it's worth being aware of it and having it there available to say, actually, in our next implementation, maybe we go with Universal Editor and give it a try. And so our key takeaways. Number one, there's no excuses anymore. We used to have the excuse, "Oh, I'm sorry. I'm on 6.5, I can't do that." That's not an excuse anymore. Definitely have a look at it. Give it a try. It's low complexity. As we saw, it's super simple to mark up a component. The devs will love it because they really don't have to add very much to their code. And you can just filter all of those attributes out at the CDM level or when you're exposing the content in production. And then you've got super clean content that doesn't have any of the authoring additional stuff around it that isn't necessary to render the page. And then it's really, really easy to try. The documentation on Experience League is really good. There's tutorials. There's worked examples showing you how to build it. Takes you both through if you're on cloud service, but also if you want to run it locally. So you can run a 6.5. You can run Universal Editor service locally. You get yourself up and running and just actually play around with it and try it out.
And so that is the end. And if there's any questions, obviously, there's links here to Experience League Documentation. And feel free to connect to me on LinkedIn. I'll also be down at the peer-to-peer booth later on if you've got any more detailed questions that we don't get time for here.
Thank you.
[Music]
