Why Document Authoring Wins

by Josh Oransky

The argument over which authoring surface to use on Edge Delivery Services has become slightly religious. Universal Editor is the new sanctioned answer. SharePoint is the "we already use Microsoft" answer. Document Authoring (DA) is the "you're a developer who likes simple things" answer. They all work. After enough rebuilds, one of them tends to come out ahead, and it's usually DA.

The argument against

DA looks alarmingly simple. There's no preview pane, no WYSIWYG editor, and nothing to define before you can start typing. Authors edit pages in a tab that looks like a Notion document and click Preview to render. Stakeholders see this and worry the platform isn't "enterprise enough."

Then a content team uses it for two weeks and stops complaining.

Why authors actually like it

The same simplicity that worried stakeholders is what authors find liberating. The page is a document. Sections are paragraphs. Blocks are tables. Everything is keyboard-driven, copy-pasteable, and version-controlled by Git through the round-trip API. Authors who have spent a decade fighting AEM's component dialogs and inherited overlays do not miss them.

You also get a few specific wins:

• Multi-author concurrency works. Multiple people can edit the same page simultaneously without locking. The collaboration model is the document.
• Bulk operations are trivial. Find and replace across hundreds of pages is a single API call, not a sprint of dialogs.
• Roundtripping to code is clean. Pulling content into a repo, editing programmatically, and pushing it back is the supported workflow, not a hack.
• Onboarding takes hours. If a new hire can write a doc, they can author a page. Universal Editor takes a week of training to use properly.

When you should not use DA

Mostly, you should still use DA. The one case that genuinely isn't DA is headless consumption by mobile apps, which wants AEM Sites as the backend with EDS as the public front end. The other objection you'll hear is structured content: product catalogs, taxonomy-driven listings, anything where the field set is non-negotiable. A document is the wrong shape for that, and it's the strongest argument for Universal Editor's typed forms. DA has two answers for it.

Structured content

Structured Content turns DA into a form-based editor. You define a schema, DA generates the form from it, and authors fill in typed fields with real constraints on what each one accepts. What comes out the other side is JSON that blocks fetch directly, with the fields indexed so listings and queries work the way they would against any structured source. Authors get the form, developers get the contract, and the rest of the site is unchanged.

Apps and plugins

Whatever a schema can't express, you build. DA apps and plugins are micro frontends: your own HTML and JavaScript, loaded into the DA interface, running against the author's session and able to write back into the document. A taxonomy picker, a product lookup against your PIM, a campaign builder. That's your code, on your release schedule.

But for the standard marketing site, the blog, the resource library, and the campaign landing pages, DA is faster to author, faster to learn, faster to build against, and faster to migrate to than any of the alternatives. The shape of the document is the shape of the page.

"Enterprise enough" usually turns out to mean "complex enough that the procurement team feels okay paying for it." Authors don't care about that. They care whether they can publish before the marketing window closes. DA lets them.