Stack-o-bricks content models

Lots of recent conversations about pros and cons of the “Stack-O-Bricks” layout model for web CMS. (AKA Gutenberg, Paragraphs, Grids, and other variations).

To often, the discussion treats “use fields and widgets has instead of raw markup” as the extent of structured content.

Structured content isn’t about “put things in fields and use widgets instead of HTML” — that’s just one means to the end of capturing meaning rather than simply presentation.

In some cases (unpredictably structured one-off pages, curated collections that differ dramatically over time, etc) simply giving people a container ands letting them stack design modules as needed is fine.

But when it comes time to reuse the content in other ways — displaying pricing details in the sidebar of each article that mentions a product, say — the “stack of design patterns” content model fails miserably.

If your core “product” page isn’t modeled around meaning — short description, audience, pricing levels, current version, whatever — then the fact that your random chunks of text and image are in “fields” instead of “markup” won’t help you extract, reuse, and repurpose them.

That’s just one example, but it’s literally what one of our clients is trying to wrestle with now. They used “structured content” but their content model maps to design patterns, rather than the meaning of the underlying material they’re presenting. Lots of untangling to do.