[Music] [Martin Buergi] Welcome everyone. Welcome to Accelerating CMS projects with Edge Delivery Service.

My name is Martin Buergi, I'm a Product Manager for AEM Sites. And with me is my co-speaker Pauline Huynh, Senior Product Marketing Manager, also part of the AEM Sites team. And before we get into the session content, we noticed in the registration list that we have a lot of developers in the audience. And so the developers that never worked with Edge Delivery Service, quickly raise hands? Okay. We have a few and we have a great idea for you. We believe Edge Delivery Service is so simple, that if you start the tutorial, you have your first web page up and running in the next 30 minutes and still paying attention to the awesome content we deliver. So if you overcame, here's the link that you need to go to aem.live/developer/tutorial, and it would be amazing to get some feedback at the end of the session. And with that I would say, Pauline, why don't we have a quick look at the poll you just filled out? [Pauline Huynh] Okay. Wow. All right. I can see the results. Okay. So it looks like many of you are kind of, all top three choices, business outcomes, development cycle, and content creation, which makes sense because you are in a session about CMS projects, about all these things. So you're in the right session. So we're going to dive a little bit into Edge Delivery. But first, I want to talk a little bit about what I like to do in my free time. It's not writing convertible. It's watching movies. And so whether it's in a movie theater with surround sound or at home in my sweatpants, on my couch, I really love watching movies to relax. And last year, there were quite a few highly anticipated movies that came out. So one is illustrated here. Can you guys kind of guess what this is, representing at least? [Man] It's not Oppenheimer. Or is it? It might be Oppenheimer. Yeah, it's Barbie. Barbie and Ken, that's us, in a different version. But no, Barbie was one of the top movies last year. You could not get away from it whether you hated it, loved it, didn't care about it, we're forced to go because your kids dragged you. It was the biggest blockbuster. You might be wondering, what the heck does Barbie have to do with my CMS project? Well, if you really think about it, when it comes down to it, movies really matter-- Two things really matter for movies. One is speed and agility. And so that's how fast can I get my movie to market? How efficient can I be in building, filming, creating all these movies? And then once you get there, what business outcomes am I going to drive? How much is it going to make in the box office? How much revenue am I going to drive? And fun fact, Barbie actually made $1 billion in 17 days. So that's a crazy number. So imagine if your website could drive $1 billion in 17 days, you all would probably not be here and probably be on an island somewhere, but here we are. And so that's exactly what a CMS project is. It's agility. How do I ensure that I can get to market quickly? How can I get my website up and running and be really efficient in doing so? And at the same time, how do I drive more business outcomes from it? Because you're not doing it just for the sake of doing it. You're not getting it out there just to have it out there. You want it to be working for your brand. And this is exactly what Edge Delivery is all about. Quick question. How many of you are familiar or heard about Edge Delivery whether in the past or maybe during the conference? Any show of hands? Okay. Okay. That's great. That's pretty good. That was more than I expected. But, yeah, so Edge Delivery is hyper focused on business outcomes. That means traffic, conversion, engagement, revenue. And at the same time, we're not compromising on agility. That means speeding up content creation, speeding up development cycles. And how we do that is by focusing on these four key parts of a CMS project. So site performance, experimentation, content creation, and development. And over the last year, we've actually launched this last year and we've worked on over 300 live websites, and we've been delivering seven million web pages and 130,000 experiments weekly. And this is across many different use cases and customers, sizes, industries, which we will share a little bit more about today. But basically, across all these projects, we've gained a lot of insights and learnings that we wanted to share with you today, so that you can effectively accelerate your CMS project and get to those business outcomes faster.

