Squirrel Notes is an email newsletter about CMS and other content technologies. It publishes twice each month.

This issue was published on Monday, June 04, 2018.

Subscribe to receive future issues

Non-sequiturs from the world of content management.

Content Engineering. I just love this Wikipedia article on Content Engineering.

[...] a term applied to an engineering specialty dealing with the issues around the use of content in computer-facilitated environments [including] content production, content management, content modeling, content conversion, and content use and repurposing

I've always felt that "content management" was a limiting term. Management feels focused on the actual content, while many developers often end up managing sources and channels more than content.

How about "content orchestration"? Or "content architecture"?

Multi-Track CMS Development. More and more, I see CMSs offering alternate modes of development, outside of their core programing language or framework.

  • Almost anything in .NET can be developed at the Razor level. Umbraco does quite a bit of this. This is technically templating, but (unfortunately), it allows full-blown C# code inline, so it can be dangerous.

  • Crafter CMS has a Groovy development environment, which is a scripting variant of Java.

  • Magnolia has a highly-developed "light development" mode for front-end devs to do considerable programming and development. I've seen entire websites developed in Magnolia by front-end devs who don't know any Java.

  • Drupal does templating in Twig which might be "sandboxed" to provide pseudo-programming functionality. (I discussed this years ago in a blog post: Smarty as a Sub-Language.)

  • I have written Denina which is an editorial scripting system.

I'm looking for other examples, if you know of any.

Content Shapes in Craft CMS. I had a demo of Craft CMS the other day, and I enjoyed their concept of sections which use an explicitly-specified content aggregation type. You define in advance if the section is a "channel" (serial content; a blog) or "structures" (hierarchical content; simple pages) or a "single" (literally a single page, like a landing page).

I teach this idea of content having a "shape" in my CMS course. I think there's room for more types/shapes, and coincidentally, one of my former students actually sketched his notes from that exact lecture of the course the other day and posted the result to Twitter.

GraphQL and the Standardization of Headless? I've been looking at GraphQL lately. I'm wondering how headless CMS might adopt some standards. GraphQL seems headed in this direction.

One of the points of my Codegarden talk (see below) is that we're missing a common communication layer — the "SQL of headless," if you will. It's not REST or JSON — what we need is a standardized query language, and a common understanding of how content is modeled so we can abstract a headless CMS like be abstract a database.

What will be the "database table" of headless — the common data structure we can all accept and organize around?

Codegarden 2018. I spent three days out in Odense, Denmark speaking at and attending Codegarden 2018, the Umbraco developers conference. It was a pretty amazing trip, and I was deeply impressed with the quality and cohesiveness of the Umbraco developer community. They announced Umbraco Headless during the opening keynote.

My talk was entitled "7 Things We Know About Headless and 3 Things We Don't." Video to come soon.