# A Conceptual Look at Content Structure in the Headless Era

A *headless content management system* or *headless CMS,* is a CMS in which the content is separated from its presentation. They differ from traditional monolithic CMSs in the following main aspects.
1. The headless backend management of the site’s content is decoupled from the frontend that displays it;
2. The headles CMS delivers structured data from an API. Rather than merging templates and content to create HTML, a headless CMS returns JSON or unstyled XML.

### The benefits of an headless architecture
1. Without a designated frontend, a headless CMS provides the greatest flexibility to offer its content to different channels. Such websites, mobile apps, reader for visually impaired users or blind, PDF creators and more. Its API can also be used as a connector to external services and platforms, in a distributed content management stack.
2. By decoupling the frontend by the backend, any dependency between two modules is removedallowing the front-end to be changed completely without touching the CMS.
This mean that the two modules can be implemented in parallel in an isolated context, by only agreed on how the API would look like.
The backend does not need be aware of the way in which the frontend will organize the navigation patterns,it needs to allow content editors to organize the content in a semantic structure, upon which the frontend can build its logics, and patterns.

These pretty straightforward principles, impact the way how we were used to working on monolithic architecture.

### The drawback of an headless architecture
1. If we have a veteran experience on monolithic architectures, we are instinctively prone to apply the old model of content structure.
By doing this we do not fully take the advantages of the headless paradigm.
2. There are a number of benefits of storing and managing content and design within a CMS, but this is apparently in contradiction with the headless philosophy.
To achieve a certain design control on what we publish on a specific channel, we need to do a step back and understand where form and content intersect, and where the form functions has content.

## Form and Content
In the monolithic era, we were used to structuring the form in pages templates more or less flexible, sometimes even organizing our content in function of these available templates, by example custom posts type on WordPress. Often this distinction had a semantic meaning, based on the type of content and its structure, but other time it had only the function of a category, a workaround to couple different templates to the same kind of content.
This way of designing the backend, apparently handily, but could introduce rigidity in the design workflow. Whenever the need of packaging a content in a new template appear, the backend needs to be restructured, by creating a new custom post type and making sure that all the listing pages will consider that new type of entity.

### A look at Editing Interface
First generation of editing interface to add content to the CMS were basically a simple form, a limited set of input.
Title, summary, picture, body text as WYSIWYG editor. That was all.

> When I think WYSIWYG, I think of the Word toolbar. This type of WYSIWYG is for adding tables, images, forms, type and colour. It's a toolkit to create pages of content. Just like desktop publishing. And that's the dangerous thing. Content creators are used to having these tools at their disposal so they can craft their document. Why? Because writing isn't done in a CMS, it's done elsewhere.
> ...
> If we consider the majority use-cases of correcting typos, restructuring slightly, or small on the fly editing, then the smaller toolbars for adding semantic value are useful. But for most use cases, a WYSIWYG is not useful for content people. It's just familiar.
>
> -- <cite>[Mark Boulton][1]</cite>

[1]: https://markboulton.co.uk/journal/wysiwtfftwomg/

More modern editing interfaces are usually block based, this has introduced a new methodology for working with content.
A more flexible way of data modelling, where the content is defined as a composition of predefined semantic structures.

> Using a system of Blocks to compose and format content, the new block-based editor is designed to create rich, flexible layouts for websites and digital products. Content is created in the unit of blocks instead of freeform text with inserted media, embeds and Shortcodes (there’s a Shortcode block though).
>
>Blocks treat Paragraphs, Headings, Media, and Embeds all as components that, when strung together, make up the content stored in the WordPress database, replacing the traditional concept of freeform text with embedded media and shortcodes. The new editor is designed with progressive enhancement, meaning that it is back-compatible with all legacy content, and it also offers a process to try to convert and split a Classic block into equivalent blocks using client-side parsing. Finally, the blocks offer enhanced editing and format controls.
>
>The Editor offers rich new value to users with visual, drag-and-drop creation tools and powerful developer enhancements with modern vendor packages, reusable components, rich APIs and hooks to modify and extend the editor through Custom Blocks, Custom Block Styles and Plugins
>
> -- <cite>[WordPress Documentation][1]</cite>

[2]: https://developer.wordpress.org/block-editor/

This concept sound greats, and to some extent is a revolutionary way of editing content. That is actually what everyone has thought in the 2012 when Medium was launched.

>It’s true: Medium has the best web-based editor I’ve ever seen. And I’ve seen them all
>
> -- <cite>[Anil Dash][2]</cite>

[3]: https://twitter.com/anildash/status/269185787080347648

This concept sounds greats, and to some extent is a revolutionary way of editing content. That is actually what everyone has thought in the 2012 when Medium was launched. But Medium as never had the ambition to be a content management system, it has been introduced to the world by an article written by its founder which start as following.

>Medium is a new place on the Internet where people share ideas and stories that are longer than 140 characters and not just for friends. It’s designed for little stories that make your day better and manifestos that change the world. It’s used by everyone from professional journalists to amateur cooks. It’s simple, beautiful, collaborative, and it helps you find the right audience for whatever you have to say.
>
> -- <cite>[Ev Williams][3]</cite>

[4]: https://medium.com/@ev/welcome-to-medium-9e53ca408c48

By reading again the __*"Block Editor Handbook"*__ from the WordPress documentation, with the headless philosophy in mind, a sentence seams to be out of place.
__*"..the new block-based editor is designed to create rich, flexible layouts for websites and digital products.."*__

How can we keep the sacrosanct separation of concerns between data and presentation, if the content editor aim to shape the layout of the presentation layer?

>The kind of toolbar you find on Medium, or on Basecamp. As you can see they are similar. They are used for applying semantics to document structure; giving words emphasis, making unordered lists, or numbered lists, making words headlines. However, they're not there for the user to get creative. They do not change the colour of a word.
> -- <cite>[Mark Boulton][1]</cite>

[5]: https://markboulton.co.uk/journal/wysiwtfftwomg/

### How to make use of the great Gutenberg's features in a headless context?
*To tell the truth, WordPress is not my favourite piece of software. When I think WordPress, I relate with the idea that I have of Microsoft Word and PowerPoint. An outdated way of doing certain things, that still been used because a lot of people are familiar with it, knowing how hard has been to learn how to use these tools, are afraid to start again this process.*

*That said, in 2020 I still have to deal with it.*

The WordPress editor Gutenberg is a modular customizable set of packages powered by React. Below I will outline some principles which can be used as guidelines, to customize the block editors, by removing some features, in order to preserve the benefits of the headless architecture offered by WordPress itself. In a Typescript envirioment

1. The block editors should be **only used to apply semantics** to document structure, any other data related to a specific presentation module should be declared elsewhere.

2. S