And so these learnings we're going to cover is really performance-first foundation drives business outcomes. You'll hear that a little bit frequently when we talk about Edge Delivery. Second is built-in experimentation makes continuous optimization a breeze. And last, authoring autonomy and modern development unlocks agility. And underlying all that, of course, is our favorite topic, GenAI. And so first let's dive into Site Performance. This is a key aspect of every website, so that's kind of why I want to start with it. And what I want to first start with is, imagine you're going to a movie theater. Maybe after bash or something, you want to go see a midnight movie and maybe you want to go see Dune 2. I'd imagine you probably are going to a theater that is easy to find, it's discoverable, maybe it's the one nearest to you that shows up on Google search. And then once you get there, if you are given some crappy movie experience, you'd probably get up and leave if this is the entire movie, and possibly even final alternative options. So there are two key points here. One, discoverability is really important. And that's why we care so much about SEO. And I say that because 75% of users don't even go past the first page. And that's a crazy metric, right? And not surprising because I'd imagine all of you are not going to page 10 for every topic. But that's why we focus on performance because it's so important that you're optimizing your performance with green Core Web Vitals and 100 Google Lighthouse score because my tiger mom at least wouldn't settle for anything below 100, maybe 98, but definitely not 50. And you shouldn't either. And so that's why you want to optimize for these performance metrics, especially Core Web Vitals because it's an official key ranking factor in search results. And second, like I said, the user experience is really important because once they get there, you want to make sure you're delivering a great experience, so they stay engage and convert. And so what we saw, whatever. - I'll just stand here. - I'll stay here. Okay. And so what we've seen across customers and projects is, this is exactly the case. Once they've optimized for performance, they are rewarded with more traffic, better SEO results. And so HanesBrands here with their Maidenform site, which you may have heard in their session yesterday. They saw two times global organic monthly traffic. And a B2B company, BambooHR, they saw three times global organic monthly traffic. And this is from, of course, performance. But you might be wondering, so is it driving conversion? Yes, it is. So here life sciences companies at Danaher, they saw three times boost in organic monthly traffic. And with that, two to four times weekly leads created. Since they are a B2B business, this is what really key for their website. And so they are seeing great rewards from optimizing for performance. So you might think, okay, this is super obvious. Performance is impacting. Why isn't everyone doing it, Martin? Yeah. It's a great question, Pauline. And interesting fact, compared to two years ago, most of our customers have now web performance on their radar and they even define that as a key success metric for their web pages. And so why is it difficult? And I'm trying to explain that to you. Let's assume-- And what I've seen. And let's assume I'm a developer and have to build a new website. And now, Pauline, I need quickly you holding my microphone because, so I'm the developer and let's just say this is the bandwidth of my web performance. Let's say this one here is Lighthouse score zero, meaning I drink a coffee before my website is ready. Here we have Lighthouse score 100, super blazing, lightning fast. Now I pick a starting point for my project that is not optimized for performance. It means I don't start with a Lighthouse score 100. Maybe I start just with an 80. And not because I have a deadline, we all know deadlines. I focus on features and functionality development. Performance, yeah, something for later. But performance slowly goes down. And once I get into the complex well known performance killers, the ones you see here that come with a lot of JavaScript blocking time and chattiness, I might end up somewhere at the end of the project with a Lighthouse score around 30 and 40, which is actually kind of the average what we see on the internet today. And what do I do now as a developer? I try to bring my Lighthouse score back up. And based on my skill set and experience, I might get to a 50 and 60. But we rarely see web pages going to a Lighthouse score 95 and 100 where we would like to have them to get rewarded by Google and the customers. And I just want to make sure before we go to that slide, I want to make sure--. We're not-- I don't blame developers. I'm just saying it's difficult and complex to build fast web pages if the tools are not optimized for performance. That's really key. And that's also why we said we need to change that. And we need to productize speed by providing a performance first architecture with the Edge Delivery Service that help our customers to build fast web pages in a simple and guided way.

