Deane Barker's Technical Blog

AI and the Forced Platform-ization of Enterprise Software

Sat, 3 Jan 2026 00:00:00 -0600

I’ve become interested in the last few years in the “layers” in which we build, customize, and integrate software. More pointedly, I’m fascinated at how the era AI and “vibe-coding” is going to completely upend them over the next decade. The current “us vs. them” perspective of software development is never going to be the same.

Back to layers – at the bare minimum, there are two:

Vendor: the organization that produces the software
User: the organization that uses the software

The vendor clearly builds the software and makes all sorts of choices. But the user makes choices too, in how they’ll configure it, what settings they will use, and the common knowledge they’ll share about how that software works at their organizations.

Customers “adapt” software (or “re-invent” it, according to Diffusion of Innovations).

Many times, with enterprise software especially, there’s a middle level:

Vendor
Integrator/Partner: the organization that oversees the installation, activation, and configuration of the software
User

The integrator has special knowledge of the software. They can use some special tools or skills – like the ability to write code against the vendor’s APIs – to make the software do special things for the user.

Most software actually consists of at least four layers:

The “core” that the vendor builds and that no one can touch
Some special tools and APIs which can be used to make the software work differently
Settings and configuration on a per-instance basis – so, things global to an organization
Settings and configuration on a per-user basis – so, things specific to a human

And we could go on and on. There are so many different ways to peel this onion.

At Episerver/Optimizely, I came up with this graphic. This was internal (and it’s about five-years-old now), but I’ve shown it to so many people by this point that I’ll just publish it here:

