In today's digital landscape, Adobe Edge Delivery Services have gathered significant attention, and rightfully so. Initial implementations have brought promising results (see reference #1). Volvo Trucks increased their site performance score from 35 to 100 and improved discoverability and keyword rankings (increased visibility score from 2.5% to 43%). Merative reduced page load speed from 10.9 to 1.6 seconds and improved its web performance score from 34 to 100. Together with accelerated development workflows, they boosted engagement by 42% and conversion by 100%. Both organizations witnessed remarkable improvements in site performance facilitated by Edge Delivery Services. They enable us to deliver faster sites and develop and publish them faster.

At the heart of accelerated content publishing lies document-based authoring. By allowing authors to craft content in familiar environments like Google Docs or Word, Edge Delivery Services eliminate the need for direct interaction with AEM. This not only expedites content creation but also simplifies author onboarding and training. Furthermore, easy access to centralized content on Google Drive facilitates its translation and localization.

The process of transforming a document into a web page is truly fascinating. Authors supply content in documents, and developers handle the frontend elements, called blocks. These parts are then merged to create a cohesive web experience.

Authors can easily manage basic content layout and formatting without needing any specialized expertise. They can apply formatting such as bold or italic text, create headings, and insert images into documents just as they normally would. However, for more complex layouts, following certain conventions is necessary. Content is organized within tables, and each table header contains the name of a specific block used to layout and style the content.

Adobe provides ready-to-use boilerplates to make things easier. Let's take a look at an example of how cards are defined.

It is quite simple, but authors need to know what blocks are available and how to organize content in a corresponding table.

While these templates are helpful, they might not cover everything needed for building a website. By comparing the available templates with our page designs, we can identify any missing elements or ones that need customization. This analysis helps us specify new blocks and how the content should be organized in tables. Developers will implement these blocks later, but authors can start their work using these specifications before the blocks are ready.

Adobe claims that with Edge Delivery Services, “the CMS adapts to the content authors create, instead of forcing authors to think in components, structure (…)”. Personally, I think that this benefit might be exaggerated. Before we begin working with documents, we must agree on how they should be structured. This agreement defines a guideline for authors and developers, ensuring the content aligns with the blocks.

Document-based authoring isn't merely about swapping the AEM page editor for Google Docs or MS Word. It transforms our ways of working, particularly in creating web content. It promotes early collaboration between content creators and developers, speeding up site development. Based on my past project experience, I've witnessed its positive impact on efficiency. Now, let's delve into its benefits.

As previously mentioned, the list of blocks serves as an agreement between content producers and developers. Once the specifications are agreed upon, we can initiate multiple streams simultaneously, thereby shortening the overall project duration. This collaboration extends beyond just authors and developers. For instance, if we require assistance from an SEO agency to optimize metadata, they can work concurrently with platform development.

With document-based authoring, we can achieve more than just the fast-tracking. We can establish cross-functional teams comprising developers and content producers. They work closely together and regularly integrate their work. At the end of each sprint, we witness progress on our site. Authors and developers conduct joint demos, allowing us to observe the continuous evolution of the solution. This agile approach facilitates early validation and feedback, which I'll discuss further in the next section.

Both the fast-tracking and agile approaches promote early validation. We can review initial deliverables and quickly identify any gaps. Fixing these issues may require additional time and effort, potentially resulting in change requests. Nonetheless, recognizing them early on is crucial for managing stakeholders' expectations. The sooner we identify them, the more flexibility we have in addressing them. Let me provide some examples below.

• Wireframes and initial designs. Proposing a page layout without finalized content requires making assumptions about the length of the text. However, the actual text may be shorter or longer than anticipated. With clearer visibility, we might find it necessary to revisit the wireframes.

• Required blocks. While preparing content, page owners may have specific requirements for formatting and styling the text. In the previous project, we received a request to use a dedicated quotation format on a particular page. This request influenced the specification for components and expanded the developers' scope of work.

• Content completeness. Compiling the text and assets into a document prompts authors to verify their availability. In my project, we encountered issues such as low-quality images, assets with unclear licensing conditions, broken links, and links with no defined target.

• Compliance. In highly regulated environments, content demands additional review by a compliance team. We can request their evaluation of documents as soon as they are prepared. While the compliance team must also approve the final web experience, early initiation gives us more time to address any feedback.

The cases mentioned above are just a few examples. Undoubtedly, you may encounter many more in your projects. They may uncover additional activities that were not initially planned. Early validation enables us to identify and address them promptly.

Now, let's explore some standard capabilities of Word or Google Docs. These tools have been around for a while and come with OOTB features that can significantly benefit authors.

• Real-time authors collaboration. One of my favorite features of Google Docs is the ability to collaborate on the same file with others in real-time. This means we all have access to a single, up-to-date version of the document. I can see changes made by my colleagues instantly and offer feedback and comments directly within the document. Using Google Docs for content management offers the same collaborative opportunities for authors.

• Content versioning. Another feature I appreciate in Google Docs is versioning. I can easily track how the document evolved, identify contributors, and review changes made by my team mates. If necessary, I can revert any unwanted changes. All of these functionalities come pre-packaged for document-based authoring.

Finally, I want to share a potential benefit based on my past project experience. We collaborated with an external authoring agency. We might not have needed their services if we had utilized document-based authoring. Page owners could have published content directly from documents. I believe this approach could have shortened the timeline by 2 months and saved us some money.

Document-based authoring offers significant value. It allows us to optimize timelines and address potential risks sooner. However, every coin has two sides. Using documents for authoring can also introduce challenges, which I will discuss in the following section with some examples.

Let's revisit the card block example discussed earlier. It consists of a row with the block name. The following rows contain images and descriptions. This simple structure wouldn't be sufficient for my project.