And maybe some of you will ask now if it's just another CDN. Well, a CDN is not a guarantee for a fast web page or a fast website. We see ourselves more as a co-pilot for your CDN that follows specific patterns and rules. Let me give you some of the highlights. High availability. We push all the elements of a web page to the edge of the internet to your CDN, making it super-fast available. And the separation of concern that we have with Edge Delivery Service allows us to cache these elements almost indefinitely. Next one is we have a very opinionated way how we render and deliver web pages experiences to the end users, so that they get the delightful and fast experience even if you have all the Martech stack and experimentation personalization on your website. So with Edge Delivery Service, we basically tell developers how to integrate these things because we spend years figuring out how to make it work. So we take the guessing out of your daily work.

But we also want to make sure that your website is not just fast on day one and later it drops. So we'll help developers by doing automated testing for all the code change, so that they can identify if a code change suddenly leads to a degradation. And the last one here, I think this is a really big one because there are so many things that could still have an impact on your experience. So we'll take care of the whole monitoring for you because we want developers to focus on innovation that will lead to more engagement and conversion. To give you a few examples, we monitor all your web pages for core web vitals. If you suddenly see that there's a degradation, we'll inform you. Or, a very famous part is, are the broken links. It's incredible to see how many broken links suddenly appear. We'll detect them for you. We'll tell them you should fix them. And it's also an area we heavily invest, also with AI detection because it's important that you get a great experience for your end customer. And you, again, can focus on innovation. And so I would like to end this section showing you three customers that moved their site to Edge Delivery Service. And what you see here are the core web vitals over the past 12 months. And it's not difficult to really see where we went live on Edge Delivery Service with the site. And that's the moment where Google rewarded then the website with the fast performance. Okay. Awesome. Thanks, Martin. So first, now we know performance is a key strategy for optimization. It's not just a nice to have these days. We can make it a must have. So, of course, now you have a performance first foundation right from the get-go, but it's still a website. You still need content. So how do we actually accelerate content creation? And how do we enable content authors? What we learned is that, we really need to empower content authors. You need to enable authoring autonomy, so that they're not relying on developers or anyone else for every single little update. And that's why that, we want to simplify authoring by enabling them to work in their preferred tools, how they prefer to work, what fits best in their workflows. And so this flexibility is really important, why we made it so that edge delivery can enable authors to use AEM authoring or document-based authoring.

And so what are those tools? And so you may know already AEM authoring. But for those of you who are maybe new customers and are unfamiliar, that's basically our WYSIWYG in context editing with AEM governance and workflows, all that good stuff. And then we have Document-Based Authoring, which we introduced last year. Now this is allowing authors to create using Microsoft Word or Google Docs. I know that sounds crazy, but we learned talking to a lot of content authors that they already start their content creation process in Word documents or in Google Docs. So for me, I can make updates to a .com for the AEM sites page, I actually start in Word docs. And so we wanted to streamline that workflow and really enable them to create, edit, review, publish right within the source documents themselves. Now I know what you're thinking. That sounds crazy. Why the heck-- How am I going to manage a whole enterprise site from a SharePoint? - Can you really do that, Martin? - Yeah. And I have a couple of likes, examples I want to show you, so that you see there's not just a set of limited use cases where word authoring works great. So let me switch here to my browser. And I would like to start with our own website here, Adobe Express, as an example because I think it's a great example of a very immersive experience. A lot is happening. So we have a carousel here, we have a column layout here. We even have kind of commerce elements where you can buy products on it. And it's all personalized. And as it is, oh, Adobe, we have plenty of localization as well. And probably you wouldn't believe it, but the whole website is managed in SharePoint here.

