On Functionality as Content…

I’ve been thinking lately about logic as content. Meaning, the codification of decisions and analysis as something that can and should be managed as editorial content.

I used to love text adventures. I played Zork quite a bit when I was a kid. That game is a combination of text content and logic. The author both wrote the description of a place, and then made logical decisions about what happened when the user wanted to do things.

These logical decisions – where do they live? The concept that going East from the Forest leads to you to the top of the Canyon isn’t something you write narratively, but it’s absolutely something you decide EDITORIALLY. What do we do with this logic?

I maintain that we need to start identifying “editorial logic” like this, and we need to manage it like content.

Let’s say you have an integration from your HR system to your intranet. When an employee is scheduled for a job change, you automatically make an announcement on the Monday after the week in which the change occurs.

“The Monday after the week in which the change occurs” – that’s logic. It’s… “content logic” or “experience logic.”

If that logic changes, is this a development task? I maintain it shouldn’t be. That schedule is a content/experience decision. It should be made and managed by editors. It needs permissions, versioning, version control, workflow, and all the other services we apply to content.

I had a consulting client once that had productized a set of rules around a common industry process. Their customers subscribed to these rules, put them in their enterprise ERP systems, and used them to save money (sorry, but I have to be vague here).

Those rules were pure logic – “When X occurs, check Y, and if it was Z days ago, then do …something” – but that’s also CONTENT. This logic was managed by a team of …editors, for lack of a better word.

I’ve done a fair amount of research, writing, and speaking around scripting logic in CMS (and applications in general). But those conversations tend to get bogged down in specifics, like languages and execution environments.

I just want some acknowledgment or acceptance of the idea that someone’s experience of your content is both a product of the content itself, and often of rules and logic that act on that content and on the user. As we move further into “low-code” and “no-code” development processes, we need to start moving this logic to “editor side,” and managing it with the full array of services we give to other content.

This is item #23 in a sequence of 58 items.

You can use your left/right arrow keys to navigate