The point I was trying to make was that code and functionality “leaks” out of a software vendor at so many different levels. The actual resulting software that’s perceived by any given user is a roll-up of everything in that list. They may think that the core software (#1) does all the things they experience, without knowing that their accumulated experience is an aggregation of 11 different layers, all homogenized (with varying degrees of success) to look like a single thing.

This is sort of a re-hash of the “product vs. platform” debate.

A product is a thing designed to be used one way. It promises very fast implementation and low cognitive overhead, but isn’t very flexible and is not designed to be.
A platform is a thing designed to be adapted and built upon. It’s flexible and powerful, but often needs to be implemented carefully and requires considerable thought about all the things you can do with it.

I maintain that one of the key decisions of every product company is: are you a product or a platform? Where along that spectrum do you lie? And if you don’t do something exactly how a customer or prospect wants, do you just admit that, or do you provide some tools or options to change it?

So, what does this have to do with AI? People have been modifying software for years – hell, I made a living doing it for a long time.

…but it’s different this time.

The fundamental relationship between user and vendor is about to change. Those two layers we talked about in the start? They’re about to get something really… weird, in between them. And this is a fundamental shift that we just haven’t seen before.

Lately, I’ve been following Ink and Switch and their research around “malleable software,” which is software the user can change. They have some great videos on this.

(The subtitle for that linked article is telling: “Restoring user agency in a world of locked-down apps.”)

In the age of AI, we’re going to encounter this more and more. AI has given us the option to change anything we like, and that option is slowly going to become an expectation. Consequently, we’re drifting into the “platform-ization” of everything. How “malleable” your software is will become a key point of evaluation, no matter how much you try to tell people you’re selling a product, not a platform.

I did some research last year on using AI to create dynamic/disposable components around a data core –

How Should a CMS Repository Understand the Content Within It?

I said this:

Once I was satisfied that my data was secure (that my repository was “well-defended”), then I didn’t really care what Claude did with it. I don’t recommend getting callous with your data, but all of these apps took basically no effort from me, so I would have been happy to create them, use them, throw them away, and create new ones.

Consider this: could every user roll their own UI? We usually talk about “the UI,” and maybe we have a default…but what if I don’t like it? So long as the repository can defend itself, then could I just have some AI agent write me my own UI that I do like?

This is the future of enterprise software. More and more, vendors are going to be designing two things:

The inviolate core of the software (the Queen Bee)
The API/integration layer where AI and users can mess with stuff (the Worker Bees)

Let’s take it to an extreme: you design some enterprise software to manage some data. You ship it without a UI, or perhaps just a very shallow UI. It’s just a data repository, a very well-realized API, an MCP server, and set of good documentation. You let your customers use AI to roll their own UI.

If you did that, what problems would you be solving? What problems would you not have to solve anymore? What layers come out of the product?

What would you stop building in the product, and let other people build on the product? What stuff would you yourself start building on the product, rather than in the product?

The next generation of AI-enabled browsers is going to redefine how UIs exist in relation to users. They’ll let the user re-arrange software to their own desires. Imagine that every user has an AI agent that effectively writes browser extensions “over the top” of your software – automatic TamperMonkey for the masses. Imagine being surprised every time you see how one of your users’ UI looks and functions.

How ready for this are you?

Technically, how many layers do you have in your software stack? What affordances do you have for functional insertion in each different layer? How close to the “base” layer can a customer affect? If someone throws away your UI, does the rest of the product still work? Does it still provide value?

Mentally, emotionally, and philosophically, how ready are you to release your grip on all the layers? How ready are you to concede that AI is going to add layers to your product that you never conceived of? Are you going to embrace this or fight it?

Progress against this idea will improve software as a whole. In general, vendors are holding on too tightly to their functionality. Too many offerings are “all product, no platform,” and that inflexibility is not going to play well in the future.

AI is going to generate some soul searching and hopefully constructive determination over where the actual value-add of an enterprise software vendor lies.

I suspect that a wholesale re-definition of the relationship between vendor and customer is not far behind.

Postscript: Scriptable Software

If you like the idea of malleable software and how you might enable it at your organization, maybe watch this talk I gave in Croatia in 2022.

It sums up a lot of what I’m thinking in this space, and it was given before AI really broke open in the last few years, so it’s a case for the pure idea, independent of any AI implications.

Low Code: Short Term vs. Long Term Value

Sat, 4 Oct 2025 00:00:00 -0500

I spent some time with a low-code app building platform this week. I built a demo app with it, and I was pretty impressed overall. It wasn’t as bad as I had feared.

I did have two superficial thoughts about it –

Consistency Has Value in the Long Term

While working with it, I would get a little frustrated because it would take me longer to do something. But the hidden value I saw is that there’s less chance to color outside the lines.

In this particular platform, there’s basically one way to do most things. You can’t really get… clever, with your code. The way things are implemented is pretty regimented, and while you can get to the destination you, the route is sometimes a little circuitous.

In the short term, this can be annoying. But in the longer term – especially with larger, distributed teams – this would be a huge value-add. One of the problems with code is understanding it after it’s been written. And there’s always a tendency to try to demonstrate your skill by optimizing and abstracting and otherwise trying to leave evidence that you’re The Smartest Guy in the Room™

Not being able to deviate from implementation and coding patterns is weirdly freeing. The platform becomes “bad cop” – meaning, you can say:

I would have used [insert ridiculously theoretical coding methodology here], but I couldn’t because the platform wouldn’t let me. Bummer.

This leaves you with really simple, clear, understandable program flow. People behind you can easily figure out what you were trying to do without you have to explain it.

In some sense, the code becomes self-documenting because it exists in relation to a much smaller set of possibilities and patterns. When someone after you is trying to figure out what you were doing, there’s a vastly reduced “menu” of things you might have been trying to do, so it becomes easier to make sense of it.

A Common Execution Environment Removes a Lot of Uncertainty

If you assume someone’s codebase, and can figure it out, there’s still a lot of uncertainty about how to run it. What language is it written in? What runtime does it need? What dependencies does it have? What weird quirks about the environment do I need to configure?

I think every developer has some horror story about “just trying to get it running.” You can spend hours just getting a dev environment running correctly for some code before you even start thinking about fixing or improving it.

The particular low-code platform I was working with has a built-in runtime. They have cloud and on-prem versions, but either way, you’re writing an app to fit into their architecture. To deploy, you click a button and it runs inside their containered environment.

Like the other point, this is freeing. The urge to do anything interesting or clever in the runtime environment is gone – you have no choice, because it’s only going to run in one environment, one way. You’re all working towards the same runtime.

Again, in the short time, this might feel limiting. But over the long time, I imagine this is hugely valuable. Theoretically, the code will always run. Ten years from now, you can pull it off the shelve, understand it easily, change it, then put it back on the shelf in the same spot.

Both this observations point to a common problem in software development –

Software doesn’t “happen” at one time. We often think only about writing code. We don’t think about maintaining it, evolving it, improving it, or sharing it. With few exceptions, code only has real value over time. Unless you’re writing something for a one-time project then throwing it away, you are going to have to revisit that code at some time.

This means you have to understand it, and you have to have a place to run it. When every possibility is open to you, those two things can suck up an absurd amount of time. Reducing options in the short-term can be annoying, but over the long-term, the value should be huge.

I got my car washed today. I hate it went you have to drive out through the dryers and there’s some big timer flashing at you, because you have to time it just right – you have to drive slow enough to use all the time, but sometimes you go too fast, and then you have to back up. I think about this way too much, and it probably doesn’t matter. My Jeep looks about the same no matter what I do.

But this particular car wash was on a track. I was getting pushed along. I got pushed out through the dryers and spit out the other side and then I drove off. I didn’t have to think about it. And again, my Jeep pretty much looked the same as it always does.

Sometimes it’s nice not waste effort on things that don’t matter much.

Lessons Learned from Vibe-Coding a Configuration Parser

Sun, 28 Sep 2025 00:00:00 -0500

I vibe-coded something the other day. And not something temporary – this is a library I want to use in production environments. The process got me thinking about where the real value – and the real work – of functional code lies.

Years ago, I came up with a syntax for configuring a “pipelined” software process. It was a way to specify “commands” and pass “arguments” to them in plain text.

It looks like this:

doThisThing  -argument:value
thenDoThis
andThenThis  -argument1:value -argument2:value

I know, I know – this is not at all original. It looks a lot like any shell, and that’s clearly what I emulated. (I was doing a fair amount of Powershell at the time, I remember.)

Back then, I wrote a parser for this in C#, for the Denina project. It would take in the text above, and return a configuration object with a clean set of objects to represent the commands and arguments. I could then use that in whatever software process I was managing.

Recently, I had been thinking about a new application for it. I wanted a version of it in JavaScript, along with some enhancements.

…but I just did not want to write this. Parsers are notoriously tedious to write, and it usually devolves to a lot of debugging. Consequently, I was procrastinating.

(You might be looking at the above example and thinking, “But that looks so simple…” Well, read the spec linked below. There’s a lot going on there you can’t see.)

So, I figured this was a good scenario for vibe-coding. This is a pure code problem – there’s no UI in this case. Additionally, this is easily testable – the text turns into an object, and it’s pretty clear if that object is configured the way it’s supposed to be.

I’ve vibe-coded some stuff before, but this was a little different because it wasn’t meant to be disposable, throwaway code. I wanted to keep this for use in production environments.

I decided that I just need to specify very precisely how this was supposed to work, and make sure there was as little room for interpretation as possible.

I decided to write a “spec” for the language. I figured this would be the safest way to explain to AI how it works. This wasn’t meant to be a formal spec (a la PEGN, or whatever), but just a very descriptive explanation of how it works that could double as documentation.

And here it is –

Configuration Language: Specification

That’s 2,000 words and dozens of examples. It took about 90 minutes to write the first draft.

I figured it was in great shape, but just to be sure, I uploaded it to ChatGPT with this prompt:

Read this and let me know if anything is vague, contradictory, or otherwise doesn’t make sense.

It came back with 27 problems.

Some of them were nitpicky, which annoyed me… but that doesn’t matter. If I was asking to AI to write this, then it only mattered that AI understood it. In this case, lack of context was a benefit – AI was coming at it with no prior knowledge, while this idea had been kicking around in my human brain for a decade.

Besides the nitpicking, some other issues were quite valid. Some changes were clarifications to the doc to better explain what was in my head, but others were actual, meaningful decisions I hadn’t thought of, but had to come to a decision on.

For example:

someCommand -argument
someCommand -argument:

Does the trailing colon on an argument matter? I had initially stated in the spec that an argument without a value got a default of “true” (as if to say, “this argument exists”). However, if I end an argument name with a colon as if I’m going to supply a value, but then I don’t… is that the same thing?

No, I decided. If you end with a colon, then that’s an empty string value. I would have never thought to specify this, and having AI bring it up evolved the language and covered an edge case.

I went through this same process dozens of times for other edge cases I hadn’t thought of.

Once I had finished editing that first round of complaints, I told ChatGPT to forget the prior conversation and sent it the text again with the same prompt. I don’t remember what it came back with, but it was damn-near the same number of problems.

I spent an entire morning like this – working on this specification document “alongside” AI. I would edit, it would nit-pick some more, and so on and so on.

I finally got it down to complaining about a single-digit number of really weird problems, and decided an AI could finally take a run at writing it.

I used Claude in Visual Studio Code in agent mode. I told it:

Read this document and create that functionality in a single-file JavaScript module with no external dependencies. Export all classes. Write unit tests to ensure proper implementation.

It took 14 minutes, and I’m happy to report that the results are stellar. It wrote 45 unit tests (all of which passed, after a couple attempts and edits). Performance is exceptional: a fairly complicated chuck of CL parses into an object in about half a millisecond.

I looked through the code a bit. From what I can see, it’s not particularly clever – it’s what you would call a “brute force” parser. It goes line by line and does string spitting to divide everything up. Lots of conditionals and loops. At the risk of sounding defensive, I easily could have written this myself.

I asked for a couple changes – nothing that would affect the spec or the underlying language, but rather just some preferences for the JavaScript implementation. And I changed the name of one construct after some second thoughts. (I had to tell it to unit test the changes. I think it’s up to 49 tests now.)

I’ve been using the resulting code for a week and it’s faded into the background in the sense that it “just works.” Performance is great, and it’s never made a mistake that I’ve detected, so it’s become a lovely black box that I don’t have to care about.

So, what did I learn from this, and what existing notions did it reinforce?

Vibe-coding is really good when you have a tightly defined use case with objective results that are easily unit-tested.
It’s helpful to write documentation in advance and use it for context. I basically documented non-existent software, then just told AI to write some actual software to match what I wrote.
It helps to have very clear demarcation lines around the code. What AI wrote was really modular (I literally told it to write a module). Nothing in here will “leak” into other code. This matches how I use AI to assist when coding: I always ask it for “a pure function with no side-effects or dependencies to do …X.” That keeps AI-generated code tightly confined.
Did vibe-coding this save me time? …I don’t know. I probably had 4-5 hours total into this. Could I have written the parser in that amount of time with the same performance and quality? …maybe?

Get second opinions – AI and otherwise. Fight battles with the idea before code gets written. If you assume the code will be fine, what are the other questions that need to be answered?
It helps to have a clear plan. I’ve spent a decade “with” this language in another project. I knew it worked, so I had an evolved (or so I thought) mental model of what I wanted.

And this last point perhaps gets a little philosophical.

What was the main thread of work in writing a JavaScript parser for my configuration language? Was it writing the actual code? Or was it deciding what problem I was trying to solve, how I wanted it solved, and all the different ways it might go wrong?

Ankur Goyal has borrowed the term “async programming” to describe this:

The shift is subtle but powerful: instead of writing code line by line, we’re learning to describe problems clearly and let tools solve them in the background.

[…] AI isn’t replacing programming, but the most valuable parts of programming are becoming more prominent while routine tasks move to the background.

(And I did, in fact, let AI solve my problem “in the background.” Once Claude started running, I think I set my laptop down and went to get breakfast.)

Honestly, writing the actual code of this parser just wasn’t that important. It really didn’t involve a lot decisions – I even told Claude not to use any dependencies, so there weren’t many questions about architecture (it’s not going to write a parser combinator library from scratch, so brute-force was the only real option).

This reminds me of the book How Big Things Get Done: The Surprising Factors That Determine the Fate of Every Project, from Home Renovations to Space Exploration and Everything In Between. It’s written by a guy who has spent his career studying large-scale construction projects like dams and nuclear power plants.

One of the core ideas of the book is: think slow, move fast. Few projects ever fail from lack of planning. The book encourages lots planning, edge case speculation, proofs-of-concept, and “red team” analysis. That’s where the problems get identified and the core idea and solution starts to emerge and get refined.

And that’s what we’re trying to get to: the core nature of the problem and the solution. We’re trying to solve problems, not write code. The code is just the solution vector. I’m not trying to trivialize it by any stretch, but the real obstacle was not what ended up being just 395 lines of JavaScript – it was the problem definition and the decision of how to solve it.

Two-Stage Content Modeling

Sun, 21 Sep 2025 00:00:00 -0500

I’ve been wrestling with a question: how much power should AI have over your CMS repository? In particular, how much access should it have to your content models?

There’s an argument that we should let AI do whatever it wants to our models. I’ve seen lots of stories about how people are just letting AI engines modify their content models to fit the requirements of whatever output they want.

I’ve argued against this –

Queen Bees: The Resurgence of CMS Repositories in the Age of AI

My concern is that content models are foundational. Lots of things depend on them. If you change a type carelessly, you can easily break some functionality you might not even know existed.

For example –

One day, you decide not to show the “Date Published” on your blog post pages anymore. So you let AI delete that from the model – since you don’t see it, you don’t need it right? It makes it easier for editors, since it simplifies the interface.

Unfortunately, unbeknownst to you…

…the “Date Published” property was used by a syncing process that transmitted new posts to your PR agency
…the blog post listing page and RSS feed both require the “Date Published” to show the order of the posts; no date, no listing
….your regulatory archiving process needed the “Date Published” to calculate retention times

But, you claim, the date was a required field for these exact reasons! It was safe!

…well, it was required and safe when it existed. No property at all means no validation.

And this is my biggest concern with not being jealously protective of our content models. It’s short-sighted to build them based only on what you can see or what output you want. It’s just as short-sighted to modify them based on the same criteria.

I had a debate about this some years ago with my friend Allan Thraen. I think it was just after I taught a CMS class for Hack Your Future in Copenhagen. In that class, we were letting students add stuff to their models all they liked.

The students had a great time, and I briefly caught myself thinking that maybe we were too strict over our models? That led to a discussion that resulted in this post:

Repouring the Foundation: The Perils of Content Modeling on the Fly

And Allan responded with this:

The Curious Case of Content Modelling

Which brings me back to the core question: should we let AI into our models?

Sure, sure, in a perfect world, the AI engine would have a ton of context. In our example from above, it would know that the “Date Published” property was being used in all those different ways and would know not to touch it.

But in my earlier post, I also made this point:

I get a little skeptical when people talk simply of “AI” as if they can guarantee that all their employees will be using the same engine with the same settings and the same context.

In reality, I think we need to say “an AI” to represent that every AI is like a new freelance contractor that shows up to do a job, without knowing any other contractor that has worked in the past or may be working right now.

One solution, of course, is just to deny content model permissions to anyone but a selected few technically-minded people. And this is great… but now we’re back to the original state of not allowing AI in either.

Something else I said in that post:

AI will simply magnify the volume of activity a single human can initiate

Put another way: with AI, people can do stupid things at scale.

So, how do CMS and AI get along? How do we empower the amazing things that AI will allow and prevent disasters?

I got to thinking about this out loud on a Content Matters podcast episode with Dave Hillis, the CMO of Ingeniux. Dave and I go way back, and he thinks pretty deeply about CMS. He had read the blog post from above, and that kind of framed our conversation about how CMS and AI are going to get along in this brave new world.

An example I always use in modeling is a field for “Mood.”

Let’s say we want to add “Mood” to our content model, to represent the mood the CEO was in when she wrote whatever she wrote. This is kind of silly, but it represents something that might be added to a model on a whim only to be deleted later. Also, it doesn’t affect anything else – it’s harmless, essentially. As a developer, I don’t much care if they have this property on their model or not.

So, how do we enable this level of manipulation? How do we let an editor tell AI to add a “Mood” property so they can type stuff in a textbox and have it output on the page?

I think the solution is two-stage modeling. We’re going to need to concede that not all parts of our model are equally important – some parts of it need to be protected and some don’t.

We can divide the properties on our types into two “stages” then (in quotes because I don’t know if that’s the right nomenclature; I’m still thinking about it):

Level 1: These are properties created by a developer that have significant impact on the functioning of various digital properties. I put these on “Level 1” because they’re foundational – everything is built on top of them. If the foundation of a house shifts, you have problems.
Level 2: These are whatever the editors want. They can add and remove to their heart’s desire, provided they don’t duplicate a property name from Level 1. This is where the “Mood” property can live – go nuts, fam.

Implicit in this is that AI acting as an agent of the user (…right?!) would have delegated access to Level 2, but no access to Level 1. Level 2 would effectively be a “sandbox” where nothing structural was attached.

The key is that the effective content model is the combination of those two. The actual model of content delivered downstream is both levels together, as one unit. Nothing outside of the modeling system even needs to know they exist at different levels of import.

For a blog post, what goes in Level 1? I’m thinking just Title and Date Published? Those are basically required – the date for the reasons we mentioned above, and the title just because we have to list content objects somewhere (lots of systems will default to “Untitled” because without a name, content gets hard to work with).

What about Body? …meh. Maybe?

You technically don’t need a body for a blog (a tweet might be considered a title with no body?). Additionally, as a developer, I’m not sure I care much about the body? It needs to be output in the template, sure, but that might not be my concern. And by putting this on Level 2, editors can change it – they might want different validation or different rich text options or whatever. If someone else is doing the templating, then a lot of that becomes less crucial to core development.

Now, to be clear, lots of systems can already do this via various features.

Some systems have very granular permissions around every property on a type. I remember that Sitecore allowed detailed permissions down to the field level (everything in Sitecore is a content object – an “item” – so content models are actually defined as collections of content objects).

Some systems use composition or inheritance in their content models, where a content type can be a merging of two other types. This means we could model Level 1 in one type (“Blog Post Foundation”), Model 2 in another type (“Blog Post”) which incorporates the Level 1 type, and then just secure permissions so that very few people can modify the Level 1 type.

But, of couse, this all comes down to granular modeling permissions. If you don’t have that – meaning users just have binary, all or nothing access to modify the models – then I’m not sure any of this matters.

Assuming we have that level of permissions control, these model architectures work well. In addition to being efficient and reducing repetition, they have some neat two-stage implications and allow you to segregate parts of your model into the important stuff… and all the other stuff.

Given that the required permissions and architectures already exist, then what are we talking about here, in terms of CMS evolution?

Nothing, really. We’re just talking about modeling practices, effective permission management, and making sure we treat AIs as extensions of humans – no AI should have more access than the person who can give it a prompt.

With this in place, we’re a step closer to living in harmony.

Where's the Line Between the Web and Your CMS?

Wed, 17 Sep 2025 00:00:00 -0500

A couple weeks ago, I wrote about a stupid thing I did with redirects once.

My friend Andy Cohen reposted it on LinkedIn, and, among other things, said this:

Redirects don’t belong in the CMS layer

I’m inclined to agree. I think a CMS can be a source for redirect data, but I’m coming to believe that any redirection should happen long before anything arrives on your CMS’s doorstep. In fact, a lot of things should happen before anything is serviced by your CMS.

I self-host this site – cached and proxied through a Cloudflare tunnel. It’s on a bespoke system that has grown organically over seven years. It’s basically a templating and organizational layer on top of 6,000-ish Markdown files.

Last week, for whatever reason, I was running the server in the console, which meant I was watching the requests march down the screen, Matrix-style.

What I was seeing was mostly redirects.

I quickly learned that I wasn’t sending cache headers with redirect responses. It didn’t occur to me that they have “cachability” like anything else. So I fixed this.

But there was still a lot of damn redirects. Remember that this site used to be Gadgetopia, which on the web since 2002. Given the URL footprint (7,000 or so unique inbound URLs) and the longevity, the site gets a lot of random traffic. It’s mostly bots, I’m sure, but there are still a lot of links out there.

A few years ago, I salvaged about 350 of those posts, then pushed the other 7,000+ off to another site I called the “archives” (an example). Getting people there involves some logic, because some posts redirect here, some there, etc.

I had built that logic into my CMS, but the wastefulness of this suddenly occurred to me. I’m no longer adding to Gadgetopia, and that content is not going to change. With Andy’s prompting, I decided that this doesn’t need to be in my CMS. My CMS can be a source of information for it, but the action of all these things should be somewhere else.

I wrote a simple exporter to get the old Gadgetopia URLs out to a Cloudflare redirect CSV, and uploaded that via their Bulk Export. Instantly, that dropped inbound traffic by 80% - 90%. To be fair, the overhead of that traffic was low – the requests were redirected early, and the responses were all empty bodies with just a Location header, but still…

So, that’s a CMS being a source for redirection, but not the actual executor of the logic. Simple enough.

But, I had a bunch of other logic that just didn’t need to be in my CMS.

I have a rule that an inbound URL either has to end with a trailing slash, or have a dot (“.”) in it (meaning a direct request to a file). If you try to come into a path without a trailing slash, you’ll get redirected.
I filter querystring args. I have a list of arguments I use for the site, and the CMS will strip anything not in that list and redirect you back without them. I do this so that the URL you see will be “clean,” stripped of any marketing cruft, in case you bookmark it or share it out again.
For the same reason, the URL needs to be normalized. Any double slashes, parent pathing, or upper-casing will be corrected and redirected.
I have a “kill list” of URL patterns that are DOA. These are mostly hack attempts to random WordPress-ish directories or other vulnerabilities (anything containing non-ASCII characters, for example). These are detected and 404ed very early in the request.
POST requests are only allowed through a very narrow range of paths.

And there are some more, getting increasingly esoteric. I have these in a class/infrastructure I called a PathFilter.

The goal is that any inbound URL that’s actually processed by my CMS should be… perfect. Maybe this is anal-retentiveness, I don’t know. But I steadfastly maintain that there’s value in being protective of your “URL-space.” URLs are “tickets” to content. Keep your tickets in order.

To handle this logic, I created a Cloudflare Worker.

You can route all inbound traffic through a JavaScript function (the “Worker”). That JavaScript can do whatever it likes, up to and including servicing the entire request via some MVC-ish mechanism.

My Worker examines the request, does the logic noted above and some other stuff, and either redirects, 404s, or passes the request through. Essentially, you can program against Cloudlfare’s CDN logic.

Cloudflare tracks execution in two ways:

CPU Time is just what it sounds like – how long a CPU took to process it. This is essentially nothing. Usually 0ms, but occasionally 1ms.
Wall Time is how long the request got held up at the Worker, all things considered. This is generally in the 10-20ms range. Sometimes higher, but I’m curious how long my bespoke code was taking for the same thing.

Does this bind me to Cloudflare? Yeah, loosely. The logic is contained in JavaScript, which could probably transport to any other proxy that allows it. Or I could write it in my own Node-based proxy.

Now, none of this is new. Cloudflare Workers have been around since 2017.

But the whole thing got me thinking about the division of responsibilities. How much work should your CMS do on the incoming request? Is that the highest and best purpose of your CMS – just figuring out if it should even service the request? Or should that work be pushed off somewhere else?

At this moment, my CMS can trust that every single inbound request is one that should be serviced. I pulled hundreds of lines of logic out of the CMS – deleting an entire subsystem, in fact. For all my CMS knows, the web is a lovely place where all URLs are perfect and no mistakes are ever made.

I’ve started to take this a step further, and I’m separating the idea of my CMS from the web server entirely. It’s not headless – the web server will have a native connection to the CMS (via a C# API). So it’s not remote, but at the same time, I’m divorcing the concept of my CMS and my web server.

So, even if your system is installed on your own metal, there could be an argument to have two systems: a CMS, and then a web server integration. Requests hit your web server, are processed by your web server integration code, and then call out to the CMS code to be resolved against content.

As a neat side effect of all this, static file generation is a hop, skip, and a jump away. Since my CMS is just producing HTML and providing it to a web server – with no notion of it being used to satisfy a web request – then who says we can’t just write it to a file instead? My web server is now calling an HtmlOutputFactory in a DLL that I can also invoke from the command line and get the exact same HTML that the web server gets.

At some point, I’d like to see if I can serve the same website from an entirely different web server (not Kestrel, the default web server for ASP.NET). I’ve been smitten lately with SimpleW, and I think under the new architecture, I could serve the exact same site from it in about three lines of code.

And consider the inverse: could your static site generator be hooked up to your CMS as a dynamic content generation system? Could it generate a single path at a time, on demand, and return that to your CMS? The lines get really fuzzy here…

This is probably an example of turning around in a circle to end up right back where you started, but it was a educational experience. …or a re-educational experience? I think these were all concepts I knew, but had lost track of for some reason.

Anyway, thanks to Andy for his LinkedIn assertion that flipped some bit in my brain and allowed me to separate the two concerns more clearly.

Content Query Languages

Thu, 4 Sep 2025 00:00:00 -0500

I have a weird fetish for blurring the lines between code and content in CMS. Traditionally, you have code which is written by developers, and content which is written by editors, and never shall the two meet.

But what happens when editors need to write some code-ish stuff? What happens when things fall into the middle – too simple or ephemeral for a full developer, but too complex for an editor using a UI and the patterns established way back during implementation?

Can we enable editors to …sort-of develop? Can we create a new class of editor called a “citizen developer”?

I’ve talked about this a lot. I hinted at it 20 years ago, in the context of templating languages:

Smarty as a “Sub-Language”

Then I wrote about it explicitly 10 years ago:

Editorial Scripting in CMS

That post eventually became a full-blown scripting library called Denina. Here’s me talking about that at the Umbraco Codegarden event in Denmark.

The wiki for Denina includes some good content about the philosophy and prior art behind this:

I’ve never stopped with this weird obsession. Here’s me in Croatia in 2023 talking about the entire concept of “scriptable software” (clearly, I was stuck on the “promise and peril” title motif).

I spent five years at Episerver/Optimizely, and I ~~think~~ know I drove people nuts there with my attempts to bring scripting into that platform.

Lately, I’m focusing this obsession to content querying and aggregation: how can we use code concepts to find content and bring it together into the groupings that we need?

I’ve often said that the way a CMS aggregates content is really the soul of the CMS. And learning all the tools to query and bring content together is often the most challenging part of understanding a CMS. It usually represents a level of “mastery” of that CMS.

Most CMSs try to implement aggregation tools visually in some kind of UI. The zenith of this approach might have been Drupal’s various query builders, as part of the Drupal Views module (which I think is in the core now). In my (ahem) view, this was the outer fringe of where you could go with a UI. Drupal Views almost constituted its own software.

Admittedly, Views included a templating layer, which added complexity, but it’s still trying to encapsulate a very complicated layer of query logic into a clickable UI.

I’ve had a running love affair with query languages, especially when it comes to CMS. I’ve always been curious if it might be easier to simply train editors on how to write some light “code” rather than fiddling with a complicated UI.

To this end, I’ve tried several times to implement content query languages in text. I like text queries because they’re precise and they can be easily stored as content (indeed, they’re serialized by definition).

A query is, in some ways, a content object. It should probably be versioned and have permissions and such. And if you put it in a reusable component, then you have this thing you can move around that will magically produce other content.

(OMG… it’s like a… prompt… but more on that below…)

My first attempt was in Episerver, about a decade ago. I did this brutally simply: on save, I picked a set of key properties to flatten into a simple database table. Then I let my customer embed a component that contained a query against that table. It got the matching content IDs from my supplemental SQL table, then looked them up through the traditional API in the context of the visitor (thereby complying with permissions and personalization and languages and all that).

My customer could embed components in rich text. The component had a field for “query” that would look like this:

type = 'article' AND category = 'agriculture'

That’s literally just the WHERE clause of a SQL statement that ran against a simple, flat table that was indexed well. Simple tables make sense to users because they’re all familiar with Excel – rows and columns are clear and ambiguous.

I wrote about that project a bit here:

Supplemental Indexing in Content Management

Having a separate index of CMS content, structured for optimal querying, can help you solve a lot of sticky problems.

More recently, I wrote a variation of SQL that I called “TreeQL” that was designed for a hierarchical content structure. You could write something like:

SELECT descendants OF /news/ ORDER BY depth

My code (it’s on GitHub) simply parsed that using Parlot (a really great parser combinator library) into a C# object, using which you could implement your own search logic. I have a video of me using that in an Episerver add-on here.

For Episerver, I used the object to convert it to LINQ, which was slow. If I took it further, I would have used Opti Find or Opti Graph or something.

And lately, I’ve been fiddling around with another query paradigm using a “filter” model. In this model, the editor writes a series of directives that progressively carve a subset out of a larger dataset.

You start with the entire set of records. You can include records to establish a subset, then include records from that subset, or exclude records from it (those essentially do the exact same thing, just from opposite directions). Each include or exclude directive operates on the result of the prior one.

include: parent = /news/ or /events/
include: type = article
include: year > 2020

exclude: internal is true

sort: date descending
take: 10

Now, if you’re a developer, you might be looking at this with some level of condescension. I get that. But this is not for you – this is for non-technical editors who know what they want in very basic, logical terms.

Your could even make it simpler by rolling up some of the different queries into dedicated directives. Like this:

path:  /news/ or /events/
type:  article
since: 2020-01-01

I’ve found that when designing syntax, you sort of have to work in metaphors. And the metaphor of a “pipeline” that “filters” is something that non-technical people seem to understand well.

These are all examples of what are formally known as “domain-specific languages” (DSLs), or colloquially as “little languages.”

Some concepts that are very basic developers to are just too abstract from editors – branching, variables, looping, etc. Editors like “straight line” execution, so those are a step too far. But how far is too far?

Well, that’s the trick, really…

Anyway, my first swing at translating this to code was insanely inefficient, swapping it in and out of memory. But then I realized that you can use Common Table Expressions (in SQLite, specifically, though they exist in most SQL databases) to distill this directly to SQL:

WITH
all AS (SELECT * FROM articles),
x AS (SELECT * FROM all WHERE (parent = '/news/' OR parent = '/events/') = true),
y AS (SELECT * FROM x WHERE (year > 2020) = true),
z AS (SELECT * FROM y WHERE (internal = 1) = false)
SELECT * FROM z
ORDER BY date DESC
LIMIT 10

CTEs are very fast – with a few thousand records and zero indexing, that query will run on my laptop in about 10ms. And derived fields will cascade “down” the list, so if I create some calculated field in the base query (the first one) and name that field, the users can refer to it just like it was in the underlying data, without ever knowing it was invented.

Of course, the translation to SQL assumes a simple relational table model, but as I mentioned above, I’ve used supplemental indexing to effectively “fake” this on-the-fly, alongside my CMS repository. (SQLite in-memory databases are really handy for this – copy in all the data on startup in a few seconds, then keep it updated; rebuild on a schedule just to keep it accurate.)

Again, rows and columns make sense to non-developers, so the mental model is clear. If your data isn’t rows and columns, create a representation of it that is.

If you don’t have an underlying table, you’d just need some other type of translation into whatever API you do have.

As with any language design, the trick here is to assume as much as possible.

By default, I’m assuming the table and the fields. I’m removing any concept of joins, and I’m replacing the concept of parenthetical WHERE clauses with a modeling of “whittling down” the entire dataset progressively.

The way I have this currently written, the directives are extensible, so you could wrap them around your own content model.

I work at Staffbase, and here’s what it might look like to aggregate multiple news channels if I wanted to insert a list of news in a page (this would be wrapped in a “widget” you could drop into text from the UI):

channel: 'CEO Blog' or 'Marketing Minutes' or 'New HQ'
type: social

filter-out: text contains 'confidential'
filter-out: audiences includes 'External Contractors'

sort: date descending
limit: 3

(To be clear, this is a little contrived, because we do have a pre-built widget that does roughly this same thing. But there are always edge cases that any pre-built thing wouldn’t cover.)

The thing I wrote above about assumptions is even more true for specific implementations. Given that I know the underlying model and purpose of the content, I can write channel and ‘type’ directives specific to the content. And with any implementation, I can change directive names – like filter-out rather than exclude – to fit what my editors will understand best.

Now, by this point, you might be screaming: but this is what we have APIs for!

I get that. But the difference with a “query language” if that it exists in text. And this matters. Editors can write text in an input box. You can serialize text and store it. You can provide a bunch of content-like services to text, which you really can’t do to API code that runs in the native computational process of the system.

I wish more vendors would implement this.

Sanity has something called Graph‑Relational Object Queries (with the fantastic acronym of “GROQ”), which is this exact concept. It looks like this:

*[_type == 'movie' && releaseYear >= 1979] | order(releaseYear) {
  _id, title, releaseYear
}[0…100]

That’s a little complex, but I’m quite sure it’s powerful. And kudos to them for providing the option.

And then, of course, there’s GraphQL, which is the closest thing we have to a standard in the content space. It looks like this:

query {
  empireHero: hero(episode: EMPIRE) {
    name
  }
  jediHero: hero(episode: JEDI) {
    name
  }
}

I’m happy that there’s some kind of standard, but GraphQL is verbose to write (so many braces…), and it’s really designed for two things in particular:

Hiding the underlying implementation and letting you design your own model facade at the query level
Careful specification of output format, specifically to avoid “over-fetching” and return only what you need (partially for network efficiency when delivering directly to clients)

Part of what I’m trying to find is the happy balance between expressiveness/power and approachability.

I’ve been encouraged recently by what the research firm Ink and Switch has been calling “malleable software.” This is an emerging term to refer to software that can be modified by the end user. Their definition is more for end user software, rather than CMS software with a group of editors, but I love how the concept of software as an amorphous concept that should wrap around the user’s needs is starting to emerge.

And, of course, what will AI do to all of this? Will AI eliminate the need for explicit query languages entirely?

…maybe? While we might just store a prompt – “Give me the last 10 articles about the new headquarters project…” – that’s still a “query” at some level. It’s still serialized to text and writable by an editor. And you would need some understanding of how it will be interpreted to get what you want out of it – with experience, you’ll come to understand how to get the machine to give you what you want.

The problem I see right now with this approach is that AI is non-derivative, and it can give you a lot of different variations of solutions for the same problem – it’s currently the opposite of “precise.” You would need to turn the temperature setting way down, I think, to ensure some consistency in how it’s interpreting queries. When it comes to querying content, the fuzziness of AI is just not appropriate.

So, there are lots of questions and experimentation here, but few hard-and-fast answers. I’ve implemented a few of these for customers, but I’m still waiting on the perfect opportunity to take it a step further.

That opportunity will be a specific combination of content domain, editor experience, CMS capabilities, and situational requirements.

Postscript: Samples

I started playing around a bit with my query tool that I explained above. Here are some samples. These are being run in real-time against the SQLite database running behind this website (the content is in Markdown, but I have a content index in SQL for navigation and such).

This site runs on a block-based templating system, so I wrapped this functionality up in a block and embedded three of them below, complete with some debug information.

As I mentioned above, CTEs are really fast, and the backing table is pretty well-indexed. At this writing, it has 9,328 rows.

Here are the last three blog posts –

Parse: 0ms
Query: 8ms

include: path starts /tech/blog/
sort: date desc
take: 3

WITH
a AS (SELECT * FROM records),
b AS (SELECT * FROM a WHERE (key LIKE '/tech/blog/%') = true)
SELECT * FROM b
ORDER BY  date desc
LIMIT  3

James Bond-related books that I own. This uses a custom SQLite function that I wrote to find an element in a JSON array stored as a field value.

Parse: 0ms
Query: 17ms

include: path starts /library/titles/
include: tagged with james-bond
sort: title
take: 5

WITH
a AS (SELECT * FROM records),
b AS (SELECT * FROM a WHERE (key LIKE '/library/titles/%') = true),
c AS (SELECT * FROM b WHERE (json_has_element(tags, 'james-bond')) = true)
SELECT * FROM c
ORDER BY  title
LIMIT  5

Content containing the word “gumby.” (I don’t know why I use this word, but apparently I do.) This uses SQLite’s full-text indexing system.

Just to prove a point, I filtered out this post (the one you’re reading right now) using an injected variable. Just before I parse the commands, I run the source through a Fluid execution, replacing the variable {{ doc.path }} with the path to this document. (It’s a full templating engine. You could do lots of stuff here.)

(Worth saying: that’s another reason why text is great – you can manipulate it easily.)

This is kind of handy, because you could embed the same script on lots of pages (or in a template), and it would provide varied output because its effective source would be contextual to the data from the page on which it’s executing.

Parse: 0ms
Query: 26ms

include: text matches gumby
exclude: path is not {{ doc.path }}
sort: title

WITH
a AS (SELECT * FROM records),
b AS (SELECT * FROM a WHERE ((key in (SELECT path FROM search WHERE text MATCH 'gumby'))) = true),
c AS (SELECT * FROM b WHERE (key = '/tech/blog/content-querying/') = false)
SELECT * FROM c
ORDER BY  title

Update: GROQ by Sanity

With some help from Knut Melvær, I did play around with Sanity’s GROQ a bit. It’s actually quite expressive and simple to pick up.

Consider this query:

*["timeline-computing-history" in timelines[]._ref] | order(dateRange.startDate)
{
  "id":_id,
  title,
  "desc":shortDescription,
  "date":dateRange.startDate,
  "timelines":timelines[]->{"id":_id,title}
}

That’s pulling content from a POC that Knut (graciously) threw together in response to this post: CMS for Historical Timelines. I actually didn’t need anything but the top line. Everything below it is just a “projection” to shape the results.

And kudos to Sanity for some great documentation. This page alone is worth volumes of traditional documentation.

My Own WTF, or How to Not Handle URL Redirects

Wed, 27 Aug 2025 00:00:00 -0500

About 10 years ago, I did a CMS migration for a large health system.

With the new CMS, they were changing the URLs of about 100,000 pages, so we did a standard redirection strategy. We had the old URL stored with the new content, so on app startup, we iterated all the content and loaded a URL lookup table into memory –

Old URL → New URL

When a 404 comes in, look for the old URL, send a redirect to the new URL. (I wrote quite a bit about that strategy here: Patterns in URL Redirection After CMS Migrations.)

This is all pretty standard. Even 100,000 key/value pairs doesn’t take a lot of space in memory, and creating that structure took about 90 seconds on app startup. It was done in the background, asynchronously, so it would become available just over a minute after the site came online. Given that the app restarted pretty rarely (once a month, maybe?), this was fine.

However, I made a critical mistake: I didn’t actually start the process on app startup. For whatever reason, I triggered the creation of the lookup table when the first 404 came in.

The first 404 would look for the data in memory, and if it didn’t exist, it would then kick of the 90-second process to create it. I figured this was pretty efficient.

What I didn’t realize is that this site got a lot of traffic. And in the 90 seconds after that initial 404 started the process, a lot of 404s would come in. The site was big and had been online for a long time, so it was constantly being pelted with 404s. I’m sure most of this traffic was from crawlers trying to access the accumulated history of dozens of URL changes over the course of a couple decades of existence.

This means that for 90 seconds (theoretically) every single 404 kicked off that same process. Until that first process completed and the lookup table was in memory, all those 404s wouldn’t find the data, and they would dutifully set about creating it.

We launched the new site, and it mysteriously kept failing. Seconds after launch, the web server process would go ballistic until it stopped responding, at which point we’d fall back to the old environment. I never checked, but at some point, I’m sure we had hundreds of threads trying to iterate all the content and create the same lookup table in memory.

This happened on three consecutive days. Each day, I had “fixed” something which I suspected was the problem. Each day, I was wrong.

Needless to say, the client was just thrilled with all of this…

Confusingly, there was no excess memory usage, because as each process completed, it overwrote the table that was there, so we only ever got the one table in memory – we just had hundreds of processes overwriting it again and again.

In theory, it would eventually resolve itself, because when the first process would finally write the data, the process wouldn’t be started again (because new 404s would find it in memory), but we never got to the end of that chain of processes, because the server would straight up die before that point. I suppose the server would have chewed through it eventually (90 seconds turning into 90 minutes or whatever), but we could never wait that long.

Since the problem seemed to be CPU-bound, I started looking for infinite recursion somewhere, and I wasn’t finding it.

I don’t remember when I figured out what was going on, but when I did, I felt like the sky fell in on me. Realizing the sheer stupidity of what I did was epic.

I believe I got very quiet. I think I laid my head on my desk for a long period of time.

I fixed it by setting an “in process” flag when the first process started, and just returning an actual 404 and bailing out for every 404 that came in during that 90-second window so that only one background process was ever running at a time. There were undoubtedly better solutions for fixing and improving this, but it needed to be done in a hurry, so that’s what I did.

It’s a perfect demonstration that you need to test error conditions like lots of 404s. Consider that –

The average load test would have likely only tested URLs that existed, so it would have never triggered this
Even if my load test included a single 404 (it didn’t…), the problem would have never surfaced on a single 404 (indeed, that was the exact situation I had coded it for)

To be fair to me, these two points made it a non-trivial thing to discover. What test would you put in place for this?

The only thing I can think of is that I could have pulled web logs from the existing site and found some way to “replay” them on the new site. That would be the best way to simulate real traffic (indeed, it wouldn’t even be “simulated” at that point – it would be the actual traffic).

But, clearly, I made multiple mistakes in how I coded this in the first place. It was not my finest moment.

Update

Added on August 28, 2025

I sent this to the client developer that was on the project all those years ago. He responded:

[pats Deane on back] We’ve forgiven you. It’s time to forgive yourself.

CMS for Historical Timelines

Tue, 26 Aug 2025 00:00:00 -0500

I’ve often said that the last thing the world needs is another CMS. Yet, here we go…

I read a lot of history (literally five minutes ago, I finished And the Band Played On).

To understand history, nothing beats a timeline.

They help me put things into context. I like seeing when something began, all the different phases it went through, and what their relative timespan was. This is what it takes for me to sort something out in my head.

I’ve often thought about coming up with a software system to manage timelines – a “CMS for history,” if you will. This post is an exploration of that idea, along with a bunch of supporting links and random stuff I’ve gathered over the years.

My goal would be to find some data model that could represent the passage of time, the events that occur within it, the geographies associated with those events, and actors that were involved in them. With a solid model behind this, you could visually represent it in different ways, query it around the involvement of various entities, and even overlay different timelines to see where they intersect.

Some random use cases:

Learning. This is the primary use case – to be able to more clearly visualize the passage of time and the events that occur within it. In particular, there are some historical threads I’ve been studying on and off for years. I’d like to start building and maintaining timelines of them all.

Event planning and coordination. I’ve been involved in some conference organization which required planning for specific things to occur, down to the minute in some cases – “At 8:32 a.m., Person X has to be Location Y,” etc.
Event reconstruction. This is a derivative of #1, but consider a crime scene or accident investigation that needs to recreate several places, people, and events across time.

Research organization. Lots of history books, autobiographies, and memoirs involve plotting a lot of observations on a timeline.
Real-life logging. Sometimes you need a log of where people are at specific times. Imagine application logging…but for people.

Last year, in an effort to research this, I made a post to the History Stack Exchange: Is there a formal ontology for documenting historical timelines? I wrote, in part:

How do historical researchers organize their notes? If you’re researching and documenting the history of…well, anything, are there systems designed to keep track of “the timeline”?

I’m reading “House of Gucci” right now, which is the long, storied history of the Gucci family and company (it was the source material for the 2021 movie starring Lady Gaga). It’s incredibly detailed, and I find myself wondering how did the author keep track of it all? It had to be something more elaborate than a bunch of sticky notes on a whiteboard.

The resulting answers were few, but quite good. I learned that techniques used in the study of history are known as “historiography” (someone edited my post and applied that tag). A few mentioned mentioned some resources (linked below), but honestly, I had trouble conveying the concept of serializing history to a data model. Explaining it to non-CMS people was harder than I thought.

I ended up adding a music analogy, which I thought worked pretty well:

Musical notation is a codification of a concept (a series of audible sounds). It’s a standard protocol, which many people understand, and it’s used to serialize music into a recordable form. It’s transferable across time and space – I can write some music down that someone can play later, because we both understand the protocol. Does anything like this exist for historical timelines?

Still, no existing solution jumped out at me.

Getting down to nuts and bolts, in my head, the data model looks something like this:

erDiagram
    TIMELINE }o--o{ EVENT : "linked to"
    EVENT }o--o{ ACTOR : involves
    LOCATION }o--o{ EVENT : "occurs at"
    EVENT }o--o{ SUBJECT : "affects"
    ACTOR ||..o{ ACTOR : "member of"
    LOCATION ||..o{ LOCATION : "contained within"

    TIMELINE {
        string id
        string name
        int period
        datetime basePeriod
    }
    EVENT {
        string id
        int startPeriod
        int endPeriod
        string status
    }
    SUBJECT {
        string id
        string name
    }
    ACTOR {
        string id
        string parentActorId
        string name
    }
    LOCATION {
        int id
        string parentLocationId
        string name
    }

A Timeline is the largest object. They’re the “container” through which you view everything.
A Timeline has a Period. This is the minimum period of time the Timeline breaks up into. If you’re studying the history of Christianity, it’s probably okay to have your period be a full year. If you’re reconstructing the meltdown of a nuclear reactor, you might have a period of a second or less.
A Timeline has a Base Period, which is a point in time when the timeline starts.
Events are assigned to Timelines. An Event could be assigned to more than one Timeline, though maybe that’s over-engineering.
Events are placed on a timeline by Start Period, which represents the number of Periods from the Base Period. If your Period is 1 year, your Base Period is 5000 BC, and an event has a Start Period of 6100, then the Event occurred at 1100 AD.
Events can have an End Period as well, for Events that span time. An End Period of NULL meants the event is a point in time, not a span.
Events can be linked to one or more Actors. This is a network of humans that are somehow involved in the Event.
Events can be linked to one or more Locations. This is a network of geospatial locations that are somehow involved in the Event.
Events can be linked to one or more Subjects. This is a network of objects (purposely left vague) that are somehow involved in the Event.

The concept of putting events on a timeline is neither novel nor complex. However, it gets a little daunting when I bring Actors, Subjects, and Locations into it. In some senses, I am theoretically trying to represent everything on Earth.

The trick is in the details, of course. How in-depth you decide to go depends very much on what you’re trying to model – what historical concept you want to represent.

In tossing this idea around, I’ve uncovered some interesting things:

History Timeline is a software package that purports to do exactly what I’m seeking. However, it appears to be client software, optimized for printing, rather than data-driven, server-based software.
Someone on the Stack Exchange question pointed me to LODE, the ontology for Linking Open Descriptions of Events. That comes very close to what I want to do, but it’s more a transmission or serialization format. Additionally, it’s been around since 2009, and not a lot seems to have happened with it (but maybe that’s because it was so good on first draft?). Still, there’s a lot to be learned there.
I purchased a “World History Timeline” from a company called World History and Mythology. I was a little shocked when it was a Microsoft Excel download. Yes, they created a macro-enabled Excel document that they used to plot out the history of the world – each cell is a period (using my nomenclature from above), and each row is a grouping of some kind. It’s a spectacular work, but it was very difficult to browse for me. Honestly, the idea of Excel as a content delivery platform had never occured to me…
MermaidJS includes a timeline option for a diagram type (clearly, this is simply a visualization format). Here’s an example:

timeline
    title Deane's Life
    1971 : Born
    1989 : Graduates High School
    1997 : Graduates College
    1999 : Marries Annie

I even created my own web component to visualize timelines. It’s here (css is here) if you want to look at it. It’s unfinished, but it looks something like this:

Period 1

Period 2

Period 3

I found a company called History Factory that compiles organizational histories for companies. I’m not sure if they have any specific or proprietary software that they use for this, but I love the idea that they essentially produce timelines for a living.
There are lots of “timeline modules” for various CMS platforms. For example, Timeline for Craft CMS and there are literally dozens for WordPress
TimelineJS is a gorgeous open-source visualization tool from the Knight Lab at Northwestern University. It’s amazing, but it’s a visualization/design tool. It doesn’t have a lot of sophistication in the underlying data. (Put another way: the tool I’m dreaming of would likely generate data to power TimelineJS installations, among other visualizations.)
Here’s a spectacular timeline of world history. Again, this is a visualization, and I think it’s mostly a community project, not a product or platform. But it’s beautifully done.

So, there’s a lot of prior art here. I’m trying to thread my desire in between what already exists and figure out where there’s overlap.

Here are some open(-ish) questions I’m dealing with –

Is this a CMS? Yes, I think it is. This, of course, is is a bit of a “Holy War” question, but the Events, Actors, Locations, and Subjects and the relationships between them are unquestionably “content.” The only novel thing is organizing them in relation to time.
Would you build it on top of an existing CMS? More than likely, yes. Like I said, the individual entities are content and can benefit from all the services that a CMS already provides.
How is this different than a web calendar? A web calendar is always a human-oriented period by default, since it’s concerned with scheduling things for humans (consider documenting the Age of Exploration on Google Calendar…). And while they do have some Location, people (Actor), and resource (Subject) functionality, it’s only in the context of invitations, so not quite the same thing.
What parts of this are…novel? Very little, honestly. As I mentioned above, the entities themselves are core content, and the linking from events to Locations, Actors, and Subjects feels like a semantic triple to me. I think I’m just needing to add some conceptual “overlay” for the timeline piece of it. I also like the concept of arbitrary-length Periods that build on the Base Period, but that’s just math.

After writing this, I’m beginning to think this is just an editorial UI on top of another data management tool… but that’s what all CMSs are in the end, really.

So, that’s it, basically. That’s the idea.

Believe me, the last thing I need to do is create another CMS. But this idea simply will not leave me alone. And some recent research I’ve been doing about AI in relation to CMS repositories makes me think this would be easier to build than I had originally feared.

Please, someone, talk me out of this.

Update: Timelines for Fiction

Added on August 29, 2025

Earlier in this post I mentioned the book And the Band Played on, and in the Stack Exchange post, I referred to House of Gucci. These are both historical re-creations where timelines would be used for accuracy and research.

However, I just started reading the zombie novel World War Z (more known for a mostly unrelated movie with Brad Pitt).

I love the format of this novel. It’s a series of “interviews” with people who survived a zombie war that occurred sometime in the past. It’s very rashomonic in the sense that multiple people talk about the same series of events.

In just the first 30 pages, for example, I’m hearing bits and pieces about the “Warmbrunn-Knight Report” and “Flight 575” and some battle in Yonkers. None of this has been fully explained to me yet.

What this tells me is that there is a timeline to this. I assume the author wrote a detailed timeline of what actually happened, and then he wrote this novel by figuring out who had access to what information when. So there is a master timeline, and I’m just seeing different windows into it.

I love this use of a timeline. It’s something I would have never thought of.

How Should a CMS Repository Understand the Content Within It?

Sat, 23 Aug 2025 00:00:00 -0500

Last week, I wrote about how CMS repositories would need to adapt to the coming changes around AI.

I said this:

My belief is that the CMS of the future will be a set of strict rules around a content model, and that will be “beyond the reach” of AI. AI engines can do whatever they want with content, so long as they obey the model rules we put in place…

And, more succinctly:

A good content repository in the age of AI should be well-defended and well-described.

I decided to play around this with a little bit.

I wanted to create a “CMS repository” that was “well-defended and well-described.” I was wondering if I built out a repository in such a way that it would ensure good data and would be able to describe itself to AI agents, how would that affect my ability to apply AI-generated process agents to it?

Put another way: if we have a great repository, will we get better results from vibe-coding? Could the repository itself serve as an integral part of the vibe-coding process? Could I be “repository-centric,” and let AI handle all of the other work?

So, what repository system did I pick for this experiment?

SQLite

Now, you can argue that choice, but here was my reasoning:

It’s super easy to work with
SQL databases are, by definition, self-describing; every one of them will serialize the “content model” to a text file of SQL DDL
There’s effectively no “space” between the data storage and the SQL API, but I’ll talk more about this below…

My goal was to lock down a database/repository as securely as I could, both to ensure no bad data could get in, but also because a well-defended repository is well-described by definition.

I came up with idea of a simple “Friend CRM” – a database to track my friend’s information and allow me to store notes I take about them.

It was pretty simple:

A User was a person who could work with the data (more on this below as well…)
A Person record contained information about a person
A Note record contained some textual notes about something
A Note could be associated with one or more Person records
Both Person and Note records could have Tags
Every time a Person or Note was inserted, edited, or deleted, a record indicating this would be written to a history table, along with a serialized version of the old data (if applicable)

Very simple. But what I tried to do was codify all the business rules in the database itself, instead of enforcing them at the application or UI layers.

In general, developers tend to push validation off to the application layer. Our core data storage tends to be “loose,” and we just filter and strain the data before we try to persist it. Our general practice is we won’t attempt a database operation unless we already know the data is good.

This is fine, but it leaves a “gap” between the data storage and the content/data model. Our repository will store far bigger data variances than we intend. The theoretical problem is that something could conceivably get “under” the app layer.

This isn’t likely, but imagine if someone got SQL access to your database – this usually gives developers chills. “Use the API!” they scream. Anything going directly to the repo is considered potential bad data, because the API is the “sheriff.”

flowchart LR
    A("Repo")
    B("API 
 (the only proper gateway)")
    C("Good Incoming Data")
D("Bad Actor
(sneaking in the back door)")
    C-->B-->A
    D-->A

This is pretty normal in modern web apps, but the API becomes effectively where the content model is defined, because that’s the finest “strainer” for the data. If the API is the last word on the type of data than can be persisted, then the core repository system and the API are effectively a bundle that have to be used together.

In this case, I was trying to define the database in such an exacting way that it became self-describing and self-defending. The database would both store the data and understand the model intuitively.

My litmus test was, “Could I give someone SQL-level access to this database without fear?”

To this end, I spent a lot of time learning about SQLite CHECK constraints. A simple “constraint” is a general rule, like “NOT NULL.” But a CHECK constraint will run defined logic on values and accept or reject them at the database level.

You can write CHECK constraints to do lots of validation:

Ensure a number value is above or below a set point or within a range
Run a REGEX(-ish) pattern on text input to ensure it complies
Ensure the length of a string is in compliance
Prevent the deletion of a row until some condition involving another table or value is satisfied

For example:

CHECK(username NOT GLOB '*[^a-z]*')
CHECK(length(password) >= 8)
CHECK(type IN ('user', 'admin'))

When included in a table definition, those CHECK constraints ensure that any value for the username value is comprised only of lower-case letters, the password value is at least eight characters, and the type value is only “user” or “admin” and nothing else. If any data comes in that violates those rules, the database will simply refuse to insert or update.

Additionally, I defined a bunch of triggers. So, for example, when records are deleted from some of the tables, I write the old data it to a “history” table as a crude form of versioning. Another example: if you try to delete the last record from the junction/interstitial table that links two records, it can cancel that to ensure that no record exists without being linked to something else.

These are things we normally enforce in the application/API layer, certainly (and sometimes even only in the UI layer, if we’re lazy). By moving these “back” to the data storage, I was hoping that I could “collapse” the application and data storage layers into one, and therefore make the database self-describing.

The goal was to be able to serialize this database structure – which now also happens to be a content model – to a text file (SQL DDL), and show it to an AI engine and tell it… “Build stuff that works with this.”

Here is the resulting SQL DDL. It’s pretty tight – even if you have SQL level access, it’s hard to get data in there that doesn’t work. This is accomplished via a set of CHECK constraints and TRIGGERS working together.

There were a couple edge cases I couldn’t work in. For instance: I wanted to ensure that a Note was assigned to at least one Person. However, there’s a problem that you have to insert the Note record before you assigned, so there will be a microsecond when it’s not assigned. I consulted ChatGPT and Claude, and they offered some really bizarre ways around this, using the tools SQLite has. (A stored proc would have solved this, but SQLite doesn’t have those.)

But, it’s pretty close. It’s a very well-defended and consequently well-described repository. By giving an AI engine the SQL DDL, it should understand the data and be able to build stuff with it… hopefully.

Now, if I provided this model definition to an AI agent, could it build something good from it?

This is what me and Claude ended up vibing:

flowchart TD
    A(Full Web UI)
    B(Web API)
    C(Notifier)
    D(Micro UI)
    E(Static Site Gen)
    G(Batch Process)
    F{{CMS / Repository}}

    F --> A
    F --> B
    F --> G
    B --> C
    B --> D
    F --> E

    style F fill:#FFe5dd,stroke:#DD4085,stroke-width:2px,color:#000,height:3rem;

The Repo is the aforementioned SQLite database
The Full Web UI is a Node/Express web app that provides data management functionality
The Web API is a REST API that provides remote access with token authentication
The Notifier is a Node background process that polls the web API and pops up a Windows notification when a new record is added or changed
The Micro UI is a small Electron app that provides nothing but the ability to type a note and search for a person to link it to
The Static Site Gen is a CLI process that wrote out all the Note records in a journal-like format (one output among many, I would assume)
The Batch Process is a scheduled process that searches for profanity and replaces it with a sanitized version (“f**k”, for example)

Now, I didn’t actually need of these – this was all just a big POC. (I was actually struggling a little to come up with different apps to write.)

But the point I was trying to prove was that if we have a well-described repository, that will assist AI in creating applications that operate on it. The Queen Bee can craft its own Worker Bees.

The results were… pretty good. Not perfect, but certainly promising.

However, I did realize pretty quickly that the SQL DDL was just not enough, sadly. The problem is that this described the data model, but it didn’t describe how I wanted to work with it as content.

For example: I gave the SQL database definition to Claude and told it: “Make me a Web UI for this.”

And I certainly got a web UI, but it was something like phpMyAdmin. Claude literally gave me a bare-bones UI to manage the tables, columns, and rows. For instance, to link a note to a person, I would need to add the Note, record the resulting ID, find a Person, record their ID, and then manually add the record in the junction/interstitial table. This is not what I wanted.

But to be fair to Claude, this was a web UI to manage the data as the database understood it. All the database understands was tables, columns, constraints, and triggers. And Claude did pretty good with this: I was gratified to see that Claude acknowledged all my CHECK constraints – for example, the apiKey column on the User table can only be (1) NULL, or (2) 32 characters. Claude correctly understood this and “elevated” this to the UI level to validate it there.

However, this clearly still didn’t manage the content in the way a human would want to manage it. And there’s no way to do this in the database definition – tables don’t have a place to state what the data means to a human.

So I determined that I need to provide that, and I wrote a short narrative explaining how a human would work with the data.

Here it is, in its entirety:

This is a database that is used to track information about people I know, including a running log of notes related to that person.

There are named users for the database. No one should be able to access the UI for the database until they provide a correct username and password.

I can enter people’s data into the database and tag them (friends, coworkers, relatives, etc.) I can also enter whatever birthday information I have about them: their full birthdate, just the month and year, or just the year.

I can add free-form notes, and associate the notes with one or more people. I can also tag these notes (phone call, meeting, request, etc). The notes are intended to be Markdown text.

I can use tags to find all the people or notes that are associated with it.

Whenever I change or delete a person or a note, the existing information is archived so that I always have a history of what the record was originally.

I tried to stay away from dictating any details of the UI, because this description was about the content model – what the data meant, and how I wanted to work with it – in conceptual terms.

So my description (my context) became two-part:

The SQL DDL
The “friendly” description of how I wanted to work with the data (as a text file)

Every time I wanted Claude to generate something, I gave it the SQL file, the text file, and then an additional description of what I wanted to build.

For example, here’s the “additional description” for the Batch Process. Using just that and the two other items mentioned above, it seemed Claude could build about anything.

All builds were done independently of each other. The only thing they had in common were the two files noted above.

In the end, I had a SQLite database file (the “Queen Bee”), and six folders, each containing an application that operated on the database (the “Worker Bees”). The worker bees didn’t know anything about each other, except for the exception noted.

Here are some screencaps of what everything looked like (that had a UI or any worth getting an image of):

The Web UI “dashboard”

A person record in the Web UI

The Web/REST API

The Micro UI as a standalone Electron app

So, what did I learn from this? Well, it was a little all over the map, but here are some thoughts:

Something I already knew: data and content are not the same thing. Databases store “data.” You need a “Contentbase.” What the data is and what the data is intended to be used for are drastically different concepts, and computers can only reliably assume the former.
I still like the Queen Bee/Worker Bee analogy. Instead of my “CMS” being one big thing, I have a core repository and an… ecosystem of applications (a constellation? an array?), each doing their own thing, with only the repo in common.
The idea of a "well-described repository” is promising. But you’ll need to find a way to describe both the mechanics of the data storage and how you want to work with the data. As Kevin mentioned above, this is your context – your “contextual base.” You need to be sure that this well-rounded from both a raw data and intentional perspective.
The SQL DDL can be generated real-time, and the same is probably true for other repos as well. It wouldn’t be hard to provide a remote endpoint that would explain all the rules and intentions of the repository that your agent could connect to. However, you need to find a way to inject the “friendly” description of how you want to work with the data. As mentioned in my prior post, there’s no standard way to describe this.

If I was going stick with SQLite (I’m not), then I’d probably come up with some “meta table” that would store the friendly descriptions of the other tables, what they meant in terms of domain-level content objects, and how I would want to work with them. I’m not sure there would be a way to provided standardized access to this from the SQL level, but from the remote API level (which is where most access would come from), I could have an endpoint that returned a combination of friendly descriptions and SQL DDL.
Once I was satisfied that my data was secure (that my repository was “well-defended”), then I didn’t really care what Claude did with it. I don’t recommend getting callous with your data, but all of these apps took basically no effort from me, so I would have been happy to create them, use them, throw them away, and create new ones.

Consider this: could every user roll their own UI? We usually talk about “the UI,” and maybe we have a default…but what if I don’t like it? So long as the repository can defend itself, then could I just have some AI agent write me my own UI that I do like?

Pass-through identity will matter more. SQLite doesn’t have any user permissions (if you have access to the database file, you can do everything). That was a key issue in this case, because all my vibe-coded apps were connecting in “God mode.” In real-life, I’d use a database server that required login, and I would make them connect as actual database users that can be tracked and throttled, rather than funneling everything through the same user (as we tend to do with our applications).
Related to that, the idea of lots of independent worker bees doing content operations independently brings up questions around what non-developers might do. A human could always do something dumb, but AI will enable them to do dumb things at scale.

And where did this all leave me?

With a pretty big question, it turns out.

Frankly, I’m still a little unsure of where AI leaves the boundaries of CMS. Let’s assume I had a more full-featured database server, like SQL Server or Postgres – one that gave me stored procs, and more ways to make the database “well-defended and well-described.”

Could I implement an entire CMS purely in a database and call it good?

This, of course, is nothing new – this is how we did CMS back in the day. The entire idea of CMS, in fact, was the generalize content storage so we didn’t have to custom build databases for everything.

But with AI, we’re removing a lot of the work of custom-building things. If you have an agent to do the work for you, then do you really care if something is custom-built? Would it be easier to lock a content model down in a SQL database, and then just use AI to generalize everything into whatever output you wanted?

This comes back to a key point: most current CMS repositories say nothing about the model. They store it in a way that’s optimized for efficiency and adaptability, not intelligence, logic, intention, and discovery.

We don’t store an “articles” table. Instead we do something like this:

erDiagram
    TYPE ||--o{ PROPERTY : has
    OBJECT ||--o{ TYPE : "is instance of"
    OBJECT ||--o{ OBJECT_PROPERTY : has
    OBJECT_PROPERTY ||--o{ PROPERTY : "is instance of"
    TYPE {
        int id
        string name
    }
    PROPERTY {
        int id
        int typeId
        string name
    }
    OBJECT {
        int id
        string typeId
    }
    OBJECT_PROPERTY {
        int int
        int objectId
        int propertyId
        string value
    }

This is very common repository model. (I think we call this an “object oriented repository,” but I’m sure the nomenclature is loose. Also, this assumes you’re using a relational database, which might not be true.)

Content in here doesn’t make any immediate logical sense, and it’s not intended to.

So why do we do this?

We do it to generalize, so we can adapt our repository to any “shape” of content – it doesn’t matter what you’re actually storing, this model will make it fit. Indeed, a big part of every CMS vendor’s business model is built off the idea that they’ll provide a general place to put content, adaptable to whatever your actual model is.

flowchart LR

    a("Repository
(in generalized format)")
    b("API
(interprets the generalized format)")
    c("Editorial UI")
    d("Output")

    a-->b
    b-->c
    b-->d

    style b fill:#cce5ff,stroke:#004085,stroke-width:2px,color:#000;

But are we just kicking the can down the road?

Since our repository could technically represent anything now, the customer just has to describe the content model somewhere else. We provide our vague, amorphous repository to the customer, and we have big configuration UIs and API/app layers where they can explain the model. Then we use that to extrude content into our generalized data repository.

…but what if we just described the content model at the repository? And then we pushed all the generalization off to AI? What if AI removed the labor overhead of making specific, form-fit repository and by doing so, made the repository the most efficient place to describe the model?

flowchart LR

    a("Repository
(in specific, well-described format)")
    b("Editorial UI via AI
(AI understands the specific format)")
    c("Output via AI
(AI understands the specific format)")

    a-->b
    a-->c

    style b fill:#cce5ff,stroke:#004085,stroke-width:2px,color:#000;
    style c fill:#cce5ff,stroke:#004085,stroke-width:2px,color:#000;

I mean, we have to describe the content model somewhere, right? Why not describe it in the repository itself? And since our current databases – as demonstrated above – can’t understand intention, we’ll to find a way to let AI make sense of what the data does, not just what it is.

Are we coming full-circle back to bespoke databases? Has AI removed the comparative advantage to generalizing our repositories? Has AI made us less afraid of potential technical debt related to overly specific content models?

Will that be the CMS of the future? Just a really good repository that can be “well-defended and well-described”? And then we let AI handle everything else?

Well, this brings me back to the same argument I made in the last post.

I’ve just now spent a couple hours messing with databases and slowly wandered in a circle back to the same point.

I do this frequently.

The Missing Service: Notify One Time

Wed, 13 Aug 2025 00:00:00 -0500

There are lots of things I see on the web that are “upcoming,” and I think, “How can I find out when this happens?” Of course, I just could keep checking back to the URL I’m looking at, but I’ll no-doubt eventually stop doing that.

And let’s face facts: no one really wants to give their email to a website. Very few people want to subscribe to all your content, certainly not if they just want to find out about one thing.

What people might want is to be notified when a specific thing happened. For example:

When Part 2 of a blog post series publishes
When a specific software update is released
When a book is finally released
When new tour dates are announced
When early election voting opens

For these things, I will give you my email address, only if you promise to use it solely for the thing I want. If you promise to email me that one time about that thing I want to know about and then forget my email, then I’d be willing to give it to you.

That said, this is what I want to see on a website (obviously, this is just a demo/POC, so don’t enter anything here):

Notify One Time

You are providing your email to the Notify One Time service. This is an independent service on which this site owner has an account.

You are asking to be notified when [whatever event] occurs.

When this event occurs, the site owner will provide the announcement text, we will email it to you, and then delete your email forever. The site owner will never see your email address and can never send anything else to it.

Notify One Time (“NOT”), would be a non-profit service. (Maybe? I’m not much of a businessman. I don’t know the best way to organize this.)

As a site owner, I could create an account and register events. For example, when my upcoming book is published. For each event, I would get some script code to embed the above UI on my website.

If a visitor wants to be notified when that happens, they could enter their email address and it that would get sent to the Notify One Time servers, linked to my event.

As I site owner, I could never see the emails. I could maybe get an analytic or two – like the aggregate number of people who had provided their emails, maybe even over some time distribution – but I could never actually see the data.

Then, when my book publishes, I would log into my account at Notify One Time, and “resolve” the event by providing the text of the announcement email (which, presumably, would have an Amazon link or something).

Notify One Time would then send that announcement email to everyone who subscribed. And then… it would delete every email that was provided, irrevocably and forever.

I could then remove the script code (but it would likely have something in it to check the the event was active, and hide itself if it had already been resolved).

The key to this is to get people to recognize and trust the system. If NOT became some known-ish brand and people understood the model, then they would see the logo and know that there was no commitment. They were just signing up for one email, full stop.

Postscript: Preventing Abuse

I know this will be an immediate question: “What’s to stop my ex-boyfriend from signing me up for a bunch of notifications?”

A few thoughts here –

The risk is low. To do this, your ex-boyfriend would have to find a bunch of pages that have Notify One Time forms embedded. Even then, they are, by definition, only signing you up for a single email to be sent, the contents of which they have no control over, sometime in the future.
We could require email verification – send an initial email and require confirmation – but I don’t like this as it adds cognitive overhead and could ironically become an abuse vector all by itself.
What we would probably do if have some heuristic to sense abuse. For instance, if the same email gets submitted many times in the same time period, we could flag it and then require email verification for that particular address.

But, as I noted in the first point, I think the potential for abuse is low, and the threat of material damage is even lower. But I concede that I might just be naive.

Queen Bees: The Resurgence of CMS Repositories in the Age of AI

Sun, 10 Aug 2025 00:00:00 -0500

I’m wondering if the coming age of AI will force CMSs to retrench back to the repository level.

Since the birth of the CMS, we’ve walked away from the repositories. We initially imbued them with lots of tools and features – modeling, versioning, workflows, permissions, version control, etc. – but these are ultimately… unsexy. It’s hard to sell tools that are literally designed to keep your life boring and uneventful.

Soon, building content output became more important. The content itself gave way in importance to site management and site building.

Then, those even gave way to post-publish optimization tools. No one cared what happened “to the left of the Publish button.” All the cool kids moved to the right of it, and just wanted to talk about what happened once the content was published.

In the background, our repositories haven’t really evolved. Show me a vendor that regularly releases new repository service features, and I’ll show you a vendor no one is talking about.

But let’s back up a bit –

Right now, CMSs do a lot, especially if they’ve made the jump to that vague definition of “digital experience platform” (DXP). Let’s build it out from the bottom up:

Content Modeling: defining what the content is – types, properties, datatypes, validation rules, etc.
Content Storage and Access: providing basic persistence and access to content; APIs, both remote and native; querying facilities
Content “Management:” allowing everything that happens from creation to deletion, like permissions, workflow, lifecycle management, auditing, etc. (in quotes because this is the actual management stuff; that word does too much work)
Content Aggregation: grouping content in ways to provide increased value; trees, menus, tagging, collections, relations, assemblies, etc.
Content Publishing: generating and transmitting some kind of output artifact
Content Optimization: adapting content to immediate context; personalization and experimentation and customer behavior tracking and all that

This is an onion of successive layers.

The first few layers – the first two? the first three? the first four? – are very core to the idea of “managing content.” But as we go further down the list we get into more and more abstract levels of functionality that “wrap” the core.

AI might start to peel this onion, meaning it will start to replace some of the outer layers and even redefine what they mean. Consequently, CMSs might start to shed those layers, effectively ceding them to AI, and retrench back to the core.

When this happens, the question will become: where does it stop? How close to the core do we let AI absorb? At what point do we say:

“Enough. You can go no farther. The features and functionality this close to the core are managed by humans and cannot be manipulated by AI.”

Specifically I’m thinking in particular about content modeling. This is on my mind because of a group discussion we had at CMS Connect 25 in Montreal last week. A bunch of us were batting around what content modeling looks like in the age of AI, and I started to get a little uneasy.

The core question we all seemed to be dancing around was this: do we let AI manage our content models?

Right now, I say NO.

To me, this is the cliff that prevents us from retreating any further. While we might retreat to the very concept of defining what our content is, that’s where we turn toward the invader and make our stand.

I feel like content models should be inviolate. They’re built with a very human understanding of the nature of your content and how it relates to your organizational domain. So many decisions are implemented in content models that are based on a human’s understanding of what works at that organization and the people who comprise it.

Additionally, a good model represents not only what you need out of content now, but what you might need in the future. A smart human doesn’t have a myopic focus on only the output or usage they need immediately, but what they might do in the future, along multiple axes, including how to output the content, manage the content, operate on the content, govern the content, etc.

Yes, this might be a Pollyanna-esque view of the whole thing. I get that. But this is where my head is at right now.

For some years now, I’ve managed a database of all my books. As an initial build-time task, I needed to define a model of what constitutes a “book.”

Each one has a Title and a Subtitle and a bunch of other obvious stuff, of course. But then I include some data that only makes sense to me – fields for “Loaned To,” and “Acquisition Notes” (how I came to possess it), and “Repair Notes” (poor bindings and stuff that could be repaired), “Reading Environment Notes” (where I was when I read it, if it was somewhere interesting, like on vacation or a business trip or a road trip).

A lot of this is based purely on what I want to know and store about my books. In particular, it’s not related to any existing output (I don’t need to publish information about how a book needs to be repaired, for example), so there’s no existing thing to reverse-engineer. In fact, when I first put this content model together, I wasn’t even planning to output the data anywhere – it was just a tracking exercise.

To me, this content model is something that I own. This is the basic idea – the nature, the notion – of what I’m trying to manage. To be overly dramatic, this content represents the “soul” of what a book represents to me.

I’m not ready to surrender this to AI. I don’t think I ever will be.

Right now, I’m using this to output a library inventory and a reading list, but who knows what I’ll do with it in the future? The model exists apart from any particular output. In fact, the outputs can be considered ephemeral. They’ve existed for many years, but who knows? I might throw them away someday and do something else with the data.

Some people would say that AI should manage the model. In particular, it’s kind of vogue to say, “just show AI what you want to get out of it, and it will suggest and manage a content model for you.”

For smaller one-off projects where the content exists for the sake of that one output, maybe this would be fine. But for larger notions of enterprise content, I feel like this is short-sighted.

In my situation:

I didn’t have an output planned when I created the database. There was literally nothing to show to an AI.
I have at least two outputs now. And who knows what else I’ll do later? I can’t show AI “what I want out of the data” because the end of that story hasn’t been written and likely never will be. My model and my data is a bundle of potential energy which I haven’t finished harnessing in different ways yet.
If I did have an AI work backwards to create my model, I would have gotten a model really good for one particular output – the one I showed to the AI. I worry that an “output-centric model” is way too specific to that particular output.

So, at this moment, I’m settling on this working premise –

Humans create the content model. An AI may work only within the bounds of it. AI is subservient to the content model. It can operate on content, but it cannot define what content is.

A good content repository in the age of AI should be well-defended and well-described.

Well-defended: It should protect content by concise and expressive data and validation rules
Well-described: It should expose its modeling as openly and clearly as possible

This is the only way we’re going to keep everything under control when multiple AIs start working with our content as they evolve over the next decade.

Imagine that our ironclad repository and model is the queen bee of a hive. Lots of AIs are hovering around it, working independently and concurrently, attending to The Queen’s needs and otherwise acting in service of The Queen.

But they are not The Queen. They are ultimately disposable.

And the last point is non-trivial. What an AI does is or can often be ephemeral, and should be considered as such, which is utterly antithetical to the principles that a repository is designed around.

Let me tangent a bit on this point –

Remember when computer virtualization became a thing? My career started when a server was 1:1 to a plastic box in a data center somewhere. Servers were a big deal – you ordered them, and they showed up on a wooden pallet, and you got a buddy to hold them for you while you bolted them into the rack.

But one day we got virtual servers, and so long as we could wrangle an IT guy, then we could get a new server by filing a ticket. And then when we got AWS and Azure, and suddenly we had the option to create servers in seconds, without even involving IT if we didn’t want to.

And – this was the really weird part – we could shut them down just as fast. Given the hourly billing, we were introduced to the idea of creating a server to do a set amount of work, then throwing it away. Servers really became “freelance computation” that you could hire for the specific period of time you needed.

Computational power became disposable.

This is where I think AIs is going in relation to content. We’ll use AI to work or create artifacts from content or UIs to work with content, with the understanding that what they create is basically disposable. Why? Because the cost to create what it is has been effectively driven to zero. When creating something doesn’t cost anything, you don’t need to keep the output. You can get it back by just asking for it.

Let’s say that one day, I have a little extra time. To make sure all my books are tagged, I could very easily just say:

Hey Claude, connect to this repository and learn all about the content model and the content in it.

Then produce an optimized UI as a browser-based app for me to apply tags to any book records that don’t already have them. In the UI, show me some details about the book, and maybe prefill the form field with some suggested tags. Also, show me all the tags currently across all books in use and the number of times they appear. Finally, show me a running percentage of how far I am toward getting all books tagged.

I get my UI in a few minutes and run it (maybe just on localhost). I work away until all my books are tagged, and then I just throw the UI away. I don’t need it anymore, and if I ever do, I’ll just ask for it from scratch again.

In the end, I didn’t want the UI. I wanted the outcome of having it. I didn’t want the shovel, I wanted a hole in the ground.

This really re-frames the concept of “vibe-coding.” I care less about the textbook correctness of code that I’m not going to keep. And remember, since my content model is “well-described” and my repository “well-defended,” even stupid code is prevented from doing damage. I’ve put rules around The Queen, and I don’t much care how a worker bee does their job, so long as they obey the rules.

A key point is that what I just did with Claude is only one thing that might be happening in the repository at any given time. Somewhere else, some other person might be doing this:

Hey ChatGPT, connect to this repository and learn all about the content model and the content in it.

Then execute a batch process to identify books that have a Date Completed value for which there is no physical copy in the library. Append the tag “read-but-unowned” to the current value of the “Tags” field.

Think about what’s going on here:

This operation is being done by a different AI engine. Let to its own devices, it might interpret the content different unless it has access to a clear, concise description of how the content is defined.

This operation is being done simultaneously with the other operation. This means that they’re both depending on a stable content model. In this particular case, the two operations are “sharing” access to the Tags property, and each AI is ignorant of the fact that the other one is working with the same field. Each AI needs the definition of that property to stay the same as it was when the operation was started.
This operation is transactional and ephemeral. I’m just asking it to do a job then stop. Will I need to do this again? Maybe, but probably not enough to keep the code around. Note that I’m not specifically asking it to “create” anything. In the first instance I said “produce a UI” and in the other I said “execute a batch process.” I don’t want the shovel – I just want the hole in the ground.

Let’s do it again:

Hey Gemini, connect to this repository and learn all about the content model and the content in it.

Then generate a static website that has a home page that lists all the books, a tag overview page that lists all the tags in use, a single page for each tag that lists the books with that tag, and then a single page for every book, to which any reference of the book is linked. Search Amazon to find the product URL for the book. If you find one, put that on the page too, using affiliate link token “jamesbondfan007.” Give this to me as a ZIP file of HTML documents that I can just extract to a web server root.

Another AI engine. Another ephemeral job. Another worker bee.

What do all these scenarios have in common?

The Queen.

A content model, and a repository. They all depend on some common definition of what content is, and some common location to access the content itself.

They are worker bees, performing actions on behalf of The Queen. They can’t usurp The Queen, only serve her and then die.

Where we might have depended on tools in a CMS to do the jobs we’ve described, we’ll use temporary AI agents to do it in the future. We’ll probably use a lot of them with all sorts of different models and capabilities, invoked and given direction by different people, starting and stopping in overlap with each other, and occasionally coming into conflict with each other. Lots and lots of worker bees, all trying to serve The Queen at the same time.

With the withering state of repositories, what possible hope do we have of controlling and coordinating all this, while keeping our content safe and avoiding risk?

Primarily, we need a well-defended, well-described content model that no AI can change directly.

In my mind, this becomes the limit of our retrenchment. This is the core of the onion. We cede no more territory than this.

If an AI requires a change (a different property, a different type, whatever…), then it either needs to explain the change to a human, or put that property and its data somewhere else and manage it from there.

Secondly, we’ll need to revisit security, audit, and concurrency capabilities. We’ll need to acknowledge the increasing frequency of “user agency” – AIs acting on content on behalf of human users.

If I give AI either of the first two scenarios above, how do we record those write operations? Did I do that? Or did the AI do that? Well, we both did. We’ll need to account for the scenario of an AI acting at a human’s direction. In addition to being clear that this was a delegated action, we might want to store meta about the AI that was used – vendor, model, instance, etc. – and we might even store the prompt so that we can audit and recreate what happened later, if we need to.

Thirdly, very boring, unsexy risk mitigation features will have renewed importance. Versioning, version control, rollback, and concurrency and conflict management will become a bigger concern, and will need to be more granular. We’ll need to track changes to content in a way that they can be reconciled, merged, or canceled after the fact, because the proliferation of worker bees will cause them to run over each other, in addition to the fact that AI will simply magnify the volume of activity a single human can initiate.

Simply put: content repositories will need to get better and stronger.

The Queen must rule. Long live The Queen.

On the other side, the outputs – the worker bees – are less important. They can unbundle. I might use one worker bee for a specific project, but use a different one the next week, maybe even to re-do that same project. Worker bees are easier. I don’t bet the company on a worker bee.

This is the future we’re in for, I think –

The resurgence of repository services as a key enabler of AI capabilities. Some repositories will perform well in the face of an AI swarm. Others will not.
Rich, inviolate content models no AI can modify directly. Well-defended and well-described.
Some common description protocol for these models. MCP is the telephone, but what language are we speaking? RDF? JCR? OWL? JSON Schema? …WSDL?
External APIs for description (“Connect to this repository and learn all about the content model…”)
Ephemeral content operations (“worker bees”) from which we simply want to retain the outcome, not the tool used to achieve it
Stronger and more granular control and auditing features, particularly those that increase the level of concurrency management
Evolved security models that understand humans and AIs will work together, and so two “users” can and will collaborate on the same action

Who is going to lead this charge? Which vendors and which architectural paradigms are closest to it already?

Generally speaking: CMS vendors who have continued to improve their “boring” repositories over time, resisting the desire to concentrate only on more glamorous output and optimization tooling, and ensuring that their repositories provided a solid foundational base for everything else.

I’ll resist the urge to be more specific than that. I’ll let others make their own arguments.

Good luck, everyone.

The Joy of Mixing Custom Elements, Web Components, and Markdown

Sat, 9 Aug 2025 00:00:00 -0500

I love Markdown. I write faster and more natively in it than any other format or tool.

If we zoom way out, here’s the most basic philosophy of Markdown: replace complicated stuff with simpler stuff.

That’s all it does, really. It replaces some tedious nested taggy stuff with way simpler stuff that makes more visual sense and is faster to type. At its core, Markdown is really just a bunch of macros.

This website runs on 6,000-ish Markdown files. They’re processed on the server – meaning the Markdig library from .NET processes them, then sends back the resulting HTML. I’m all-in on Markdown, to the point where I wrote my own online editor for it.

Server-side processing of Markdown is a pretty common model – most static site generators fundamentally do the same thing: they process the Markdown, turn it into HTML, and that gets sent to the server (via being written to files).

One of the philosophical points of Markdown is that you can mix it with HTML. Meaning, a Markdown parser is supposed to leave HTML alone – if a line of text looks like it has some tags, the parser should skip it.

This means you can do this:

This is some **Markdown!**

<img src="yay.jpg" />

This is some more ***Markdown!***

And that should work fine. The first and last lines will be processed and transformed, and the middle line will be left alone and output as it’s written.

These were the original rules around inline HTML in Markdown:

The only restrictions are that block-level HTML elements […] must be separated from surrounding content by blank lines, and the start and end tags of the block should not be indented with tabs or spaces.

I didn’t find the need for blank lines in the CommonMark spec, but just note that every Markdown processor might be a little different in this respect, so test.

Anyway, we’ll likely get HTML that’s something like this out of the above Markdown.

<p>This is some <strong>Markdown!</strong></p>
<img src="yay.jpg" />
<p>This is some more <em><strong>Markdown!</strong></em></p>

Our img tag is intact and has been left alone.

This is great, and helps you in some sticky situations. You can effectively “escape out” to HTML when you need to.

However, this still leaves you with the problem where you might have a bunch of complicated, tedious HTML that forms a repeatable component of some kind that you don’t want to hand-manage and reproduce over and over. What if you want a Markdown-friendly way to represent a feedback form, or a tabbed UI, or a mortgage calculator, or something else way beyond the scope of text formatting.

For these situations, what you really want is to put a token or a placeholder in your Markdown, and have something else expand it later on into a larger, more complicated HTML construct.

What you sort of need is… Markdown for More Complicated HTML™.

Enter Custom Elements.

These have been around a long time. They tend to get lost behind all the attention paid to the big client-side frameworks like React, but the first public spec was published in 2013, finalized in 2016, and we’ve had broad browser support since 2018 or so.

Custom Elements can do a lot, but a core function is that they divorce the source markup from what’s effectively output into the DOM.

You can write X in the markup; the Custom Element will output Y into the DOM.

X is simple; Y is way more complicated.

X is written by an editor; Y is written by logical processing.

So, considered at that level, Custom Elements can be used as… HTML macros.

This means that when you combine them with Markdown, you get a really neat synergy of features.

Markdown expands into text formatting
Custom Elements (that the Markdown processor ignores) expands into more complicated stuff

Consider this scenario: you have a blog post which is Part 1 of a series. You want to let people subscribe to be notified about Part 2, but that involves a little widget of some kind in the HTML. And for whatever reason, you have to put this between two paragraphs.

What if you could do this:

This is some **Markdown!**

<subscribe-to />

This is some more **Markdown!**

(Remember, that middle line is HTML, so the Markdown processor will leave it alone.)

Then, in the browser, that subscribe-to tag will expand into something like this:

<div part="outer">
  <label part="label">Want to know when Part 2 is published?</label>
  <input part="input" type="text" name="email" placeholder="Give us your email">
  <button part="button" type="button">Let me know!</button>
</div>

This is exactly what Custom Elements can do.

To be clear, this is not a tutorial about Custom Elements in general – there’s a lot of depth there – but just a joyful discovery of what happens when we combine them with hand-written Markdown and come to the conclusion that both Custom Elements and Markdown sort of operate on the same principle from the perspective of the writer: they replace simpler stuff with more complex stuff.

Custom Elements can just be simple tokens like the above (actually, what’s above is not quite valid, but more on that below), or you can expose configuration parameters to make them more usable in more situations:

This is some **Markdown!**

<subscribe-to buttonText="Get me the details!" />

This is some more **Markdown!**

You can even put stuff between Custom Element tags then use that in the processing and output. (You can go even further, by defining child tag structures and “slots” and all sorts of stuff that we won’t get into. Again, there’s so much depth there…)

This is some **Markdown!**

<subscribe-to>

We'll use your email once, then delete it. _We promise!_

</subscribe-to>

This is some more **Markdown!**

Guess what happens to that line between the subscribe-to tags? Yes, it gets processed by the Markdown engine, because it’s not HTML – there’s no tag on that line. So the Markdown engine will process it, but leave the line above and below it alone, resulting in this:

<subscribe-to>
  <p>We'll use your email once, then delete it. <em>We promise!</em></p>
</subscribe-to>

During a bout of insomnia, I did some local testing of the general theory.

I had Claude vibe-code a simple Node script that read a Markdown file which looked a lot like the samples above (Markdown paragraphs above and below, with a subscribe-to Custom Element in the middle). Then it processed the Markdown – Custom Element included – and output the result into a file.

Here’s the Markdown source. There are two subscribe-to tags in there – one simple version, and one with a bunch of options I thought up.

You can see that when the browser encounters this –

<subscribe-to />

– it expands into HTML (in a shadow DOM) that ends up looking like this in the browser:

Or this when you add some advanced options:

Here’s the output file.

(That’s raw HTML; you can view the source. Understand that it’s still subscribe-to in the source, but inspect the DOM and you can see what it effectively expands into. The JavaScript definition for the Custom Element is inline in the HTML doc. I used Lit as a base because it makes a lot of things so much easier.)

I just love this.

An editor has Markdown acting as text macros, Custom Elements acting as HTML macros, and they can mix the two in the same file. Simpler things become more complicated things. They can use Gruber’s “escape hatch” to handle infinitely complexity while being abstracted away from verbosity.

This opens some lovely possibilities for page, layout, and element complexity and functionality while retaining the “I wrote it in a simple text editor!” joy that made Markdown so awesome to start with.

Postscript: Minor Technical Note

I’ve been lying to you a little in this entire document. You actually can’t do this:

<subscribe-to />

Custom Elements cannot be self-closing (or a “void tag,” as they’re called). You technically have to do this:

<subscribe-to></subscribe-to>

The self-closing version will work sometimes, kind of accidentally. Where it falls apart is when you put something between the tags, because the browser considers the self-closing tag as just the opening tag, which it then claims never closes.

But here’s how and why I started ~~lying to you~~ displaying the self-closing version.

Because – and stick with me here – here’s something else you can’t do: put your tag attributes on multiple lines.

<subscribe-to
  buttonText="I love getting email!"
  anotherAttribute="Another value"
>

This time, it’s not the browser that’s the problem – the browser is totally fine with you breaking out the attributes to their own lines. This time, it’s the Markdown engine. It looks at those middle lines and decides that they’re not HTML, not understanding that it’s logically part of the opening tag. This means that – you guessed it – the Markdown engine tries to process it and everything falls apart.

(As noted above, this might vary a bit between Markdown engines. Claude picked Marked for this POC.)

I didn’t like that I couldn’t do this. I wanted to be able to break out all my attributes on their own lines.

To solve this, I had Claude vibe up a simple (?) Markdown pre-processor. So before the source Markdown got fed into Marked, some code in the Node app “fixes” the tag – reassembles it all back on the same line.

And, while I was doing that, I also “fixed” the self-closing tag issue. If the code detected a self-closing tag that contained a dash (which Custom Elements must), it changed it to an explicitly closed tag. That’s why I showed you the self-closing tag. But know that by the time it got to the Markdown engine, it was explicitly closed.

It was just cleaner and less confusing while I was early in the explanation.

Here’s the source of the Node app with the preprocessor in a (pretty gross-looking) function called preprocessMarkdown.

(Full disclosure: I didn’t even bother to check this. It was just a POC, so I had Claude write it. I could have written it myself, but didn’t want to put in the effort for something with no larger goal.)

Postscript: Fun and Madness with Markdown Preprocessing

Once you crack open the door of Markdown pre-processing, you can be sorely tempted to head further down that road. For instance, if you don’t like the idea of raw HTML in your Markdown, you could essentially write your own mini-language.

For example, something like:

@:subscribe-to
 buttonText: I love email!
 placeHolder: Give us your email!

All you have to do is write some preprocessing code that detects that construct and forms it into the Custom Element tag.

Is that “better” than raw HTML? I don’t know… maybe?

The looming problem is that this is just one simplistic Custom Element example. When you get into more advanced features like child tag structures and slots and such, you’d probably end up re-interpreting and re-implementing way more of the HTML spec than you want to.

I predict there will be a point where you regret trying to do this. Pre-processing and the initial excitement of a domain-specific language is a siren that might lead you to your doom.

(I swear, I have never tried to do something this foolish… I swear…)

Postscript: Fun with Language Design

When you realize that Custom Elements effectively abstract writing HTML away from deeper logical programming, you realize that designing the logical interface of your Custom Elements is a fun exercise in language design.

The basic principle becomes: don’t ask for anything you don’t absolutely need. Do as much work as possible for your editors in code. Require them to provide as little information as possible.

If we want to embed a feedback form, for instance, we could do something like this:

<input-form submitButtonText="Send message!">
  <input-text label="Your Name" spec="required >4" />
  <input-text label="Your Email" spec="required email" />
  <input-text label="Ticket Number" spec="required regex:[A-Z]{2}[0-9]{4}" />
  <input-text label="Your Message" spec="required multiline" />
  <submit-message>
    <p>Thanks for your submission! We normally respond in two business days.</p>
  </submit-message>
</input-form>

This provides everything we (the developers) need to render a feedback form.

We control the layout, so we’ll expand those input-text tags into multi-tag constructs to render each field.
We can assume that things like the form METHOD and ACTION are standardized to the site, so we don’t need to ask for those.
We can automatically obtain the URL/page from which they submitted. We could even develop some system where data from specific META tags in the HEAD are written to the form in hidden fields, meaning additional data can be injected into the form at the page templating level.
We assume the form needs a submit button, so there’s no need to specify it.
We can provide an “override default setting” model, where lots of stuff have default values that will be used if not provided. For example, I’m passing in submitButtonText, but that would certainly have a default value (“Submit Form”) that would be used if I didn’t feel like changing it.
Inside the input-text tags, we can roll up validation (required, >4 meaning at least five characters) and UI (multiline) specification into the same SPEC attribute, so we have no need for another tag for textarea.
We can derive all the field names from the label. Assuming we submit the form with client-side code, we could easily find the value of the the label for each input field via the for attribute, then serialize and submit that data as well, so the server would also get the “friendly name” of each input field.

What we’ve done here is designed a specification language – two of them, actually.

The combination of tags to specify the information we need to display and submit the form
The embedded spec values which define validation and UI variations

This is really, really fun. You start to ask interesting questions about what information you actually need explicitly, and what information you can derive. You’ll find situations where you can make vast changes based on fun combinations of explicit information and environmental data.

It’s not hard to put together something that is unique to your specific situation and strikes a lovely combination among granularity, utility, and simplicity.

Postscript: Processing Markdown Client-Side

The original point of this post was about how to mix Markdown that’s processed server-side with Custom Elements that are processed client-side. As I noted, this is a common model, and the basis for all of the static site generation that happens these days.

But, what if you just wanted to process the Markdown client-side as well?

You certainly can. I’ve read that md-block is quite good for this.

I don’t do it for a few reasons:

I still have weird hang-ups about sending content source to the browser. Something about airing my dirty laundry? It’s not entirely rational, and I’ve spent a lot of time thinking about how it correlates to breaking the fourth wall.
I wrote a bunch of Markdig extensions specific to my site and needs. I wrote these in C#, so I wouldn’t be able to port them to the browser (…I don’t think? WASM might be able to do it?). Some client-side implementations might have extension frameworks too (here’s an example of one in zero-md), however my Markdown usage on this site extends back six years to when I was really a “C# or death” kind of guy.

Some of the extensions I wrote require information from the server, which means rendering the Markdown in the browser would require multiple round-trips back to the server to get information, and I don’t love this.

If you did want to render client-side, there’s also a bit of a perspective shift needed. Somewhat ironically in the context of this post, you’d need to surround your Markdown in a Custom Element (like the aforementioned md-block tag).

This means that your Markdown rendering is a Custom Element on the same “level” as the Custom Elements we’ve been talking about above. The Custom Elements are not “embedded and ignored” by the Markdown engine, but rather they exist “alongside” the Markdown.

Depending on the Markdown library, you might need to close that tag before opening the Custom Element.

Like:

<client-markdown>
  This is some ***Markdown!***
</client-markdown>
<subscribe-to />
<client-markdown>
  This is some more ***Markdown!***
</client-markdown>

Your need to do this probably depends on the library you use. I can’t generalize with any authority.

In the end, your document is now fully an HTML document, not a Markdown document that becomes an HTML document. It’s a minor perspective shift, but might have some cascading effects on things I’ve written above.

Postscript: Processing Custom Elements Server-Side

You can also do the opposite of the above – if your server-side process is running in JavaScript (so, something like Node, Deno, or Bun), you can render the Custom Elements into expanded HTML on the server and send the HTML.

I have never done this, but Lit supports it. They even have a library that will re-hydrate the resulting HTML into “regular” Custom Elements when the page is finished loading.

Clearly, unless you do that, you’re not going to get any interactivity, so this is mostly useful as a templating language (…I think? Honestly, I know very little about it, other than that it exists).

Update: Additional Links

Added on August 31, 2025

This post got some good traction on Hacker News, and a few interesting resources popped up there. Additionally, lots of people emailed me after reading the thread to offer more links.

Markdown UI is an attempt to basically do what I did above, but in some type of Markdown language.
MDX is an attempt to combine Markdown and the JDX language from React
MarkDoc is a Markdown-based documentation format made by Stripe. It looks like a mix of Markdown and Liquid
VitePress is some combination of Markdown and Vue
react-markdown-with-mdx is something I do not understand very well. The description is “Higher Order Component to add MDX syntax support to react-markdown,” and there there is a long explanation here

The Missing Protocol: Let Me Know

Tue, 5 Aug 2025 00:00:00 -0500

I want a new protocol, tentatively called “Let Me Know” (LMK). The purpose is to provide someone an anonymous way to get notified when a singular, specific event occurs.

Here’s a basic use case:

Some random blog author has published Parts 1 and 2 of a series. You enjoyed it, and you want to know when Part 3 is published.

You don’t want to give away any personal information, you don’t want to subscribe to an RSS feed of other content, you don’t want to follow them on social media, etc. You just want an anonymous way to find out when Part 3 is published without having to manually check their website and evaluate it for the content.

My idea is that there’s a button at the bottom of Part 2, called “Let Me Know.”

The user clicks this, and it registers an endpoint with some agent.

The “endpoint” is a URL specific to that singular event.
An “agent” is a persistent background service of some kind that will check to see if this event has occurred. For example, a browser extension will add it to a “check list.” Alternately, some subscription service could add it to a list.

Whatever agent registers the endpoint will ping the end point at a specific interval. Let’s say once per day by default.

The endpoint will often simply return:

{
  "happened": false
}

Or:

204 No Content

Either of those responses mean, “The subscribed event has not happened yet. Check back later.”

Alternately, the endpoint can advise the agent when to check again.

{
  "happened": "false",
  "delay": 604800 // Don't check again for one week
}

Your agent will keep dutifully checking on its default schedule, or obeying the delay response if it’s provided.

But hopefully, on some bright shining day in the future, something like this will be returned:

{
  "happened": true,
  "when": "2025-08-06T05:38:20.234Z",

  // This can be included in the notification
  "message": "Part 3 of the Awesome Blog Post Series has finally been published!",

  // The notification can provide one or more things to do from here
  "actions":
  [
    {
      "Read the post",
      "https://domain.com/part-3"
    },
    {
      "Visit the home page",
      "https://domain.com/"
    }
  ]
}

You will get this notification… somehow.

If your agent is in a browser extension, you might get a pop-up.
If you agent is some subscription service, you might get an email.
If your agent is a mobile app, you might get a push notification.

But somehow, you will be notified that the event – whatever the thing was you were waiting for – has occured.

And then – and this is key – the endpoint is automatically deleted from your agent.

The event has happened, so the agent does not check again. The one task you assigned to it has been completed. If you want to find out about Part 4, you’ll subscribe (presumably) using a button at the bottom of Part 3. Or not. Whatever.

At any given time, you can review the endpoints registered in your agent, see when they were registered, when they were last checked, when they are scheduled to check again, force then to check again, etc. And you can delete any that you don’t really care about anymore.

As for the button that lets you subscribe to the event (which has now occurred), a few things could happen:

The author could manually delete it.
If the endpoint architecture was built into their CMS, it could be automatically suppressed when the event happens (or, more likely, proactively display when the event hasn’t happened yet; default would be to not display).
The button could consist of some client-side code that would ping the endpoint itself and decide whether or not to display.

If the button still shows up after the event has occured, it’s not that big of a deal. If an agent tries to register an endpoint for an event that has occured, the worst that could happen is that it notifies immediately. Alternately, the agent could detect this when it tries to register and notify the user that there’s no point in registering it and provide the actions from the response.

From the author’s standpoint, their CMS or other system could have an “LMK Control Panel” that would let them register new endpoints, manually resolve endpoints by providing messages and actions (they would “publish a resolution”), archive endpoints, get “ping analytics” of the traffic to specific endpoints, etc.

And… that’s it. That’s all it does.

You register an endpoint, the agent starts checking it, and then the agent lets you know when the endpoint returns in the affirmative.

You have never given anyone any personal information. Your agent checking the endpoint is as anonymous as you visiting the website. There is no commitment or cognitive overhead – you’re not exposed to a bunch of other events of content you don’t care about, and if the event never happens, you will never hear about it again.

There’s no AI to this. No magic. No problems to be solved. Like any standard or protocol, it’s just a matter of agreeing on it and evangelizing it.

But…

I showed this all to a friend, and he pointed out the “Subscribe” button “at the bottom of every YouTube video.”

I responded:

Yeah, but I don’t want to “subscribe.” I just want to know when this ONE THING happens.

There might be 20 unrelated videos between the one I watched and the Part 2 that I want to see. Just yell when Part 2 is out, and then never talk to me again and forget we ever had this interaction, unless I subscribe to something else.

And he responded with the cold, hard truth:

That makes sense. I can understand why you’re asking for that, and can understand why creators would never want to build it

…[sigh]. Yeah.

Technical Postscript

The only thing I might add is a /meta pseudo-endpoint that would provide data about the endpoint. It could return something like this:

{
  "created": "2025-08-05",
  "purpose": "To notify when Part 2 of Awesome Blog Post Series is published"
  "contact": "deane@deanebarker.net <Deane Barker>",
  "happened": false // So the agent can filter for active events
}

Your agent could retrieve this when the endpoint is registered and use the data to maintain its list and give you more information about the endpoints you’re checking.

Update

Added on October 12, 2025

Someone wrote an implementation of both the client and server in Ada (server) and POSIX/Bash (client; presumed).

The protocol couldn’t be far simpler: A client sends a UDP packet containing the tag, and the server replies with the tag if the event has occurred or an empty packet otherwise.

The Perennial Question of Diegetic Ludonarrative Kayfaybe

Sun, 19 Jan 2025 00:00:00 -0600

Lately, I’ve been introduced to some fascinating words:

Diegesis: this is the concept that audible noises in a narrative are sometimes “in” the story, meaning the characters can hear them, and sometimes they’re on the soundtrack, meaning only the viewers can hear them. (I wrote about this a bit here.)
Ludonarrative Dissonance: this is the idea that some aspects of a video game are part of a larger narrative, and other parts are part of the gameplay, and there are times when the intended narrative and the player’s actions disagree, leading to dissonance (did you know “ludology” is the study of video games?)
Kayfaybe: this is the staging of reality inside professional wrestling, both in shows and events, and as well as when interacting with fans (yes, it’s a weird word, and there doesn’t seem to be an accepted etymology for it, other than a rumor it’s pig latin-ish for “be fake”; more at Wikipedia)

Not to get absurdly philosophic on you or anything, but in the entertainment or content industries, there are three “levels of existence”:

The production of it (ex: the writers of a TV show)
What happens in the narrative or the content (ex: the characters in the TV show)
The consumption of it (ex: the person watching the TV show)

When we’re watching a TV show, at some level, we’re aware that the content is happening “away” from us. We are watching entertainment, and we’re not part of it. We go where the action goes, and we have no agency or choice what happens.

What’s the equivalent of digital experiences? When we view a website, do we maintain that distance, mentally?

Sure, we can navigate, but only within prescribed patterns. When we search, we see results that are given to us, we can’t see how they were created or get access to the repository of content. We have more agency than when we watch TV, but we’re still operating within prescribed channels.

Maybe intranets or groupware are different? With those platforms we understand the larger constructs at work. We usually have some concept of IA or content organization – we know that we’re looking at a “site” or a “list” in Sharepoint, for example. We’re oriented to how the information is managed. We understand the constructs; we can visualize the building blocks; we can see The Matrix.

To what extent is this helpful? To what extent do we need or want our users to “break the fourth wall” of our information structures? Is it helpful for users to be able to mentally frame what our content is in a meta-sense?

In more concrete terms: what if we published and linked our content models to the content they underpin? What if every page had a link at the bottom to our data dictionary with the type definition, all the properties, and showed where in the repository the content existed, spatially and all the processes acting on it?

Would that help the user’s experience? Would it help them understand the content?

Gregort Litt discusses the “nightmare bicycle” concept from a book by Andrea diSessa:

Imagine a bicycle where the product manager said: “people don’t get math so we can’t have numbered gears. We need labeled buttons for gravel mode, downhill mode, …”

This is the hypothetical “nightmare bicycle” that Andrea diSessa imagines in his book Changing Minds.

As he points out: it would be terrible! We’d lose the intuitive understanding of how to use the gears to solve any situation we encounter. Which mode do you use for gravel + downhill?

He makes the point that humans are capable of figuring out what “mode” applies to them, so long as we make the model clear.

Good designs expose systematic structure; they lean on their users’ ability to understand this structure and apply it to new situations. We were born for this.

Bad designs paper over the structure with superficial labels that hide the underlying system, inhibiting their users’ ability to actually build a clear model in their heads.

For casual users this might not be helpful. But for more indoctrinated users (I made that label up) that are going to be spending more than a trivial amount of time with a content repository, would help for them to “peel back the curtain” and understand how the content… works? Should we bring them inside and show them how the sausage is made?

Consider that you can download the entire Wikipedia database. They have an long page telling you how to do it and how to work with it. You can basically “walk backstage” and see everything, down the the level of a raw database dump.

I talked about this at the Codegarden conference back in 2019. Watch the first five minutes or so of this talk. It’s got Friends and Old Spice and shirtless dudes.

Also, I talk about we (those of us working in content) do –

We lie for a living.

That sounds harsh, but a huge part of our job is hiding the messy reality of how things work. Sure, we know the user has some concept of a “page,” but we want to pretend that our content was birthed to a virgin and borne softly on the wings of angels right to the viewer’s browser.

I’ve written about this line between us and them before: see Breaking the Fourth Wall of Content. I said, in part:

Unlike the traditional theater where the audience sits in the gallery and views the stage through the proscenium, intranets are like theater-in-the-round or “participatory theater,” where the stage is surrounded, there’s little place to hide, and actors come walking in through the aisles among the audience. The audience is “in” the performance. Other people are doing the acting, but the lines between “us” and “them” get blurrier and in some performances, actors come and sit in the audience and maybe even pull us up on stage. When this happens, we’re not voyeurs anymore; rather, we become part of the performance.

We spend a lot of time trying to pretend our IA and content modeling constructs don’t exist. They belong to “us,” not “them.” And if they’re ever detected, that’s like being caught in public in our underwear.

I feel like we need to think about this a little more. Digital experience is usually framed as an “us vs. them” proposition. Should it be? If not always, then when? And why does this matter?

What Are We All Afraid Of?

Fri, 17 Jan 2025 00:00:00 -0600

We don’t talk enough about fear.

In business – and in marketing especially – no one is “afraid” of anything. We’re “frustrated in our ability to execute” or we’re “concerned for changing market conditions.”

We speak in the detached patois of the insider; but we’re not “afraid” of anything. That’s a such a … pedestrian emotion.

And, anyway, why would we be afraid? MarTech marketing is always telling us how great we are.

We’re “Rockstar CMOs” or “Change Agents” or “LeadGen Ninjas” or whatever our last LinkedIn blurb read. We call ourselves this because that’s what we’re told by … ironically … the marketing of companies who want us to spend our money with them.

(You’d think people who worked in marketing would be less susceptible to marketing. You’d be wrong.)

But inescapably, underneath the posturing, we’re all afraid of something.

In 2014, Harvard Business Review asked 114 CEOs what they were afraid of. I expected to hear things about “disruptive technology” or “market displacement” – things they didn’t cause but could only react to, heroically, even in defeat. One pictures them, back against the wall, valiantly swinging their swords against the advancing hordes, standing courageously between their org chart and the abyss.

But, refreshingly, the number one fear was: “being found incompetent.”

That was followed by “underachievement” and “feeling vulnerable.”

Someone finally told the truth. CEOs, even.

I think fear is even more deeply seated in marketing because the field is, by nature, all about the appearance of value and fit. I’m trying to avoid using the word “pretension” here, but let’s be honest – marketing is about creating a mood, a feeling, a brand. In few worlds is being afraid of something a good look, and in marketing we tend to turn our campaigns back on ourselves. We want to embody what we espouse, so we buy into our own press releases.

And this is where it gets personal –

Marketing is often viewed as “art,” at some level. Accounting or operations is so easily separable from us as people – we can keep it at arm’s length, because it’s just numbers or processes. But marketing requires … interpretation, emotion, and subjective judgments about beauty and the human condition. There’s vulnerability in the exercise of that.

In the aptly titled Art and Fear, David Barnes and Ted Orland says this:

The chasm widens even further when your work isn’t going well, when happy accidents aren’t happening, or hunches aren’t paying off. If you buy into the premise that art can be made only by people who are extraordinary, such down periods only serve to confirm that you aren’t.

Screwing up finance might mean you don’t understand numbers. Screwing up marketing implies you don’t understand humans.

Compounding this is that our failures are inherently public. Marketing is meant to be seen, so if we fall flat on our faces, it’s not in some backroom accounting process or private warehouse operation or intranet implementation. No, if marketing goes sideways, everyone sees it. You can hide an internal process that doesn’t work, but crappy marketing campaigns are everyone’s business.

And there are just so many moving parts in the average MarTech suite. The “right” answer seems to be just around the corner.

TK Rader did a brilliant (if satirical) write-up on LinkedIn about how a bad CMO can keep their job for way too long, just because it’s so easy to get caught up and camouflaged by the constant eddy of technologies, stacks, suites, and methodologies in the marketing space.

Month 1: Tell the CEO that the MarTech stack is broken … Month 3: Marketo implementation is going well. It should come together any moment now. … But wait. Nothing is converting. I know WHY. Our BRAND is totally off. The website and the look and feel needs a re-design and our messaging needs a reboot. … Bounce rates up? It wasn’t our ICP traffic anyway so don’t worry. … Ok. Sure. We’ll do this. But listen, I really think we need to re-think how we capture demand and take a PLG approach. … Month 15: It’s not my fault. The Product just can’t support the PLG motion.

This is likely why CMO tenure is the lowest in the C-Suite. You can find a lot of statistics about this, so I’m hesitant to cite just one, but the average tenure of a CMO is about three years, and for a CMO in technology it’s even lower than that – less than two years, according to some studies.

So, we posture. We pretend. We swallow our fears as if none of that mattered.

But we all know there are things that keep us awake at night. There are things lurking out there past the light of the campfire that threaten to carry us off into the darkness.

What are those things?

Here are some ideas:

“Our content underperforms. It’s so repetitive. It seems like we haven’t had an original thought in a long time.”
“Our metrics are probably wrong. I’m not tracking the right things. I know how many people visited the website, but not what they did, what they liked, or how any of this even matters. What even is a ‘customer journey’?”
“Our content process is poorly architected. Campaigns take way too long to get started, and small changes turn into big messes.”
“We aren’t using the tools we paid for, and my boss is eventually going to notice. I promised that buying Tool X would make things better, but I can’t show that we’ve even been able to integrate it.”

Do any of those sound familiar?

They certainly sound familiar to me, and I’m not even in marketing, technically.

I’m the guy people in marketing talk to about their problems and their fears. I’m the guy people ask to come in and help them with those problems.

Sometimes they’re honest about them. Often, they’re not. A lot of times, I have to read between the lines.

But I always ask myself: “What is this person afraid of?”

In the next few weeks, we’re going to throw off the shackles of pretension and get really honest about what worries us and what we can do about any of it. There are solutions, but a lot of them are disguised under layers of posturing and assumption that you know exactly what your problems are and can find the corresponding solution to any of them.

So, let’s turn the lights on.

Theme 1: “Our content is not very good”

I’ve always felt like the Martech industry is more concerned with swimming pools than it is with what goes in them. We spend an inordinate time building magnificent holes in the ground yet often forget to fill them with water.

I keep trying to “back people up” to content – the stuff we’re supposed to be managing.

But we can back up further … human action. Because, in the end, this is what we’re trying to create: some form of human action, whether it be a “hard” conversion, like a checkout, or a softer conversion, like a changed opinion or a new perspective.

And this is where we often break down in Martech. So long as the architecture is in place, the content becomes sadly interchangeable. Or, at best, it becomes fatalistic – like, “We’ll just throw this out there and hope it works, and if it doesn’t, well… what’re gonna do? People like what they like.”

(And, while I’m not a Luddite by any measure, do you think Generative AI is going to make this better or worse?)

I’m not a content strategist, and I’m just going to assume you’ve engaged a good one. A good content strategist can help at the macro level – they can develop messaging strategies and architecture which are geared to getting your message across.

But let’s drill down further. How do you actually create better content? How do you create content that engages people? That delights people? That they share with other people, and return to more than once?

(I’m reminded of this 1994 long-form ad for MCI which I watch probably once a year and have shared with dozens of people over decades. Please, create content like this.)

I have a couple ideas here.

Solution 1.1: Better ideation and collaboration on content with a CMP

I’ll always believe that content gets better with transparency. Great content teams that I’ve worked with have a wide funnel at the top. There’s maximum visibility into their process – they “open the box” so everyone can look inside.

Great content doesn’t just come from a vaunted few. Lots of people inside your organization have one half off a great idea. The trick is to find the other half and put them together.

And this might sound weird coming from a guy so closely associated with CMS, but your CMS is not the place that this happens. A CMS is a publishing platform, not really a collaboration or ideation platform.

Years ago, I wrote a blog post called The First 85%, which posited that most of the “work” that goes into content happens outside your CMS. When someone actually logs into the CMS to create an artifact (the material form that the content takes), this is way, way into the process.

There are platforms designed specifically for that first 85% – the category is called “Content Marketing Platforms.”

(Honestly, I’ve never loved that label or acronym, because I think they have value far beyond just marketing. They’re more “Content Collaboration Platforms” or “Content Creation Platforms,” but then the acronym gets problematic…)

CMPs are based around the idea that content and its artifact are two different things. We tend to look at a web page and says, “that’s content.” But it’s not. That’s actually an artifact – a web page. The content is the message, the idea, the persuasion, all the effort and input that went into it. At artifact is just the media it got wrapped in.

In perfect world, we move to “multi-artifact” or “multi-channel” content. The same content turned into multiple artifacts and pushed into multiple channels reinforces the difference.

CMPs are about content. They assist with all the things you need to come up with better ideas and work through the sometimes-messy process that results in great content that affects people.

Intake: providing the ability for anyone in the organization to contribute ideas
Campaign management: figuring out how to group content into thematic campaigns
Large-scale content scheduling and editorial calendaring: – coordinating all the content efforts of entire organization for maximum efficient and effectiveness
Drafting content: actually putting fingers to keys and creating words or video or audio
Commenting and discussion: providing feedback and editorial review
Work process management: defining and tracking the steps that move content through editorial and publication processes

The “word du jour” in Martech is “content supply chain.” The goal is for your organization to strip the “heroics” out of content creation. No content process should require champions. No one should do battle. There should be no surprises.

Content creation should be – dare I say it – boring. In a good way. You want predictability. Reliability. And this is what a CDP seeks to provide.

(I maintain it should be boring like a trip to the dentist is boring. If your trip to the dentist is anything other than “boring,” that’s never good.)

Whenever I contemplate the idea of content being boring, I think back to a documentary called Saturday Night, which chronicles the weeklong development of an episode of Saturday Night Live. Contrary to the popular image of freewheeling insanity, the process of delivering an episode of SNL is incredibly precise and predictable. After watching that, I came to understand that creativity has to exist with process. It can run wild, but within guardrails that ensures that everything gets done.

This is what CDPs provide. They give you the framework to abstract the process of developing content to an enforceable platform, and let your staff concentrate and creating the best content they can.

Too much content either never gets started because it doesn’t get captured and developed, or derails because there isn’t a framework in place to shepherd it to publication.

Solution 1.2: Content accountability with micro-events and experimentation

I was in Helsinki once when a woman came up to me after a talk and asked, “How can I get my content creators to care about their content?”

She was stating an inconvenient truth out loud – a lot of times, people just create the content and publish it. Whether or not it actually does anything is not really their problem. They just throw it over the wall and hope for the best

One of the problems here is simple attribution – we generally don’t identify or track conversions as well as we should, so how would we know if our content was “effective”? In many cases, we can’t even define what “effective” even means.

A lot of content creators know this. I don’t want to say they hide behind it, but they simply know that their accountability ends with publication. They just have to get content out the door and are less concerned with what happens after that.

This is what my Finnish friend was struggling with. Her editors created a bunch of content, but after they hit publish, they didn’t have any skin in the game.

One of the solutions here is to include your tracking down to the “micro-event” or “micro-action” level. So, you don’t just track cart checkouts, but you break tracking down into smaller actions. If we accept that a conversion funnel includes lots of smaller events leading up to the moment where someone provides demonstrable value, you can start tracking those events.

Don’t just track who clicks a video link from your home page. Track who plays it. Who gets to 10%. 50% 100% percent.
Don’t just track page views, track scroll depth. How far “down” a piece of content does the visitor progress? (I like this so much better than time-on-page. Scrolling implies they’re doing something, and didn’t just switch windows or go to the bathroom.)

Once you’ve drilled down this level, you can more accurately track that wildly over-used word: “engagement.” And because you can track this more granularly, that means you can bring experimentation to bear.

Experimentation is what it sounds like: trying different things, with a structured tracking system to definitively define which option works better.

Consider:

Don’t just write one headline for that article. Write five, each taking a different angle or in a different format or tone. Then find out which one gets clicked on more often.
Fiddle with design elements on the page. Try different images that completely change the tone and focus of the article.
Break the content down into different lengths. Find which one gets people to the Call to Action more consistently. Clearly, more people are likely to get to the end of shorter content, but how serious are they? Fewer people will stick with longer content, but they might be naturally more qualified leads.

Believe me when I said that you don’t know the answer to any of this. You don’t – you might have theories or suspicions, but you don’t know. The only people who know are the people who are consuming your content, and experimentation fundamentally becomes a way to ask them.

I would never be so bold as to say that you’ll ever be able to absolutely predict with your customers want and what will resonate with them, but experimentation and micro-analytics gets you closer to refining that prediction over time.

Solution 1.3: Content desire with CDP journey analytics

There’s a great scene in Friends where the gang is having a trivia contest to see who knows each other better (remember: the winner gets Monica and Rachel’s apartment).

Ross: Rachel claims this is her favorite movie…

Chandler: Dangerous Liaisons

Ross: Correct. Her actual favorite movie is…

Joey: Weekend at Bernie’s!

I love this, because it reveals a truth: we are what we consume. Humans have a process of “content association” and “content disassociation.” We love to be associated with Dangerous Liaisons because that makes us look erudite. We might not be so open about Weekend at Bernies, because that less of the image we’re going for.

No matter what people say they want, what they are is what they consume. There’s a lot of content out there, and there’s no better way to figure out someone likes than to follow them around and, well, keep track.

You might think this is analytics, but it’s not – analytics is about tracking content consumption is aggregate. Analytics tells you that 1,000 people read your blog post.

But customer data is something different – customer data tells you that this person read four blog posts, a product page, and downloaded a white paper. You might not even know who “this person” is, but they left a behavior trail in their wake.

Analytics is channel-centric, and cross-identity. Customer data is identity-centric, and cross-channel.

Let me say that again: analytics is about a channel, in aggregate. Customer data is about… Bob. Or Mary. Or whoever.

Every trail tells a story. Content recommendation platforms can use that story to predict the content someone will consume next, specifically what content is most likely to lead that journey to a conversion.

You see, if you watch enough journeys, you start to recognize patterns. Then you can consider Identity X and find patterns of (1) people consuming the same type of content, and (2) people who arrive at a positive outcome (a conversion). Combine those two things and you can pretty accurately figure out what Identity X should see next.

Knowing this, it becomes much clearer what content in your system is most effective. Additionally, you can “load level” your content by figuring out if you have more content of a particular topic that your visitors want, or less content. This helps drive better decisions about what content to create.

Again, this isn’t just about consumption. This is about consumption as part of a larger process. Just because someone consumes something doesn’t mean anything by itself. Hell, you can get people to consume anything with clickbait-ish titles.

But if they consume something, and then go on to convert or provide value, then that gives you a key piece of data. Now you have some understanding of the path that your customers go on, and you can develop content to meet that need, instead of just piling on more and more content that performs well in isolation.

This speaks to a larger, healthy perspective shift – moving from content to journey. Very few customers consume a single piece of content, then convert. Rather, everyone is on a journey through your content domain. They move from content to content, experience to experience. The key is not concentrating on specific “islands of consumption,” but rather to understand the transitions between them. Why does Content X lead to Content Y, and is that the path someone takes before they become a conversion?

It’s a study in what’s called “positive deviancy.” Instead of trying to figure out what’s wrong with your content, figure out what’s right. Use tooling to examine those journeys that worked, then extract the commonalities from those and capitalize on them.

We can do all the focus groups we want, and we’ll never learn exactly what makes our customers tick. I’m not saying you shouldn’t talk to your customers, but they’re probably going to tell you about Dangerous Liaisons, rather than Weekend at Bernie’s. We don’t want to know what customer say they want; rather, we want to examine the successful journey they actually embark on.

…and that was the end of the series. As I said, the intention was to create more “themes,” each with their own set of “solutions,” but the project never made it to the finish line.

I did find this list of topics I may have expanded upon over the life of the series.

Competitors are using AI better than me
My metrics are wrong
My content process is poorly architected
My website isn’t performing well
I could push to more channels
I’m going to get sued over accessibility
I’m not capturing enough data
We aren’t using the tools we paid for
Campaigns take too long to get started
We can’t attribute marketing success
There are problems in our digital estate that we don’t know about
There are too many things going on and I can’t control it all
We don’t capture or understand our data; all our decisions are based on nothing but gut feeling and we can’t defend them
We can’t track traffic all the way through to revenue

Managing Service and Content Quality Over Time

Mon, 6 Jan 2025 00:00:00 -0600

I’ve spent time working with young people, specifically teenage boys. Being in that stage of life, they regularly regaled me with all the cool things they were going to buy when they got old and rich – as if those two things were inextricably bound together – cars and houses and electronics and gadgets, etc.

At about this same time, I had a very successful (adult) friend who actually bought a Lamborghini. Soon, he was complaining about how he had to have it shipped to another city to get oil changes, and had to have the wrap re-done regularly (they don’t actually paint cars anymore, I guess?). I remember asking him how much it cost to insure – I don’t remember the number, but it was absurd.

This gave me a handy object lesson for my young charges –

Expensive things aren’t expensive just once. They continue to be expensive over time. And while lots of people dream about getting these things, not enough people think about more boring topics like maintaining them.

I feel like there’s a corollary with large websites. They’re not just difficult to build and accumulate – they often continue to be difficult over time. If you don’t stay on top of them, they slowly (or quickly) fall apart.

I have about 6,000 URLs of content on the website you’re reading right now. That represents so many things that could go wrong. In addition to all those URLs, I also possess a weird anal-retentivity against errors that has driven me to do some hilarious things to try and ensure quality (…for a website that makes no money and that I tinker with incessantly; I have great business sense…🙄).

Let’s think for a second about all the things that need to happen for a website to provide the value you’re hoping for –

The website has to be up – it has to provide some response to a request
That response has to be valid; 200 OK; not just an error page
That response has to have valid HTML constructs that make sense when interpreted by a browser
Functionality you have programmed – like search or taxonomy – has to work correctly
The content has to be minimally valid – located in the right place visually, spelled right, organized correctly, etc.

And this all comes before any whiff of content strategy. All of this has to happen before someone can even decide if your content is any good.

Here are some things that I do. Keep in mind, this is a personal website, maintained by one person. What you might do for an enterprise property with more than one team member is likely different, but a lot of the themes are the same.

The first step down this road is simple Site Monitoring. There are services that do this – they make requests against your site so often just to make sure it’s still up. At the most basic level, they check for a response. Any service worth its cost will also check that the status code is a 200 (because a 404 response is still a response…)

Going a bit further, you can configure a lot of them detect specific HTML patterns, to make sure what’s coming back is what you expect and not just some “we’re down for maintenance” page.

Again, these exist as paid services, but they’re also wildly easy to script yourself.

Back in the early days of the internet, I used a simple VBScript for this. HTML parsing in that language was basically non-existent, so I just embedded an HTML comment as the last thing on the page. The script would make sure the HTML comment was in the response, to ensure that the page rendering didn’t error out before that point.

A long time ago, I used Nagios for this, but that system has long-since been eclipsed by others. For a particular project, I pointed it at a hidden URL that did a lot of things in the background – connected to database, tried to access specific files – any one of which would throw a nasty error if something went wrong. So one URL call effectively “ran” 20 or so tests.

I was given a free account at Visualping last year. I’ve been using that for a while and quite like it. It’s meant to detect and summarize site changes – which it does very well; it’s AI summaries of changes are eerily well-done – but it also doubles as a site monitoring tool.

So, that’s pretty simple. But, let’s go further. Say that we know the website is up and delivering a response. How do we know that response is what we want?

This is where you move into Automated Browser Testing. These are tools and services that will instantiate a “virtual browser” in memory, load your website, then interact with it as if they’re a person until they reach some state that constitutes a valid test.

For example, you could have your test bring up your search page, “type” something in the search box, “press” the submit button, and ensure some results come back. It could even comb through those results to make sure an item that you expect appears in the list.

By setting up that test, we’re “forcing” a lot of preceding functionality be available. To get a specific list of results, our search engine has to have indexed the content properly…and our search UI has to be working…and our website has to be up…etc. We’re now effectively testing the end result of a long line of dominoes to make sure something is working.

(Do you need “standard” Site Monitoring if you’re using Automated Browser Testing? Probably not, but I haven’t thought about it too hard. There are probably some cases where both would make sense.)

A lot of these services are based on an open-source tool called Selenium. The one I’ve worked with is called Ghost Inspector.

Years ago, I used Ghost Inspector while working on a large project over the course of about a year. It effectively ran about 100 spot checks on different parts of a the developing website once an hour. If a change in Thing A caused an error in Thing Z, many levels removed, we got notified. It was basically holistic unit testing. The tests were timed, but you can run them on-demand as well, from an API call, so you could run the tests as part of a build process.

(We were open with this customer about the testing suite, and we offered to transfer our Ghost Inspector account to them so they could continue using the tests after launch. They didn’t take us up on it, and I thought they were abandoning a huge amount of hard-won value.)

So, now we know the website is up, and we know that all sorts of functionality is working. But, this is just technical – it’s service quality, not really content quality. How can we be sure the website is returning what we want it to?

This is where we move into Digital Quality Management (sometimes called “Digital Governance Management” – the term is currently a little slippery).

There are an entire category of software products here. They consume your website (remember, we’re just assuming that everything is working – if it’s actually broken we would have caught it by now), and they verify and measure multiple factors:

Performance: how fast is the website responding, both from a service response and a client response; is any particular page slow to respond or render?
SEO: how well is a particular URL performing in relation to a targeted set of keywords?
Accessibility: are there accessibility violations at any URL, from something as simple as missing ALT text in an image, to things more complex, like poor color contrast (even inside individual images)

These platforms will crawl your website regularly (or on-demand), check for compliance, then send you notifications and reports about issues. Some of them will plug into your CMS to provide pre-publish checking, but they tend to be CMS-agnostic, as content for large enterprise properties often comes from many different sources. They consume the finished product, regardless of what was used to generate it.

These platforms come pre-configured with lots of rules for the above, but what gets interesting is when you build out custom rules.

I have a homegrown DQM system running against my site (note: I do not recommend this – it’s an unholy mess of LINQpad scripts – but it just kind of grew over time). You can see the latest report here.

Here are a few things I check for –

Each page must have one – and only one – H1 tag
H2, H3, and H4 tags must be in the correct order, meaning an H3 can’t appear unless preceded by an H2; you can’t skip heading levels
The clickable text of any link to a URL ending in “.pdf” must end with “(PDF)” so I’m not blind-linking someone to anything but HTML
All internal site links should be relative (they should not include the domain), and they must either have a dot (“.”) or end in a slash (this is just a rule I made to be consistent…)
…and so on – I think there are 32 rules I run. I add a new one every once in a while, and some are temporary rules just to make sure some problem is fixed and doesn’t reoccur.

I can allow exceptions to these rules. Some pages break a rule or two, and I can “pre-acknowledge” this to avoid it throwing errors. I’ve even drilled this down to the HTML element level – I can exempt single elements from particular rules if I need to.

There are 30+ tests I run – you can see them at the bottom of the report. Some are specific to my situation, some are related to some weird one-off problems that happened at some point (I should probably prune these…), and some are just good tests in general. Most all DQM tools will let you write your own tests to enforce your own concepts of quality and governance.

So, now we’ve ensured the site is responding, that’s it’s sending back a valid response, and the content its sending back is performant, accessible, search-friendly, and complies with whatever arbitrary rules we want to put in place.

Congratulations. We’ve achieved a minimal level of quality.

This is getting long, but there are some other practices I’ll talk about in future installments:

Systemic spellcheck. This is not red squiggly lines in a text editor. Rather, how do you spellcheck every last one of the million-plus words on a large website. For that matter, what even constitutes a “word”… but we’ll save that rabbit hole for the future.
Something I’m calling Novel Entity Analysis. A lot of problems manifest with the spontaneous appearance of something new – with 6,000 URLs and a million-plus words, it should be fairly rare that a new, previously unobserved token appears anywhere. And if it does, I should know about it. The same goes for new URLs and new HTML constructs (tag+ID, or tag+class).
Simple random page review. I have the ability to pull a truly random page from my website with one-click. Lemme tell you, you’d be amazed at the stuff you find when you wander through content you haven’t looked at in years…

So, in the absence in covering those topics today, let me leave you with these three “meta issues” you’re going to have to figure out when implementing a digital quality program in any form. None of these issues are technical, but here the point to the larger issue with these programs –

The biggest threat to digital quality is that no one cares, or interest wanes over time, so all of your wonderful plans amount to nothing.

So, to prevent that –

You’ll need to manage exceptions. Rules will be broken, often for good reasons, and how do specify that “this is wrong, but okay,” to avoid pointless alarm? Understand that this isn’t a minor issue. It’s not just about convenience – you need to acknowledge issues even if you don’t fix them, because persistent unacknowledged issues are the first step to people ignoring the system altogether. How do you get people to understand that every issue is a problem? If they think they can routinely ignore stuff, they will ignore everything.
You’ll need to manage notifications. How do tell someone that something is wrong? Do you push notifications? At what severity? If you have people pull them from some report, how do you ensure this gets done? What auditing processes do you put in place to make sure that things aren’t just getting ignored?
You’ll need to manage follow-up. For me, it’s easy (spoiler: I handle everything), but for larger organizations, who does what? How do you manage the triage, task assignment, discussion, and backlog that results from these things? Unquestionably, you are creating new work. To be sure, it’s good and necessary work, but you’ll need processes to manage it.

So, there’s a lot here. I’ll just conclude by saying that this matters, because content matters. If you publish something on the Internet, please take care of it. Make sure it doesn’t suck, or start to suck over time.

The Internet can be a mess. Let’s all keep our ends of it clean.

The Looming Art of Gist Management

Tue, 31 Dec 2024 00:00:00 -0600

Lots of people think content strategy is a dying art, in the age of AI.

I don’t.

I think that content strategy has never been more important. AI has quietly forced content strategy to the forefront through a dynamic that a lot of people don’t quite realize yet.

But let’s start by going way, way back. Let’s talk about how the history of how we develop for the web has always been a battle for control –

I’ve been developing for the web for… 30-ish years? Since 1995, I think (the web was born in 1993, so this is pretty close to the beginning). I began in HTML 1.0 on Internet Explorer 1.0, if that tells you anything.

I remember writing my first HTML page in Notepad, and when I realized that whatever it put in the TITLE tag would appear in the title bar of the browser window, I felt like an elite hacker.

The first websites were intensely static, and built to stay that way. They only came one way. We designed for 640-pixels wide, because that’s basically the only thing we count on. Everyone had a 15” CRT, except for your rich friend who didn’t have any student loans – he had a 17”. Back then, you had a wide array of font choices, so long as your choice was Times New Roman. Design options and browser choices were so limited that you could be pretty confident that what you “designed” would come out the same way.

But, over time, the web has been in a steady, constant process of relinquishing control to the person who consumes the content.

The web was a visual medium. We were determined to control that visual. How things looked was as important as the content being delivered.

Slowly, monitors got bigger. Screen sizes expanded. We couldn’t count on standard widths anymore, so we had to design for the lowest common denominator. Then new browsers came out, and we added all sorts of hacks to figure out what browser you were on and account for it.

Eventually, monitors and graphics cards got better to the then-mind-blowing point where the monitor was sometimes bigger than you wanted your browser to be. So people would browse in a non-maximized window, which lead to all sorts of odd sizing.

New browsers showed up. We had Mosaic, then Internet Explorer, then Mozilla showed up, and Opera was always lurking in the background. And they all had different rendering engines. Cross-browsing testing was a total crapshoot.

Then RSS happened. This was (and is) a niche protocol (yes, yes, I know you and I love it, but does your grandmother?). However, the key is that it first introduced the basic idea of restructuring content for consumption elsewhere.

Here’s a quote from the W3C release in 1997:

Code-named Aurora, the software will let PC users customize the way they view information on their desktops.

Content creators were suddenly confronted with the idea that their content could be stripped of its visuals and consumed outside their control (albeit with their permission). This was the first step in multi-channel publishing, and introduced us to concepts of channel rigidity – some things just didn’t work in RSS. A lot of us limited the information to a preview and drove visitors back to the website – where we had total control, dammit! – but others developed different templates and renderings for RSS.

And then mobile devices happened –

Suddenly, we couldn’t count on anything. So we created mobile sites (“m-dots”) to hold onto control as long as possible, then eventually conceded to responsive design and let the container dictate the visuals.

This was a monumental shift, mentally. We were conceding that what something looked like was less important than the content we delivered. We made sure the content looked acceptable, but designs slowly became less complicated. We got back to simple single-column vertical scrollers (remember when we were floating everything…?). Since we couldn’t control how things looked exactly, we just made sure the content came through.

We used to be in control. We weren’t anymore. We learned to accept this and adapt. It used to be important to make your visuals look the same everywhere. But suddenly it became more important just make sure the general design ideas and themes came through everywhere.

Enter AI –

Weirdly, this is exactly the same thing, just down a different axis.

We’re not letting go of visual control anymore. We’re letting go of cognitive control. The current batch of AI tools is interpreting everything we create. It’s synthesizing it and translating it.

The effect on delivery is paradigm-shifting –

Visuals are basically gone. Content is being delivered in other apps and tools that we have zero control over, so designing something might become extraneous.
Exact wording and phrasing is even gone. AI is like a big game of “Telephone” – our exact words are being synthesized and changed and then delivered with the same claimed authority as the original author.

This shift is even more monumental than anything that has happened in the browser or front-end design wars. Not only can’t you control what your content looks like, but you can’t even control the words or visuals it’s delivered in.

(And no, video and audio won’t help. Before long, more people will read, watch, or listen to AI-summarized output more than they consume the source.)

So, where does this leave us? We’ve spent a long time designing content, and managing content, and now that’s becoming less and less important. I’ve seen predictions that the web will eventually succumb to “AI agents” that just gather stuff and do tasks for us.

Weirdly, the agent concept was always the idea. Tim Berners-Lee – the guy who invented the web – wrote a landmark article back in 2001 called The Semantic Web. This was the abstract:

A new form of Web content that is meaningful to computers will unleash a revolution of new possibilities

Berners-Lee was pushing RDF – a method of infusing the web with machine-understandable meaning, so that computers could understand it all and do things for us. For the founder of the web, the “prescriptive web” was just a pause on the road to his ultimate goal.

However, AI almost seems to have gone “around” RDF and achieved basically the same thing. Instead of being fed structure, AI is just trying to figure out structure itself.

AI is basically a new channel. Should we “publish” to it like we publish to social and email?

Which brings me back to my to my original point –

When you strip away control of the visuals, which we’ve been doing for 20 years, and you strip away control over the exact content, which AI is steadily doing now, what’s left?

The message.

The core point.

The… gist.

What’s the gist? That’s the basic idea. That’s the change you want to influence in the person who consume your content. It’s the idea you want to put in their head. The action you want them to take. The impression you want them to get.

In the future, all we can really count on is the suggestion… the gist.

In politics, people are constantly told to stay “on message.” Good political communicators know that with the frenzied, fractured, biased media world in which we live, they have to keep hammering away at simple points to be heard. They have to relentlessly push a core idea. They can’t control what happens to their words after they say them, so they have to stay true to the gist, or everything will get lost.

And the gist is where content strategy rules. You have designers and you have developers and you have copywriters, but technology is advancing to the point where the value these people add can be circumvented. Things don’t have to be designed, or programmed, or even written.

But the gist will always be there. The new content strategist is going to understand that they can’t count on anything anymore, they can only try to make sure the the idea gets through. They will ideate campaigns and write words and film videos with the understanding that 95% of people will consume them through some level of AI filtering, summarization, or contextualization. And they’ll make sure the gist keeps coming through.

It’s not visual anymore. It’s not words anymore. Instead, we’re trying to persuade machines to deliver the ideas we want to get across.

To be clear: the new skill of content strategy is your ability to train the machine.

In that sense, it’s a whole new world.

Software Isn't the Problem

Tue, 28 May 2019 00:00:00 -0500

Everyone wants to believe their shortcomings lie elsewhere. Humans are really good at placing the blame on anything but themselves.

Often, this surfaces as limitations that we’ve convinced ourselves exist and are holding us back.

If only I didn’t have to do my chores, I could be a better guitar player.
If only the gym was closer, I would workout more.
If only traffic wasn’t so bad in the morning, I wouldn’t be late for work.

If only…

The Projection Defense

This is called projection.

Psychological projection is a defense mechanism in which the human ego defends itself against unconscious impulses or qualities (both positive and negative) by denying their existence in themselves while attributing them to others

No, no, you’re right – it’s not you. It’s clearly everyone else that’s wrong.

We take limitations or shortcomings that are inherent to us, and we project them onto some other thing. That thing is the problem, not us.

We do this with software all the time. We blame software limitations for what ails our organizations. If only we had better software, things would be different. There’s no point trying to be better, because we’re hobbled by poor software.

Some of this might be true, certainly. But a non-trivial portion of it isn’t. We put too much emphasis on software’s abilities to make up for our shortcomings.

We look at new software like a kid with their nose pressed up against the window of a candy store. If only we had that software package, then everything would be different.

But…would it? If you had the latest software package for whatever industry or practice you’re managing, would everything really be different? Would you expand to your full potential and begin to make leaps and bounds toward your goals?

If the gym was a little closer, would you really become the triathlete you’re sure you could be?

Probably not. We project negativity onto existing software and positivity onto software not-yet-acquired, but often the limitations are outside the software. It’s not the software holding us back.

My talk for 2017 was called Why Content Projects Fail. I gave it 6-7 times around the world, and this slide below never failed to get a laugh.

This is all of us:

In my talk, I discussed why we project our problems onto software:

There’s a good chance significant parts of our problem originated externally to technology
But, we tend not to look to people, governance, or process, because these things exist now
If the problems could been fixed without new technology…then why weren’t they? We had all the control.
It’s easy to say, “Things will be better when we have new technology because we’ll have something we don’t have now. We just don’t have the right tools now.”

Blaming software is a handy way out of awkward questions. And software has no opinion and no defense – your old software can’t shirk this blame, and your new software can’t realistically manage your expectations.

I’ve written about this before in relation to several different CMS features –

Content Personalization: A Reality Check (October 2016):

The sad truth: most organizations can barely manage a single effective version of their content, much less multiple versions. No client I know has multiple versions of their content just sitting around, tailored to different audiences. This is something you see in case studies, but that few organizations actually have the resources to do.

The Truth About CMS Form Builders (January 2017):

After your website launched, how many forms did you need built in the following year? For most of my clients, the answer is “not many.” How many forms will you need built in the next year? It’s usually the same answer.

You Want Collaboration, Not Workflow (June 2014):

Seemingly every project has grand plans around workflow. Editors are going to submit content to an approver, then it’s going to an editorial committee of which 60% need to sign off, then it’s going to a metadata specialist, then the legal department, and then it will be published when the temperature in Moscow hits 60 degrees and the Oakland Raiders win the Superbowl, etc. Of course, none of this ever happens.

I sound like a cynic, but 22 years in this business has taught me that all of the above is accurate.

Truth: if the shackles were thrown off and they had all the marketing tools at their disposal…many (most?) customers just wouldn’t know what to do with them all. They’ve pinpointed their problems as deficient or missing software, but this implies that if this shortcoming was patched, everything would fall into place, and this is just not true in so many cases.

This reminds me of YAGNI, the programming principle of “You aren’t gonna need it.”

[…] a programmer should not add functionality until deemed necessary.

Perhaps we should modify it to “YAGUI: You aren’t gonna use it.”

The Boring Truth

Now, I’m not saying all marketing tools are pointless. This market is ruthless, and if they didn’t work, they’d get drummed out of existence. But they’re still around, so someone is getting value from them.

How do they do it? Magic?

Nope. Just boring stuff like –

Adequate Staffing

If you’re planning an expansion of your digital marketing technology, you need to take stock of your staffing. This stuff takes work. Is everyone sitting around with nothing to do? If not, you need to be prepared to hire.

In fact, I just read a book entirely dedicated to the idea of building a “content team,” which is an idea foreign to a lot of organizations because content just kinda…happens, or “someone from marketing handles that.”

And it’s not just you – this article is a blistering indictment of the implementation of an electronic records system at a hospital. They found that it meant they had to hire more people – each doctor now had to have a “scribe” follow them around to patient visits to “work the software” while the doctor did their original job.

Adequate Training

Software likes to pretend that it’s easy to use and everything “just works.” This is compounded in the era of AI and ML (“It learns by itself!!”). Don’t believe it. You’ll likely need formal training to activate the software and evaluate the results.

Consider: Sitecore is so complex that it has an entire service line – Sitecore Business Optimization Strategies – that uses your Sitecore installation for you. You can buy a car and a driver in the same transaction.

Adequate Time

Transformation doesn’t happen overnight. You’re going to make a lot of mistakes. Once you have all the tools at your disposal that you were convinced you need, give yourself a year to make All the Mistakes™.

You need time to absorb all that new functionality, figure out how to work it into your processes, probably shed or swap some people, and then actually get down to business. Search for the phrase “software adoption” sometime. There have been many, many books written on the psychology and time required to get people to adopt new processes. This is not just like flipping a switch.

(Michael Sampson has written a good book here – User Adoption Strategies. It’s a bit Sharepoint-centric, but still widely applicable.)

Adequate Leadership and Vision

If the things you want to do are as transformational as you believe, then you’re going to need to paint a picture for the rest of the organization to get on board. You’re going to have to slay political dragons and fight for budget, people, and reorganization. We might need to reframe your organization’s entire relationship to its content and communications channels.

A client was just in my office last week to discuss rebuild of their website. As we talked about different technologies we could bring to bear, it became obvious that their relationship with their customer was still rooted to when they started the company in 1986. Some of their processes were just thinly-veiled versions of the originals. They needed to completely change how they related to their customer.

New technology might lay these situations bare, and there’s no ThanosSnap 5.0™ that’s going to magically fix what you find. You might be waking a sleeping giant, and you need to make sure you have the leadership, vision, and executive backing to see it through when it unravels.

…

Software doesn’t work in a vacuum. It’s nothing but a tool that assists an otherwise healthy and prepared organization to move forward. It’s a force multiplier – it can absolutely make you better, but you have to bring something to the party.

The Awkward Part

Here’s what gets tricky as a someone in software and service sales: how do you tell someone that the software isn’t the problem?

I was at a Boye and Company CMS Experts Group meeting in Brooklyn two weeks ago, and we had a raging discussion about the Hertz Accenture fiasco that’s in the news right now. Some of us expressed amazement at the $32 million price tag. Clearly, Hertz is a big customer with big needs, and there’s a lot of integration there, but…$32 million?

We imagined someone at Accenture and Adobe just selling Hertz everything they could toss into the deal, whether Hertz could use it or not.

Of course, we debated, what’s the alternative? As people selling software and sales, do we need to pretend that customers can use everything we sell? Or should we advocate for our customers and tell them that we just don’t think they’re going to get any use out of Feature X?

A pause…then John Eckman from 10Up said what everyone was thinking:

If you do that, then you’re passing judgment on their skill level.

And he’s right. If I tell a customer they shouldn’t buy a personalization engine because they’re not going to use it, what I’m really saying is:

The problem isn’t the software. The problem is you. You just don’t have the skill to use that.

It might be graceless, but there it is.

Obviously, you can’t say that. But what you can do is nudge this customer toward a more holistic approach to their software when they have unrealistic expectations. From the prior post about personalization:

When I discussed personalization with a client once, I kept asking them, “Okay, now that we know who the visitor is, what do you want to do about it?”

They kept responding: “Well, we want to change the value proposition.”

This isn’t enough. There is no button in your CMS that says “Change the value proposition.”

My client was convinced the software would Just Work.

In reality, personalization actually made their job harder because it put them in a position where they now had to bring acute content strategy to bear to respond to an identified audience. Put another way: ignorance is bliss, and if your software can now resolve your ignorance and enlighten you to tiny changes in your audience demographic, are you skilled enough to do anything about it?

These things can’t be easily deconstructed, and the software can’t save you. Some problems are complex just because they’re complex. This stuff isn’t magic.

Customers need to be introduced to the breadth of what they need to do, then guided into a integrated approach that circles all the organizational wagons around whatever uber-feature they have their eye on.

Otherwise, you just aren’t gonna use it.

Words with Friends

I wanted to make sure I wasn’t all alone on this, so I got in touch with a few friends to get some outside perspective.

Here’s Jessica Fardin, CMO of Episerver who says the organization’s culture is often to blame.

Software only becomes a vanity fix if a company’s culture isn’t onboard to really diagnose problems from top to bottom. You can’t blame the plumber if you never opened the walls and just painted over a leak in the ceiling.

I’ve witnessed the most successful Episerver customers not being afraid to communicate operational flaws with impacted groups often and early. It’s OK to say, “This isn’t working.”

The alternative is finger pointing after the fact and, to Deane’s point, it’s less awkward to blame a platform than a person or the processes they can’t let go of.

First, never under-estimate any organization’s ability to point fingers. Second, that last point is so true, especially the word “awkward.” It’s easy to blame software because you can’t hurt its feelings, and it won’t demand severance pay. It’s easy to walk away from.

Here’s Tom Wentworth, SVP of Product Marketing for Acquia who points some of the blame back at vendors.

There’s an Innovator’s Dilemma problem in web content management. Products are evolving in capabilities and complexity at a much faster rate than customers are able to consume them.

Vendors get some of the blame because we make it look so easy to deliver a personalized 1-1 customer journey in a product demo. The truth is that customers underestimate the impact of organizational change.

You can’t just double click on “DigitalTransformation.exe”. The customers who are most successful – and avoid the $32 million dollar price tag – are the ones who do the hard but boring work to connect people, process, then products.

But vendors do need to simplify our products to help customers get to value faster. The future of web content management is less complexity, not more.

I give Tom credit for going there. Vendors reinforce “Wedding Day Syndrome” – your spouse is never gonna look better than on your wedding day. When you see them all made-up in a wedding gown or looking dapper in a tux and tails, don’t get the idea that this is how it’s always going to be. They’re just not gonna look that good stumbling back into bed in a vomit-stained t-shirt after a 3 a.m. feeding.

So far, we have customers and vendors to blame. For some balance, here’s Arild Henrichsen from Epinova who says that we integrators share some of it.

We can’t forget that there is also a middle ground between the over-promise of vendors and the skill limitations of users: Botched CMS implementations by agencies.

The most competent CMS platform and editorial team can be rendered almost useless by a bad implementation – usually from a team that either lacks understanding of that particular CMS platform, or lacks understanding of the customer’s needs.

Integrators have a special responsibility to strike that balance between customers’ creative ambitions and their skillset – creative flexibility vs editorial control – and executing implementations in a way that can scale as the customer reaches a higher level of digital maturity.

Sure, I’ll take that blame.

But, just to keep score, The Blame Game™ is currently:

Customers: 1
Vendors: 1
Integrators: 1
Software: 0

(Or Humans 3, Computers 0, depending on how you want to roll that up.)

Back to vendors for a second –

Tony Byrne from Real Story Group provides this slide which presents the “Capacity/Hyperbole Gap” problem. On the far right is what the vendor claims their software can do under the best conditions. Moving leftwards we find what the software can actually do assuming you have the skill to use it. Then far left is what the software can do with the skill an average customer actually possesses.

Tony adds:

I think an organization that really focuses on capacity building first and tools later is going to discover that they can get away with much simpler tools at the customer engagement tier and push complexity down in the stack.

Here’s Brody Dorland, co-founder of DivvyHQ, an editorial management platform, who says that organizational pain drives motivation.

The two main drivers for success in the Divvy world seem to be “shared pain” and “readiness.” And the two actually go hand in hand.

Meaning, a good number of folks walk through our virtual front door everyday and, upon our initial conversation, they have communicated some level of pain in their current processes. But pain can come from the top (i.e. leadership lacking visibility/oversight into a siloed operation), or from the bottom (i.e. users in the trenches).

More often than not, only one of these groups is hurting and driving for change. That’s an average customer for us and we may not get full adoption. But once in a blue moon, both the top and bottom have come together, acknowledged each other’s shared pain points, and recognized that they are “ready” for a change.

Those on the top need to feel the tactical pain of those on the bottom; and those on the bottom need to appreciate the organizational pressure felt by those on the top. This is basic human empathy – we need to step into each other’s shoes and try to feel what they feel.

Here’s Brandon Kelly from Craft CMS:

All the successful Craft shops have mastered the art of follow-through. Even if an implementation seems like a perfect fit on day one, it’s not going to last. Business needs and workflows evolve. If the CMS doesn’t adapt to those changes, the client will grow to resent it and eventually look for a new solution, and a new partner.

So, Brandon is pushing for a refined implementation over time. Get it in, then smooth it out on the back slope.

And here’s “Rock You Like a Carrie Hane” (that joke will never get old) from Tanzen who says you should start with the goal state and work backwards.

My clients’ and students’ technology is never perfect, so we get creative and work backwards from the ideal. We create our strategy with no tech stack in mind, but what needs to be accomplished. Then we either find tech to support the goals or figure out how we can adjust our tactics using what we’ve got.

To repeat Carrie: “no tech stack in mind.” Get your non-tech house in order first.

All these people are seasoned professionals who have forgotten more about this business than most people will ever know. And I have yet to find someone who is willing to blame the software.

To make sure I got as many angles as possible, I reached out to Meghan Walsh, Senior Director of Content Services for Hilton. Meg is well-known in the content community as a doer – someone in the trenches trying to make all this theory work.

Meg says:

I’ve worked places with dying CMS platforms and been able to do great things with content – maybe not as much as we hoped – but great things – because we focused on the what of content first - -which is all people and process and goals. It’s the system-agnostic stuff. The technology is the how.

I’ve made some bad decisions in my career about content structure, use and operations. Some of those bad decisions were hidden behind the curtain of the technology. I’m continually trying to learn from that.

[…] Technology is the easy blame because it is, well, technology. As a practitioner, as a content leader in my company, I can’t take the easy way out.

Let’s round this out with the legendary Karen McGrane, a friend with whom I’ve shared many war stories and commiserated over many drinks.

I say flat out to clients all the time “your technology isn’t your problem. YOU are your problem.” And everybody laughs, probably because they’ve all been through enough implementations to know that the software won’t save them.

They say that success has many parents, but failure is an orphan. To me it seems like this failure has all kinds of deadbeat parents. Execs that just want to write a big check and make a problem go away. Budgeting that allocates money for software but not services. Under-resourced internal teams that don’t have the influence they need to make changes. Unrealistic timelines that don’t allow for the kind of iteration we take for granted in other processes.

Never enough time and money to get it right, but always enough to do it over.

I saved Karen for last because I was sure she was gonna put the period on this sentence, and I’m not sure I can add anything more to that.

Parting Thoughts

Earlier this week, I was having a DM conversation with Mark Demeny from Sitecore about something. We realized, to our delight, that we were both going to be in Copenhagen at the end of the week. So, that Friday, I had a lovely dinner with Mark and Amanda Shiga overlooking Copenhagen’s South Harbor (in this spot).

CMS geeks are gonna geek, and we dutifully talked for a couple of hours about all the usual topics, companies, and people (our greatest accomplishment might have been to awaken CMS Borat after almost three years of silence). I love it when people who are passionate about something have free time to go deep, and this was that kind of dinner – none of us had anywhere we needed to be.

Towards the end, our conversation turned to how we can actually get better as professionals in this industry. Related to this, I’ve had discussions with multiple people over the years about the idea of an “unconference” in Reykjavík or somewhere thereabouts (we have our eye on this hotel).

Mark, Amanda, and I discussed what this might look like: who would we have speak, would we have some collective theme or goal, and what would be the value proposition? There are a lot of angles to this business, and what front should we attack first?

In the end, we centered about this idea –

The most valuable thing we could do would be to talk about organizational and personal psychology and motivations.

Far more than software, this is the biggest problem we face in this industry – getting organizations out of their own way and finding ways to get groups of people working effectively and consistently towards a common goal. The best idea we had was to invite a bunch of organizational therapists to the event and just listen.

Afterwards, I was reminded of one of the best business books I’ve ever read: The Advantage by Patrick Lencioni. (Honestly, you could swap in any number of Lencioni’s books here: The Five Dysfunctions of a Team; Silos, Politics and Turf Wars; etc.).

In The Advantage, Lencioni says this:

Most leaders prefer to look for answers where the light is better… and the light is certainly better in the measurable, objective, and data-driven world of organizational intelligence than in the messier, more unpredictable world of organizational health.

You could substitute almost anything for “organizational intelligence” in that sentence (i.e. “technology”) because almost anything else is easier than confronting the messy reality of human frailties, egos, and shortcomings. So we look elsewhere, at easier targets.

But the light isn’t any better, we just don’t like the dark.

Someday, all of us consultants, engineers, and designers are going to finally summit The Mountain of Efficacy and reach that place when we have figured out the most effective way to move our clients forward.

On that day, when we at last pull ourselves over that peak, exhausted and bleeding, we shouldn’t be at all surprised to find a bunch of governance, operations, and strategy experts who have been sitting there for years.

Postscript: Romano Tours

This SNL sketch is worth watching. It might accidentally be the deepest, most thoughtful bit they’ve done in years, and it highly relates to this post.

You are still going to be you, wherever you go, and no matter what software you use.

Towards a Content Modeling Standard

Wed, 24 Apr 2019 00:00:00 -0500

We (I?) talk incessantly about headless CMS. But not many people are talking about the “head.” Headless is obsessed with how content is managed but ambivalent about how it’s delivered. It seems that delivery is always custom, and this is largely the selling point.

But does it always have to be custom? Should it always be custom? What’s stopping us from making it…less custom?

But, first, a quick recap –

Headless CMS is a content management system without a publishing infrastructure. Content is “published” by simply making it available through an API (though, usually, by pushing it into a CDN), and some channel – a website, a mobile app, etc. – proactively retrieves the content for display.

(Also, see the definition of coupling models over at the Web Content Management Glossary.)

What are the majority use cases of headless? I wrote about this at length a couple years ago. In that post, I made the point that headless in WCM is still very much a question mark:

What might be surprising is that we more or less agreed on this: the use case of a single repository of information feeding a single website is not a great value-add for a headless CMS.

The “we” in that post is me and some of the folks from Contentful, who I visited in Berlin. In that afternoon, and in that post, we talked about a lot of different things you can do with a headless CMS, but running a single website wasn’t really one of them.

Can you run a website from a headless CMS? Of course. And, as I pointed out in a CMSWire article last year, headless CMS is something of a return to how we were all building sites at the turn of the century. Back then, we built all “headless” CMSs – systems that managed content using one set of logic, and displayed it using another.

Fourteen years ago, I wrote this:

Now, lets put the 50-yard line of this game at the database. So the creation, management, approval, and general administration of content all leads up to one moment – when a certain content record in a database table is declared “active.” Everything is working up to that point. The “active” records in the database table are free to be used on the public side of the site.

Why not just create a view of the database that only includes those records, then give your designers and presentation specialists a read-only user and a copy of ColdFusion? Who says that the language the CMS is programmed in has to be the language the content is presented in?

Today, that seems a little prescient.

Headless is all about administration and management. It actively eschews presentation. It does not care what you do with the content it manages.

So…who does care?

Put another way, what is the “head” in headless, when it comes to WCM? What is the counterpart to the headless system that manages the content?

To be pedantic, we could just say “website,” and this isn’t wrong. But just like we created content management systems to standardize the common patterns of managing content, will someone create a “content delivery system” to standardize the delivery of content?

Yes, there are any number of web frameworks to build a website on, but they’re just tools that neither know nor care what you’re writing. The line between content-based website and transactional web application gets pretty slippery.

Speaking of content sites in particular, there are patterns. Meaning, there are things we have to do over and over again, and these are patterns that traditional web CMSs have organically grown around. Things like:

Global page elements
Hierarchical navigation
Positionable content elements
Personalized content delivery
Full-text search
Object-level permissions

When will someone standardize these elements into a framework that can be “backed” by a headless CMS?

(True story: Blend is sort of stuck on a project to create a “base site” profile, meaning we’re trying to codify the basic, foundational elements that go in every site we end up building. It’s harder than you think, but work continues.)

Here’s an example how this might play out at a business level.

Some enterprising front-end dev might look deeply at Kentico Cloud and think,

“You know, I could build a front-end for this. With some conventions and a little training, I could create a system that would give you a packaged website, backed by a Kentico Cloud instance.”

And then, later, when this has become a raging success –

“Man, there are a lot of Contentful users. Maybe we should create a version of the front-end to be backed by Contentful.”

Even later –

“Okay, now I have versions for Kentico Cloud, Contentful, Directus, Prismic.io. And for the traditional systems that have remote APIs, like Sitecore, Episerver, Drupal, etc. And also for the ECM systems like Alfresco and Nuxeo.”

And then this person dies from exhaustion because they’re updating all these front-ends all the time.

The point: before we could standardize a front-end (a “head”), we would need to standardize the APIs. All of these headless systems would either need to agree on an API, or there would need to be a thriving ecosystem of API abstractions for them. This way, your front-end could make generic calls into the void and not care who responds to them.

And when I say “standardize an API,” I don’t mean to standardize the bindings or the protocols. So, not like REST, for example. And I don’t mean to standardize the discovery, like WSDL or Swagger.

I mean that we need to abstract and standardize the very idea of content. We need to come up with a common lens with which to view content types, content objects, properties, datatypes, values, and relationships in the ways they relate to WCM.

This isn’t to say we haven’t tried. There are two major content-centric API systems in (somewhat) common use:

Content Repository API for Java (“the JCR”). This was developed at Day Software for their CQ product (now Adobe Experience Manager), then spun off as a standard (JSR 170). It’s popular in the Java WCM space (AEM, of course, is built on it, as is Magnolia). Clearly, it’s Java-centric, but does have a PHP port (but no .NET port, to my eternal temptation).
Content Management Interoperability Services (CMIS). This is an open-standard started by the Association for Intelligent Information Management (AIIM) and since approved by OASIS. It’s very well-accepted in the enterprise content management space.

Now, I don’t claim to be an expert in either of these, but my understanding is that they’re not competing standards. They have specific angles and can work together productively.

When will something like API standardization come to the headless space, to define the interactions with a WCM “head”? I think the next logical step in the slow uncoupling of content management and delivery is the commoditization of a delivery layer. There are a ton of front-end ninjas floating around out there that are probably just dying to build something, but the headless market is so red ocean right now that some people don’t know which horse to back.

I think the market might be waking up to this. I had a demo of GatsbyJS a while back, which purports to be the front-end for a headless website. It’s a set of JS libraries around React. Combined with static site generation, this provides a presentation layer that actually doesn’t rely on JavaScript and has a static version for all the content. (During the demo, my partner was browsing their docs. For giggles, he shut off JavaScript. It worked exactly the same, just a little slower.)

On the subject of standardization of APIs, Sam Bhagwat from GatsbyJS had this to say:

The tricky part here, of course, is that CMS-es don’t want to be commoditized any more than newspaper publishers do (hence all the controversy around AMP!). And publishing your data in a standard format is basically screaming “I’m a commodity!” So every CMS will output different schemas, and probably will for a while.

Andrea Schauerhuber from Gentics Mesh, based in Vienna, mentioned that perhaps we don’t need to standardize, given the flexibility of one of the common API protocols:

[…] with GraphQL in the game I think that today it is very easy to offer APIs that are extremely flexible. Developers basically are able to tailor the requests to their need. […] with GraphQL it has become so simple to “model” the data response in a way that your app can process it easily.

(Andrea also wanted to point out that Gentics Mesh supports content trees, in defiance of my rant above…)

From the traditional (coupled) CMS vendor side, I’ve recently become aware of JavaScript Services for Sitecore, which is an attempt by Sitecore to provide a front-end for a headless implementation of their system. JSS is a set of libraries that will bind components directly to Sitecore objects and do all the plumbing behind the scenes.

Let’s look at The Headless Equation™ as having three layers:

Repository
API
Delivery Channel (the “head”)

In this model, the title of this post is getting ahead of itself. We can’t standardize the head until we standardize the API. And we can’t standardize the API until we standardize how repositories conceptualize content models. For us to make progress here, we’re going to need to agree on a set of concepts around which we slap on any API (REST, GraphQL, SOAP, whatever).

Some of the basic content modeling questions need need to resolve to create The One Standard™ (some are obvious; others, less so) –

Are there structured content types?
Do those types have attributes?
What base data types can we agree on?
What description framework can we put around custom types?
Can attributes repeat?
How are empty attributes/null indicated?
Can attributes be a full, encapsulated object? Can this be restricted by type?
Can attributes reference another object? Can this restricted by type?
Are those references two-way?
Can we enforce referential integrity?
Is content in a hierarchy?
What base grouping or sectioning structures can we agree on? (Categories, types, branches of a content tree, etc.)
What parametric search options can we agree on?
Do we support full-text, tokenized search?
What discovery framework can we create to allow programmatic investigations of capabilities? (WSDL, FTW, finally.)

Finding a baseline standard here would help the entire headless industry enormously. And there’s precedent for this – standards like Dublin Core and CommonMark and even ANSI SQL have tried (or are trying) to create a baseline for a wide variety of implementations. Vendors can do whatever they want as a superset of this, but claiming standards compliance means they at least support the baseline.

But I circle back to a cynical problem endemic to these situations: vendors in the space right now probably don’t want portability. They want lock-in.

No one who is depending on subscription revenue or looking for a seed round wants to be easily swappable. Rather, they want people to base the upper layer around their product and Cement. That. In. Place. And this probably has some variance based on the size of the vendor – a smaller vendor likes the idea of portability to gain new adherents, while an established vendor with an existing base of users wants to keep them in place.

So, this entire idea will likely remain a pipe dream. But there’s value here, and if anyone knows of a way to build some momentum behind this idea, I’m all ears.

Content, Campaigns, and Context: Why CDPs Are Having a Moment

Thu, 18 Apr 2019 00:00:00 -0500

Someone tweeted about me the other day:

@gadgetopia loves to hear himself write.

And it’s true. I love to write. And I write for myself, really.

If someone reads me, that’s awesome, but it’s not really required. Honestly, I’ll just yell into the void all day long.

I’m content-centric. For me, creating the content is the point. I need to do it at some base psychological level, and I guess it’s just a bonus if it coincides with a business goal.

The average organization has historically been content-centric as well. We create content first, and we hope that it has some value to some person down the road. The value is usually just assumed, because you can’t exactly predict these things, but we hope we do okay.

Personally, my feeling is that if you create good content, it’ll pay off at some point. Call that “shotgun content strategy” – shoot a lot in one general direction, and eventually you’ll hit something. This is grossly inefficient, but a hard thing to accept is that creating content is the easiest part – getting an actual return on that content is harder.

(Note: I showed this post to my marketing manager. She said, “When I was at an agency, we used to call that ‘spray and pray’ marketing.”)

Exhibit A: the content management system. We build our processes around systems for creating, editing, and managing content. Our strategy often starts and ends with content – we’ll create it then throw it out into the world and hope that it works. There are people out there consuming it…somewhere. We hope they like it.

The dream of content-centrism is something like throwing bread on the ground at the beach, and watching swarms of seagulls descend on it and fight over it. Wouldn’t this be great? We don’t know anything about the seagulls or their story or their relationship with the bread. We just toss it out, and they descend, and we hope this is how it works with our content.

This is First Wave Content Marketing: content management systems as the foundational pillar of a content marketing infrastructure. Names like Episerver and Sitecore and Drupal loom large here.

The next stage of maturation is the Rubicon an organization crosses when they go from content-centrism to campaign-centrism. There’s always a very different vibe to organizations that speak of “content” and those that speak of “campaigns.”

The former will say “we published a blog post!” and the latter will say, “we’re seeing great conversions and engagement from our last campaign!” The former just throws content into the void (guilty), while the latter plans coordinated marketing campaigns around ideas they what to communicate, then builds content in support of those ideas. They can’t imagine just creating content without being part of a larger effort to influence.

The campaign is a conceptual framework of positioning and framing. The content is just what gets bolted onto that framework. The campaign became The Thing – content was now just created and managed in support of The Thing.

This shift changed how we sell CMS. We used to lead pitches with management – “This is how you edit a page of content.” But then the market changed, and we started to lead pitches with marketing – “This is how you set-up an A/B test campaign.” It was a tectonic shift in how this industry was structured. Management became secondary to marketing, and content became secondary to campaigns. This was a healthy change.

So, let’s call this Second Wave Content Marketing: when campaign management began to take precedence over content management. This is when names like Pardot and Eloqua and Marketo started to creep into more and more conversations. In addition to a CMS, people wanted to know how that was going to integrate with their larger marketing platforms.

I feel like there’s a Third Wave of Content Marketing coming, driven by a technology shift called Customer Data Platforms, or CDPs. This is where content and campaigns become subordinate to context.

Haven’t heard of these? You will. (apologies to Tom Selleck)

They are:

[…] packaged software which creates a persistent, unified customer database that is accessible to other systems. Data is pulled from multiple sources, cleaned and combined to create a single customer profile. This structured data is then made available to other marketing systems.

The idea is that your CDP is the single source of truth for your customer data and a history of their behavior – their “context” with you. A CDP tracks customer activity across every channel, even when the customer can’t be identified.

If your customer identifies themselves at some point (ex: they register for a webinar), their profile is “de-anonymized” and can then be matched up to all sorts of other information, and you can begin to push known information about that customer into your CDP.

(And, yes, this is where some vaguely creepy things can start to happen with data purchased from profiling firms, but that has nothing to do with a CDP, directly. A CDP is just where organizations put that data, alongside lots of other – less creepy – data.)

Two differentiating points to note:

This is not a CRM. A CRM tracks the actions of humans dealing with humans around specific tasks – selling or supporting something. You’ll often push data from your CRM into your CDP, and vice-versa.
This is not analytics. Analytics is usually channel-centric. They tell you what aggregate visitors did in aggregate on a particular channel, not everything a specific person did. Additionally, analytics are historically declarative (“this thing happened”), not an aggregation platform – put another way, you don’t go pushing data into them after the fact to reference later.

A CDP is a central clearing house for massive amounts of data about your customers’ behavior. It might share data with a CRM in both directions, but it’s very much a separate segment. A CDP gives you intricate details about their behaviors – “Person X took Action Y in channel Z” – and gives you a place to put data about them that you source externally and after their direct interaction with you.

CDPs are suddenly a big deal in the digital marketing world. Vendors are sprouting up everywhere. CMS vendors are offering integrations or building their own offerings. Marketing suite vendors are adding CDPs as core parts of their family of tools.

You might be thinking, “Didn’t big companies already do this?” And they did. But these systems have never really been productized – bigger, more advanced organizations just built their own, and only now are patterns emerging that are driving generalized products.

From my friend Tony Byrne from Real Story Group –

The search for unified customer and prospect data is not new. For more than a decade now, larger enterprises have been custom-building – often at great effort – what RSG calls “Customer Data Backbones.” These were typically API layers built with traditional enterprise integration toolsets and data warehouse platforms. Early-adopter enterprises have built impressive customer data backbones, but the resulting layer tended to be very bespoke and IT-intensive and therefore not as adaptive as agile marketers always needed.

CDPs are the technology industry’s attempt to replace custom backbones with more marketer- friendly, packaged solutions.

TLDR: we already did this ourselves, just like we built custom CMSs for a long time. Companies are just productizing these now.

And this is why the shift is coming: when something gets productized and ultimately commoditized, it becomes part of the common lexicon of an industry. Now we can all talk about a “CDP” and know we’re discussing the same thing – either an actual platform/tool, or the generalized concept of warehousing customer context data.

The “data warehouse” analogy is apt. These are data warehouses for customer behavior, in the sense that they’re designed to store and make sense of data pushed into them from all directions. And like that segment, custom solutions without names existed for a long time.

The adoption pattern might be similar too – back in the 90s, before the data warehouse market became productized, this was a space where every company just built their own thing.

But then someone slapped a name on it – Bill Inmon published Building the Data Warehouse in the early 90s (I read it when I was starting my career in IT a few years later) – and now there was a “named market” that vendors could coalesce around. We weren’t just building consolidated databases – we were data warehousing! Sometimes all anything needs is a name to give birth to a segment (and a million “expert consultants”).

There’s a developing OASIS standard that was spun out of Jahia, the WCM company. It was originally called a “context server,” but then they conceded that a name had happened:

Since the OASIS Context Server TC has been established, the term Customer Data Platform (CDP) has emerged and can be interchangeably be used for the Context Server. To reflect this, the specification produced by this TC has changed its name to : the Customer Data Platform specification.

I actually like the “context” name better. That’s what this is – the context that your customer has with your digital channels. If you ever ask the question, “What does this person know about us?,” then these products seek to provide that answer. They want to record the context between your customer and you.

Organizations are acquiring packaged CDPs from three main sources:

Pure-play vendors
CMS vendors
Marketing suite vendors

There are slew of pure plays in this space, almost all of them SaaS vendors.

BlueConic
Lytics
Tealium
Treasure Data
and dozens more…

I know, I know – you haven’t heard of any of these. That’s fine. Back in 2003, you hadn’t heard of WordPress either.

RSG is currently covering 26 pure plays and another 3-4 larger suite vendors. I spent some time with a handful of reports that RSG was kind enough to provide. Axes of evaluation seem to be:

Ingestion: how easy is it to get data into the platform?
Analysis and Segmentation: how can you play around with the data inside the platform?
Usability: what user level is targeted by the platform? Developers? Marketers?
Connectors: what external services does the product integrate with, either for automatic data ingestion or more complicated analysis?

Vendors are all over the map, both in core functionality and also seemingly in targeting. Some products are for developers, some marketers, some for data scientists.

Another problem – simultaneously more mundane and more dangerous – is that no one is disclosing revenue, so you have no way of knowing who the real players are, and who’s going to be around when the inevitable shakeout and consolidation happens. That problem is what tends to drive people away from pure plays and into the arms of their existing marketing suite or CMS vendor.

So traditional CMS vendors are jumping into the fray with their own solutions. Here’s Joey Moore from Episerver about their Insight product.

The digital experience platform is the natural home of the CDP. This became increasingly apparent, and why we developed our own solution some years back. Clients were pulling customer data out of the platform to use somewhere else or pushing external data in, often from solutions that we now provide (think email marketing or product recommendations). So in that regard we kind of had a head start as we understood the lifecycle and the value of the data that was being captured.

Fundamentally a CDP comes down to three things; Scalability, there’s only ever going be an increasing amount of data. Interoperability, to realize the value of the data, you need to be able to put it to work. Security, your customers trust you to look after their data and breach of that trust can cause irreparable harm.

And here’s Mark Demeny from Sitecore:

We’d agree that we’re in the midst of a third wave of content marketing built around context, and that’s been one of the guiding principles for our development efforts for quite some time now, particularly with the xDB, where our primary focus wasn’t to provide analytics for historical analysis, but to provide a foundation for audience interaction (and be deeply integrated with our marketing automation and other tools).

In the past, there was some opinion that CDP would be subsumed as a feature into other marketing and advertising technologies, but shifts in the market have changed the dynamic towards something more capable of handling the complexity of the current state of the market.

First, the number of channels is starting to increase to include things like offline, support, voice and IoT that don’t necessarily go through the web and martech channels particularly easily. Second, first party control over how your customers choose to interact with your brand is even more important in the age of GDPR and diminishing comfort and ROI from social channels.

But, like any move into an adjacent market, not all CMS vendors are convinced this is the right direction. Here’s an opinion from a mid-tier vendor who asked to remain anonymous, as they’re still watching the market develop.

We’re all for using customer data to improve content choices, to sharpen customer experiences or to upgrade personalization. Plenty of our customers have been integrating our CMS with their custom-built CDPs in the past and we now see customers making the connections between their CMS the new productized CDPs. However, the risk of feature creep and missing clearly identifiable excellence in the CMS is palpable. We don’t want to be yet another DXP that tries to do everything but can’t really get the fundamentals right – or which cannot realize the promised benefits of the integrated suite.

The trend toward data-driven content and experience management is great – we just believe CMS users are better off handling their marketing use case needs through more specialized tools that connect well.

The marketing suite vendors are all jumping in as well. A couple of them declined to comment, but Adobe and Salesforce both announced CDP plans in the last week.

After the Adobe and Salesforce announcements of entry into the CDP space, very few people doubt its usefulness. However, many people still rightfully challenge the ability of CDPs to deliver value, as the value is only seen after integration with channels that allow both transactional and personalized communications.

I love that quote because it says, “This is something we’re all super-excited about, but we’re not sure everyone can make it work…” Which, let’s face it, is the story told of all higher-end marketing features from the last 10 years.

Regardless, in the end, all indications appear that this is What’s Next. (apologies to Martin Sheen)

In writing this, I’m not trying to savvy anyone. If you’re creating good content regularly, good for you – you’re doing better than most, even if you’re just yelling into the void.

But, the natural maturation of a content marketing engine has traditionally moved that focus from content to campaigns. Organizations that got there were once on the leading edge. But the advent of the CDP signals that we’re moving up the scale to organizations that have comprehensive, contextual customer tracking, and who develop campaigns in response to that data, and target content directly to defined segments of that data.

A gross over-simplification: Good content gets you to 90%. A good campaign strategy gets you to 99%. Perhaps understanding and leveraging context is that last 1%?

(Until, of course, the next thing comes along. To preserve my alliteration, I hope it starts with a hard “C.”)

And this brings me to my final point, and what I think might be the natural end stage of this trend –

A CDP might become the foundational pillar of a content marketing engine. To date, we’ve been fixated on CMS. But when undergoing a digital transformation (a phrase I loathe, but which fits here), organizations might shop for a CDP first, then layer a CMS over top of that. The CDP will be the core of their content efforts, not a CMS. The CMS will just serve in support of a CDP.

I’m interested to see how the market develops. The current batch of CDPs aren’t cheap, and there doesn’t seem to be much of an open-source community around them, despite Apache Unomi being a top-level project and the reference implementation for the OASIS standard.

This article at CMSWire puts some more context around Unomi – notably that it’s a “headless CDP,” to which you bring your own interface or third-parties start selling productized interfaces and data mining solutions for it. (Trivia: I can’t find confirmation of this, but the fact that Unomi sounds just like “you know me” cannot be an accident.)

I think we might see three-way a digital divide, where we group organizations by what “C” they’ve achieved:

Content-centric: most all organizations will remain here
Campaign-centric: will require some investment in marketing automation and considerable investment in staffing
Context-centric: will require a further investment in CDP tools

I’m a old-school, server-side content guy. I was never comfortable with marketing technology, honestly – I believed in the management and publication of good content, full stop. Start with that and you’ll be fine.

But, weirdly, CDPs don’t freak me out. And part of this is probably because I’ve been selling the idea of human-centered content for more than a decade, and the promise of moving the locus of control from the content to the customer seems like a natural, healthy progression to me. I particularly like the separation of customer and behavior data from content – I feel like there’s a crossing of concerns there otherwise, that makes things muddier.

Also, I’ve mentioned the phrase “content marketing” a few times in this post. It’s little-known fact that when you say that three times, Rob Rose appears, just like Beetlejuice. (I’m kidding – Rob has been a friend for 10 years. I sent him the draft of this post and asked him to comment.)

Successful Marketers are starting to look at their databases as “audiences” rather than simply “leads” or “opportunities”. The pressures of GDPR and other data management challenges require companies to take a CRM-like approach to their classic marketing data. This is where CDP’s can truly serve as the pre-customer database. This is where marketers utilize (and manage) a much more holistic (and cross channel) view of audiences and their preferences in order to develop trust much earlier in their journey.

Here’s what I like about this quote:

"audiences”: We do our best work for audiences. We perform for audiences. Whether it’s theater or digital, a more concrete concept of the “audience” makes us better at what we do. Editors like to know their stuff is being consumed, and if they can have a longer view of that context, they’re likely to get higher satisfaction from content creation.
"pre-customer”: This speaks to the fact that with a CRM, you’re talking to customers or direct prospects. A CDP, rather, is elevating your content consumers to a higher level. You can still push content like crazy, but now you’re taking direct steps to realize some return on that.
"develop trust much earlier in their journey”: And this has always been the implicit dream of content marketing. We’re going to show you what we know and what we can do before we even start talking to you about a sale. Hopefully, we’ll build credibility (trust) before we unleash sales on you.

If this reasoning helps organizations push more content because they can realize a return on it more easily, then that’s a good thing.

CDPs might provide the justification and ROI necessary for organizations to invest in better content. If they can identify a piece of the ROI puzzle earlier, then more exploratory content is easier to justify. A CMO might throw more money at content creation if there’s a mechanism for them to isolate a return on it, and a CDP might be that mechanism.

I’m here for that. We all should be.

Repouring the Foundation: The Perils of Content Modeling on the Fly

Sun, 7 Apr 2019 00:00:00 -0500

I teach “Introduction to Content Management” in the Content Strategy program at FH Joanneum. I talk about content modeling quite a bit, and in the final lecture, I have a slide that just says this:

Content models are foundational.

And they are. Your content model is the base on which you build most everything else you do with your CMS.

Defining the content model of a CMS implementation is one of the first things you do. At Blend, we’ll usually start by paging through wireframes and writing down the content types we see, adding attributes, combining them, abstracting reusable elements, etc. This forms the core of the entire implementation.

A content model can be said to be “established” when you’ve implemented it and built a bunch of functionality on top of it. During the implementation, you’ll realize you have some mistakes and inefficiencies, which you can correct as an expected task of development.

But fast forward two years down the road – your model is now loaded up with actual content, and you have templates, workflows, external integrations, and all sorts of other things built which depend on your content being in the format that you settled on when you launched the site.

Like it or not, your model is now “established.”

Changing content models after they’re established can be tricky, just like changing the foundation of a house can be tricky after you’ve poured it.

True story: I don’t have a front porch on my house because – 20 years ago – the contractor started building it four feet (just over one meter) too close to the road. We didn’t realize this until after the foundation was poured. At that point, it was too late.

I was talking to my friend Allan Thraen about this the other day. Allan worked at Episerver for a decade, and now he’s off on his own at CodeArt. Our conversation drifted into the idea of letting editors modify an established content model without a developer being involved, and was this a good idea?

The conversation resulted in a great blog post from Allan: The Curious Case of Content Modeling.

It’s worth reading. In particular, Allan recounts the situation of a client using Contentful, and allowing business users to do their own content modeling, without any developers being consulted:

If they for instance added a new field, or even a new content type, it would of course not be visible on the web site until their developer had put it into their rendering, but they could start to create content for it right away and that way it would be easy for the developer to see just how it would fit and make the proper front-end adjustments. In fact, all they needed was a front-end developer to update their site with the desired changes.

As a back-end engineer, this just freaks me right the hell out, but it seems to be working for them so who am I to judge?

The key is this: content modeling takes skill. It’s easy to build a dumb, inefficient content model that makes future changes difficult (“We don’t need ‘FirstName’ and ‘LastName.' That’s just wasteful! Let’s just have one ‘Name’ field!”)

However, if you do have skill at it, then it doesn’t matter what your job title is. These skills are more often found with engineers than editors, just because engineers have experience with data modeling and abstraction, but a good content strategist can generate perfectly fine content models. In many teams, there might be a super-user, administrator, or metator (all hail Boiko!) that has the wisdom and perspective to do this well.

In fact, here are two books that do a wonderful job of bringing content modeling into the editorial space:

Content Everywhere, by Sara Wachter-Boettcher
Designing Connected Content, by Carrie Hane and Mike Atherton

(I wrote a sidebar for the former, and I’m quoted in the latter…but, really, who’s keeping track?)

Also, Ann Rockley did a lovely job several years ago in defining a “back end content strategist”: Why You Need Two Types of Content Strategist

Back-end strategists … have a love for structure, scalability, and technology. They make recommendations about how to use technology – hardware and software – to handle all that content in efficient and powerful ways. This type of strategist answers questions like these:

How can we organize content so that our authors can easily store and retrieve it, and prepare it for automated selection and delivery in the relevant channels?

How do we structure the content so that modules are consistent and can be easily assembled (mixed and matched) on-demand to meet customer needs?

How do we make sure that we aren’t creating, recreating, and recreating content over and over for each channel?

That’s great stuff, and it really gets to the absolute core of content modeling. All those questions are critical when defining what your content looks like inside your CMS.

But content modeling still has a reputation for being something like the Dark Arts, which is done by a select few and requires an Act of God to be deployed where it can provide some productive value.

So, the desire to modify established content models “on-the-fly” is still something people ask for in RFPs. More and more editorial groups want to be able to do everything without a developer involved, in a continuing quest to liberate themselves from any external limitations.

Generally speaking, content modeling can be done two ways:

As Allan points out in this article, many systems allow for the definition of content models from the administrative interface. Episerver used to do this, Drupal does this – dozens of systems do this. At any time, an editor with sufficient permissions could conceivably go in and just…change stuff.
In contrast, many systems require content modeling to be done from code or configuration. In most every current Episerver implementation, content models are C# classes. In Sitecore, a lot of developers do their content modeling from a Visual Studio extension called Sitecore Rocks, then this can be synchronized with the production instance. These are things that a developer needs to do.

When you model content from code, you have technically “done development,” and you’ll need a code deploy to get your changes launched. Many editorial teams hate this, because then they’re dependent on someone else, not to mention being subject to deployment schedules, change control, regression testing, etc. They’re trying to achieve this ideal vision of being able to do everything without outside resources or limitations.

However, this is often not realistic for the same reason I quote at the beginning of this post:

Content models are foundational.

And just like the foundation of a house, a lot of stuff rides “on top” of an established content model. The model change might just be the tip of the iceberg, and is all the stuff below the waterline also editable from the interface?

Let’s assume an editorial team can edit their content model, and they decide to add a property/attribute – let’s say they add “Mood” to an article to track the mood that the author was in when they wrote it. Let’s also assume they know what they’re doing, and they know to add it as a dropdown or a checkbox list or a text box or whatever is correct for their implementation.

Doing this from the interface allows them to do exactly one thing: capture data. But they don’t capture data just for giggles. Clearly, the editorial team is going to do something else with this property.

Do they want to output it somewhere?
Do they want to use this in some event tracking or workflow, maybe to trigger additional review of the author is “angry” or “hostile”?
Do they want it to affect channel distribution? So, “happy” articles also get pushed into the @goodnews tweet stream.
Do they only want this attribute only available to editors who have been working at the company for six months?
Do they want to disallow editing of this attribute after the article is published, or prevent editors from changing their mood after the fact?

So, you can sure add the property, but how much more can do you than that? Most systems have file-based templating, so to get that attribute even added to an output artifact, someone is going to have to change a template file and deploy it…which brings you right back to the code change you were trying to avoid in the first place.

Now, this isn’t the case with all systems. Some CMSs will allow you to do a lot more than just add the attribute.

Drupal is probably the King of Configuration. You can do a lot in Drupal without writing code, and you could conceivably get that attribute output somewhere from the interface by adding it to a view or modifying the display fields of a type. And there are other Drupal-like CMSs that treat output as a matter of configuration.
Some systems like Umbraco and TERMINALFOUR allow templating from the interface. The actual templates are editable through embedded code editors, and don’t have to be “deployed.” In some cases, they read/write from the file system, so you get the best of both worlds (spoiler: it’s actually the worst of both worlds because now you’re writing files in production that aren’t in source control, but whatever…)

But here we’re still just discussing the ideal scenario: (1) adding an attribute, and (2) getting that to display somewhere. This is probably the simplest use case. And even if you accomplish this purely from the UI, you’ve still had to engage a developer-ish person to re-template or style the output.

If you’re working this hard to avoid a code deploy, maybe you just have a DevOps problem? Or if you’re that estranged from developers, maybe you have an organizational or managerial problem?

And don’t even get me started about the scarier edge cases:

Content model changes or deletions. Aside from losing data – which is a huge problem – there might be dozens of processes that editors don’t know about that depend on the content being in a specific format.
Things other than templating. Integrations, workflows, advanced permissions, and anything that involves data exchange with an external system.

The larger principle at work here is the division of duties. Who can do what in a CMS implementation? I touched on this a while back in a post about another quasi-development feature that editorial teams constantly want to do: ~/tech/blog/truth-about-cms-form-builders/

Understand that if your expectations are to integrate your forms with a wide variety of other systems, then you’re not going to get the freedom from development that you’re looking for, and only having the UI portion of these integration scenarios under editorial control will rarely ever be helpful.

The same thing applies here. You can find systems that will let editors change content models on-the-fly, but that’s not nearly as much freedom as they actually want.

In most cases, it will give them very limited control over a very limited number of things. In addition to waiting on a development team to finish all the things they can’t, they might find that the first thing the developer does is undo all their work and re-implement it to account for technical parameters they weren’t aware of and couldn’t be expected to understand.

Once a content model becomes established, it’s hard to change, and it probably should be. In most implementations, there’s a lot riding on it.

I remain unconvinced that reducing the barrier to change here will result in a better experience over the long term.

Words, Links, and Centrality: Evaluating 17 Years of Gadgetopia Content

Mon, 1 Apr 2019 00:00:00 -0500

I’ve been blogging at Gadgetopia for almost 17 years. Here’s my first post from 2002.

I’ve decided to do some clean-up.

Some history –

Before Twitter, blogs and RSS were Twitter, so a lot of my posts from 2003-2005 were very tweet-like – they were very short, often less than 100 words, and just contained a single link. They were admittedly low-value. I was often just throwing out a link that my audience might find interesting, and adding some context around it (and, okay, I would often throw in an opinion or…12).

And let you think the word “audience” is overstating things, know that back in the heady “blogosphere” days in the early Naughts, we did have defined audiences. RSS, comments, and pingbacks coalesced to form loose communities, much like social networks do now. I still know and interact with people who I first “met” in Gadgetopia comments 10-15 years ago. I’ve met several of them in-person.

A big problem for Gadgetopia is that many of those old posts have broken links, and many times, the link was the entire point of the post. This means that they’re a segment in a chain of link rot. Without the link, the post doesn’t make sense, and I’m just cluttering up the internet.

So, it’s time for a purge. I’m determined to clean up old posts by removing them intelligently. I won’t “404 Not Found” them (yes, I used that as a verb) – that status code means “Nothing was ever here.” Rather, I’ll “410 Gone” them, which means, “There was something here, but it has been removed.” Additionally, I’ll provide contact information so if someone really wants something, they can get in touch, and I’ll dig it out of the archives just for them.

But here’s the thing –

When inventorying content, you cross an important line when you can no longer look at each piece of content individually. At some point, you can’t come to a determination through nuanced perception and analysis, because there’s just too much content.

Gadgetopia has over 7,000 posts. Even if I reviewed 100 blog posts a day – which is harder than you think – it would still take me almost four straight months to sort through everything.

So, what do you do when there’s too much?

Content Evaluation Rules

Back in 2009, I worked with David Hobbs on a content migration for The College of Nurses of Ontario.

David is a consultant who specializes in migrations and large-scale site transformations. It was on this first consulting project together that he brought up the idea of “rules.” David had the idea that we would score each piece of content according to a set of metrics, and our first pass of evaluation would be based on that numeric value.

I remember thinking this was really…impersonal. I was convinced nothing could substitute for human-powered, individual evaluation. For me, a content inventory was an artisanal experience.

Honestly, I don’t remember if we actually implemented rules on that project, but a few years later, David gave a great conference session on rule processing. He had a case study where he had done this for a client at scale. What he described there made more sense to me, because the client had a lot of content. I started to come around, and the idea of a rule-based approach has stuck with me.

David has gone on to create a “content exploration” tool called Content Chimera – currently in beta – which allows for the slicing, dicing, scoring, and mass evaluation of content:

Content Exploration and Decision-Making At Scale

That tagline is telling, and we’ll revisit it below.

But, back to Gadgetopia – the only way I can hope to get through all this content is to evaluate posts with the help of some set of rules or metrics. I’m still in the middle of this process, but I thought I’d share with you some of what I’ve learned, and some of the data I’m planning to use when scoring and evaluating Gadgetopia posts.

What Are The Goals of Your Content?

When you evaluate content, you invariably run into the question: what is the overall point of the content?

There’s just no way to figure out whether something stays or goes without evaluating it against some yardstick of value. “Is this worth keeping?” can only be answered with some measure of “worth” in mind.

For Gadgetopia, there are two goals to the content:

To further the CMS industry, at whatever level is possible. I like to think that posts I’ve published have sparked discussions, decisions, or otherwise influenced behavior. (ex: someone told me the other day that their framing of “content operations” came from this post, which they credited as the seminal definition of the term – I don’t know of this is actually true, but it made me feel pretty good)
To provide marketing value for my company, Blend Interactive. Second only to our body of work itself, Gadgetopia is the largest collection of public evidence that we know what we’re doing (yes, even more than my book). I often refer to Gadgetopia posts in proposals, and I send links to people to support a sales effort.

(Note that these are the goals of the content today. As I’ve been going through old content, I was struck by how the goals of a site and its content change over time. Posts that seemed valuable a decade ago seem silly now, and that’s okay. We all change. Even websites.)

In articulating those goals, I’ve been careful to give myself permission to make decisions in flagrant violation of the rules when that decision would impede one the two goals above. (Which raises the question, why even have rules then? We’ll talk more about that in the conclusion below.)

More helpfully, my goals help me define what I’m looking to keep: I want to keep content that somehow benefits the CMS industry with its availability, or helps market my company by demonstrating our competence and breadth of experience.

Rules are helpful to me only to the extent that they assist me in identifying that content.

False Positives and Negatives

Here’s what I originally feared when David proposed using evaluation rules: a rule might make a mistake – it will somehow be applied to some outlier content that fits outside the norm, and that content will either be:

Kept when it doesn’t advance a goal
Discarded when it does advance a goal, or there’s some other intangible or tacit reason why it should be kept

That latter freaks me out more than the former. A pointless post taking up space at some URL doesn’t bother me so much, but a good post that can’t be found anymore is specifically what I’m trying to avoid.

Rules aren’t perfect, and they’re going to make mistakes. The two fears aren’t reasons to discard their use entirely, but we’ll talk more later about how to minimize the chance they’ll do real damage.

David points out that your fear of rules is directly proportional to how permanent your changes are going to be. If you’re actually deleting, well, that can be scary. But if you’re just archiving at some level, or perhaps just removing content from indices, then the ramifications of rules become a lot easier to live with.

Finally, when looking at a content repository as large as this one, you need to ask: would a rule make more or fewer mistakes than a manual review? Without assistance, I’d probably make a ton of mistakes on my own. Worse, without rules to make it easier, I would never even do the evaluation, which might be the biggest mistake of them all.

Rule: Traffic

The first, and most obvious metric might be raw traffic, in the form of page views.

I managed to pull the number of page views each post had gotten since January 1. I’d like to say this was graceful, but I just pulled a CSV from Google Analytics, and parsed it. I snapshotted this at a particular moment in time, but since it’s representative of larger period, it’s a valid metric.

Of course, some posts were published during this time period, so they would have less traffic, and other posts were published within the last year, so they have had less of a chance to develop a “Google presence.” However, this doesn’t matter, because all posts from the last couple of years will likely be retained, so the odds of a false positive based on low traffic is slim.

Clearly, there’s a long tail of posts with zero page views. How long? About 90% of the site. Yes, it’s true – over 6,500 posts have had no views in the last three months. That statistic hurt a little to comprehend, but there you go.

But, let’s go back to my two goals, and put this in perspective – if a post fulfills one of those two goals, does it matter that it doesn’t have any traffic in the three-month span I was checking for? No, it doesn’t. Given my goals, even if a post has no page views, I still might send it out on a proposal once a year or so, and it’s critical for that. So lack of traffic to an otherwise good post isn’t the deciding factor.

Consider this post: Spanning the Gap from Feature to Conversion: Are We Building the Right Bridges?

That’s gotten zero traffic since January 1, but it’s a good post that makes a solid point. I wouldn’t get rid of it based purely on the work I put into it and my belief that it has some value to the broader industry. So, traffic or not, that one stays.

What about the opposite – what if an objectively “bad” post gets a ton of traffic? Should I keep it? No – it doesn’t really fulfill a goal for me and is probably just cluttering up the internet.

This post about the mathematical order of operations is consistently the highest-trafficked post on Gadgetopia due to a quirk of Google indexing (to the point where I put a note at the top directing people to the comments, where the answer to their question is probably located). Do I want to keep this? No. It has nothing to do with anything else on the site.

Also worth noting – I think I might be doing a disservice to the internet by keeping this post up. The search referrers make it obvious that it’s mainly found by kids doing homework, and there are far better resources than this to find the answer to the question. Removing this post would allow people to find the answer more directly.

I actually 410’d a bunch of posts last year. Using the Google Search Console, I found all sorts of posts that were lodged in Google for strange reasons, and were attracting pointless, no-value traffic.

For example, I had a post about some aspect of a mobile phone (I’m being intentionally vague to avoid being indexed for the phrase again). This was just a “pass-through” post – I had a couple of sentences with a link to a news article I had found.

This post got a ton of traffic from Google, year after year. And it was pointless traffic from visitors that didn’t further any goal for me, and who really just needed to click the link in the post. But, they still often didn’t find what they were looking for, so they came back to my post, and filled up the comment with complaints.

So, I wrote some code in WordPress to send back a 410 whenever the post was requested, and added this note to the page:

If you’re looking for information on a [phrase that will not be written here], here is the link you want: [the link]

Here, take a look for yourself. With the 410, Google eventually de-indexed it, and any vestigial traffic due to hard-coded links will find my note.

Note:
The linked post above has since been redirected to the archives, so that link no longer reflects what’s claimed here.

Traffic is just not an absolute metric for me. It’s interesting to look at, and I might take it into account, but I wouldn’t remove or keep any post based solely on that number.

Rule: Size

The second metric is content size, specifically word count. This matters because a lot of my earlier posts were really just tweets-in-disguise (Gadgetopia predates Twitter by six years). The longer a post, the more “meat” it had, and thus the greater potential for contributing toward one of my goals.

I did a search for posts of less than 100 words. Result: 2,805 posts. Most of these (about 1,700) have a single outbound link. There are so many small posts, in fact, that moving the threshold up to less than 300 words still includes 88% of the posts.

On the other end of the scale, here are the longest posts on Gadgetopia:

Content Management is an Emergent Skill: 6,290 words
Interview with Josh Clark: 5,070 words, but most of them not my own
The Truth About CMS Form Builders: 3,711 words
Content Personalization: A Reality Check: 3,596 words
Multi-stage Templating as Progressive Denormalization: Tied at 3,470 words
Points of Differentiation in Headless CMS: Tied at 3,470 words

Clearly, size seems to be very correlated with posts I would keep.

I haven’t reviewed them all, but I can’t think of a single post less than 100 words that I would keep. On the other side, very long posts are likely to be something about CMS as that’s the topic I write most deeply about (the Josh Clark interview even relates – at the time he was running Big Medium).

A possible option here: correlate word count against some of the other, more advanced metrics below and determine the smallest size that could reasonably product a post of marketing or thought leadership value.

Rule: Link Integrity

I’ve decided to clean up because so many links are broken. So, the third rule I’m looking at is outbound link count and integrity – what percentage of links in the post are broken?

A common pattern for me years ago was posting simply as a method to share a link, so I searched for how many posts contained just a single link (3,385) and how many of those single-link posts were broken (2,264).

That’s right: fully 67% of single-link posts are just broken segments in a chain. If someone got to them, they wouldn’t get any further.

But what threshold do you set when just some of the links are broken. When does that invalidate the entire post?

Consider this post from 15 years ago where I discussed (and linked to) all the tools I use to do my job. There are 29 links in that post, and 24 of them are no longer valid. Clearly, this post needs to go.

But what about this post from 16 years ago where I discuss the difference between ephemeral and permanent content (which is ironic in the context of this discussion). Of the 18 links, 5 of them are broken. That’s less than half, but still a lot.

That post in particular is complicated because it’s on a topic I still ponder quite often today. Even though many of the links are bad, the topic is still valid, and I make some points worth preserving. If I decide to keep it, do I somehow call out that I know a lot of the links are broken, but I’m keeping it anyway?

I actually did this with a post last year. I put a note and the top that said:

Sadly the serial number lookup system doesn’t seem to be in the same place any longer. The link no longer works, but the story and reasoning are still interesting, so I’m leaving the post up. Plus, the screencap link still works, so you can see how the system used to work.

And here’s another:

The main link in this article no longer works (as of October 2016), but the quote stands on its own, so I’m leaving this post up.

I’ll probably end up removing these two posts for other reasons (they don’t contribute to either of my two goals), but what about situations like the older post listed earlier, where a critical mass of broken links still doesn’t invalidate the main thrust of the content?

I could envision a script that periodically checked links and put a class on them that popped a message on mouseover that said, “Note: this link doesn’t work anymore,” and maybe a note at the top that warned the reader before they invested time.

So, outbound link integrity is another brush stroke, but – like the other rules – not absolute.

Rule: Centrality

For years, I’ve kept track of intra-site links. When a post is published, I extract all the links to other posts on Gadgetopia. I store these in a database table, so at the bottom of every post, I can provide links to posts which link into that post.

This was an attempt to provide links to posts that were related, but didn’t exist at the time I was writing the first post. It’s worked reasonably well over the years, enabled readers to look “forward in time” to see how the post they’re reading was referenced later on.

Using this data, I attempted to capture something else I’m been interested in for some time: “centrality.”

By centrality, I mean, how central is a post to the “network” of posts on Gadgetopia? Every post which has an outbound link to another Gadgetopia post or an inbound link from another post combine to form a network of posts. You can envision a map with cities and highways which connect those cities. Post A might link to Post B which might link to Post C and form something of a link chain. Mathematically, this is known as a “graph”, and we can do all sorts of analysis on it (there’s an entire science to it: Graph Theory).

I found a graphing library (QuickGraph), and calculated paths from one post to another. There were 1,286 posts with an inbound or outbound link (so they were considered part of the larger network/graph), which resulted in about 1.6 million theoretical paths.

It turned out that only 20,944 could be calculated (if two posts were linked to each other but nothing else, they then formed a “link island” that didn’t connect to any of the other 1,284 posts). Each path was a series of “hops,” and I recorded every post that any hop passed through, then counted up the occurrences.

This, it turns out, is called “betweenness centrality.” I didn’t realize it was a known thing until a mathematician responded to my question on the Math Stack Exchange to tell me that I had re-invented an algorithm. Yay!

Here, then, are the five “most central” Gadgetopia posts:

What Makes a Content Management System: June 2007
Content Publishing Models: June 2006
The Content Tree: August 2005
The Four Disciplines of Content Management: November 2007
Middle Ground: Content Management using Static HTML: November 2005

Those are all very foundational posts. I wrote them all well over a decade ago, linked to them often in the years immediately after, and linked to posts that linked to them in the many years since.

Clearly, centrality is deeply affected by age, since the passing of time makes it more likely that a post will appear in a “link chain”…but that’s not wrong. This is a measure of how central something is, and age is naturally going to affect that.

So, centrality has value. Looking at the list of posts from most central downwards, it absolutely correlates with high-value posts which meet my goals.

Rule: Keywords

The gold standard of a rule would be for it to understand what a post is about, and make a recommendation based on that.

But this is an inherent human-powered concept (-ish; don’t @ me about AI and ML…). And remember that the inability to scale human evaluation is why we’re talking about rules in the first place.

The next best option for automated processing is keyword analysis: what specific words/tokens appear together in content that fits a certain profile?

I’ve identified some words that I feel like would signify a valuable post. Here is my first, rough pass at it:

CMS
content management
editor
publishing
workflow
approval
scheduling
expiration
vendor
URL

I started to write my own algorithm to find these words, when I realized was just re-writing a scoring search engine. So I rigged up a script using Lucene.NET to index all the posts, then run a big query with all those terms concatenated with an OR operator, and then score the result, with the title of a post boosted to 1.2x.

Based on the keyword list above (which is subject to change), here are the top posts:

What Makes a Content Management System: June 2007; Score: 1.53
Content Publishing Models: June 2006; Score: 1.09
Patterns in URL Redirection After CMS Migrations: August 2016; Score 0.86
You Want Collaboration, Not Workflow: June 2014; Score 0.79
The Why and How of CMS Vendor Partnerships: April 2009; Score: 0.76

(Hilariously, when I publish this post, it will no-doubt acquire the highest score, since it literally contains a list of every single keyword, perfectly adjacent to each other.)

This method is very promising, because I’m scanning down the list of the top 100 posts by score, and there’s maybe three posts I don’t think I would keep.

What’s also interesting is that my list of keywords keeps changing as I look through the results. It shows me posts that I absolutely know I plan to keep, and they help jog my memory of other keywords that might reveal other posts. So, this will take some time to evaluate, as I refine my list of words.

(Yes yes – this could be automated. I could find a set of posts I know I will keep, then use term vectoring to find other posts which are similar to them. And, again, don’t think I haven’t considered the AI/ML options, but I just don’t know enough about that field to make any good decisions around it)

Conclusion

After sifting through old posts for a week, and slicing and dicing them based on the metrics from above, I keep coming back to David’s tag line for Content Chimera:

Content Exploration and Decision-Making At Scale

That’s really what this is: an exploration of content.

Rules are less of a final arbitrator, and more a rough tool that helps you explore a repository of content and make preliminary judgments with a relatively high degree of accuracy. I suspect I could select content (1) based purely on rules, or (2) based on pure manual evaluation, and realize that my results are 99% the same.

Additionally, the definition and development of these rules has forced me to think critically about my content and figure out what particular metric signals that a piece of content is worth keeping. Or at least worth reviewing to determine if I should keep it.

For me, I’m looking mainly for:

Longer blog posts…
With a good keyword score…
And some measure of centrality.

What I’m going to use my rules for is to rule out content that has none of the above. Looking at those three metrics, I’m pretty sure I can strike out 90% of the site with confidence that I’m not removing anything of value. If something is less than, say, 800 words, with a low keyword score and no centrality to speak of, then it’s just gonna go.

Note that I’m not going to delete it forever – I’m just going to change the status and return a 410 with my contact information. If I see a lot of 410s for a particular piece of content, I can review on a case-by-case basis to see if I made a mistake.

As for the remaining 700-800 posts, I’ll review link integrity as a second pass, then manually review from there. And as for traffic, I’ve decided not to pay attention to it, for reasons I explained above.

And this gets to the zen of it all –

We need to acknowledge that content has goals and a purpose, and that purpose is different for every site and every creator. If you don’t know what the goals of your content are, you simply can’t make an informed decision about whether or not to keep it.

Rules do not take the place of goals, and that was never their intention (apologies to David for my reaction to his plan in 2009). They only make you more efficient in finding content that fulfills the goals you’ve defined.

Note:
Special thanks to David Hobbs for his help in writing this post.

Problems, Patterns and Why Every CMS Thinks It Knows What You Need

Tue, 19 Mar 2019 00:00:00 -0500

Let’s start off with a premise –

Generally speaking, a CMS is a system to manage content that doesn’t exist yet and that it can’t know anything about at the time the CMS is designed and built.

So, Episerver and Sitecore and Drupal are all “solutions in theory,” designed and built to manage content and build websites that do not exist at that time. In their unimplemented, unplanned state, every productized CMS is theoretical. It certainly hopes that it can manage your content, but it doesn’t know this, because it knows nothing about your content.

Why am I talking about this?

Because I’ve gone on-record before as opposing the building of custom CMSs for any reason:

And then the other day, I tweeted a screencap of two slides of a deck I use when teaching “Introduction to Content Management” in the content strategy program at FH Joanneum.

The lecture is on “Acquiring a CMS,” and it presents the four major models of how one gets a CMS. The fourth model is to “Build Your Own,” and the next slide just says “Don’t.”

Yes, this is a pithy witticism (“Thank you, I’ll be here all week, tip your server”), but is it universal? Meaning, are there some situations when you should build your own CMS? (To be fair, a few slides later I do, in fact, list some reasons when it makes sense.)

While most of the responses to this tweet were positive, someone did call me out on it. Pete Czech from NP Group wrote:

Maybe WCMS but I can point you to a ton of use cases where custom makes sense. Maybe ya need to add some context to this claim…

And I felt badly about this. Because in addition to a “pithy witticism,” it was also a gross generalization, and I hate those. My LinkedIn profile literally reads: “I believe there are very few absolutes in this industry,” yet there I was tossing one out.

And Pete isn’t wrong. There are use cases where building a custom CMS makes sense. I just think it’s exceedingly rare.

Why? Patterns.

Question: how can any product fulfill your needs when it doesn’t know you? How can a coffee maker know how you want to make coffee?

Because most everybody makes coffee the same way. Making coffee is a well-known thing – you heat water and strain it through crushed coffee beans. This general process is so common that products can be created to automate it because a manufacturer can guess with a high degree of accuracy what you want to do. There are patterns to making coffee, and a coffee maker is just a codification of those patterns.

Usage patterns have a range of variability, of course. People might make coffee a little differently. Maybe you use two scoops of grounds, and I use three. Perhaps you put hot water in the pot, and I start with cold water. But for making coffee, the range of patterns is pretty narrow, and coffee makers can handle this confined variability just fine.

Sure, some people might like a french press or a pour over (weirdos), but coffee maker manufacturers have just decided that those people are outside the range of the patterns they want to support with their product. They might try to convince those people of the advantages of adapting to the more mainstream pattern (“It’s so much easier! People won’t call you a hipster!”), but they’ve otherwise accepted that the “pattern space” their coffee maker encompasses is enough to capture the share of the market they want.

The management of content falls into patterns too.

Consider content modeling: we generally divide out content into types, and those types have properties, and those properties have data types (ex: our news article has a publication date which is a datetime value).
Consider approvals: they’re usually always linear, and each step can either be assigned to a single person, or a group of people, one approval from which is enough to move it to the next step (ex: we need the managing editor to approve this, then one person from Legal…)
Consider URL management: each content object usually has am individual URL segment, which is combined with other segments based on spatial or type context (ex: the full URL of an object is the concatenation of all of its ancestors from the root object towards it)

Patterns are just problems that became so common we developed generally useful methods of solving them, to the point where those methods became accepted by the larger industry – people got sick of re-solving them, so someone rolled them together into a solution, combined it with solutions to other common problems, then bundled all that up as a commercial product. It’s kind of like evolution: some solution worked and got carried forward.

To be absurdly general: software is just a bundle of solutions to problems that people often have.

This means that no existing piece of software was created to solve your problem. How could it? When it was built, the creators didn’t know about your problem. But they knew about problems like yours, and they’re assuming that other people in the future will have the same problems, which is what rolled forward into you having a problem and this software magically solving it.

When you’re considering the “fit” between your problems and existing software, what you’re necessarily doing is forming a mental Venn diagram and determining how well the packaged software overlaps with your problem set. There are a few outcomes to this analysis, from positive to negative:

The system solves your exact problem, as produced. Your problem is so common as to be considered a pattern, and it’s already been addressed.
The system cannot solve your problem as-produced, but it could be modified or configured to solve your problem. This is where extensibility, APIs, and add-ons are helpful. More open, “platform-y” systems can pivot in various directions to solve more problems. (This is also where pure SaaS systems can be problematic.)
The system cannot solve your problem as-produced, but your underlying need is a little flexible, and perhaps you could modify that need a little (ex: through an organizational or process change) and then the system can solve your problem.
The system cannot ever solve your problem but this doesn’t matter because your problem is (a) actually not that relevant, or (b) its relative importance doesn’t rise to the level where it should outweigh the other advantages of the system.
The system cannot ever solve your problem, and your problem is real, relevant, and significant.

Note:
I talked about this more in-depth in another post: Checking the Box: How CMS Feature Support Is Not a Binary Question

Clearly, what any vendor is trying to avoid is #5. When it comes to your problem, every vendor is going to claim their system already solves it as a pattern (#1) or can solve it with some small and routine tweaks (#2), or that your problem can be solved some other way (#3) or that it’s just not a big problem to start with (#4).

If the vendor is stuck at #5, then they have a strategic decision to make: is this problem a pattern that we expand to solve in the future? Is your pattern common enough that they need to care about it to secure future business?

The answer to this question changes over time – lots of patterns that are addressed in the current generation of products started as weird problems that became less weird as potential customers brought them up again and again, often in response to changes in their market and business environment. Being aware of these trends and making decisions about what problems are evolving into patterns is fundamentally what the discipline of “product management” is all about.

Other vendors are happy to walk at #5. They say principled things like, “We’re not trying to make everyone happy” and “We have a narrow scope,” and they just pass on the sale.

This works, to a point. But, eventually, they might find themselves walking away from too many sales, at which point they’ll expand their “pattern coverage” through new features or though an acquisition (increasingly the latter).

Which brings me back to a custom CMS. Should you do it?

My non-flippant answer is this: only if you can demonstrably prove that your usage patterns are so specific that they’re not adequately covered by existing products (and, by usage patterns, I also mean non-usage stuff, like budget, licensing, hosting, etc).

If you walk away from known solutions to patterns, you need to acknowledge that you’re losing a lot of accumulated wisdom. An existing CMS is a massive pile of experience with a UI. Most any CMS has evolved around the solving of patterns that came up again and again, to the point where bundling a solution to them was helpful.

Also worth noting is that, in the world of CMS, the word “custom” is loaded. There’s a spectrum along which a CMS can be custom. How often is something totally custom, and how often is it a custom solution built around an existing framework? I suspect the latter is far more common.

For instance, if you have some odd delivery requirements (“We want to send content to little projectors strapped to the bellies of mosquitoes!”), that doesn’t mean you have to re-invent the entire technology stack. Just because one part of your requirements falls outside any known pattern, doesn’t mean they all do.

The content delivered by those projector-laden mosquitoes is still going to have to be managed somewhere, with modeling and workflow requirements that likely fall solidly within the known pattern space. Thus, start with a headless CMS that patterns the things you do share with the rest of the world, but keeps its nose (proboscis?) out of the things you don’t.

(Speaking of headless, patterns are why I think the market for headless CMS will change remarkably as it matures. Right now, people are rolling their own delivery layers. But, eventually, they’re going to start writing their own delivery solutions over and over to the point where they think, “Hey, I’ve done this enough times that I think I know enough to turn this into a product,” and thus launch the Website Builder Era of headless CMS. How many times do you solve a problem, before you think, “Hey…I’ve seen this before. This might be a pattern!”)

(Don’t look now, but the Headless Website Builder Era might already be here: Netgen Layouts, ContentPepper, and others, I’m sure…)

So, to Pete and anyone else that was annoyed with my absolutist take on custom CMS – sure, I’ll take that criticism.

I hereby state, for the record, that there are some situations where custom solutions work, but in those situations: (1) you need to have a real outlier in terms of usage patterns, and (2) you need to understand that the “custom” parts are likely only going to be where you usage diverts from known patterns, and therefore we have to place the word “custom” on some kind of spectrum.

Note:
I showed a draft of this post to Pete, and he responded by writing his own post: Making the Case for a Custom-built CMS. It’s a good post, and he has a number of interesting case studies in there. He wraps up with this:

I want to reiterate that I know the reasons for a custom CMS are on the fringes. That’s the precise reason why it’s important to recognize as developers and digital professionals that the custom CMS has a place in our arsenal. The fringes are typically where the fun stuff happens – I think most developers would agree.

I can’t argue with that point.

Breaking the Fourth Wall of Content

Wed, 27 Feb 2019 00:00:00 -0600

I’ve seen every episode of Friends at least three times. If you haven’t seen it (what?!), it’s a classic four-camera sitcom, where all the sets are open on one side. There’s an implied “fourth wall” that the cameras see “through” to film the actors on-set.

Sitcoms have been filmed this way for years, though single-camera shows are becoming more common. As far I know, you saw the fourth wall in only one episode of Friends, when Joey and Chandler were trying to break into Monica’s secret closet. It was painted purple.

(Also common to the four-camera setup: a laugh track, which is slowly dying out as well. If your comedy doesn’t have a laugh track, it’s probably a single camera set-up.)

The phrase “breaking the fourth wall” refers to when a show acknowledges that it’s, well, a show; when the characters somehow admit that they’re actually actors in front of a camera. In doing so, they would “break through” the fourth wall. They usually do this as a form of meta-comedy, and it can be really smart and funny when it’s done well.

Note:
To my knowledge, this never happened in Friends. In other shows it was more common and even celebrated – Arrested Development and Moonlighting were known for it. More recently, Kevin Spacey’s character would often talk directly to the camera in House of Cards.

Most performance art involves a tacit agreement, sometimes called Suspension of Disbelief. We “agree” to believe that two 20-something women lived in this relatively palatial Manhattan apartment along with their quirky-yet-relatable friends. This is the fantasy, and we’re not supposed to question it. The fourth wall needs to stay intact or the performance doesn’t work.

It’s the same with theater. The frame in which you behold the stage is known as the proscenium. All action takes place through this lens. You could, of course, run up on stage and look through the wings and see the costumes and the actors waiting for their cue, but you’re not supposed to do this. You’re supposed to play by the rules and constrain yourself to the gallery to view a fantasy world where the founding fathers were black and they broke into hip hop songs all the time. This is the contract you implicitly agree to.

The Fourth Wall of Content

What are we supposed to believe about the origins of the content we consume? Are we supposed to believe that this content just exists, suspended in some fantasy world, waiting to be magically cast out to our browsers, all Harry Potter-like? Or are we always aware that there’s a more raw, less refined version of the content somewhere else that was transformed into something more palatable for us to consume it?

Consider a templated page of highly-structured content (e.g. – an employee profile in a directory). We show this to the world as a single page of HTML, with content and template values inter-mixed so that an uninterrupted string of HTML is produced and appears on our screens as an integrated document. But do we expect our visitors to actually … believe this? Do they actually think someone typed this all manually?

Or, do we accept that they know there’s some structured content “back there” somewhere? Just like someone in a theater audience knows that the actors break character as soon as they’re out of view of the audience, do our visitors know that there’s a content type in the background, and that some values on the page are part of that content while others are part of something called a “template” that gets applied to all content, and that there’s a set of rules we made to organize the content in the site? To what extent do our visitors “lift the curtain” on our content?

I started word processing back in the early 90s, in college. Back then, Microsoft Word wasn’t common – all the cool kids were using WordPerfect.

I used the DOS version for a while, then graduated to the Windows version, which was a revelation. The DOS version had to represent different formatting with colors – something was “bright white,” for instance when it was bolded. To see what something really looked like, you needed to go to Print Preview.

But in Windows, you had this great feature called “Reveal Codes.” This would show you a little pane at the bottom of your text and the formatting codes. So you could see “bold” codes surrounding text which was bolded (a lot like HTML tags, really). This was my first introduction to the concept of markup.

I loved it. With this, I could peer behind the scenes. I could lift the curtain and see how the sausage was made. Everything was suddenly clear to me, and weird formatting issues suddenly made sense and were easily resolved. I felt like I was seeing the document for what it really was, rather than the homogenized version that was intended for the unenlightened masses. I had a privileged view while “they” did not – they merely saw the manufactured result of it; a PDF, or a printed page.

This dichotomy has never left me, and it’s paralleled in the larger content industry: we spent a lot of time trying to hide the things we do from the end user. We want them to see the result, but not how it happened. We want to maintain some … mystique (?), and there’s a strange intimacy to the extent that we reveal to them what we’re actually doing, both technically and logically.

We’re All In This Together

Indulge me with this gross generalization, but in a public website scenario, there are two types of people:

Editors
Visitors

Editors make the content and are the ones who understand how it’s formed: the structure, the organization, the nomenclature. Editors understand the very subtle difference between why a News Article is not a Blog Post, and how putting multiple content objects in the same folder will cause the left navigation to change.

A visitor just consumes the content. They can’t “Reveal Codes.” They can’t see behind the curtain and understand how the content comes together. They can’t tell a News Article from a Blog Post, and they have no understanding of the underlying IA that makes it all go. Visitors only understand what we reveal to them. Things that are blatantly obvious to us are hidden from them. They are led to believe that are content sprang magically forth from the ether in a perfectly consumable form.

To understand this better, let’s turn it on its head, by discussing intranets – the internal, employee-focused information systems used within a company.

The editor/visitor segregation breaks down a little when some visitors are editors, and editors are also sometimes visitors, and everyone works for the same organization. That organizational co-mingling breaks the dichotomy of “us vs them.” When the visitors are employees and they know there’s a Corporate Comms department, we suddenly drop the pretense that we have to “fool” them.

When my first book came out last year, intranet expert Martin White wrote a great review of it. Martin and I had met a couple of time over the years, and we exchanged some emails about it. Martin said there needed to be a chapter on intranets. What followed was a discussion about whether intranets were “web content management” in the traditional form.

I made this case:

With [SharePoint, and ECM in general], there’s very little “hidden.” With something like Episerver or Drupal, you have an admin/editorial side, and then a public side, and the latter is a very disguised version of the former. Put another way, you have admins/editors, and you have visitors/consumers, and the two are not meant to share the same view.

With SP, intranets, and ECM, you really have differing gradients of the same class: “user.” You have users only consume, and users that are allowed to also contribute, and users that are allowed edit and create content. The views are largely the same, and vary simply by degrees and permissions.

For instance, a particular document library in an ECM system might look the roughly same for everyone, some users just have a few more links and options than others. There’s little need or desire to “project” the library as something completely different, visually and functionally. Whereas with a public website, the raw document library would be the administrative view, and it would be viewed by the public through a facade that made it look like something not resembling a document library at all.

Unlike the traditional theater where the audience sits in the gallery and views the stage through the proscenium, intranets are like theater-in-the-round or “participatory theater,” where the stage is surrounded, there’s little place to hide, and actors come walking in through the aisles among the audience. The audience is “in” the performance. Other people are doing the acting, but the lines between “us” and “them” get blurrier and in some performances, actors come and sit in the audience and maybe even pull us up on stage. When this happens, we’re not voyeurs anymore; rather, we become part of the performance.

With intranets, we often have to be explicitly trained in how our intranet works. Someone will teach us the secrets of what a “section” is, and they’ll give names to things like “local navigation.” We understand that the content on the intranet isn’t magic, it’s simply the result of pieces of information interacting with each other through a set of rules. We interact with our intranet every single day, so we begin to reverse-engineer the patterns.

Just like you start to notice little ticks and details of TV shows you watch over and over, we begin to figure out what’s happening behind-the-scenes of websites we’re exposed to every day. We learn the rules and dispel the magic – we slowly break through the fourth wall.

Shadows on the Wall

The idea of teaching our visitors how things were built seems bizarre. Contemporary usage of a CMS is as a form of “projection.” We take content and project it into something else, and then try to pretend that the original thing never existed in the first place.

I’m thinking now of Plato’s Cave:

Plato has Socrates describe a group of people who have lived chained to the wall of a cave all of their lives, facing a blank wall. The people watch shadows projected on the wall from objects passing in front of a fire behind them, and give names to these shadows. The shadows are the prisoners’ reality. Socrates explains how the philosopher is like a prisoner who is freed from the cave and comes to understand that the shadows on the wall are not reality at all, for he can perceive the true form of reality rather than the manufactured reality that is the shadows seen by the prisoners.

The content that visitors see are really just shadows on the wall.

But when you need to draw users deeper into content, perhaps it makes sense to reveal the underlying structure a little more?

For a brochureware site, there’s no point – the user is ephemeral. They will consume, then not return, so any training or indoctrination about the content is wasted. Brochureware is the one-night stand of CMS.

As mentioned, intranets are the polar opposite, but what about something in the middle – a reference site, or a content-based web app, where users will return again and again. How do you decide when to enlighten them with IA and content model – the “insider information” to help them understand better?

How could we make the source of the shadows more explicit? Consider:

Could we have a link in the footer that says “Show me the content model of this page.” Clicking that link would reveals the raw, untemplated content structure. What would be the point of this? Well, as I said before, it probably matters more as intimacy with the site increases – for brochureware, no one cares. But for more content-focused sites, there might be value here (consider that Wikipedia essentially lets you do this).
Could we have a “Explain this Page” link and revealed a bunch of pop-up menus that explain how the page and the site worked? Like, it would label the left nav and explain why those links appear (“All these pages are in the same section, entitled ‘About Us’.”)

Do those options seem weird to you? Probably. But why? Why is there some reluctance about letting visitors turn their heads toward the light that casts the shadows?

Actually, we’re at a weird inflection point right now where we’re revealing more than ever before. Front-end development and single-page applications (SPA) – the so-called “JAMStack” – can’t really hide what they do. Network calls can be monitored, and JSON isn’t hard to read. If you want to reverse engineer how a SPA works, it’s all there for you to understand.

There used to be a clear delineation between client and server, and the server was a “magic box” from which stuff sprang forth. The stuff was generated on the server from … what? Some more pure data, we assumed. But the visitor didn’t really know what happened on the server. They could have no knowledge of what CMS or server architecture was being used, except what they might glean from artifacts in the HTTP headers. HTML was ejected from the server post-transformation.

But now you can monitor all traffic between your browser and the web server, and some of that traffic might be extremely detailed API calls (see GraphQL), complete with internal labels and names for logical concepts that might be presented to the end user in a completely different context. I realize the data we send might not be our exact content model, but it’s probably a lot closer than the shadows the visitor sees rendered in their browser.

Monitoring network traffic might be like running up on stage and peering into the wings. You’re seeing the backstage of the production – breaking the fantasy contract – and you might be shocked to find out the same dude plays four different parts in the background.

Us vs Them

The web as it stands today has grown up with an idea of an “us vs. them” mentality. The traditional paradigm has been one of a thin-client talking to the mothership. Strange things happened inside the mothership – both logically and technically – and we weren’t privy to them. We didn’t know how the content was generated, and to some extent, we didn’t know how it was organized. In fact, the goal was for a generation and organization process so unknowable that content just seemed to magically appear out of the ether.

This has inculcated us to the idea that visitors should be ignorant of the wizard behind the curtain. But is that limiting? I think the answer depends on your particular website and use case, but I can easily imagine situations where letting users understand your core definitions and architecture of content – not just your templated end product – might be the exact right thing to do.

I’m tempted to end this with some specific advice, but I can’t get behind anything in particular.

However, I just can’t shake the idea of “projection” in CMS, and how the very idea of content created for an audience is deeply imbued with the idea of “them” and “us.” We (us) create, manage, transform, and deliver. They consume.

As a mildly prolific content creator for more than a decade, I can tell you that “their” role is much shorter and simpler than ours, and I suppose that’s the basis of performance art in general. Actors rehearse and rehearse for a performance we consume in a couple of hours.

I think the basis of performance art – and of content – is that we hold our cards close to the vest, by design. We attempt to curate an image of spontaneous, miraculous conception. Our joy is in the visitor not even conceiving that it took work to deliver the end result. We try to be effortless and unseen, like shadows projected on a wall to an audience that never turns their heads.

Squirrel Notes: The First Year

Thu, 20 Dec 2018 00:00:00 -0600

I just sent the last Squirrel Notes of 2018 – Issue #20 – which concludes the first full year.

If you’re not familiar with Squirrel Notes, it’s an email newsletter about content management that I publish about twice a month. Each issue has five “notes,” which are just random things of interest that I’ve picked up from the world of CMS.

Here’s a little self-examination about why I started this, and where it’s going.

The Reasons

An email newsletter seems like such a step backwards. But there were a few things that struck me last year –

I subscribed to a newsletter called Recommendo, which is nothing more than six personal recommendations and tips from a group of editors. It’s quirky, and idiosyncratic, and it directly represents nothing more than the genuine opinions of actual humans. I love getting the newsletter – meaning, I literally smile when I see it in my inbox. I wanted to do something that would (hopefully, fingers crossed) give someone else that same feeling.

Just as much as Recommendo, I love the car videos of Doug DeMuro. He has a YouTube channel with millions of subscribers, and he reviews cars – new cars, old cars, all cars. His videos are about 25 minutes, and they’re not…corporate. When Doug reviews a car, he concentrates on what he calls the “quirks and features” of the car (he says that so much, in fact, there’s actually a drinking game).

One day, while watching a video, I realized this is what I identified with – the weirdness, the intricacy, and the specific oddness of what sets one car apart from another. Doug makes car content for weird car people, not normal people. He talks about random, odd things that only occur to people who really love cars, and I started wondering if I could capture this same vibe for people who love CMS.

(I think the word for this is “wonk.” A wonk is someone who geeks out on the esoteric, intricacies of stuff, sometimes with little practical application. Sara Wachter-Boettcher once called me a “CMS wonk” at a conference in Helsinki. I’ll own that.)

Also this year, I was traveling a lot and talking to a lot of people about CMS. I love it when two people who enjoy CMS start rambling about it, and topics just start falling from the sky. This person knows that person, and this system is going in that direction, and this trend is about to become the Next Big Thing. There’s so much information that just drifts by, and I wanted some way to call it out for people who are as weirdly interested in it as me.

So, I had started taking notes on random tidbits I picked up on the road (read: “notes”), and then this collided with my aforementioned love for Recommendo, and…

I don’t know at what exact point I took the actual plunge, but this tweet is from January 8th.

I have this urge to create a monthly email newsletter about CMS. I have no idea why I want to do this so much.

I put together a trial issue and then ended up writing another 5-6 in advance. I was actually sitting in a CMS selection process next to Karen McGrane in NYC, and during breaks, I would send her test emails of various issues. She encouraged me to forge ahead with it.

The only name I ever considered was Squirrel Notes. My book has a squirrel, and I was emailing my notes, so….well, there you go. The entire idea is literally notes.

I announced my planned newsletter in a tweet on January 12th, and I got about 100 subscribers in 48 hours. I sent Issue #1 on January 18th, and off we went.

The List

I made a couple decisions up-front.

I wouldn’t ask for any information other than email. I have no plans to market to the list, so I didn’t need any other demographics – hell, I’m just happy you’re here. An email address often reveals identity and employer, but subscribers are otherwise anonymous.
I would try to grow the list slowly and organically. I don’t want anyone on the list that doesn’t really want to be on it.

As of this writing, the list is just over 300 subscribers. And I’m proud that only about 5% of people who have ever subscribed have unsubscribed. So, only about one person in 20 thinks, “Nah, I don’t want to read this after all.”

(That math, BTW, is: total unsubscribers / current subscribers + total unsubscribers.)

I haven’t done any marketing outside of some Twitter posts and a LinkedIn post or two. All the growth has been word of mouth. I’m hesitant to do a big marketing push because I don’t want someone to subscribe who isn’t genuinely interested. Also, the newsletter doesn’t really have much of a commercial point to it. I’m sure there’s some incidentally marketing benefit to me and Blend, but that’s nothing you can calculate the ROI of a marketing campaign around.

(That said, if you want to mention Squirrel Notes to other people you think would be interested, please do.)

To let people know what they’d be getting, I have a public archive of most all issues. I hold the latest two back (otherwise, why would you subscribe?), but at any given time, you can see any other issues. I’d rather a potential subscriber look through some issues and make an educated decision to subscribe, rather than subscribe blindly, get an issue or two, and decide it’s not what they wanted.

(This just happened the other day. A guy subscribed, got one issue, then unsubscribed, which sadly inflates the stat I mentioned above. This annoys me.)

My feeling is this: there are only X number of people in the world that would be interested in this over the long term. What is that number? 500? 1,000? It’s certainly not much – of the emails I recognize, I can tell you that the list is basically consultants and vendors; so “industry insiders,” to some extent (“wonks”!). That’s a fairly small group, and I don’t think a contrived, artificial list of 20,000 vaguely interested people is going to do me much good.

I monitor bounces carefully. Curiously, it tells me a bit about comings and goings in the industry. I see a bounce which strikes me as odd because I recognize the email, and then I’ll see a notification that the person has switched jobs.

Also, it’s very gratifying to see that person resubscribe under their new email or their personal email account, which tells me that they want to make sure they keep receiving the newsletter (in that case, I delete their old email from the list, so it’s not technically an unsubscribe).

I sweat the open rate. MailChimp tracks how many people open the email (as best it can, given privacy settings). The list currently has an open rate of over 50%, which is very good, and there’s likely another 30% of people who prevent their email clients from registering the open (and this is likely even more common among my tech-savvy subscriber base). I’m reasonably confident that 80% or 90% of subscribers read each issue.

If the open rate were to drop precipitously, then I’d have to give serious thought about whether to continue, for this simple reason: if it’s not a thing someone wants to see in their inbox, what’s the point?

The Content

Every issue after the first two has five notes. Those first couple had six, because I had no plan and I was just throwing in all sorts of stuff. I quickly settled on five as the standard.

I’m pretty ruthless about word counts. Very few issues will have over 600 words. A college-educated adult can read about 350 words per minute, and skim much faster. My goal is to make Notes a two-minute read at most. If an issue is “heavy,” I will trim pretty ruthlessly – delete entire paragraphs, remove wordy clauses, or just nip and tuck everywhere.

I saturate each Note with links. My goal is for you to click something – I want you to see something interesting and investigate it. My mission is basically to write teasers to get you interested in other content. I want to “incite exploration,” to put a dramatic phrase on it.

I stay pretty close to CMS, but I edge into content technology in general. Really, I’m interested in anything related to CMS that would broaden the perspective of somebody who works with this software for a living.

I used to put the content in categories – things like “theory,” “events,” etc. When I was sending her test issues, Karen told me to dump the categories as they didn’t matter. But I was smitten with them, so they stayed…only to get dumped a few issues in, when they got tedious. She was right – you can categorize them in your own head; you don’t need me to tell you where they fit in.

Also, I used to show teasers at the bottom – “In the next issue of Notes…” I did this because I often had the next issue partially written as the current issue was being sent…but not always. It got to be a bit of a pain, and I was often thrashing the next issue together just to have the previews. So, I’ve dropped this for now. It might come back.

I try to get one issue out every two weeks, but not always, and I’m okay with that. For Notes to have longevity, it needs to not be stressful. So if I’m busy on a given week, I just wait until the next week. I decided early on that I wasn’t going to stress about it. I know you’re not staring at your inbox waiting for Notes to arrive, and a self-imposed schedule was just going to make me resent it.

I’ve never put any effort into the timing of delivery days or times. I send it whenever it gets done. If it’s outside working hours in North America, I might schedule it for the next morning, but I’m all over the map here.

The Process

I wrote a book on CMS, so you know the technical process behind each issue of Notes is stone-cold dialed in to the best possible industry practices. Woot! Woot!

Uh, no.

It’s not even content-managed. I write each issue as a delimited Markdown file. The files are sitting in Dropbox (where they are versioned), in folders by issue number (“001”, “002”, etc.). Each folder has a “notes.md” file, and a “header.md” and “footer.md” file if I have anything special for the header and footer of that issue.

I have a C# script that I run directly out of LinqPad to create the email. All the files are parsed and passed to a DotLiquid template. That template generates HTML which is pushed into MailChimp via their API (I have never used the actual MailChimp editor for Notes).

When MailChimp is updated for the first time (so, when the campaign is created), the script writes an “issue.meta” file in the same folder which contains the campaign ID (so I can update it in future executions). After the campaign is actually sent, I run the script once again to get the number of emails sent and the date they were sent on, which get written to the same file. This is the the metadata that powers the archive.

The script also generates a flat HTML file for the archive, which is written to a private “server” (in quotes because it’s actually the computer sitting under my desk in my office). The website (which is out on Azure) calls to it for an issue it doesn’t have, then holds the issue in cache. When the script runs, the last thing it does is call an endpoint on the server to clear that cache, so any new requests will get re-fetched.

Therefore, my “process” is simply this: I write, execute, review, write, execute, review, and so on. It’s awfully low-tech, considering what I do for a living.

But I have no plans to change the process, just the output. I’ll always compose the Notes in a Markdown file, but I’d like to eventually push them into a hosted repository of some sort, for reasons I’ll explain below.

The technical part of Notes has been really fun. It’s low-tech, but it’s not hacked up. The code is solid, and I actually haven’t touched the script or the template in months. It works beautifully.

It’s also a neat example of doing something “exploratorily.” I had no idea what I was going to do originally, so I didn’t want to put a lot of effort into it. I figured I’d screw around and see what happened. I had the following luxuries:

I’m the only editor
I’m technical, and comfortable in Markdown
I could template them myself
Delivery is decoupled – MailChimp and static HTML are my delivery channels

When I do finally decide to model them for a repository, I’ll be in a great position because I’ve been tinkering with the process and format for a year, so it will be nicely established by then.

Note that I surely wouldn’t do any of this for a client, but for a hobby, I’m having a blast with it.

The Future

As I mentioned, one goal is 2019 is to move the individual Notes into a content repository of some kind. Through 20 issues, there’s just over 100 of them now (not exactly 100, because of those pesky six-note issues in the beginning).

I’d like to enhance the archive. Right now, you can scroll through issues, and view a full issue. This list is getting longer, and it’s eventually going to have to paginate, which gets weirder with flat files.

Additionally, I’d like to:

Give each note it’s own permanent URL
Make the archive searchable
Tag posts, to group them by subject/concept
Be able to link posts back to each other

That last one is important. This last issue, for example, I made an addendum to a Note from the prior email. I’d like to refer to that prior Note, but I need a URL to do it, so they’re eventually going to need permalinks.

Note:
I did eventually archive all issues and notes on this site: Squirrel Notes (though I still don’t run it out of a CMS).

Additionally, the tagging would enable me to track “conversations” that develop over time. I remember this need from my blogging heyday – I’d do multiple posts on the same theme, and I wanted a “topic page” that recorded that particular conversation.

Note:
Here’s a semi-cringey post about this same idea from 2005: Coming Soon: Guided Content Maps. I never did do it, though.

Finally, one other thing I need to do is modify the subject lines. Right now the subject is just “Squirrel Notes #20” or something. I’d like it to still have that standard, but perhaps have a slug from the lead Note to give you an idea what it’s about. I hope this would increase open rates, but there’s a chance they might get worse (what if the slug isn’t something you’re interested in?).

So, that’s it. I’m one year and 20 issues in, and I hope to continue it for as long as possible. I hope you enjoy seeing it in your inbox every couple of weeks.

The Technical Basis for Content Experience

Fri, 16 Nov 2018 00:00:00 -0600

In Jonathan Haidt’s 2012 book, “The Righteous Mind: Why Good People Are Divided by Politics and Religion,” he mentions a study where subjects were shown pictures of a furnished room and asked to describe it.

Subjects from capitalist countries tended to describe the individual items in the room (“there’s a couch and a lamp”) while subjects from more socialist countries tended to describe the entire room (“it’s a living room”).

One group of subjects was perceiving the objects. The other group was perceiving the larger whole which emerged from the combination of the objects.

Note:
I’m describing this from memory. I don’t doubt I might be a bit off here. I did make a couple attempts to re-find this anecdote to no avail.

The point was that our concept of the role government should play in our life is deeply rooted in our conception of individuality opposed to the aggregation of people into a community. Or vice-versa, I suppose – one’s experience with government probably influences how we see everything else.

But, the point remains – do we perceive objects, or aggregations of objects? And does the appearance of an object with another object change the nature of both?

I know, this is a bizarre start to a post about CMS, but stick with me –

What is that ineffable quality that makes a CMS? We’ve been structuring and recording information for millennia. We’ve had relational databases for decades. But what is it that makes a data repository a CMS?

I think headless CMS has forced some soul-searching onto the larger CMS landscape. It’s driving a discussion of what a “CMS” even is. How big is that umbrella, and where is the boundary between what is a CMS and what isn’t?

I’ve been wrestling with this question for over a decade. See “What Makes a Content Management System” from June 2007. In that post, I took a feature-based approach to the question – what is and isn’t a CMS is just a super-set of features above a relational database.

But, lately, I think it’s more subtle than that.

I think the soul of a CMS lies in its ability to reason about abstractions. A CMS can interpret and respond to an abstracted, intentional request – don’t just give me a specific content object, but rather here is my need, and respond with the bundle of content structured in such a way that meets that need.

(I’m reminded of my wife, who is a kindergarten teacher. My wife gets kids like no one else. She understands that a child actually says, of course, but more importantly, she understands what a child doesn’t say. My wife can evaluate a child and understand their need, which is far above what they can merely articulate in verbal form.)

I hate to use the word “experience,” I really do. First, it’s hopelessly over-used. Second, it’s conflated with specific features. Third, it cracks open the gaping abyss of marketing hyperbole into which we might get sucked for all eternity.

But it fits.

Remember that a visitor knows nothing of your content model or objects. They don’t know a Text Page from an Article Page, or what Content Object #234 looks like.

And the products page of your website is not content. It’s really an experience. It’s made up of content, for sure. But the request for it is an intention that needs to be interpreted and formed into a “payload” of content to provide an effective response.

Put another way, when a visitor requests /products, they’re not saying “Give me Content Object #234.” Rather, they’re saying, “I have a content need. Give me an experience that fulfills it.” Visitors don’t perceive actual content; they perceive the experience of content.

I gave the developer keynote at Sitecore Symposium this past October. In that talk, I set forth a five-layer model for what constitutes a “CMS.” It looked like this:

Modeling and Aggregation: this the ability to describe content, relate it to one other, and organize it into structure that provide value
Editorial Tools: these are the tools that allow editors to work with content – so, the editorial UI at the most basic level, plus other tools like versioning, workflow, preview, etc.
Response Logic: hold this thought – we’ll come back to this below
Delivery and Presentation: the ability to transform raw content into a form suitable for consumption, and inject it into a consumption channel
Optimization: the ability to impact the performance of content post-publication – things like personalization, A/B testing, etc.

I grouped the first two layers – Modeling and Aggregation and Editorial Tools – under the label of “repository services.” These two things are needed to provide the ability for editors to work with content. They need some sort of UI to manipulate it, and they need the rules and storage mechanisms to hold onto it.

These repository services are all that a headless CMS aspires to be, almost universally. In fact, the entire pitch of headless right now seems to be, “We do only this thing, and we do it well, so you can fill in the other layers however you see fit.”

At Symposium, I made the case that this makes it tough to even call these systems a “CMS.” True, that term is applicable in a purely semantic sense: a headless CMS is a system that allows you to manage your content. But, in the years since “CMS” became a term, it’s become a colloquial shorthand for a system that provides all the layers (with #5 being more recent, and more common in the commercial space).

I argued that a headless CMS should really be called an “HCR,” or a “headless content repository.” Honestly, the “headless” qualifier is perhaps redundant. In their most pure form, these systems are simply content repositories.

Don’t interpret this as a pejorative term or a value judgment. Content repositories are critical, and they’re the technical basis for everything we do with content. A good repository is a wonderful thing.

But remember, repositories are about content, not about experiences.

I’m beginning to think the line of differentiation between repository and CMS is layer #3 from my model above: what I’m calling “response logic.” With a traditional CMS, there’s a layer of logic that can interpret intentions and choreograph a response of multiple content objects, organized into a larger structure, to provide an experience.

Digging deeper, let’s take a second to establish a couple precepts –

First, every CMS responds to requests. At one level a CMS is simply a database. We make a request of it – either a URL is requested, or an API is invoked – and the CMS responds by providing content.
Second, requests can be for one of two things: (1) specific content, which is common from an API (“give me content ID #234”), or (2) some abstracted representation of a payload of content (“I want the URL /products”).

Response logic, then, are the rules and processing a CMS uses to respond to a request. We can further sub-divide this logic into two parts:

Transactional response logic, which simply manages the transactional details of providing a piece of content
Abstraction response logic, which interprets request abstraction and determines what specific content should fulfill it

For a specific content object (ID #234, in our example), transactional response logic performs these steps:

Access Control Checking: is this security context allowed to view this content?
Publication Status Checking: is this content assigned a state that allows viewing?
Version Selection: which version of this content is the published version?
Variation Selection: is this content being personalized or multivariate tested, and, if so, what combination of variations should be presented?

This is where headless systems really stop. Headless CMS requires you to manually identify or query content, much like SQL against a database, so that’s what they do.

But that isn’t the interesting part.

Abstraction logic can interpret a non-specific content request (/products, in our example), and do this:

Abstraction mapping: in WCM, the abstraction “name” would be a URL, so the CMS has to map the URL to a specific content object in the repository. Generally, speaking abstractions link to specific content objects, but that object might be nothing more than a query that aggregates more content (a view from Drupal Views, for example)
Contextual content association: the CMS needs to then gather all the content of the response payload, and it needs to run all the transactional rules on each

So when someone requests /products, our CMS has to figure out what content represents that view (likely a “Text Page” called “Products”), then determine everything else that needs to be rendered with it: content to form the menus, crumbtrails, header media, related content, etc.

All this content together is the “response payload.”

And this is where we cross the line into what I would call a “CMS”: something that has the ability to respond to abstracted content requests. It has a layer of knowledge of just what needs to happen when someone wants /products, or when they’re looking at the home screen of your app, or all the content necessary to fully-render your white paper into a PDF.

A traditional CMS has always played the role of ringleader – it was the dispatcher that translated the intention of abstraction requests into the actual content required to fulfill it. A system that exchanged intention for experience.

With a content channel based on a headless system, where is this response abstraction logic? As we’ve established, it’s not in the repository. It’s either baked directly into the delivery layer, or it’s something between the delivery layer and the repository.

You might have URL queries embedded in PHP code that directly executes on request
You might have a .NET framework that maps abstractions to backend queries via a BFF
You might have a React component that makes queries for specific objects to form an aggregated display

Something, somewhere, has to choreograph a response payload. Regardless of where you put this or how you codify the rules, this is response logic. A traditional CMS has it built-in, while the current slate of headless CMS requires you to bring it with you.

This tacit ability for a CMS to choreograph an intentional request into a coordinated response of content is, in some senses, the “soul” of a CMS. It’s the thing that makes a CMS more than just a database. It’s what makes a CMS a CMS.

An interesting aspect of response logic that we can use to speculate on the future of headless is that response logic embraces convention. Indeed, response logic is convention. It’s some larger framework for converting a request abstract into a response payload.

I promise that if you build response logic enough times, you’ll come up with common rules and practices for mapping request abstractions into content payloads. You’ll do the same things over and over again until patterns emerge. You’ll eventually codify those patterns, and before you know it, you’ll have developed a response logic layer.

And this is what I think we’ll see in the headless space: commoditized response logic. Someone, somewhere, will come up with a framework to add response logic to a particular headless CMS. They’ll package this into a system and sell it or release it to open-source. Then, that headless CMS will have some new remote API abstraction “on top” of their existing API. The abstraction API will take some shorthand request (like /products), translate it to all the calls required to form the response payload, then assemble it and send it back.

So, you won’t build stuff directly with Contentful or Kentico Cloud. You’ll build something with “The Headless Whizbang Experience Manager 5000”, and some headless repository will be abstracted behind it. (And just watch – they’ll be interchangeable, so you can use Whizbang with a plethora of backing repositories.)

(This could most easily happen with some MVC framework. Even now, an MVC framework is a form of response logic – it converts an inbound request abstraction into executable code. Someone, very soon, will release some code that maps models in an MVC framework to content objects in a headless content repository.)

Could headless systems build response logic in? Well, yes, of course, but their marketing message has always been a rejection of it, so they’ll likely leave it to other software (or build it themselves as a separate product).

But the easiest way do start down this road is to allow URL rewriting/aliasing on the inbound request.

I mean, wouldn’t it be handy if we could alias this…

http://headless-cms.com/my-account/recent-posts

Into this:

http://headless-cms.com/
my-account/
items/
?select=id,title,summary
&type=blog-post
&sortby=date
&sortdirection=desc
&limit=3
&auth=[key]

Even something as simple as that moves us from content to experience. The former is an intention (“tell me what’s new in your world”), the response to which constitutes an experience. The latter is simply the mechanics that gets us there.

Abstractions like this would be helpful to centralize logic. If you have your app installed on 10,000 devices and one day you decide you want to show the top four blog posts instead of the top three, wouldn’t it be handy to be able to change the backing querystring for the /recent_posts URL? Wouldn’t it be nice to have some cushy layer of configurable logic rather than just fielding raw queries all day?

(What? You already do this via a BFF or proxy? Well congratulations, you just wrote some response logic.)

The pitch of headless always fixates on templating and rendering. “You can use React!” or “Angular!” or whatever else! It’s as if the last mile of concatenating a string of HTML is the single biggest problem we have to solve.

It isn’t. Templating is actually the easy part.

Rather, I think that the headless CMS category has been defined by an explicit rejection of response logic, and, by extension, a rejection of experience in favor of raw content.

The current spate of headless systems are trying to be super-content-databases that just respond to raw queries without any regard to the experience that a choreographed response is meant to represent. You need to bring your own experience manager.

And, to be fair, this is the point. They’re not ignorant of experience, they just trust you to handle it yourself.

But at some point, I think we’re gonna miss this. We’re going to find ourselves re-implementing it enough that we realize there are patterns there, and how can we develop some commoditization around it?

And this might be the next step for headless: how do we allow our customers to develop response logic at the repository level? How do we move headless systems from just managing content and responding to requests, and rather start managing an experience of content at the perceptual level?

It’ll be interesting to see if they go in this direction.

Note:
After this post was written, Kentico released Web Spotlight which is a web content management system built on top of their Kentico Kontent headless product.

Points of Differentiation in Headless CMS

Tue, 16 Oct 2018 00:00:00 -0500

When was the last time a project failed on selection of the database server?

Have you ever heard, “This project would have worked if we had used Postgres rather than MySQL.” Or SQL Server rather than Firebird. Etc.

You don’t hear this because we just don’t expect much from database servers. They have a wide range of functionality, but what do we use? Tables, columns, keys, and maybe stored procs or views? (Truth: I don’t remember the last time I wrote a stored proc. I’ve actually written a manifesto against them.)

When was the last time you used a feature of a database server that isn’t available in a competing product? Not something that’s just done differently, but a feature that literally doesn’t exist in anything other than the database server you selected for your project?

The way we use them, database servers are largely fungible, which means:

Something that is exchangeable or substitutable.

Assuming we can connect, we can usually swap one for another. This is why database abstraction layers exist.

Our usage patterns of database servers are very narrow. We just don’t ask a lot from them, generally. If you’re a Windows developer, you’re probably always gonna use SQL Server because it’s just fine, and you wouldn’t think to question that.

When usage patterns are narrow, software is easily substituted. As usage patterns get wider – as you start doing more interesting, varied, and complex things with the software – it gets harder to substitute because you start to wiggle your way into places that only a subset of the products support.

Now, consider headless CMS.

Right now, the usage patterns for headless are narrow. These products are still young, so mostly they’re being used for remote management and access to a structured repository of content…full stop. If you can model your content, manage it, and access it over REST, you’re good. We’re just not asking for much right now.

This is one of the selling points of headless: don’t buy a bunch of stuff you don’t need. Indeed, this was the original point. The value prop – implicitly or explicitly – is, “We’re stripped down to the core essentials.”

Given this, how are headless vendors competing? How are the individual vendors setting themselves apart from each other to avoid fungibility? How are they proclaiming “This is the thing we offer that no one else does that will help with your project!”

In short: why should a customer pick one headless CMS over another?

Here are some thoughts.

Content Modeling

The most basic thing a CMS needs to do is to allow you to accurately represent a logical domain of content in a structured, reusable, and manageable way. This means creating content types, properties, and relationships to describe what your content is and how it should be managed.

There are three sub-disciplines here:

Discrete Modeling: This is describing a content object unto itself, meaning the properties that are specific to that content object and wholly contained with it. “Title,” for example.
Relational Modeling: This is describing how a content object relates to other content objects. For instance, our “Article” type should have a property called “Author” which is actually a link over to a separate content object of the “Author” type (trivia: I stumbled on the phrase “relational content modeling” 12 years ago.)
Organizational Modeling: This is the grouping of content into aggregations (I’ve called these “assemblies” in the past). A content tree is a core type of content organization (which I’ve called “geographies” in the past). So are things like categories, taxonomies, lists, and menus. Given sufficiently advanced relational modeling, you can usually rig up organizational models (you can create a content type for “Taxonomy Term,” for example), but some systems have specific subsystems for common organizational schemes.

Most headless systems are doing well on the first two items here – discrete and relational modeling. You can create different content types, and specify reference properties to link them together.

However, there’s still a dearth of organizational modeling. Some systems have categorization and tagging, but it’s sporadic. I do know of one vendor with a fabulously visual graph database, where every entity is related to every other entity – and everything in the installation is an entity, from the folder the content lives in, the editor who created it, each individual tag assigned to it, etc.

Weirdly, content trees are conspicuously absent. “That’s web-centric,” one vendor told me – a point with which I strenuously disagree. I feel like parent-child relationships are a natural way to model all sorts of content, but the tide of headless vendors is clearly against me on this.

UI Usability

The editorial UI is what editors interact with to create content. This includes the interfaces they navigate through, as well the the editing widgets themselves. Some of this piggy backs on the content model, since widget selection very much depends on the underlying datatype of the property (a date-picker for “Published Date”, for example).

Headless systems benefit greatly from a coincident of their timing – they were born into the Era of the Big Client. Most all headless systems have come into being after mature JavaScript frameworks have taken over page rendering.

And, since they allow remote access to content, many editorial UIs are simply Single Page Applications (SPAs) making REST calls using the same querying API available to their customers. Indeed, a headless CMS that used more traditional HTML via server-side rendering would seem highly out of place.

And, given their age and purposefully-limited featureset, headless vendors don’t have legacy UI elements to support, and their interfaces tend to be very clean and content-centered (indeed, what else is there to do?).

Editorial Tools

These are the tools that editors use to actually manage content, apart from the actual UI. Things like:

Note:
Shameless plug: all terms linked to entries in the web content management glossary.

These are the…boring (?) tools that editors use to get content created, edited, managed, published, unpublished, archived, and deleted. These tools are unglamorous, but necessary.

While grouped under what I’d call “repository services,” these tools are often the last in line to get developed. In many cases, their absence just doesn’t stick out enough during demos, because few vendors proactively demo them (how exciting is it to watch something get archived?), and many users take them for granted so they don’t think to ask for them (“Of course it allows for approvals! What CMS wouldn’t…?”).

These are tools that get developed later in a CMS’s lifetime, when the user base has gotten large enough that enough customers are asking for them. In a new market, when vendors are scrambling to show of exciting, highly-visible stuff, these tools fall through the cracks.

Performance Scalability

A big selling point in headless is its ability to serve a massive throughput of data – so-called “hard” scalability, or raw requests-per-second. Most headless systems do this by publishing into a Content Delivery Network (CDN). So, when you request content from your headless CMS, you’re actually requesting content from Cloudfront or Fastly or something.

The “cache-ability” of your content will differ greatly depending on architecture and level of personalization. Additionally, you can implement your own caching schemes – my book website, for example, has made just six requests to its headless CMS in the last 15 days, as it caches everything at the web server (not a typo: six).

But there are situations – mobile, for instance, when you might literally have millions of clients in people’s pockets, each making live requests all the time – you need massive scalability.

Dev Ops Integration and Scalability

The headless market is still decidedly developer-centric. As such, many headless systems are building deep integration into dev ops tools.

For instance, having to create your content model from a UI is not something a developer usually wants to see. They want to define a content model in a file (I’ve said before that files are “the currency of web development”), check it into source control, and have content model changes happen directly from a branch. Additionally, they want to be able to clone environments, change their models, and generate diff files to propagate to other environments. They want to be able to manage everything from a command line, and have hooks to continuous integration platforms, unit testing suites, and other deployment workflows.

For some developers, even logging into the UI would be considered a failure. They want to manage their headless CMS like just another one of the hundreds of database instances they have in their organization. They want it to bend to their process, not the other way around.

Many headless vendors are seeking to become “content infrastructure.” The last thing a vendor wants is to become a speed bump to a development shop’s process. The goal is to fade into the background like the network itself – something you don’t think about much, but you always know is there and that you’d be helpless without it.

Remote Event Hooks

Headless CMSs are built around their APIs, so the ability to manipulate content remotely is just table stakes. But what’s trickier is event-based programming. Since you can’t program inside a SaaS CMS, when something changes inside the repository, it’s often necessary to notify an external process.

Example: above I mentioned how my book site caches all the content in the web server process, and those rarely ever talks to its headless CMS. However, when something does change, my headless CMS calls a URL on the site and tells it to clear the cache. On the next inbound request, the site retrieves the updated content.

This is commonly called a “webhook” (15 years ago, I came thisclose to naming them…). There have been attempts at standards around this, but, to my knowledge, it’s a wide-open space. Some systems just send an empty HTTP request, while others will actually POST the changed content. Some allow for authentication, some allow for customization of the HTTP request (custom headers and such), etc.

I’d like to add other integration hooks here, but I’m not sure there are many. Since you can’t code logic into a SaaS-based CMS, and the core CRUD API is a given…what else is there? Webhooks are the main conduit by which these systems communicate with the outside world about events occurring within the system.

SDKs, Code, and Query Language Support

Every headless CMS offers some form of remote access and querying, so every headless CMS can “fall back” to REST over HTTP, usually delivering JSON.

The existence of the ability to search the repository via URL-based queries is clearly binary and required, but the actual capabilities are on a spectrum. Most systems offer full-text support, but there are vagaries in the querying models that might make a difference (for example: are relational properties two-way? Given an Article, you can get the Author, but given an Author, can you find all their Articles?).

Some particular subsystem architectures, protocols, and standards are desirable for specific developers and scenarios:

Authentication schemes like SAML or OAuth
Query languages like GraphQL
Security protocols and standards like SOC 1/2, PCI DSS, or FISMA
Privacy protocols like GDPR

Additionally, some systems have abstraction libraries for specific languages (Software Development Kits, or SDKs), so you can get pre-built code that “wires up” some of the backend stuff and makes querying easier.

Delivery Channel Features

This one might seem weird, because the rejection of “channel awareness” is de rigueur in headless – “We manage content, not pages!” The whole idea is that they don’t do anything in the delivery channel.

However, some vendors are making concessions to common channels – particularly the web – and offering specific features for them. (In fact, I like that name for this phenomenon: “Channel Concessions,” which means, “We’re headless, but we concede that we can do something to help this specific channel, so we’re going to do that.”)

Some vendors have JavaScript libraries that give “click to edit” functionality in HTML
At least one vendor is offering a “landing page builder” to allow for the spatial organization of content on a page surface
Some vendors have preview functionality which will load specific preview URLs in the editorial interface, which allows HTML-based preview
One vendor has a “Synchronization API,” which allows you to make a query with a date, and effectively say “Give me all the content that has changed since this date.” This is particularly helpful for mobile, when you might need to refresh a local content repository.
I’ve seen analytics usage tracking, where a channel can callback to the repository to register the view of a piece of content. While this is channel agnostic, the most obvious usage would be web tracking.

It’s going to be interesting to see where this goes. I feel we’re going to increasingly see vendors offering features for specific channels, either in the core or in packaged add-ons that we might implement or “activate” for a project involving that channel. Like those I’ve detailed above, we’ll see tools that only make sense in the web channel, or the mobile channel, or whatever.

Taking this to an extreme conclusion, we might find vendors eventually offering full-blown “website builders” that allow all the same tools as a traditional, coupled CMS…just using their headless system as a repository. At that point, they’ll have basically created an entirely separate product.

(Watch some of the traditional vendors that are starting to offer separate headless functionality – Evoq, Kentico, etc. One day, they may just swap in their headless system as the backend repository for their core CMS, and won’t that be interesting?)

Note:
After this post was written, Kentico released Web Spotlight which is a web content management system built on top of their Kentico Kontent headless product. (Confusingly, they also still have their existing DXP product.)

Pricing and Licensing Models

While this criteria is true for any CMS (any software package at all, really), it has some uniqueness around headless CMS, for two reasons –

First, the headless market is dominated by SaaS models. There’s probably no genre of content software more specific to a SaaS licensing model than headless. Almost all systems are subscription, and pricing varies significantly.

Additionally, the axes on which subscription pricing turns are vastly different. Some systems charge by users, some don’t. Others allow a certain volume of content, others are unlimited. Almost all have some limitations around API requests, but some differentiate between retrieval requests serviced by the CDN and requests that query the repository (uncached requests, or update/create/delete requests).

Second, despite the dominance of SaaS, some headless systems can be on-premise. There are a few open-source options, and some commercial systems allow for on-premise installations. While the overwhelming majority of customers simply subscribe, some organizations demand a on-premise system. If so, the list of available options pares down very quickly.

Vendor Reputation and Stability

Like the prior section, this is true of any CMS selection, but it takes on added significance with headless because the market is so young and is tilted towards SaaS, which means the barrier to entry is low.

Right now, new headless CMSs are entering the market every single month. I’ve tried to keep up, but there’s just no way to stay on top of all the new releases.

This is due to the fact that a headless CMS is easier to build than a traditional CMS, because large parts of the traditional CMS featureset have been omitted. There’s no need for templating or response logic, no need for advanced editorial tools (at least to start), and many systems are basically just glorified database management systems (you heard it here first: phpMyAdmin was the first headless CMS…)

Additionally, since most systems are SaaS and grid computing architectures are so easy to scale, it’s just not that hard for someone to create a new system, call it a “headless CMS” and release it onto the market.

As a buyer, separating the wheat from the chaff can be tough. How do you know if this is a company that’s going to stick around, or if it’s just two guys in a basement somewhere? If the latter, there’s always a chance they’ll be the next Apple, but the odds are long and your content hangs in the balance.

Vendor Signaling

Like any other software segment, headless vendors “signal” the type of customer they’re interested in via technical architectures and pricing/licensing models.

There are several headless vendors, for example, that have significant ramp-up time and technical hoops you need to jump through to get them productive. This is in service of larger goals like scalability, performance, security, and stability, but for a single-person front-end dev shop, this is overkill.

For smaller use cases, there are vendors that signal in the opposite direction, promising simplicity, speed, and reduced ramp-up type, presumably at the sacrifice of industrial strength attributes unnecessary for that type of project. They assume a simpler project, are designed to provide the bare minimum of features and stay out of the way as much as possible.

Documentation matters too. I just spoke to a customer who preferred one vendor over another because “their documentation was focused on editors, while [the other vendor’s documentation] was focused on developers.”

I’ve mentioned that headless is very developer-centric, but some more so than others. Many offer free accounts and API sandboxes to get you moving quickly. On the other side, one vendor requires you to load their command line tools via npm just to create a trial account, because their system has no multi-tenant UI – it’s managed mainly from the command prompt. (Once you’ve done that, you can run your own UI, also installed via npm and run in your local Node.js environment.)

In short, headless vendors have a “tone.” You can label the two ends of the scale as “industrial” and “friendly,” or targeted to developers or editors. Pretty much every customer intuitively knows what end of that scale they gravitate toward, whether they explicitly acknowledge it or not.

Conclusions

I don’t doubt that I missed some categories above. But if an omission sticks out for you, understand that it might be because there’s little difference between that aspect of headless and the same thing on the coupled side.

Community and ecosystem is a good example. Trust me, I know this is important – I wrote at length about it, six years ago – but I just don’t think this is much different for headless than for any other type of CMS.

Clearly, the range of features for a headless CMS is more narrow than for a traditional, coupled CMS – by design. This means that a headless CMS has that much less room to maneuver against their competition.

A headless CMS can’t really trot out a bunch of delivery-channel marketing features which is where most other CMS segments are competing these days. Episerver and Sitecore, for example, aren’t launching any marketing campaigns around their content modeling.

Right now it doesn’t feel like there’s a dramatic, expansive featureset where a vendor can spread their wings, redefine the segment, and put considerable distance between themselves and the competition. To some extent, headless vendors are locked in a knife fight inside a phone booth.

Years ago, I made a series of posts about WS_FTP, which was a very mature FTP client. They kept pushing it out the door with new features, year after year. Some were interesting (automatic image thumbnailing), and others were ridiculous (custom skins). But what choice did they have? The only way to keep selling is to release new versions with new features (ask Joel Splosky about this), so they kept pushing functionality into the product.

But FTP will only do so much, and FTP clients are highly fungible. So, despite all their efforts, features, and bloat, WS_FTP was still pretty much like any other FTP client.

Now, I know that the headless market still has a lot of room to grow, but eventually headless vendors will reach feature parity on lots of stuff. Is there much new ground to break in content modeling, for instance? When that happens, then what?

So, my question is this: what’s the “killer app” of headless CMS? What is the thing that a particular vendor might obtain or introduce that would set them apart from everyone else, while still allowing them to fit into the standard definition of a headless CMS? Can you imagine what that thing might be? Into what realm will a vendor “spill over” into when features become too similar?

I can’t think of anything, but this is why they pay product managers. One of them is going to get trapped against the glass ceiling of the segment, and they’re going break through it. I look forward to seeing what they come up with.

Note:
Thanks to several headless vendors who discussed this post with me. Note that they didn’t necessarily agree with the core premise of reduced differentiation, but they were gracious enough to review and provide feedback nonetheless: Contentful, ButterCMS, Kentico Cloud, Cloud CMS, and Contentstack.

And thanks to Rahel Bailie for asking me the questions that prompted me to write all this down.

Multi-stage Templating as Progressive Denormalization

Tue, 21 Mar 2017 00:00:00 -0500

One of the perennial rallying cries of content management has always been that “content is separate from presentation.” We store content in a raw, pure form then when it comes out, we muck it all up with templating. This is the standard paradigm.

But is all templating equal?

We usually think of templating as the final step to create HTML out of content. In our heads, content makes the jump from “raw” to “presentation” in one step – it’s raw content then…BOOM…it becomes presentation-ready content in the blink of an eye.

But perhaps we need to expand this definition to include a layer of “transformation” at the repository level? Furthermore, maybe we need to look at the journey from raw to presentation as a series of progressive denormalization.

I’m borrowing the word “transformation” from XSLT. That technology was intended to turn XML into other XML formats to use for different purposes (or, more commonly, as part of a pipeline). Since no one reads raw XML, the assumption was that the XML would eventually get “templated” into a consumable form. (Of course, then we all started “transforming” XML directly into XHTML, which wasn’t the original plan, but whatever…)

Transformation might start earlier in the process than you think, and it ends up looking like a pipeline – content is thrown down the pipe and refined until it finally comes out the other end. From another perspective, templating might resemble a tree where content starts at the top, gets subdivided into multiple other formats, which are then further templated into end-user consumable formats.

We tend to take this for granted, but the surge of headless CMS systems has suddenly thrown this back into play, especially – and sometimes only – when we start pushing to multiple channels. Without any ability to transform at the repository, developers are having to write their own templating layers, which often means duplicate templating code and logic in multiple consuming channels.

Frustratingly, most headless vendors refuse to concede to transformation closer to the repository. Multi-stage refinement – early-stage transformation, then later-stage templating – is not well-supported in the current crop of headless CMS.

Herein, I’ll make the case of why this needs to change.

Content Transformation as a Drivetrain

The drivetrain of a car is complicated as does a lot of stuff. Let’s consider the engine as the raw content stored in the repository, and the point where the tires touch the pavement is the final step in presentation to our audience.

The relationship of the power that comes off the engine and the rotational force applied to the ground through the tires is complicated and takes a lot of work to sort out.

You can’t hook the wheels directly up to the crankshaft of the engine. The engine has to constantly turn, and if the wheels were connected directly, they’d have to turn around about 500 times per minute at idle. To fix this, we have clutches and torque converters to disconnect the engine so it can run while the car isn’t moving.
In many cases, the crankshaft of the engine is a single rotational device turning on a north-south axis, while there are (at least) two drive wheels turning east-west. This is why we have differentials – they’re a series of gears with let the power of the engine turn 90-degrees and split into two outputs.
Engines can rev from 500 rpm to sometimes 10,000 rpm, but they make peak power in a more narrow range called the “powerband.” Thus, we have transmissions which match the speed of the car to the powerband, so the engine stays as efficient as possible.

This is even a simplified analysis – we didn’t even talk about flywheels, transfer cases, driveshafts, and wheel bearings. A lot of stuff has to happen to get a single horsepower at the crankshaft to do anything productive at the wheels. Remember, in its pure form, an internal combustion engine makes pretty useless power. It has to keep running, it only turns one way, and it gets irritated when you try to put load on it outside a particular RPM range. So the drivetrain of an engine is a mechanical pipeline that “fixes” a series of problems along the way, and what comes out at the end – tire on pavement – is useful power.

Is your content the same way? Is the raw content stored in your CMS of the same value as the content that ends up in the hands of the consumer?

What the drivetrain of the car is designed to do – much like transformation and templating – is progressively refine (there’s that phrase again) the power of the engine until it’s an appropriate form to be applied to the pavement through the tires.

And here’s the point to remember: there’s one drivetrain that powers all the wheels. Each wheel doesn’t have its own transmission. We’ll come back to this in a second.

A CMS needs the ability to transform content prior to delivery to a consuming application where it will be further templated. This means transforming content as close to the “engine” (the repository) as possible so that all “tires” (consuming channels) benefit from it. This is in opposition to delivering nothing but raw content and expecting the consuming channels to bear all of the templating workload.

The problem with leaving all templating to the consuming channels is two-fold:

Latency: some transformation is complex and involves considerable computational power and perhaps external resources. Doing this on every read can be painful.
Multiple channels/platforms/languages: if we’re pushing this content into multiple channels, there’s some basic transformation that we simply don’t want to repeat in every channel.

Put another way, having content in its raw form might be less than helpful (remember our useless raw horsepower). Here are some real-life examples:

Example: Domain Specific Languages (DSL)

A health system had 900 clinics, each of which had to maintain their hours online. This meant storing open and close times for seven days of the week, and occasionally there was a clinic that was open for separate time periods in the same day – for example, from 8 a.m. to noon, then again from 2 p.m. to 5 p.m.

This was a painful interface to model. At a minimum, you’re looking at 14 different properties (open and close times for seven days of the week), or more when you consider the odd exceptions. Additionally, it was tedious. Time selectors generally suck, and editors were faced with 14 of them. It wasn’t pretty.

So what we did was allow (and train) editors on a simple domain-specific language, like this:

M-F: 8-5
Sa: 8-noon

Or:

M: 8-noon, 2-5
T-Th: 8-5

Or:

*: 8-3

We wrote a parser to turn this into a strongly typed object, which could then be turned into JSON or XML (and subsequently cached). The logic to do this parsing was complex and took considerable debugging to work out. Additionally, it wasn’t computationally cheap. But it worked beautifully, and with about five minutes of training, it made perfect sense to the editors.

(For a more common example, consider Markdown, That’s a perfect example of a DSL designed to simplify the generation of HTML.)

Example: Markup Macros

In many CMSs, editors can insert “macros” in rich text. These are text shortcuts which “expand” to larger text constructs – usually HTML, but they could theoretically be anything.

For example, the site for my book has a glossary with wiki-like links between pages. This is what they look like in the editor (from the entry for “version control”):

{%{
A version label is a designation applied to any particular
version. For example, a version might be labeled
"{{publication|Published}}" or "{{Draft}}". By versioning
content, the {{CMS}} retains a history of all the changes 
to a piece of content over time allowing {{editor|+s}} to 
rollback to prior versions if necessary or audit changes 
to content for security or regulatory purposes.
}%}

See those words in double brackets? Those are wiki-ish links that map to other terms based on ID slug and may display different text – different words entirely, or modified versions of the source word (i.e. – “editor|+s” links to “editor” but displays “editors”).I’ve written a parser to “expand” all these “macros” – to find the correct term, modify the source word, and add the hyperlink.

(And it’s not just me: Drupal has an entire architecture of “text filters,” and WordPress has a very popular system for handling “shortcodes” – I’ve used a couple in this very blog post, in fact. A more advanced version might be Episerver’s re-usable block elements that can be dragged into rich text fields.)

Example: Volume and Consistency

A law firm has 48 separate web properties. They all run on different platforms (some WordPress, some Sitecore, some hand-coded on non-executing environments like S3). They also have a series of blog posts, which they want to be able to insert into different sites (perhaps through a macro system, as described above).

However, they want the exact same format for the blog posts. They want a title, date, site name, preview, and link. They have a common HTML construct which can be styled for the individual property. What they don’t want is for each potential environment to “roll their own” templating code and form HTML from raw content. They want these all to appear the same way, in addition to the problem of some environments not being able to execute at all.

What they need, then, is transformation at the repository (the “drivetrain”). So each blog post has all its raw, editorial content, but it also contains an HTML representation of the last time it was saved which can be rendered to the page, unaltered, in any language, on any platform. This is a problem if the only thing the consuming platforms can get is the raw content to templating separately. They don’t need that – they need a bundle of content and rendering logic, cached to a string.

(Could these posts be pre-rendered and cached as HTML in some central location? Sure, but then you lose a couple things – searchability and any vendor-provided CDN or caching functionality – which we’ll discuss more below.)

The Need for Repository-Centric Transformation

These three examples both lead me to the same conclusion: I only want to do this early-stage transformation once. Here’s why:

The end result of these two situations doesn’t change post-publish. (Markdown renders to HTML, full stop.)
It’s relatively painful to do, computationally.
It would be a lot of work to re-implement and maintain this logic for more than one language or platform. (What if it depends on a library that doesn’t exist for a particular platform?)
Beyond the sheer workload, I really only want one canonical instance of this logic. (Markdown has many flavors. I don’t want developers applying their own preferred flavor to my source content.)

Think back to our car analogy – this is way up at the transmission level, right after power leaves in the engine. Late-stage templating is way back at the wheels. And once we start pushing content to multiple channels, this becomes a real problem. Remember: Each wheel on the car doesn’t have its own transmission. There’s one transmission, which all the wheels benefit from, just like there is content transformation we don’t want to repeat in each consuming channel.

(Consider the content from my glossary site. If I wanted to use that here, on Gadgetopia, I would have to rewrite all that wiki link parsing and expansion logic in PHP (it’s in .NET right now). Believe me when I tell you that I don’t want to do this.)

“Back End for Front End”

All the issues above aren’t problems if we own the entire content publishing apparatus, from start to finish. However, with the new crop of headless CMS, we often don’t. These are often SaaS systems, with which we interact through web APIs alone.

Note:
See The State of the Headless CMS Market for more on this.

Additionally, the vendors are frustratingly dogmatic in their desire to stay away from any templating, including “drivetrain” transformation. They refuse to touch it on principle, priding themselves on only managing raw content and leaving it up to the consuming services to template.

I was bouncing these issues off of a handful of vendors, and a couple mentioned that I should use a “backend for frontend,” or “BFF” as some are calling it. This would be my own infrastructure basically acting as middleware – it stands between the headless CMS and my website (or whatever). My website communicates only with my BFF, and it’s the only thing that talks to the CMS.

In this way, my BFF becomes my drivetrain. Consuming channels pull from the BFF and complete their late-stage templating individually.

This solves some problems:

We can implement our own endpoints in the BFF.
We can manage the transformation pipeline, doing some transformation in the BFF. (In the glossary example above, I could render and cache the wiki link functionality at the BFF level. A request for that rendered content would never even need to go further “back” to the CMS.)

But there are disadvantages too.

The vendor often has elaborate caching systems in place to support massive loads, and you’re paying for this – this is often a huge selling point in the value proposition. In these cases, you lose all of that, and now have to re-implement caching in your BFF.
In addition to caching, you lose all the benefits of the vendor’s API, most painfully the query logic. You effectively now have to re-implement their API, including the ability to search everything, and avoiding this might have been the reason to decided to go headless in the first place.
For the vendor, it whittles away their value proposition, and may even reduce their product to a glorified database UI. This is a perilous place to be. Data storage and related admin interfaces are not that hard to replicate, and if your value proposition dwindles, so might the reasons for keeping you around.

I’m not saying a BFF isn’t valuable and appropriate in some places, but when a vendor immediately punts to that “solution,” they’re basically saying: “You’ve pointed out a valid problem, and the solution we’re recommending neutralizes a bunch of huge advantages to our product that we sold you on. So fix that yourself…but continue to pay us.”

Clearly, this isn’t a panacea.

Possible Solutions

Support for early-stage transformation is not prevalent in the current marketplace, but some of this can be chalked up to the fact that the market is immature. “Headless” is an idea that has just lit up in the last few years, and most of these platforms are still under heavy development as they adapt to what customers want.

Most platforms will support some event-driven processing via webhooks. When content is published, some of these systems will POST the entire contents of the published item to a specified URL, which can then take actions either on external systems or on the originating system via its API (the second case study in this post describes how Contentful does this and provides sample code for receiving a webhook call).

Using these frameworks, we could transform an object. When News Article X is saved, a webhook could receive that request and expand the macros in it…but then what? What does the webhook do with the resulting data?

Ideally, we would push our result back into the content object itself, perhaps in a “hidden” field which editors can’t manage from the interface. With this, a content object might have a “Body” field and a “Processed Body” or “HTML” field. Consuming channels could use either as they needed.

Pretty quickly, however, we’re going to run into a couple annoying problems: (1) webhook recursion and (2) version proliferation. If I was to save this data in a field and republish, I might trigger the same webhook again. Additionally, I now get two versions of every content object when I publish, which can confuse auditing and governance processes.

What I’m not seeing in the market right now are either of these two options:

“Silent” saving/publish capability, which means the ability to save/publish and explicitly avoid triggering events like webhook calls. In the absence of this, I’d like to at least some explicit nod toward managing webhook recursion – some method of identifying when something has been published by the very webhook it’s about to call again.
An ability to save into the current version. Otherwise, you’re going to end up with an extra version every time you publish.

Clearly, both these situations are exceptions, but in the circumstances we’re describing, they’re exactly what they need. (Consider too that they exist in many other, more traditional CMS, so they’re part of the mainstream “CMS development toolkit,” so to speak.)

Barring this option, there’s a solution, which might be a little hack-ish –

We could update a “companion” content object. Meaning, we might have a “News Article” type and a “Published News Article” type. The latter would contain some extra fields to store the transformed result. When I save a version of the former, a webhook or event actually copies its content – along with some post-transformation data – to its “twin.” Consuming channels would only be allowed to access the companion object – the “Published News Article,” in our example.

What we’re doing here is sort of phantom decoupling. We’re pushing pure content into a separate location (really a separate object) from which we’ll allow delivery. (There’s some precedent here in ECM. Many of those systems have a concept of “workspaces,” and when content is published, it’s often pushed from one workspace to another.)

Another feature I’m waiting for a vendor to embrace is publishing “filters” which can transform content from management to delivery layer. The secret of headless CMS is that most of them are actually decoupled. You manage the content in one environment, and when you publish, it’s being pushed to another environment which is optimized for mass delivery. This usually means a separate environment on the vendor’s infrastructure, or in many cases, a full-blown CDN. So your content object is actually “set free” into a larger environment when you publish (I’ve measured in this Contentful – it takes a couple seconds to proliferate around the world into Fastly and CloudFront).

With this architecture, I’d like to see a publish webhook which allows me to affect what gets pushed into the delivery CDN. So when I publish content from the management environment, a webhook is called, from which I can return modified data. That data is what gets published. To use a terrible metaphor: published content is “bounced” off a webhook, and the CDN catches the rebound.

This would allow me to do some content transformation (adding expanded content to an extra field, for example), and publish the transformed version while maintaining the purity of the original.

I had some discussions with vendors around these points, and made a little progress when making my case:

Directus actually implemented a publish event hook for me (and sent me the commit to prove it). So you can now run a transform event when content is requested, but before it’s given back. My reading of their code (it’s open-source, remember) tells me that you could implement early stage templating through an event hook. That doesn’t necessarily cache, but it’s a step in the right direction.
One of the developers working on Contentful engaged with me in a running discussion about the idea of “metadata” on a content object. This is, simply, additional data that’s tacked onto content. It’s not versioned, you can’t manage it from the interface, and it’s not “first order” content, but you could use it to transform content and “attach” the result (for instance, the result of a transform) to be delivered with the content. This idea is just a discussion at the moment, but I like where it’s going.
The new version of Evoq(which will be “hybrid headless”) has a concept of “visualizers” which are methods to template content prior to delivery via an API. This means you can get the raw content, but also a repository-centric transformation of it.

At the core of these solutions is a desire to avoid the BFF we discussed in the previous section. If I can just do a transformation and get the transformed result somehow back onto the content itself then I get to keep two things which are critical to the entire headless value proposition: (1) the performance of their delivery environment (which I’m paying for whether I use it or not), and (2) their native search API.

Conclusion

Headless CMS wholeheartedly embraced the paradigm of “separate content from presentation.” I don’t fault them for this, but this can get destructively dogmatic in some ways. The leap from raw to presentation isn’t necessarily a one-step process. Rather, we should look at this as a pipeline or a drivetrain that refines content through a series of steps.

There is value in transforming content close to the repository, or progressively denormalizing content in such a way to increase manageability, performance, and consistency in the consuming channels. Headless vendors need to take some steps in this direction.

An Unofficial Guide to Whatever-as-a-Service

Fri, 10 Feb 2017 00:00:00 -0600

If there’s one overwhelming trend in IT in the last decade it’s that no one wants to sell you anything anymore, they just want to rent it to you. Consequently, almost anything will run “-as-a-service” these days.

SaaS is commonplace as a term, but it’s been over-used to apply to basically anything you do “in the cloud.” In the last few years, other variations on the phrase have been creeping in: namely PaaS and IaaS, but there are many, many others, and some other variations that should exist, but don’t.

The basics are simple. But, like anything, nothing stays basic and there are…complications.

The Big Three: IaaS, PaaS, and SaaS

First, let’s talk about the Big Three, which actually have official recognition from the National Institute of Standards and Technology (PDF) (NIST). Here they are, in increasing level of refinement/abstraction.

IaaS: Infrastructure as a Service. This is raw infrastructure – unadorned servers, load balancers, routers, firewalls, storage networks, etc. When you just fire up a fresh virtual server with nothing but an operating system, this is infrastructure. (And how do you pronounce this gem? The consensus seems to be “eye-azz” because the alternative is really awkward.)
PaaS: Platform as a Service. This is an environment pre-configured and intended to assist you in building a known thing. For instance, a company might advertise “CMS X Hosting,” with a preconfigured environment, ready with database services, all the right ports open, and a build job ready to deploy your stuff from source and produce an installation of CMS X. This is a platform, designed to let you build on it. The key is that you don’t need to care about the infrastructure – in many cases, you know nothing about the actual servers and storage that make it possible.
SaaS: Software as a Service. This is a vendor that delivers you the services of a piece of software. The most interaction you’ll likely have with it is to log into a web interface and do some configuration and maybe a little uploading. You interact with the software and know nothing about either the infrastructure or the platform.

Do you notice how those three definitions build on each other? Each level assumes the levels before it.

With IaaS, you’re the closest to the metal – you know about everything, and probably manually configured all of it (you nerd).
A PaaS environment certainly has infrastructure underneath it, but you’re abstracted away from all of it. You have all the tools to build the thing you want to build – whether it be an ASP.NET app, a Node app, an Episerver-powered website, whatever – but you don’t know the specifics of how that environment happens.
A SaaS environment is another level removed: you don’t even know how this magic software happens. There’s infrastructure, and a programming platform and environment, but you’re happily oblivious and you usually just click around an interface to achieve some goal.

In a conversation this week, Seth Gottlieb from Lionbridge helped put it in context like this.

A sysadmin can immediately relate to IaaS. They see the value and can be productive using it.
A programmer can immediately relate to PaaS.
A power user can immediately relate to SaaS.

At each level, the prior levels become like your parents’ sex life – you grudgingly concede that it exists in some form, but you really don’t want to know anything else about it and you would gladly pay money to not have to ever think about it.

Complication: Confusion of PaaS and SaaS

In the web development world, some of the stuff we refer to as “SaaS,” as actually “PaaS.” In general, we overuse the “SaaS” moniker.

The major push from vendors in the last few years is to get your websites in their environments, which means you build, but they host in a incubated environment designed specifically for their software. This is a platform on which you build stuff. These platforms have little or no value in their unadorned state.

There is SaaS in the CMS world, but it’s limited to systems that literally let you log in and interact with the environment as a software service. I’m thinking about systems like Squarespace and Wix. You don’t build in these environments. You simply use them.

And I’m wondering if this is the dividing line for PaaS and SaaS – do you build in it? The P in PaaS is “platform,” and a platform is a thing that supports another thing. If nothing ever sat on a platform, you’d wonder what it was for. So, if something is an environment in which we build, then it’s a platform.

Here’s an example of climbing up this ladder with Drupal:

IaaS: If you want a Drupal site, there’s nothing stopping you from getting a server at Amazon Web Services (AWS) and loading up Apache, MySQL, PHP, and whatever else you need, changing DNS and launching. You are now running on IaaS. AWS has provided the infrastructure, but you turned it into a platform and you loaded the software.
PaaS: Alternately, you could call up Acquia. They provide a platform called Acquia Cloud. This is a bunch of servers at AWS (you don’t care about the specific servers, remember, you just trust that there’s a bunch of them up there), and they’ve set them all up to run Drupal with a bunch of value-added stuff like search and really good dev ops and deployment models, which, with Drupal, can be tricky.
SaaS: Finally, if we step back in time a year, you could have used the now-defunct Drupal Gardens. These were preconfigured Drupal instances you could get by just creating an account and providing a credit card number. Naturally, there was a limited number of things you could do with them (they only had a handful of the most popular modules), and you couldn’t deploy any of your own code, but they were simple and quick.

(Related to this: Nasdaq just announced customized investor relation sites for its listed companies. Sign up for the service, and they’ll generate a custom, Acquia-hosted Drupal install, just for you. In effect, they have a SaaS product that stamps out PaaS environments which is recursive as hell.)

Finally, James Norwood from Episerver helpfully pointed out that differentiation between PaaS and SaaS it might come down to questions of tenancy: do you share your system with anyone else? If you don’t, then this is likely IaaS or PaaS. If you do, then it’s almost always SaaS.

It’s tough to share a building platform with anyone else because it’s easy to make a mistake and jack the environment up for everyone. Eventually, the vendor starts to segregate more and more, and the end of that line might be a completely sandbox, interfaced system which becomes multi-tenant SaaS.

Complication: Differentiating Between IaaS and PaaS

The big challenge for a lot of PaaS vendors is getting customers to understand the different between IaaS and their PaaS offerings. People are still in the mode of thinking about “hosting.” Basic hosting is infrastructure. But vendors are now “wrapping” hosting in a plethora of value-added services, which ostensibly bumps them up a notch to become a platform.

I talked to David Aponovich from Acquia, and he said this:

We see organizations investigating Drupal and Cloud and they’ll talk with Acquia and say, “So, we’ve decided to use Drupal over Sitecore and Adobe, but why do I need Acquia when I can just do a DIY on Amazon AWS?” And we say, well what about this, this and this, and they realize, “Oh, this isn’t just AWS infrastructure-as-a-service, there’s a lot more services and automation here – it’s a platform-as-a-service for my Drupal applications, not just services for infrastructure and hosting.” The development and a management services such as provisioning, deployment staging, and security are important.

Episerver has a PaaS product call the Digital Experience Cloud Service. Norwood articulates the benefits of it above and beyond “just” the IaaS that Azure offers:

At the end of the day, anyone can host a virtual machine on anyone’s public cloud (AWS, Azure, etc), and it will run, but it’s sort of just hosting in the old sense of the word. Episerver and many of our partners can sell you a license and then host and/or manage it for you on a public cloud, but that’s it.

With the approach Episerver invested in over two years ago now, we elected to go deep into the Microsoft Azure PaaS so we could unlock the benefits of the platform for customers as well, such benefits include elastic scalability, pay for use consumption, and application level SLAs above the infrastructure SLA. If your bet is to support every public cloud, as a vendor you get more reach, but if you go deep into the PaaS layer it’s the customer who benefits too.

That “crossing of the threshold” between IaaS and PaaS is something that vendors are having to sell people on, every day. Many people are still programmed to think in terms of simple hosting. It remains to be seen how well that definition changes.

As an integrator, I get a little annoyed with the “cloud” moniker, because it doesn’t mean anything, colloquially. In a strictly technical sense, “cloud computing” has a NIST definition (same link as above), but for most people, “cloud” just means “not my problem.”

At Blend, we host for lots of our clients. In this sense, we are as “cloud” as anything else because we make all their hosting problems go away. We host on infrastructure that we rent from AWS – pure infrastructure. But if we wrapped all that stuff in a bunch of Blend propriety stuff and created a gorgeous little incubator in which a website could thrive and grow, well, now we’re moving to a “platform.”

If you have “managed hosting,” that means someone else babysits it. Is that someone else the final value-add of the “platform”? Hosting yourself would be at the infrastructure level, but if someone else manages it for you and provides value-add on top of that (and you would hope they did, or else what would be the point), does the combination become a “platform”?

(There’s a much larger post here about how vendor PaaS platforms have encroached considerably on integrator’s service offerings, and there are some bad feelings as a result. But we’ll tackle that on another day.)

More fundamental to this particular complication is where we draw the line between infrastructure and platform. I remember getting servers back in the day with Plesk or CPanel loaded on them. These control panels managed dozens of other services on the machine – everything from FTP to SMTP. In this sense, did we have a platform?

Coming back to the idea of value-added services as the thing which moves us from infrastructure to platform, was all the stuff offered by CPanel- or Plesk-enabled servers enough to say we made that leap? They seem to think so – both their websites refer to their offerings as a “platform.”

Complication: Wedged Between PaaS and SaaS…Framework-as-a-Service?

Of course, you knew this would get blurry because it always does –

We build on platforms, but “building” is a vague term. We tend to think of building as having a completely self-contained codebase which we then push up to another environment. We even run these things locally, and when they’re running to go, we deploy them to some parallel environment.

But there are SaaS-ish (there’s always an “-ish”) systems that allow a limited amount of “building.” Take Coredna for example (yes, the capitalization is weird – it’s “Core D-N-A”). This is an ostensibly SaaS CMS system. I got a demo last week and I genuinely enjoyed what I saw.

Here was the best part –

Templating is not by configuration. This is not a “drag stuff around” system, like Squarespace or a Wix. In Coredna, you legitimately get templates written in Smarty, and you can use these to power your site. You can even point Coredna at your Git repo, and it will pull your templates from there, so you can work in an honest-to-goodness IDE.

This was refreshing to see, and I commend them for it.

More to the point: with an architecture like this, you get some form of pseudo-development or “building.” Smarty, for its part, supports looping and conditionals, which are two of the hallmarks of a logically complete language. Furthermore, Smarty knows if you’re fielding a GET or POST request, which means you could conceivably post forms back and do stuff accordingly.

Note:
Back in 2005, I discussed Smarty as a sub-language, “under” PHP. How prophetic.

At this level, we’re clearly “building” something. We’re working with code. We’re looping and we’re evaluating conditionals and we’re probably pushing the boundaries of a front-end developer and actual involving some server-side development logic. In some senses, this isn’t even “templating” anymore.

We’re building on Coredna in this sense, are we SaaS or PaaS? Clearly, Coredna exists as a discrete piece of software into which we authenticate and do stuff, but it also depends on a significant amount of code-building which we do outside the system.

I asked Sam Saltis, the founder of Coredna where he saw the system fitting in:

I see it as a SaaS platform. For me a PaaS still means that every site is a unique instance of business logic, sharing a common infrastructure. With Coredna we we have a common infrastructure like PaaS but we also have a common pre-built software layer that everyone uses.

In some senses, an argument could be made that this is PaaS, and Coredna is simply the top of the stack. It’s the thing that sits above Apache on the stack. It’s the final step in the “platform,” much like someone could argue that the ASP.NET MVC assemblies sit above IIS in a .NET platform. You have to ask the question, “how far do you have to develop the stack for the system to ‘graduate’ from PaaS to SaaS?”

(Beyond templating, I’m wondering when a SaaS system will take a deeper leap into scripting. There’s sandboxed JavaScript capabilities that are just begging to be put to use in allowing editorially scripted responses to events. I’ve even written one editorial scripting language – Denina – though it’s purely output-focused.)

And this is where we get to definitional bias: who decides where we draw the lines between the (1) infrastructure, (2) platform, and (2) software? Who decides where the “platform” ends?

There are a lot of systems that are easy to classify as SaaS, but are useless without a significant amount of site-building that looks an awful lot like programming. In these situations, the line between what’s the platform and what’s the software get blurry. Where do you draw the line between a piece of software and a code library?

In the end, something like Coredna sits in a weird space: it’s either “flexible SaaS” or “rigid PaaS.” How about something new – Framework-as-a-Service (FaaS)?

It’s clearly more constrained than a platform, but more configurable than simply software. Into this category, we might put other systems which support pseudo-development, like SharePoint Online (especially when combined with a development toolkit like Akumina) and Shopify, which you can manually template much like Coredna.

Complication: Component-as-a-Service

As the “as-a-service” suffix began to gain steam, we suddenly had vendors coming out of the woodwork laying claim to the model. I’ve seen:

Content-as-a-Service
Search-as-a-Service
Information-as-a-Service
Business-Process-as-a-Service

“As-a-service” has become a moniker for “anything you don’t own but you pay a subscription fee for.”

Many of these are things you might use in the building of something else. In this sense, they invert the above models. Instead of the subscription target being something you build “in” or “on,” the subscription target becomes a smaller component of a larger conceptual thing you’re building elsewhere.

Rather than a subscription being the over-arching framework, the subscription becomes a cog in a larger machine. Generically, we might call these things “Component-as-a-Service” (CaaS; because “Service-as-a-Service” sounds weird).

Let’s consider “Content-as-a-Service.” This is a suffix to which a number of headless CMS vendors are trying to lay claim. The idea is that content is a smaller part of a larger application, and you can abstract that away to a service.

I asked Artas Bartas over at Contentful if they considered themselves SaaS or PaaS, and this was his response:

I’d say Contentful is a SaaS offering. The way I see it, PaaS is a use-case agnostic platform that allows you build a wide range of applications without worrying about managing dependencies. Dev-focused SaaS platforms, on the other hand, are more selective in the types of use-cases they support and therefore, limit the range of applications you can build on top.

And this might be where we dip into the burgeoning world of “micro-services,” which is a paradigm of development whereby you divide your monolithic application into a bevy of tiny services, each doing one thing. Once you begin subscribing to these services, rather than building them, then you start looking around for “whatever-as-a-service.”

With Component-as-a-Service, we might be closer to fulfilling – on a grand scale – Eric Raymond’s dream of the Rule of Modularity from The Art of Unix Programming:

Developers should build a program out of simple parts connected by well-defined interfaces, so problems are local, and parts of the program can be replaced in future versions to support new features.

Conclusion

For many years, a guy named Shiva Ayyadurai (who’s married to Fran Drescher, weirdly) has claimed that he invented email. In fact, he sued Gawker Media and won a sizable settlement because Gizmodo said that he didn’t. However, many people feel that the recently departed Roy Tomlinson invented email. The debate rages.

But here’s the thing: to decide who “invented email,” you have to decide what email is. The argument becomes one of definitions, not necessarily actions.

The concept of “email” exists on a spectrum of functionality, from some encoded characters moving from one computer to another, all the way through the huge, bloated email clients we have today. At what point along that scale of innovation could someone step back and say, “yep, there it is – that’s this thing called ‘email’ and I just invented it.” The definition of a thing presumes a minimum set of requirements necessary to achieve that thing. Who decides those minimums?

I have no doubt that Ayyadurai invented something, but opinions differ on exactly what that thing was. He clearly believes his innovation can be summed up by the label of “email,” but not everyone agrees. To some, more features and functionality were required to cross the “line of definition” that constitutes email.

And the same is true of “whatever-as-a-service.” Agreeing what “whatever” is can be tricky, so splitting hairs about what constitutes infrastructure, platform, or software is subjective – even more so when you add concepts like “component” and “framework,” as we discussed above. Different people have different “lines of definition,” and arguments can be made regarding which lines a particular vendor crosses or falls short.

So, asking a vendor whether or not their offering is IaaS, PaaS, SaaS, CaaS, or FaaS is basically soliciting an opinion of where they see their product fitting on a disputed range of functionality, based on how they intend for their customers to use it.

Whether or not the marketplace agrees with that assessment is another matter entirely.

Note:
My thanks for David Aponovich, James Norwood, Sam Saltis, Artas Bartas, Seth Gottlieb and others who provided quotes and feedback during the writing of this post.

The State of the Headless CMS Market

Wed, 8 Feb 2017 00:00:00 -0600

Headless CMS is about to “tip.” It’s been gaining steam in the last few years, and 2017 looks to be its big year.

However, the market is vague and prone to definitional bias – in some senses, “headless” is whatever someone says it is. Additionally, systems exist somewhere on a range of purity and allegiance to a mythical “headless ideal.”

This post is an attempt to put some structure on the market, and define the options which (arguably) make it up. I’ve defined both specific headless offerings and “headless-ish” architectures.

For each, I provide some examples, but I clearly don’t know about every CMS in the world. This post is not meant to provide an exhaustive list. The examples are merely illustrative and a source for more research.

I’ve listed the categories in descending order of “purity,” meaning the extent to which the model aspires to be a pure headless system (and, yes, even what composes the ideal is entirely arguable).

What is Headless CMS?

“Headless” is an architecture or – even more loosely – a paradigm or belief. If we consider the “head” of a CMS to be the subsystem by which content is finally presented to the end consumer, a headless CMS is what you have when this subsystem is “lopped off.”

In a headless CMS, you have modeling and editorial tools to help you describe, create, edit, and otherwise manipulate content. But the concept of “publishing” content just means, “make it available via an API.” A headless CMS is a “content-focused datasource,” from which you can build content-based applications.

Headless is not the same as “decoupled.” A decoupled CMS is concerned with presenting content, it simply pushes that content into a delivery environment, separate from the management environment. That separation of delivery and publishing is something that headless and decoupled CMSs share, but the difference is that a decoupled system concerns itself with what happens in the delivery environment – for example, it has some concept of templating – while a headless system doesn’t. A headless CMS assumes developers have content delivery handled via other means.

A decoupled CMS is proactive – it prepares content for presentation and pushes it into a delivery environment. A headless CMS is reactive – it manages content, then just sits and waits for some process to ask for it.

Headless systems tacitly distance themselves from HTML and website-centric implementations. You can absolutely power a website from a headless system, but you can also power mobile apps, display advertising, business applications, etc. (See my prior post: “Use Cases for Headless CMS.”) Headless systems attempt to lay claim to “pure” content that can be repurposed and presented through multiple different mediums.

(Perhaps also read the definition of “coupling models” over at the Web Content Management Glossary.)

With that aside, let’s talk about what this market looks like as of this writing.

1. Pure Headless CMSs

Part of why the headless market is tipping is because “pure” players have entered it and are getting attention. They’ve defined the term and moved it from some improvised to something intentional.

Intentionality is an important point. If you’ve ever spent any time building a CMS, it likely consisted of an enhanced admin system to a relational database. The presentation of content on “the other side” was done through traditional methods (I first wrote about this model 13 years ago – CMS Administration vs. Presentation Languages).

In some senses, we were all building “headless CMSs” back in the day, before we got “more sophisticated” on the delivery side and moved on. This model was really the genesis of the modern CMS market. The difference is that vendors have now sprung up and effectively said, “This is okay. This is no longer a compromise. This is an effective paradigm of CMS, and we’re going to formalize and build on it.”

The leader here is likely Contentful, as it has funding, staff, and momentum. Contentful began as a system to store content for mobile apps (it was once called “Storage Room”), and thus had no web origins at all.

Like Contentful, Prismic is a hosted service, as is Butter CMS (seems to be blog-focused). Directus can be on-premise (it’s open-source, written in PHP) but offers hosted options for those who don’t want to manage it. (And new ones pop-up all the time: I just stumbled on Elemeno while writing this post…)

Also in this category, we have Gather Content. This has traditionally been a pre-implementation content aggregation service (a market it basically invented). However, Gather Content is seeing more and more usage by organizations using it for core content management, since the line between their original market and headless CMS is blurry. If you’ve structured, aggregated, and cleaned all your content in preparation for a CMS move…then you might already have a CMS, accidentally.

Also of interest is Kentico Cloud. You might think this should go below as a traditional/cloud hybrid, but it actually has zero relation to the Kentico CMS. It’s a scratch code, ground-up build of a new product that shares nothing with their existing CMS except the name.

2. CMSs with Specific Headless Subsystems

This is an odd category. What I’m including here is traditional CMSs complete with presentation systems, but that include some specific gesture towards headless usage, and which could be used headlessly by specific design, rather than just re-purposed to a headless use case.

The new release of Evoq (v9) will include the ability to manage content in a local installation and have that content pushed/synced to their cloud environment, where it can be accessed remotely by other processes. This is a unique model which ends up as a hybrid – clearly, serving a website is the primary purpose, but the model concedes that might not be the only purpose and provides a framework for access.

Ingenuix occupies a unique space as perhaps the only decoupled .NET CMS, so it’s accustomed to heavy remote API usage – if something happens a decoupled delivery environment that needs to be pushed “backwards” into the repository, then a remote API is how you do that. As such, Ingeniux has a separate middleware component called Dynamic Site Server (DSS) which you could conceivably use without bothering with decoupled publishing at all.

So, if there are so few vendors here, why include this category? Because I think we’ll see this more and more. I don’t think Evoq and Ingeniux will be alone here for long, and you’re going to see traditional vendors (the next category) adopt headless functionality enough to slip “upwards” into this space.

(A good example: one would expect the core Kentico CMS to connect to their cloud offering at some point, thus making that a hybrid as well. This is such an obvious pairing, that if they didn’t do it, it might feel a little odd.)

3. CMSs with Good APIs and Extensibility

This is where things get blurry and weird…

A lot of traditional CMS vendors are likely looking at the “headless” market with annoyance. Repurposing content out of a web CMS is not new – this is the essence of multi-channel publishing – and customers have been doing this for years now.

While almost all systems have local, language-specific APIs, many (if not most) systems also have remote REST/SOAP APIs to pull content from outside the CMS environment. In that sense, is this not also a “headless CMS”? By our prior definition it:

Models and manages content
Has no presentation component (for the specific act of pulling content through a remote API)
Is reactive, waiting for another process to retrieve content

Using a traditional web CMS through a remote API would look awfully like any pure headless CMS. Blend has done this with Episerver – a client accessed Episerver content via Ajax to power contextual help in their web application. And I’m hearing about “headless Drupal” more and more often.

Some vendors might have such a sophisticated remote API that they could conceivably not change a thing and simply start marketing themselves as “headless” and not be disingenuous at all.

Even if your CMS doesn’t have a remote API, some programming platforms make it easy to add this. My experience is mainly with ASP.NET, and I can attest that it’s absurdly easy (like, 10 minutes easy) to set up an XML or JSON endpoint to deliver content however you like.

Where you might run into problems is in more pedestrian things like licensing. Many commercial CMSs are licensed by website or, more abstractly, by consuming process. If you start scattering content around headlessly, a vendor might claim you’re violating the licensing agreement. It will be interesting to see how licensing adapts to this, either proactively or by customer demand.

Also interesting will be to what extent traditional CMS vendors alter their marketing to address the headless market. Some vendors are already marketing against related search terms. Here’s one such landing page from dotCMS touting the “API at its core.” Here’s another from Hippo taking the opposite tack: explaining why headless CMS is “wrong.”

I’m wondering how antagonistic or conciliatory traditional vendors will be with their marketing. I know of one vendor that refuses to promote their system as “headless” because it “helps the [headless] cause.” As more and more customers go headless, will the existing market align or distance itself?

4. Enterprise CMS

The “old guard” of content management is traditionally enterprise systems (ECM) like Documentum, Alfresco, Nuxeo, and even SharePoint. These systems are primarily concerned with managing content and have very little capacity for content presentation beyond the administrative interface itself. These systems are so management-focused, that most presentation functionality is only to make management and administration easier.

Many also include remote APIs to manipulate content, which raises the question of whether or not they fit the headless model? Content could easily be modeled and managed in something like SharePoint, then accessed externally through a headless layer like Akumina’s Interchange, on-demand and real-time.

The idea of this, however, might make ECM people a little nervous. ECM systems have traditionally been treated as “behind the firewall” systems, and they’re not normally built or secured for high-volume performance like public web serving. Web publishing out of ECM has historically been decoupled.

An argument could be made that you should put a public caching layer in front of this, which would fit the same model as something like Contentful that pushes to a global CDN, or some of the headless Drupal architectures we’ve seen which push content into an intermediate datasource (my experience was with Drupal pushing to Mongo, then that being pulled by a Rails app).

But does this blur the definition even further? If your back-end “headless” system is pushing into an intermediate layer (like you would do with ECM), then are we still headless, or are we really decoupled? Traditional decoupled systems have pushed HTML assets to the delivery environment, but pushing database records is not unheard of. I talked about that in an older article about decoupled CMS (still highly relevant to this subject) and I presented a couple CMS-to-SQL case studies just a few weeks ago.

Conclusion

All of these above might have brought us full-circle: any datasource might be considered as a headless CMS, depending on (1) how much you’re willing to ignore any built-in presentation systems, and (2) to what extent you consider an intermediate caching layer as part of the system itself.

Headless will remain a gray area, I think, defying strict boundaries. Systems will be “headless” to the extent that they fit the barest profile of that paradigm, can be re-purposed or modified to fit it, and the vendor markets them as such.

One traditional CMS vendor I talked to in putting this post together says the market will hinge on whether or not pure headless vendors pursue a blue ocean or red ocean positioning strategy. Will they attempt to fight it out in the same market as traditional CMS (red ocean), or will they attempt to embrace their differentiation and create a new, open market to conquer (blue ocean).

I suspect the latter is probably the wisest choice. But, I also know that a lot of vendors like a good old-fashioned street fight – in the world of technology, it’s a sadly rare vendor who’s willing to admit that anyone else does something better than they do. The history of this industry is littered with vendors wading into markets in which they had no business being. Time will tell whether vendors do the same here.