But often I hear from customers that, I, when I'm creating content, I need to actually pull images from a DAM. I know AEM authoring has a native DAM. How does that work with document-based authoring? Yeah. Let me-- Branding will kill me if I pull something from Google. Yeah. Let me show that. And I have here my weekend demo page. I'm here on a PDP page. And let me now author that page and use. Let's say, that hero image I want to replace that with another image I have in my AEM asset. And so if you've never seen word authoring before, I have here this-- Thank you. This nice Chrome extension, we call it Sidekick. So if I click on it, I have now full control of everything. So I can switch easily between preview live environment. I see when the live, that page was edited, previewed, and published. But let's go to the underlying document. I simply click on Edit. It will now open up here my document. Maybe you see we use Google Drive, Google Docs, and not SharePoint. But it's basically the same. So here's the title of the page. And I have my blog with the hero image. So let me change that now. And what I can do is, I click here on Assets Library. I have access to all the different assets here, repository. Let's just say I go with this skater. I know it doesn't make sense, but let's just go with it. So I clicked on it. It's now in part of my clipboard. I go here. I just paste it in. It's done. I don't have to care about image size, nothing. This is then all handled by Edge Delivery. Okay. So even I, just a little marketer can do this. That sounds great. But what if I need to integrate with third-party tools? Yeah. Which I hear comes up often talking to customers. Yeah. Great examples and I picked the PDP because we also introduced the Adobe Commerce Storefront and the Edge Delivery Service, and I want to show you how I would now integrate product data on that page. And let's say it's a page about climbing, and we should try cross selling some products to people that are-- I think I can keep it for demo. So we have extended the Sidekick here with the commerce integration. So if I click on that one, I have now access to the real-time product catalog here. And under equipment, I think we have something hikers could use, these nice hiking poles. And here I have a couple of experiences available. I go with the product teaser. So, and then I copy this one here. Just go and embed it. It's done. And as you can see, I just stored the SKU. I also have a couple of configuration options. It's not complicated. You already understand how that concept works. So what I have to do now is, I just go on preview. And what it will do now is that, product teaser component will call the commerce APIs and get the real-time product data. So first we have here this new image and down here that nice product teaser. Okay. Awesome. So I saw when you pulled in the commerce block, it populated the table from you. But what if I wanted to pull in some regular block like an additional button, teaser? Do I have to remember all the titles and create the table myself? No, absolutely not. So we have also this block library, which many authors use. It's an ISO review of all the blocks you have available. Here's a banner, for example. You click on it. And you can look at it how it would look on the different display sizes or if you have different variations. I nicely see them. So what I do is then just taking here a copy, going back, and then just paste it in. - It's pretty simple straightforward. - Okay. So as a content author, I can create content right in my document. I don't need to go and send it to somebody, translate it into another tool. That's great because my copy and pasting is not always as fast. - But how fast is it? - Yeah. So Sunstar is a customer that moved to document-based authoring. And I think the key results speak for itself. So launching a new campaign, landing page took them three weeks. And just by moving to document-based authoring, they're around two days now. Also, content updates. Even if you have, like, all approval workflows, it's updating a Word document. It's easy. And that's why also training new authorizations is pretty faster or pretty easy. Okay. Awesome. So that covers the content creation part. But, of course, we also want to make sure that we are refining and iterating. After creating, we hear that often content authors want to make sure that they're delivering meaningful content that resonates with their visitors. And that's where experimentation comes in. And experimentation, obviously, is a very well-known optimization strategy, but we often hear that it's not easy to do often because of, they don't have the tooling or there's not integration. But it starts with and it's common across many customers that we hear is that, they need to build a culture of experimentation. And this is something that is more of a change management process, something that is more cultural. And when I say culture, I mean a continuous process. That means that you're constantly creating and testing new hypotheses, you're measuring it, you're refining it, continue to iterate and repeating that cycle over and over, so that you can get to that winning content. And across all our projects where our customers are working on, doing experiments, what has worked really well is, first, they need to create so much content to support testing efforts, right? How are they going to do that if they only have a few content authors on their team? Well, they are utilizing the GenAI features that we offer now to actually help scale that content creation, so that they can do all this testing. Second, once they've already created the content, now they're actually running multiple experiments at the same time. So it's simultaneously in parallel. They're not running just one a month or something like that. That way, they can actually identify winning strategies much faster. And last, we get a question of how long should I be running experiments for? We found that the sweet spot is between two to three weeks with Edge Delivery because, one, you get statistical significance, and second, you can immediately eliminate performance as a potential impact because there's no performance degradation with experimentation in Edge Delivery because of the performance piece that we talked about earlier. And we took all these learnings and how we're enabling this continuous process, continuous optimization is really building it within the product. And so now we have built-in experimentation and GenAI, so that you can easily optimize. And so first, like I said, content authors can instantly create audience specific brand aware image and copy variations to feed into their testing and experimentation process and then it's super easy to set up. Like, even I can do it and I can do it. And Martin will show you, but essentially, there are no other tools required. There's no other tool they need to learn. Developer doesn't have to come in and integrate something. It's all built-in, done in minutes. And, of course, privacy-first and performant. Like I said, no performance degradation, but also no option is required to do testing. So super important because sometimes your content author just wants to do a quick test on what banner it works better, what image is driving more engagement, etcetera. And last, analytics. This can sometimes be a sticking point. And how we made it super easy is we're democratizing it. So the results, the insights, that's available in browser for the author. Again, no other tooling, so they continue to iterate.

