Next-Gen AEM Sites with Universal Editor

Hello everyone. My name is Nick Wittenberg and welcome to today’s session on Universal Editor. I was privileged enough to get to do some of the first work with Universal Editor in building new next gen AEM sites and I’m excited to share some of my learnings and give you a quick demo. We’re going to start by sharing a little bit about the overview of Edge Delivery Services and why we choose to use it. The challenges and objectives that we’re looking to solve and what our different content authoring options are. Next I’ll share some of my personal experience with Experience League. So Experience League, our learning resource for all of our DX customers, was our customer zero for using Universal Editor to build a new site. I’m going to share some of my experience there and some findings that we had along the way. I’ll take you through a quick demo of Universal Editor so you’ll see it live, you’ll see what it looks like to update some pages on Experience League and then we’ll talk about the value that you can expect to get from Edge Delivery Services. So first off, what is Edge Delivery Services and what are we looking to solve with it? Our digital experiences are opportunities and in order to capitalize on them, there’s a few things that we need to do really well. One is make our content discoverable. We have to attract our customers by making our content easy to find. A lot of users do not go past the first set of search results. I’m sure some of you can relate. So we need to be very high in SEO ranking in order to make our content discoverable. Next up is engagement. We need to retain our visitors by delivering fast, responsive experiences and eliminate as much bounce and exit from our experiences due to poor performance that we can. There’s a 100% increase in bounce rates after just a couple of seconds of delay on a page loading. So performance is becoming extremely important in engagement metrics as well as discoverability. Google is starting to rank pages by performance, especially the mobile experience. So hugely important that we get performance right. And lastly, conversion. Our visitors experiencing this optimized content must ultimately do what we want them to do on our site, whether that’s make a purchase or maybe your conversion metrics are a little bit different. And we’ll talk about some alternate ways of looking at this with Experience League where there’s nothing to purchase. But half of folks have left a site without converting because it was poorly curated, poorly done, and they just couldn’t take themselves all the way through the finish line. So these are things that we want to address anytime we’re building new content these days. Edge delivery built into the product speed and performance first. So we want a very high availability site with a very high cache ratio. We want to render the content in such a way that optimizes performance and user experience. We want to automate the testing of maintaining that high performance so that every code commit that we make is tested and validated that it’s not going to slow down our site and then proactively monitor and quickly resolve issues to maintain that high performance. So it’s really, I mean, the huge factor here is all about performance. There’s some operational benefits that we’ll talk about as well. But in terms of customer experience, Edge delivery services is built to address this first and foremost. Now in order to build experiences that way that deliver on that promise, there’s a couple of ways that we can author. When Edge delivery services first came out, the authoring scenario that was available to us is now called document-based authoring. Whether it’s in SharePoint or Google Drive or another repository, the authoring experience that originally went GA with Edge delivery services was very, very simple. You think of a Word document with some simple tables. That was your content management experience. And this has worked out really well for some folks. Teams that come from a headless content authoring experience into this, it makes a lot of sense for. But, of course, we have many AEM customers today that are used to a far more visual and in-context authoring experience. So to help those folks get the benefits of Edge delivery, we’ve developed Universal Editor. You’re going to use the AEM application that you’re familiar with. You’re going to open your pages and see in-context editing and a visual preview of everything you’re working on as you work on it. And content is stored in AEM where we retain much of our existing content governance capabilities that we’re used to having in AEM. All the while, we’re still producing that very high-performance site that engages well with customers and improves our time on site, our retention, our conversion. Next, we’re going to talk about our first attempt at building a site with Universal Editor with Experience League. They were our internal customer zero while we validated this approach. I led a team of developers across different skill sets and organizations with Adobe. We collaborated directly with AEM and engineering to bring this to life. And I want to share a little bit about what we learned. The first thing we gained out of this is we really went from worst to first in Lighthouse Score. We had low single-digit Lighthouse Scores on some mobile experiences on Experience League, including on the homepage, which has now been rebuilt in Universal Editor. And there’s a hundreds that you see across the bottom there are not faked. That’s a real screenshot from a real performance report. You’re not going to get that every time if you go check it yourself, but we can occasionally get straight 100s across the board on our Lighthouse Scores. And we’re usually in the mid 90s or above without any MarTech integrations factoring in. We’ve expanded the contributor model, which is a problem that we’re often solving with AEM sites. The previous way to contribute to Experience League, actually, it’s still there for documentation and tutorials. It was quite an expansive contributor model to begin with. We have lots of teams across Adobe that contribute to Experience League. And even you as an Adobe customer can contribute to Experience League. But it’s done so in Markdown files in GitHub that are a bit inaccessible for a marketer type of persona, someone with a non-technical skill set that just wants to work with content. It was a big draw for why we went and produced this word-based authoring in the first place. But for teams that are used to visual in-context authoring that AEM sites gives them or desire that as their approach, we were able to use Universal Editor to provide the best of both worlds. They now have a PM team and a marketing team that can directly contribute content to this new section of the site. They can do so with a very non-technical skill set where before they were just submitting a request for content and waiting on it to now being able to produce it themselves. And we did so with a nice visual experience that I’ll show you here in a moment. I mentioned earlier that there are some operational benefits aside from performance when it comes to edge delivery services. We had a much faster front-end development cycle than we would have with AEM sites. It’s easier to develop. There’s a lower barrier to entry in terms of skill set. And if you were to look at the front-end code, the block code of a Universal Editor page that we built versus a document-based authoring edge delivery service page, if you’re familiar with that original edge delivery use case at all, the block development remains the same. Our block code is very similar. You’re decorating blocks with very basic CSS and JavaScript. And you’re getting that benefit of faster development and lower barrier to entry that you would normally get with a document-based edge delivery project. But what you retain when compared to AEM sites is that you do have that application. The content is stored in AEM, in the JCR. And so you get all of the content governance benefits that you’re used to getting. And that could mean, for you, managing different regions and languages. It could mean having a better way of managing user groups and permissions. You have a direct connection to your asset management. So uploading an asset and then immediately using it visually, seeing what it’s going to look like on your page is all happening inside of that one application. And the list goes on. Most of the AEM sites’ content governance features are still available to us when we build a site with Universal Editor. How it’s delivered, how the front end is developed, has changed dramatically. But the content authoring experience is rather similar. So with that, I want to show you a little bit about Universal Editor. And I’ll take you on a firsthand walk through what it looks like to edit some of these new pages on Experience League. So I switched over to AEM sites. And for anybody that is familiar with AEM sites, this should look very familiar, right? The way that I browse and navigate and select the content that I might want to edit or post or publish in AEM, this experience is exactly the same. All of my options up here are the same. There’s nothing unique to this yet until I hit Edit. When I hit Edit, it’s going to open a new tab. And switching to that tab, you will see Universal Editor loading. So with Universal Editor enabled in your AEM sites environment, you get a different experience when you select that you want to edit a page. These are edge delivery blocks that have a properties panel on the right instead of a table in Word to provide your content. So for this marquee, I can do some really simple, intuitive to a marketing author persona types of updates. Here I’m browsing the assets. They live in the assets folders of this same AEM environment. So when I’m uploading new assets and want to use them immediately, I’m not moving between two systems. It’s all here. And I’ll select this hero banner image to change it out. And we see that update right away. Similarly, we have a list of approved background colors for the element behind the image. And rather than making those styles that would need to be applied somehow in the text of a table in document-based authoring, all I need to do is select from a pick list to make changes here. So these are the kinds of authoring interactions that’s expected out of AEM sites and in-context authoring in the page editor that Universal Editor replaces. The difference, though, is this is still an edge delivery block. So if you are familiar with what’s different about developing an edge delivery, the block and the decoration of that block, it’s all the same. The rest of these fields are pretty simple. I’ve got some plain text fields to edit the text that you see here. This particular block is all static content. We’ll talk a bit more about what it looks like to manage dynamic content. We have a rich text editor that will overlay and give you a few widgets. There’s not parity with everything that we do in AEM sites and the core components today, but there’s still plenty here to provide you with enough tools to build some of this simpler, high-performing content. And then I have some fields about the call-to-action buttons and how I want those buttons to appear. So a good example of a somewhat complex, static content block that has lots of options in this properties panel to configure it whichever way I like. Here we have a card block, and this is an example of where we are producing some dynamic content with our configuration in Universal Editor. So the text that you see up above, obviously I’ve got just the simple text fields for that. But this actually has a filter on it of what content types do I want to appear here as results. For visitors to this, if they select their role or they select the product they’re interested in, the cards change. And I can say, out of all of my available content types across Experience League, these are the ones that I want to populate here. To preview that, we’ll show off this preview option. It’s rid of the selection of blocks in AEM and shows you within Universal Editor what the visitors are going to experience. And now I come in here and say I am a business user of Analytics. And I’m getting something filtered down within the content types that I have selected here. So you can create a really dynamic experience. Something that comes up a lot when folks first learn about Edge Delivery Services is this looks great for static content, but I have a really dynamic site that I need to reproduce. There’s some really good opportunities for managing dynamic content here as well. Moving on down this page, you’ve got this teaser element. And this brings up another valuable, something that we’re used to doing in AEM sites that might appear different in Edge Delivery. Let me explain what I mean. Once we hear about the way the content is meant to be modeled in Edge Delivery Services, one of the common things that folks latch onto is the idea that we cannot have blocks within blocks. Blocks shouldn’t be nested. And we have a lot of folks that have built AEM sites experience before say, well, hold on, my content authors are constantly putting components within components. We do a lot of that. How would we replace that? One thing that we solved while building this was enabling an authoring experience that appears as nested elements, but still abides by the rules of Edge Delivery Services and a simple flat layer of blocks that are not nested within one another. For instance, in this section, I have a carousel and within that carousel, there’s another layer of the teasers that I can add. Here’s slide one in the carousel, which is a plain teaser. And here’s slide two in the carousel, which is a detailed teaser. These are two different blocks that are enabled as items within a thing called carousel. Carousel is not a block. It is a special type of section that only accepts these limited set of blocks. But we can present authors with the experience that they can nest things appropriately without breaking the rules of Edge Delivery Services. This I think is something that for folks that are migrating from AEM sites, common thing that we’ll want to understand and we’ll need to solve for. If I select the main section here, you’ll see a long list of blocks that are available to me. But if I select carousel, you’re only going to see those that are available within carousel. So we can also filter down the list of blocks that are available in certain contexts. There’s another example of that down towards the bottom of the page. This icon section here, each of these is a card inside of this icon block. And it’s one to many. I can continue to add as many of these as I want. I’ll get kind of a default on a new one. And away we go. So a one to many nested scenario of content is something that comes up pretty often when learning about Edge Delivery. And this is just to kind of demonstrate that we do in fact have a way to accomplish that while giving authors an intuitive experience. Another form of dynamic content, we actually built this sign up marquee to only appear to unauthenticated visitors. So if you have requirements like that, where depending on a certain state or another of a visitor, if you go to experienceleague.adobe.com and you’re authenticated already, you’re not going to see this block at the bottom of the homepage. If you sign out, you will. So we present it to authors at all times, but we can have it dynamic to visitors. So that’s a quick preview of what it looks like to edit the homepage of Experience League. And like I said, if you go to that homepage, you’re going to see something very similar to this. And this is what it looks like for the product manager and marketing teams that maintain this content to update it. Previously, this was a markdown file, same as any docs page and any updates to either the content or the UI went through a lengthy development process. Now they have the ability to come in here, edit these fields, quickly preview it and publish it. Another thing with regard to publishing that we often hear is the desire to maintain the AEM style of managing user groups and permissions, who can see what, who can edit what, who can publish what. You still get that same paradigm of security management, author governance, and this publish button can be dynamic. It doesn’t need to appear. It only appears to the user groups that you want it to. Before I step away again, there’s also a really nice responsive preview to everything. So if I want to see what this page is going to look like on tablet, in portrait, a nice little widget to do that. And you can see how your responsive behavior is looking across a bunch of different breakpoints. So I just, I really enjoyed that and how simple and quick and snappy it is to use compared to some of the previewing options that I’ve seen around some AEM sites. So that’s a quick overview of what we have available to us in Universal Editor. There’s one more point that I’ll make with a new page. Separate from the homepage, I’m going to go one further and show you that we can in fact produce pages with even more dynamic content as well as different layouts. So you saw a full width layout that was responsive. When I open this Browse All page for editing, switch to that tab quickly. And here I’ll demonstrate a couple of additional things. One is that we can have an entirely different page layout. The page that we saw before, the homepage has a white background and is full width. And here we’ve got this gray background with a navigation that takes us to different variants of this new browse experience. You can find this in the menu under featured products and browse all content. I’m actually on this page right now, the browse all content page. So if you go to Experience League and you want to know what are the pages built with Universal Editor, it’s the homepage and everything you find under featured products and under browse all. Those are the pages of Experience League that are built this way. Again, for the static content that’s on this page, I have the ability to just come in and maintain it via some simple properties here. I want to point your attention to this filter area. What this is going to do is replace the curated content down the page with results. And one thing that I want to demonstrate here is how dynamic and how we can utilize yet another part of AEM sites that we might not have managing our content in SharePoint. The topics buttons down below, as well as filtering all the results that I get, all happen by way of selecting tags that we’ve built in AEM. So all the results that might show on this page can be selected from a list of products. The products list is configured in AEM tags and authors just have a simple tag selector to use. So you can govern the metadata and the options that are available for configuring dynamic content, which is a pretty kind of an intermediate use case for AEM sites and everything that it can do to manage content. Similarly, the topics buttons are selected from an even broader set of tags. So I can come in here and look through across all the features that are part of Analytics, which of these buttons might I want to add to that experience. And to best demonstrate that, I will show it to you on the live Experience League site. One more switch here. We’re now looking at the published Experience League site. And on this Analytics page, again, I have lots of pre-populated content. This is really the same block over and over again, just being configured with those different options and different tags. And if I come in here and say I’m a developer interested in courses and tutorials, based on those filters and selections, I’m getting results that have replaced the pre-authored content on this page. So a really dynamic experience is looking across a broad content set and reacting to a visitor’s inputs. This is just really to show you that we can create a very dynamic experience and that Edge Delivery Services is good for all kinds of things beyond static content. One last thing I’ll mention back in AEM Sites is that Experience League is a multilingual global site. And we are using the out-of-box AEM translation framework, along with a connector to Adobe’s internal translation service, to produce this site in 12 languages. We chose not to do the full multi-site manager approach of languages into regions and localized variations. Experience League is one site in 12 languages. And so the same pages that you see under English, you’ll see with translated titles here under the other languages as well. But just a point to call out that with staying in AEM Sites, using Universal Editor and maintaining our AEM Sites content management capabilities, we can have the language translation framework available to us as well. So with that, we’ll now talk a bit more about the value that you can expect out of building a site with Edge Delivery Services. So what’s the value of Edge Delivery Services? Briefly alluded to this before, but just to elaborate a bit, we can really improve the development time, even when still standing up an AEM instance and using Universal Editor. Yes, it is more complex to set up initially than a document-based authoring project. There’s still an AEM application to maintain, but there’s a couple of things about it that are much different. The first is some of the separation of the content model from everything else. If we model our content according to the best practices in Edge Delivery, we can really isolate content, front-end development, design, and be agile with those and iterate on each of those separately, as opposed to what we often see with AEM Sites project, where everything kind of gets developed in more of a waterfall-style approach, where I start with a UX and a design, and then we develop some blocks and components, and then authors start to use that to populate content. They find the limits of it, they make enhancement requests, and that becomes the iteration cycle. But you still have this sort of design, develop, produce content, linear flow. With Edge Delivery services, you’re going to learn that you can actually break that up and iterate on each of those independently. We can also accelerate our whole development cycle here. A couple of things are at play here. One is I have simpler front-end development, like we mentioned earlier. There’s a lower skill set barrier to entry to build sites this way, to build your blocks and the front-end code this way. But in addition, that AEM environment that I mentioned, you still have to stand up and maintain. For Experience League, we rarely deploy that cloud manager pipeline. If you’re familiar with AEM Sites as a cloud service, or even managed services, and using the cloud manager pipeline, you know that running that pipeline and getting it to successfully execute and to pass unit tests and functional testing, that can be a timely process that a lot of teams’ biweekly or monthly cadence is built around and dependent on. We rarely deploy our AEM code. Most of the code that you see powering the Universal Editor-built Experience League pages is housed in an Edge delivery GitHub repo, just the same as a Docs-based project. The coding is not only simpler from a front-end development perspective, but deploying changes to your site is much faster and simpler to do. You still have all of that automated testing that Edge delivery gives you to maintain super high performance. In addition to all of the development benefits that we get, how do we bring this back to those original points that we made about how to improve our customer experiences, our discoverability, engagement, and conversion? Now, we have some real examples to share with you internally with Adobe, and I’m going to share with you how you can get some real-world customer examples as well. But for the purpose of this event, we can share a couple of things that we’ve learned through using Edge delivery services for adobe.com properties. As far as discoverability, when business.aw.com revamped their site on Edge delivery services, they saw a 19% improvement in SEO ranking. Engagement, which was the big one for Experience League. Experience League is not a retail site with a cart or anything to purchase. It’s all about engagement and whether folks are accessing their learning materials and spending more time with them. Engagement was the driving business value that we wanted to add to Experience League. Right out of the gate in the first few months of going live with this, this went live in March just before Adobe Summit. We’ve seen a 30% increase in time on page. That’s really one of the core metrics here. Are people spending more time learning from us? Are they spending more time watching our tutorial videos or taking our courses? This was huge. I think seeing a lift like 30% in any kind of large-scale web metric is pretty impressive. I’m really proud of what we were able to do on engagement for Experience League. Then conversion, like I said, with Experience League, there’s not something to buy or purchase. Engagement was the primary metric. Getting to those 95-plus Lighthouse scores means that anything that requires our visitors to go through a flow is well covered. They’re going to be able to get through it. They’re not going to bounce because something is taking too long or is too clunky. It’s going to happen quickly and easily. With that, thanks everyone. If you do want to see or hear some of these metrics coming from our real-world DX customers, there are some metrics we’ve been able to gather from our customers that they’re willing to share with other customers but that need to be shared under NDA. If you contact your Adobe account representative and say, hey, I want to learn more about what some of the real-world customers of Edge Delivery Services are getting out of their new and updated sites, I encourage you to do so. We do have some metrics from some of our earlier adopter customers that we can share with you. With that, we want to open this up to Q&A. I’m here to answer any questions that you may have. Thank you so much for attending. I hope you learned something today. Amazing. Thank you so much, Nick, for sharing. I’m excited to get in the Q&A, but welcome to the Skill Exchange. Yeah, thanks for having me. All right. We have a ton of amazing questions to get through, so we’re going to start with that. If you haven’t got your question already, please go ahead and drop that into the chat. We’re going to start with our first question from Eric, starting with what is the difference between AEM and Edge Delivery Service, and how can you get the best from both of those? That’s a great question. The Universal Editor approach is really the way that you get the best of both worlds. Edge Delivery Services is a brand new serverless way of delivering content that the classic AEM Sites application doesn’t do on its own. There are two ways to author Edge Delivery content, like we talked about early on. One way doesn’t involve the AEM application at all. You store your content in word processor documents, essentially. The Universal Editor setup is the way you get the best of both. You have a lot of the content governance, people and user group governance, asset management that you do in AEM assets and sites, but Universal Editor makes it so that the resulting site is super high performance, that really high performing serverless setup. The Universal Editor setup is the way that you get the best of both. Great. Okay. Next up, we have a question from Kevin. He’s asking, does Universal Editor utilize AEM editable templates and policies like the standard AEM Sites implementation? If not, do the blocks replace that standard structure of how pages are built? The short answer is not yet. It is under development by the product team to release editable templates as a feature of Universal Editor content coming in. I think it’s planned for later this year, by the end of the year. But it’s still in progress. But editable templates has at least been prioritized by that team. Sorry, can you repeat the second half of the question? Yes, I can. Standard sites implementation, if not, do the blocks replace that standard structure of how pages are built? Yeah, basically, the way you operate without editable templates using Universal Editor is you do, the very first page you create will start from a blank page, a blank canvas. You can create yourself templates using blocks, right? Create something that has five blocks that you sort of set aside as something that you want to copy, paste into a location where you want to produce new content, and then go modify it there. So there’s a manual management of sort of, you know, extra dummy pages, if you will, as templates. But that’s all going to be replaced by a true editable template experience here soon. Gotcha, okay. A short one here, will Edge Delivery help with image compression? Yeah, absolutely. So the idea with Edge Delivery is all that you ask your authors to do is provide one variation, the highest resolution variation of an image that you have. When content is published through Edge Delivery services, images get reformatted to the WebP format, which is really dynamic and does a good job of presenting at the right size and, you know, dimensions for whatever device or speed of a connection your visitor is going to your site on. Great. Okay, another question from Esther here on Universal Editor capabilities. Can you edit any page properties slash metadata in Universal Editor? Yes, you can. One point of clarification is there are actually two places to manage properties. So if you’re looking at the structure of your website in the Sites console, you haven’t actually entered into the editing experience yet. When you’re there and you hit properties like you normally would on any AEM page, the page properties experience there remains the same as it ever was, same as any other AEM page. What you saw me doing with page properties essentially in Universal Editor is actually a set of fields that are defined just like the block fields are defined. That’s defined in the Edge Delivery service code base. You can share fields between the two areas, so you can make a subset of fields available to Universal Editor that you want to have in that in-context, in-page experience, and then the full set of properties available when you go out and use the classic page properties panel.