We had to satisfy additional requirements. Firstly, we needed to determine whether the cards should align in two or three columns. Secondly, our site featured sub-branded sections, requiring extra visual branding elements for the cards within each section. To communicate these variants to the authors from the external agency, we added extra rows defining conditional layout and styling (the basic structure was similar to the one presented above).

A similar approach can be adopted with Edge Delivery Services. Each block definition can include options that allow the assignment of additional CSS classes to specific blocks (see reference #2). For instance, in the table header above, we could use Cards(2cols, brand) to indicate the expected number of columns and branding.

Edge Delivery Services promise quick author onboarding. The foundamental information we must provide to authors is the list of available blocks. Additionally, if we incorporate any conditional styling, such as through block options, we must document and share that as well.

Thankfully, there's AEM Sidekick to help. It provides a toolbar with options for previewing and publishing pages directly from Google Docs or Word documents. Moreover, it offers an extension called Sidekick Library (see reference #3). This library displays a comprehensive list of all available blocks, eliminating the need to memorize them and their variations. It streamlines the onboarding process and enhances the authoring experience.

Changes are inevitable in any project. We may discover new requirements or encounter implementation challenges, among other things. These events can impact the list of blocks or the structure of corresponding tables. Updating one or two documents isn't a big deal. However, imagine needing to rename a block or adjust a table in over a hundred documents. It sounds painfull, doesn't it?

This scenario can result in similar challenges, as discussed earlier. There might be a need to begin content production before finalizing the blocks available for our site. For instance, creating sample content to support wireframe designs is very useful. However, if we create hundreds of documents without a clear structure or with only a temporary one, we'll eventually have to reformat all the content. Trust me, it's a time-consuming and tedious task. I learned this firsthand after spending numerous hours reorganizing briefs for the external authoring agency.

Sharing documents across different teams via Google Drive or Sharepoint might seem convenient. However, in my experience, I've found that some people prefer a more traditional approach. For example, when collaborating with an SEO agency to optimize metadata, we initially suggested making updates directly in shared documents. However, they preferred receiving over a hundred documents in a zip file, making offline updates, and then sending them back. I believe they wanted to easily showcase their work results concerning the received inputs (just in case of any discussions). When trust is limited, we may find ourselves sharing batches of files and dealing with the hassle of copying data from one location to another. Managing multiple copies and ensuring we're working on the latest version can become a nightmare.

When you're working on a page, you typically use AEM Sidekick to generate a preview. Ideally, the preview will show the page exactly as you expected. However, this isn't always the case. Sometimes, you'll need to figure out why the page looks different than anticipated. It could be due to incorrectly defining the layout with the wrong table format, a typo in a block name, or an issue with the block implementation that needs to be addressed by a developer. Identifying the cause of the issue may take some time and can be more challenging compared to working with a page editor.

The issue investigation mentioned earlier is just one example of the impact on the authoring experience. Josh Boyle has written an insightful article comparing AEM sites with document-based authoring (see reference #4). He highlights the following points:

• You lose context between what you see in Word or Google Docs and the final result. This requires constant previewing of your page to ensure it looks as expected.

• Overall, AEM Sites capabilities surpass what document authoring offers.

I agree with this thesis. Tools like Sidekick Library enhance the authoring experience, and I believe we can expect similar tools to emerge in the future. However, for skilled and experienced AEM authors, working with AEM Sites is currently more comfortable.

The previous sections have discussed the advantages and challenges of document-based authoring. Now, I'd like to explore its potential applications. Some have claimed that Adobe Edge Delivery Services are only suitable for simple websites or blog-like pages. However, I believe this new approach offers much broader potential. I can imagine implementing a big corporate website in this manner. Moreover, the limitations are not necessarily linked to document-based authoring.

As long as the pages are mainly static and you don't require the advanced capabilities of the classical AEM, a site built with Edge Delivery Services should perform well, even with hundreds or thousands of pages. The primary limitation arises when we need dynamic data from various sources. Requesting information from third-party systems, waiting for responses, and consolidating data take time. Delivering on the promise of fast sites becomes challenging in such scenarios.

Before wrapping up, I'd like to offer one more insight regarding the potential impact on the landscape of agencies involved in AEM site implementation. Document-based authoring simplifies complexity and streamlines the process for business teams. In some setups, page owners draft content manuscripts in Word or Google Docs and then pass them on to a dedicated agency specializing in page authoring. This agency is tasked with inputting the content into the CMS and publishing it. However, with the popularization of Edge Delivery Services, these agencies may need to reassess the value they provide, as the core need may now be addressed by Edge Delivery Services.

In conclusion, let's revisit the question posed in the title: Can document-based authoring speed up site implementation? I am confident that it can. It strongly aligns with the core objective of Edge Delivery Services, which is to accelerate sites and their implementation. However, it's not solely about saving time on authors' onboarding and training. In my view, the primary value of document-based authoring lies in its ability to separate content production and authoring from platform development.

This deliberate separation allows us to initiate multiple streams of work concurrently, mitigating overall risk by addressing certain issues early on. Although we may not see the final formatting in the early stages, we can engage with numerous stakeholders before developers complete their tasks. Consequently, we can reduce the time-to-market for more than just platform implementation - we can expedite the launch of our sites.

If you're intrigued by these insights or have questions about how document-based authoring could benefit your projects, I invite you to reach out. Let's continue the conversation and explore the potential together. You can connect with me on LinkedIn or email me at kamil.kwarciak@ds.pl. I eagerly await your contact!

1. Reimagine digital experiences with the new Adobe Experience Manager Sites

2. Markup, Sections, Blocks, and Auto Blocking

3. What is the Sidekick Library?

4. AEM Franklin vs AEM Sites