Now, Martin, I want to set up an experiment, but I need to create content. Can you help me here with GenAI? Absolutely. And this time I'm going to use WYSIWYG to show you that. We also work with different authoring tools. And I'm using here Experience League. I hope you know Experience League. That's the website where you find all the documentation to our experience cloud, products. And they use WYSIWYG for the landing pages here for the marketing pages. So I go here to AEM as a cloud service author instance. I got a copy here of the Experience League. And if you know AEM already, this looks pretty familiar to you. So it's the same. But if I click on Edit, it will now open up the new universal editor, which we also create here at Summit. If you have not seen Universal Editor, it's just a modern WYSIWYG editor. So what you can see is. If I go here through the different elements, I can now mark them, click them, and in context editing pretty quickly. Even here for the button text, just go here, change the text. Or let's say I select that whole block. I have then also my configuration dialogue on the right side, if I want to switch here the alignment of the image, it's pretty self-explanatory. But let's go back to the task Pauline gave me. So let's say I'm not very happy here with that whole text here, but I'm not the smartest person. It takes me hours to personalize that content and that's where GenAI comes in. And thanks to the extension concept of Universal Editor, we were able to integrate GenAI here. I simply click on that link. It will open up the user interface where you already have prepared enterprise ready prompts for GenAI. I'm going to use here for the demo, Beat the Buzzer prompt because there's some extra things, I can show you with. So it's then kind of working like a GenAI. So you fill out the strategy. You can even provide the content example that I had before. But interestingly here for Beat the Buzzer, we integrated target audiences. So let's say my text should work better for the younger generation, just the TikToker social media generation. So I can select this one here. And now if I click on Generate, what it will do is, it will take the strategy, the example, and will take the description from the audience. And based on that, I will get then back a couple of variations. Let's just here we go. We have two. And now I can simply copy that and paste it back here into my universal editor. So it really accelerates the whole content creation. But we also discussed experimentation. So that's another extension we have for Universal Editor. Let's really say we want do an AB test for this landing page. Now we should set the timer and I'll show you how quick that is. I click here on this extension. This will load now my experimentation screen. I could give it a name. I could even select kind of like a start and end date. But let's just add a challenger. And I could add as many as I want. But let's just go with a regular AB test. So I'll save that one here. Now the test is ready. I have a copy of my web page. Let me go to the challenger and say we want to try how it would look like if I have here a different image. So I just double click the image. It will open up the asset selector. And if I go here, I have here this different person. I select that. And now if I go back, see? I already created my easy low-cost AB test. The only thing I have to do is I click on Publish. That was one minute. Oh, I just have to press one more button. So now the test is published and running. Now let me go over here. That's the site. That's the Edge Delivery site where we have published the content from AEM. And if I refresh now that page, and as you can see here, I'm in the staging environment. I get here this small dialogue where I have an easy way to switch between the variations for me to preview it. But also and we see here 50, even split. But also if we have collected enough data for that experiment, we'll show you here the data, the clicks, and the conversion. So after two, three weeks you get enough data to decide if you have a winner. And if you have the winner, you go back here to this experimentation dialogue. You click on delete. And then you can either promote the challenge if it was more successful or keep here than the original page. That's kind of how we do it. So to summarize, I did not have to talk to kind of anyone else. I was just able to do that on my own. And because it's that fast, I would like to show you a customer example of BambooHR. So they really incorporate that new experimentation culture. And what they do is they run up to five concurrent experiences. And the way they do that is they create quickly a hypothesis. They create the content. They let it run. And hopefully, you can see we have zoomed in a little bit on the results. So for that free trial booking tool, what they see is, first of all more clicks. But here, the SAO sales approved orders went up 29%. For this other tool experiment, they have 50 more sales approved orders. So it's really a fast and easy way just to test a small hypothesis. If it leads to more engagement and conversion, you won. Okay. So we talked a lot about content authors and how we're really accelerating not only content creation, but how can they get to that winning content faster with experimentation. But of course, in parallel, we also need developers to build. And many of you here are developers, so I'm going to talk a little bit about that. And I know you often have technical questions, so please just wait and then we'll answer them. But how are we actually going to be accelerating development? We hear often my development cycles are too long. It takes me months to create a new landing page, create some update. What we realized is that we really needed to modernize the developer experience, so that you could build quickly. And how we're doing that is, a few things. One, it's really easy to learn. So standard tools and frameworks. All you need is JavaScript to get started and we use tools like GitHub. So that means auto created preview environments for any code changes, really streamlining the development process. Second, it's really easy to get started. So we provide a few out of the box tools for you to jump start development. So first is the boilerplate template, which many of you, if you checked out the tutorial are familiar with. But essentially it is already a pre optimized template in a sense, a code foundation, so that you can start with a high performing website because it's really hard to work your way up to a 100 once you're at zero like Martin said earlier. But if you start at a 100, it's easier to maintain. It's kind of like a grade in school where if you start with an A plus, it's much easier to maintain than starting with an F.

