There’s a whole essay to be written about the value of “sub-entity” content structures that can be mixed and matched inside of otherwise vanilla CMS content types. This is a great example.
Years back when working on the redesign of @thetoast, @karenmcgrane and I debated back and forth about the value of discrete, explicitly-modeled content types for different kinds of articles. Karen argued it would be too prescriptive, and she was right.
Instead, we focused on certain kinds of elements that appeared inside of articles, decomposed different article types into combinations of those elements, and made sure the small pieces were easy to create and and modify in the editor without extra hassle.
For The Toast, that meant the wildly creative writers retained maximum flexibility and never needed to screw around with “Do we need a new post type?” to pursue a new idea. They just used internal supporting elements if they were available, and Plain Ol’ HTML if they weren’t.
Although I’ve got concerns about the under-the-hood storage mechanisms being used in Gutenberg, the approach of rolling out new kinds of blocks that can be used and combined inside of posts that act as “block containers” has similar advantages.
In the news @helenhousandi posted, it’s the ability to create a Tweetstorm inside a blog post, with the “Block” handling the work of splitting the text inside of it into tweet-sized units at appropriate sentence boundaries. The tweetstorm can be part of a longer article, though.
Although I’ve got concerns about the under-the-hood storage mechanisms being used in Gutenberg, the approach of rolling out new kinds of blocks that can be used and combined inside of posts that act as “block containers” has similar advantages.
This approach doesn’t depend on a particular data storage approach — you can make it happen using DITA or Gutenberg or Drupal Paragraphs or Contentful or any number of other approaches different CMSs take.
The underling idea — that your large-scale content types like “Article” or “Landing Page” or “Post” can be built from a growing and evolving library of smaller structured content elements — allows for a lot of evolution and growth as editorial needs change.
I have a lot of feelings about why it’s a mistake to build narrative content from “stacks of blocks” (rather than letting the blocks be embedded inside of narrative text), but that’s a tweetstorm for another day. ;-)