Multiple content models, canvasses and chunks

via https://twitter.com/eaton/status/1338601760714354689, eaton points us to https://jjosephmiller.medium.com/the-rhetoric-of-content-types-c9e6994d2b01

“Separating collections of attributes from rhetorical function is every bit as important.”

Reminds me of something eaton mentioned earlier: for a given site/platform/service, there’s not one content model, but multiple in parallel.

Content model for storage

At the very least there’s the model on the level of the database: the technical content model and the finer grained data model behind that. This content model is mostly concerned with how the content is stored

Content model for communication

On top of that the content model for a specific channel, let’s say, “the site”. The content type building blocks in the database model by themselves are not flexible, rich enough to compose the necessary screens with. The content model of the site is often more expressed throug it’s design system, with page/layout types like “landing page”, “list page”, “item page”, “sub home” and the like.

These are all composit pages. Even the single item page is not built from the content item alone. Header, footer of course, but also additional navigation, and “related content” bits and bobs get added to the core content provided by the content type.

One difference between item page and the other composits is that on the single item screen, all the additional items are “pulled in” to the content item. The foundation of the page is indeed the item itself. (the URL of the page is the URL of the content item)

For the other composit pages like a typical landing page it helps to think of those as an empty canvas (header, footer will likely still be on there, I’m talking about the space between those two). For these empty canvasses, there is no one specific content item that is the boss of the page that provides base content and context. Content: there’s no single item that defines the basic set of available items to show. Context: there’s no main metadata to derive the additional “related” items from.

So given the building blocks as defined in the database content model, we run into the need to repackage the content in a content type into smaller subsets of related fields. (Drupal: view modes)

We need canvasses and flexible content chunks that can be added to those.

Content, design, system

The above still approaches the Communication Content Model from a display/design angle. Expressed in terms derived from design system language. But the communicative function of this “title+body+image+link” content component is not necessarily the same as the communication job of this other “title+body+image+link” content component. They may have an identical structure in constituting parts, but what they communicate and how may be very different.