And last, second, we also have the out-of-the-box block collections for common blocks like, you saw button, hero, all that carousel. A lot of that we already have, so you can jump-start your development process with those blocks rather than start from scratch. And one that's really cool and I've heard a lot of customers talk about when they do a CMS project, there's often a migration involved. And that migration and I know it's a very painful word, but how we're accelerating that process is with the content importer tool. And so that's helping automate the migration process, so that it's much faster. And last, of course, we know that every CMS project is different, every website is different. And so we want to make sure that you have access to the support and expert help that you need to ensure your implementation is implemented with best practices in mind. So we have a product collaboration channel where you have direct access to Adobe experts from product engineering, much smarter people than me, who will answer any questions, provide tips, best practices to ensure success.

And so how much faster is this developer experience, though? It sounds like cool, but it actually is really fast. So we're talking about in weeks. And so for one, the channel company who spoke yesterday in a session, they actually migrated just a few pages, just a few 200,000 pages in 8 weeks, which is insane because that would have taken them, they said, at least 6 months, typically. And then with Volvo, you saw that very immersive, very interactive, rich media website. They migrated over seven pages in four weeks. So super-fast development, very quick with using all those developer tools that I talked about before. So, Martin, often development starts with blocks. And say I want to develop a block, how would that work? Yes. Let me show you.

So, Pauline-- Martin? What kind of block do we need? I want a quote because I'm trying to show some proof points on my website. - So you need quotes? - Yes. Correct. So in the old days, I would now go to the developer and tell my developer I need a good-looking quote component. Then I wait for the development, and I can then get the component and can play with it, give feedback. Now here we have a slightly optimized approach we recommend. We call it also content first. That means before I even go to my developer, I'll first create the content. And so I'm here again on my weekend demo web page. I'm in a draft folder where I have created here this empty document. So let's create a block together. And what we know, a block is nothing else than a simple table. So I'll start here with a table. And I give that block a name, quote. So I think we need a quote. So, Pauline, any historic relevant quote? Oh, super historic. - I'm Just Ken. - Okay. Let's go with I'm Just Ken and we probably also need an author here and because I want to render that author slightly different, I'll put it here on the second line here. Who said that? - Ken. - Okay, Ken. Good. See, so I created now the content of my blog the way that I as a marketer want to use it. And let's see what happens if I render now that page. So I turn on the sidekick. I click on preview...