Gotcha, thank you. That’s helpful. Keeping it rolling. What is the best method or workaround to replace any asset, image, or PDF and replace it everywhere automatically? The best method to do that is to use AEM as your dam. You’re going to be able to link two AEM dam assets from your authoring experience, whether that’s Universal Editor or talk-based, and changing an asset there at the source in the dam and publishing that is going to result in every page or experience that is referencing that asset being updated at once. Great, okay. That’s helpful. Another question from Eric. If we need to make sweeping design changes to our page templates, how easy of a process is this within Edge Delivery? I would say easier than AEM sites. That’s still a pretty big change that’s being proposed there, but one of the benefits of the Edge Delivery approach is it has a pretty clear separation between content design and your more interactive elements of your code. Also, the skill set part of Edge Delivery services, where it really doesn’t require extensive knowledge of custom frameworks, nor does it require extensive knowledge of AEM, the application, and what goes on behind the scenes there. If you can commit CSS and JavaScript changes to a GitHub repository, you’re enabled to change out the look and feel of an Edge Delivery site from a skill set perspective. It is pretty well decoupled from the content and the content model that drives the markup that gets produced by Edge Delivery services. I probably can’t give an answer there that satisfies an actual front-end developer. It would take a little more diving in to understand what that looks like, but easier than AEM sites for certain. Cool, okay. These next two questions, I think maybe they go hand in hand. I think they’re two on setting up Universal Editor and Edge Delivery. I’ll start with Karen’s question. How extensive is the setup process to use Universal Editor if you’re on 6.5, and is it only available in certain versions? Yeah, right now, Universal Editor is only available to AEM as a cloud service. I don’t know if there is any planned release for Universal Editor for AEM 6.5. That’s something that we’d have to go find out from our product teams, if there’s a plan or a roadmap for that. But right now, it’s only available to AEM as cloud service. It is pretty simple to turn on and get available from, you can just make a request from your experience in experiencecloud.adobe.com. But yeah, you need an AEM as a cloud service instance to pair it with. Gotcha, okay. Thank you for the question, Karen. That’s a good question for us to take back to, like Nick said, to our product team. Yeah, and also following up from that, does Edge Delivery require only front-end development, or are we required custom development also to enable it? Yeah, that’s a really good question. You need to do some work in AEM, the application, in order to stand up a site that is built with Universal Editor. But it is a fraction of the work involved in setting up an AEM sites project. The only thing that’s actually stored in AEM, in the JCR, if that’s a term that’s familiar to you, is the content and any customizations that you do, like workflows that are being executed by the AEM application. All of your block code lives in the GitHub repository part of the setup. All of your front-end code lives there. If you want to build something interactive, like a form or a quiz, all that code is just going in as JavaScript to a GitHub repo. You can deploy that without running your AEM Cloud Manager programs. It is much simpler, and the custom development that you do is largely based outside of the AEM application and the AEM JCR. You have a more accessible way of doing that with a simpler skill set. Gotcha. Great. All righty. Next question here. Can we migrate the existing templates to Edge Delivery Services, sorry, EDS support page templates? Can we migrate existing templates to Edge Delivery support page templates? I’m not sure what Edge Delivery support page templates is intended to mean, but the process of migrating to Edge Delivery is usually a pretty significant change. It’s a migration as if you were changing CMSs. The way that we do things is there is an automated script that is an outside-in looking script, so something can look at a published website and basically gather up all the pages that are there, format that into Edge Delivery compatible markup, and then you can go in and start to edit that with the blocks that you build, but you do need to go and create your blocks and decorate them to look like the site you used to look before. Migrating to Edge Delivery, even if you have an existing AEM site, is still a migration effort. There is not a button that just sort of converts an existing AEM site to an Edge Delivery site. There’s some work involved in migrating. Okay. Thank you. That’s helpful. Another question from Eric here. How could we do a mass upload of our blog content on AEM slash Edge Delivery? For further context, Nick, they have all the code on a spreadsheet with around 800 pages that they would like to bring over. So is that something that’s doable? Yeah. 800 pages is a relatively small number of what that automated content import process that I described can handle. We put sites out with a couple hundred thousand pages in a relatively short amount of time using Edge Delivery services. So yeah, that sort of idea of mass upload, taking advantage of a spreadsheet that kind of has maps and things out for us is something that we can do pretty easily. 800 is a very manageable number. Right. Alrighty. Last question. If I am updating page properties and not any content on the page, is it possible to roll out just properties without impacting the page? Yeah, absolutely. Whether you choose to do that in the page panel that’s available in Universal Editor or whether you choose to do it using the classic page properties panel, if that’s the only place that you go to make a change and you hit publish, you’re not going to have affected any of the content on the page. It is isolated from the content that sits inside of blocks, regardless of which editing experience you use to update it. Perfect. Okay. I see a couple more here. The first one is can you still manage access and permissions the same as before? So before using Universal Editor. Yeah. So that’s one of the benefits you get and why it is a best of both worlds kind of setup. If you’re using Edge Delivery Services and using the document-based methodology of authoring, whether you choose Google Drive or most commonly in the enterprise, SharePoint as the place to house your content, that is the space where you’re going to manage access. So one of the things that you give up with document-based authoring is having the AEM way of managing users and groups, which for folks that are already building AEM sites can feel like giving something up that they’re already kind of well-versed and already have a setup for. When we build content using Universal Editor, it is saved in the AEM JCR and we do user groups and security and governance on who can access what and permissions the exact same way that we do it with AEM sites. So I mean, it’s in AEM, right? And so if you’re used to going into the admin console, configuring profiles, going over to AEM and setting what permissions are available to folks with those admin console profiles, if you’re already doing kind of enterprise security management in AEM sites, when you build a site with Universal Editor, all of that will remain exactly the same. In fact, you could continue to use the same groups you already have set up if it’s a cloud service instance that you’ve enabled Universal Editor on. Great. And I think we have time for one more question. So I’ll ask this last one from Kevin here. Nick, do you know, does edge delivery have a translations adapter support like AEM sites does using the Global Link API as an example? So when you’re doing document-based edge delivery, we’re a little more early on in what’s out of the box, so to speak, with translation capabilities. But when building a site with Universal Editor, you can use the exact same translation framework that you’ve always used. So if you work with a translation provider that has one of those plugins to the AEM translation framework, you can run it through that exact same thing. And in fact, that’s what we did for Experience League. We have an internal translation provider internal to Adobe, but they had one of those packages to make it work with the AEM translation framework. We installed that, and the content that we built for Experience League in Universal Editor was sent through and translated into 11 more languages using the same AEM sites translation framework that we always use. Great. Amazing. And perfect. That puts us right at time. So thank you so much, Nick, for your session, the action-packed Q&A, and sharing more about how Adobe’s Universal Editor and that use case with Experience League. Yeah, of course. It was my pleasure. Thanks so much for having me.