One Page

Abstract

Document Authoring is an early-access technology preview from Adobe. It provides a fully integrated and authenticated document-based authoring experience for common tasks that are hyper-specific to web content management (WCMS) needs.

While Microsoft SharePoint and Google Drive solve many content management needs (compliance, authentication, authorization, versioning, collaboration, etc.) they are not tailor made for the needs of AEM Edge Delivery Customers. When pushed to their limits, these existing content repositories can have a feeling of, "square peg in a round hole." Companies of a certain size with certain acceptance criteria may find these tools cumbersome.

Document Authoring is

1. An API to store docs, sheets, and media at scale.
2. A UI for humans to manage content.
3. A content provider for AEM Edge Delivery Services.

Document Authoring is not

1. A WYYSIWYG editor
2. A markdown editor
3. An SPA editor
4. A SharePoint / Google Drive replacement.
5. An AEM Assets replacement.
6. Meant to host direct web traffic.

Document Authoring is inspired by

1. AEM Edge Delivery Services - Serverless, Simple, Fast.
2. Apache Sling - Wherever you POST, that's where your content will be. Wherever you GET, that's what you'll get.
3. SharePoint & Word - The muscle memory of using Word is critical.

Document Authoring goals

1. Provide a rich, performant, scalable, and stable API that eclipses what Microsoft Graph + SharePoint provides.
2. Get feature parity with Word editing. Including muscle memory behaviors like keyboard shortcuts.
3. Provide first-class bulk operation tools like localization, search & replace, versioning, and more.
4. Integrate with the larger Adobe Experience Cloud ecosystem: AEM Assets, AEM Tags, Adobe IO Runtime, etc.
5. Provide real-time content previews.
6. Provide real-time collaboration.

Document Authoring principles

1. No markdown. - Markdown is great for viewing and writing but provides a poor developer experience when considering different flavors and the ubiquity of DOM APIs.
2. Un-apologetically a document-based editor.
3. The server should be as dumb as possible. The goal is to serve static files with no manipulation.
4. Build like it will last 20 years. Prototype like it won't last more than 20 days.
5. If it doesn't work on mobile, it doesn't exist.

Document Authoring status

After much research, the Dark Alley POC is done. We are in the midst of several implementation projects in and outside of Adobe.

1. POC - Done
2. Pilot - Done
3. Collect pilot feedback & iterate - in progress
4. Security, privacy, etc. review. - in progress
5. Customer #2 / #3 / #4. - in progress

Research

1. What type of content repository? Filesystem, Sling / AEM, MongoDB, Azure Blob Storage, S3-compatible storage.
2. What editor? CKEditor, WYSIWYGHTML, TinyMCE, ProseMirror. - A relatively sane API with a lot of prior art, examples, plugins, collaborative features, comments, etc. You just have to build it all. Maybe most importantly is the UX is 100% customizable to provide an experience Adobe customers expect.