and that block does not exist. So let's see what happens. What you will see is, first of all, it does not break the page. That's a good thing. But as you can see, it just looks like regular text because there's no block available. So if I click here on the page source, we'll see it has converted that block into a nice div section. And the name of the block is now a class. And now I can go to the developer. And I tell the developer, I need my blockquote. I want to have it look like x, y, z. And don't make up your own content model. Don't make up sample content. You already have content. And so I'm now the developer. I go into my-- Let's see. Somehow, I closed that wrong tab. Let me bring that tab back to life. I was smart that I had it all here. Good. So I'm now in the GitHub where I do all my Edge Delivery development. I have these folder blocks where I have all my different blocks. And what I do is I create now a block called Quote. So that's kind of the mapping between the document and the block. And because I don't want to work on the main branch, I created here a feature branch called Block Quote. So let's click here on Quote. And what we'll see is we have two files. One file's the CSS with all the styling that we apply then to the HTML. And if I have to apply any logic or do some DOM manipulation, then that's where I do it. So as you can see, it's kind of 20 lines of code and CSS together. Once I'm done, I create a pull request.

And in that pull request, as I said, you will do web performance testing. So I immediately see if I suddenly introduced blocking time or any other degradation. And more interesting is also that every branch results in a separate environment with a unique URL. So here what we have is the before URL starts with main because it's the main GitHub branch. And now for my feature branch, I have here what is called blockquote. So if I click on that link, I have now the same content. But this time, I'll get the code from my feature branch where I have now my quote block ready. And that's the URL I can now share with the marketer. They can assign it. And they're totally fine. Then I can merge it. And so there's no build time, nothing in it. The moment I create a pull request, I have my own environment. I have that isolated code I can test. And I don't have to copy content between environments. And so what we see with customers is that they have now multiple teams working on it, each team on its own feature brand. And it's a super-fast way to develop in parallel. But like we said earlier, what if our authors don't want to use document-based authoring? What if I want to use WYSIWYG? Yes. And-- - How do you build a block with that? - Exactly. So let's check the same example and apply that to Universal Editor. And first of all, I can also load the Universal Editor with a feature branch. So what you see here is, I just loaded it with that feature brand. And if I click here...

on that content tree, I already added a quote to the page before. And I can now double click, change the quote, or even use here the dialogue where I have the same fields. So it's already there. But let me show you how we made that block into Universal Editor. And what I didn't show is also how you add then blocks. It's you select here and the section you get that plus icon. And then you can quickly add it. But I just skipped that for the time. But let me show you now how to add the block to Universal Editor. I go back into the GitHub in the same feature branch here. Building the block is exactly the same. It's agnostic from the authoring tool, from the content source. I only have to add a couple of configurations. They are here under components, these three files. So not going into too much details, just showing how much code was needed. So here I basically define what I had in my worktable. That's the definition of the template. Then in that file, I just say where in Universal Editor I want to have my blockquote to add. And the last one is kind of the dialogue definition, the model, what I see in the side rail. So I just need these three files. Everything is developed here in GitHub pretty quickly. I don't have to deploy a single line of code into my AEM Core. Okay. Well, what if-- I have another one for you. Maybe there's some existing AEM sites customers in here. What if they already use Page Editor? - Would it work for Page Editor? - Yes. So I showed you Universal Editor and we'll talk about that a bit later. But obviously, I also have an example here with Page Editor and the customer is Danaher. And its interesting discussion we had with them. So, they have many authors distributed everywhere, but they had a huge problem with the Lighthouse score. And they said to us, what's the fastest way to fix our Lighthouse score? And we said, go to Edge delivery. We bring you life pretty quickly. And they said, well, if you need to train all our authors across the planet, we'll lose just another couple of weeks. So can we just skip that? And that's where we said, yes, it's absolutely possible. And because they were on AEM as a cloud service, here is their instance. We did not touch their authoring environment. And if I now open up here this page, it will now open up Page Editor exactly the way they've used it before with the AEM components. So I still work with the AEM components here and maybe we just go down here and create a copy. Not that one, but let's just create a copy, embed that here. Works exactly as before. But the moment I click here on Publish, will listen to the publish event, will take the output, and send it to Edge delivery. And so if I go back here to their environment, which runs on Edge Delivery Service and I refresh the page...

we get now here these, the updated web page. Okay. Awesome. But, so there are all these options, document-based authoring, WYSIWYG authoring. What is recommended for, kind of-- And I think it's kind of a two-folded question. So I showed you document-based authoring and the editor. So the first question is document versus WYSIWYG, what do you recommend? And I would say I have just a simple guidance here is...

whoever uses the tools should decide. If it's the practitioner, if it's the market and merchant, they should decide. It should not be IT that decides what they think is best. It's in our experience you get to a much better result if you involve authors very early. And also make sure that they can try out these two things, because we know how humans are. If we know one thing and we don't know the other thing, I go the safe route. So the best experience we have had is, like, bring authors into the project very early. Let them try out. They say what they want to do. If they're not happy, it's always possible to kind of easily switch to the other authoring tool. Sometimes there's no question, it's given, maybe a company doesn't allow SharePoint or document-based authoring, then it's any way clear. So that's kind of the first question. Then the second part of the question is Page Editor versus Universal Editor. If you have a new site, I have a strong, a clear opinion. Go with Universal Editor because what you have seen is Universal Editor has an extension concept. So you don't have to deploy any code into AEM Core if you need to extend it. It's nicely outside with a nice extension manager where you can turn on, turn off extensions. We also provide experimentation and this GenAI extension. So great developer experience. And also Universal Editor works directly with blocks. So I don't need AEM components anymore. I don't need to understand HTML and Sling models. It's all nicely in GitHub, easier to learn.

If you talk about existing web pages, I would also strongly recommend Universal Editor because Page Editor was built before we introduced Edge Delivery Service. So Page Builder only works with AEM components. That means on Edge Delivery you have all the block concept. On the authoring, you still have to use the AEM components. And you need a mapping layer that will take the output from the AEM components and map that into a semantic HTML that we need for Universal Editor.

And if you want to switch from Page Editor to Universal Editor, basically the only thing you have to do is you run that conversion one time. So we get the output and we feed the semantic HTML back into AEM. And from that moment on, you're upgraded to Universal Editor. And what we have seen with customers, with first customers, is that the effort to do that one-time migration is way lower than building the converter, that map layer, plus also then that higher maintenance with AEM components, mapping layer plus the blocks. Okay. But if you're unsure, that is where the Slack channel comes in. We're here to help you. So with the Edge Delivery Service, we really collaborate very close with customers and partners. It's a super-fast way, these channels, just to ask us if you're unsure. And we'll figure without you what is the best way to do. And just to reiterate, developing in blocks with Edge Delivery, still works with all three, though? - Correct. - Okay. All right. So just to end that, these are the three things we covered today. You saw a little bit about how performance drives business outcomes and how we provide it out-of-the-box, so that your team doesn't have to focus on maintaining and achieving performance. You can focus on the other parts of the CMS project. Second is, of course, when experimentation is built-in, it makes that continuous optimization process super easy. You saw how fast Martin did it. It wasn't in one minute, but two minutes. And last, authoring autonomy and modern development unlocks agility. We saw the flexible authoring for different authors that Martin just talked about. We saw how to develop blocks. We saw tools provided, and, of course, the product collaboration channel that will make, you have access to the Adobe experts.

[Music]