Why you need an off-label prescription to alleviate the pain of managing your content

It’s time to get real about how we talk about content technologies, particularly about content management technologies. The content industry has a naming problem. The problem is not just about the semantics of how we name things – the frustration of sitting through a meeting where a group of professionals argue vehemently about “templates” only to discover that each profession defines the term differently should not be minimised. The naming problem here is about the expectations that go along with each name.

Content management systems actually don’t manage content

Let’s start with the CMS (Content Management System). Here’s a case where the S doesn’t actually M the C. If we look back at the history of these systems, we get a better understanding of how this misnomer came about. In the mid to late 1990s, organisations started building websites. They may have been rudimentary compared to today’s standards – just HTML and some hyperlinks, really. The sites were built based on the assumption that they were static, but of course, it soon became apparent that content continually needed updating: a date here, a typo there, a new piece of information.

I was one of those people who built basic sites for my entrepreneur friends, and the constant stream of phone calls and emails asking for “just a little change” started to get overwhelming, and I started referring site owners to webmasters (remember that job title?) to maintain.

The webmasters had that same annoyance with constant requests for changes, and they started building some basic interfaces that would allow a site owner to make content updates themselves. These interfaces were never meant for actually managing content production; they were meant for managing content publication – simply for putting the finalised copy into place for presentation.

In their defence, the concept of “content management” could seem logical to a profession where content seemed to spring into being, fully formed, ready for publication. But this is the same profession that decided that, in Excel, the opposite of “Hide” was not “Show” but “Unhide”. In other words, semantic accuracy is not the forte of technologists.

Where content management really happens

This set the stage for the next two decades of misnamed content technologies. We already had “word processing” software such as WordPerfect and Microsoft Word. As that class of software got more sophisticated, software such as FrameMaker were more accurately called “documenting processing” software.

This is the real place where content gets managed. Content gets written, re-written, marked up, moved around, moved back, moved back again, commented, edited, and eventually finalised as “good enough”.

The Web became the gateway to componentised content, where HAT (Help Authoring Tool) software let content developers, specifically technical communicators, create content in stand-alone modules (topics), smaller components (references) and even smaller components (variables), and then deliver the content into either online help systems as a series of topics, or aggregate the topics into larger units, usually some sort of manual.

Anyone who understood how a HAT worked soon realised that the software could be used to speed up the creation of any genre of content that traditionally got managed in cumbersome ways. Proposals, reports, resumes – anything that has standard boilerplate combined with changeable chunks of content, and the need to change little bits of content, like changing a company name in each proposal.

Yet, this incredibly powerful tool for all sorts of business content never took off outside of online help. Why? You guessed it, the name “Help Authoring Tool” sealed the fate of this software. The lack of imagination or understanding of software buyers about the potential of the tool solidified the perceptions of its limitations by what it was called. I say this with a bit of smugness, as a recent search on “Proposal Management Tools” turned up a system with functionality and an interface that looks exceedingly similar to a HAT.

The difference between a CMS and a CCMS

Now that a lot of product content is produced in components, the situation becomes even more confusing. The term, CMS, though firmly embedded in the lexicon of content technology, actually does not manage content – at least, not the way that content developers need to be able to manipulate text during the writing process.

I say text because we wouldn’t expect photographers or videographers to manage their content in a CMS; we know that they need software that allows them to do functions that are outside of the capability of the CMS, and then put the publication-ready work into a special CMS, a DAM (Digital Asset Management) system.

What seems to escape CMS vendors is that content developers creating text-based content need special functions, too. That’s why they tend to work outside of the CMS, and reserve the “S that doesn’t M the C” for copy-and-pasting publication-ready content.

Then, a game-changing application came along that really, truly let content developers manage content. Not just manage content, but manage it in highly sophisticated ways. The learning curve was steep, but once content developers learned how to use the software, they realised how accurately, easily, and efficiently they could manage content. Feedback such as “I could never go back to working in Word” and “our team of two is doing the work of six, with time left over” was quite common.

This time, the name of the software is dead accurate: a CCMS (Component Content Management System). Finally, a system for content developers that can actually manage the content components!

When a name limits software adoption

Where this gets interesting is the reaction of stakeholders in the industry when it comes to adopting the software. The name of the software definitely affects the perception and ultimately its adoption. For each audience, the conversations are oddly similar with similarly detrimental outcomes. 

Conversations with content developers go something like this:

• Content person: How can I intersperse universal and product-specific guidance, managed from a single source, and show users only the content that’s relevant from them based on the product they’ve bought?
• Me: Oh, there’s already software out there that can single sourcing and apply semantics for multiple outputs. It can take care of this problem and do more things that you hadn’t realised that needed fixing – like making the source easier to manage.
• Content person: Oh, really? Well, we can’t use that software for what we’re doing. According to the website, that software is to create content that’s different from what we produce.
• Me: Does it really matter what the name of the software is, as long as it has the features that you need to solve your problem? 
• Content person: It looks complicated – we want all the power without the steep learning curve.
• Me: *deep sigh*

The vendors don’t help themselves with how they position their brands. The conversation with vendors goes something like this:

• Me: I have a client that could really use your software to multichannel publish multi-variant content for a bunch of websites.
• Vendor: We do exactly that for technical documentation and product manuals.
• Me: There is no documentation involved, let alone technical manuals. You need to show how you can switch up content in these specific ways and how much more efficient that is.
• Vendor: Sure, your use case sounds completely doable with our software.
• Me: To them it will feel very off-label. How will you get their imaginations to make the leap from technical documentation to marketing content on desktop and mobile sites?
• Vendor: Ummmm, but our demo is set up for technical documentation. We can show them that.
• Me: *deep sigh*

The conversation with the technologists is a little different, but they act as firm gatekeepers

• Me: The missing piece in your content ecosystem is an authoring environment. What you need is some sort of CCMS (Component Content Management System).
• Techie: We have a CMS.
• Me: But you don’t have a CCMS. It’s not the same thing.
• Techie: I told you, we already have a CMS, and if it’s not that, the content people don’t need it. We are the technologists here.
• Me: *deep sigh*

(There is an entire subplot that demonstrates the parallel universes of the Web-based technologies – fill in a few form fields, add some metadata, and you’re good to go – and the XML-based technologies – needs far more planning but has far more power – but that’s a whole other article.)

Software by function or by genre?

Vendors think narrow – they’d probably say focused – thereby locking themselves into a particular content genre. This is a little like marketing Final Cut Pro as film editing software for a single genre – say, only for science fiction or comedies, or saying that Microsoft Word can be used to write articles and poetry but not screenplays.

Because vendors aren’t thinking of all the ways that their technologies could be used, the CCMS has remained largely in the domain of “technical documentation”. Even the term “documentation” rather than “content” signifies an aging way of working: producing manuals, using PDFs, and so on.

The same naming problem applies, perhaps to a lesser extent, for other classes of software. Consider PIM (Product Information Management) systems. They are good at managing data but not as good at managing content. When I asked a vendor how their six-figure software managed multiple products with the same description, the answer was a matter-of-fact “just copy and paste”.

Digital asset management systems, on the other hand, do what they says on the package: they manage objects (in the content world, those would be the equivalent to documents). Translation management systems also do what they say on the label: they manage the translation of content between languages. Again, when the software is named for what it does rather than for which genre, it’s less confusing for customers and easier to market by vendors.

If I were to keep going, I could create a long list – but this is an article, not a book. And speaking of books, a book has been written on the topic of how content management systems have failed authors. Rick Yagodich wrote Author Experience: Bridging the gap between people and technology in content management back in 2014, and not much has changed since then.

The challenge to vendors and adopters

The challenge to would-be adopters of technology is to think outside of the box. Much like we use medication “off-label” – the way that botox was originally used to treat strabismus (crossed eyes) but is now a beauty-industry staple for wrinkle-control, we should be looking at the suitability of the software to solve the problems at hand.

After all, I’ve seen misguided attempts to use Confluence as an authoring system, a subpar Translation Management System as a CCMS, and don’t get me started on off-label uses of GitHub for many things related to content. It’s not that I’m anti-GitHub; I just realise its limitations.

When other technologies could make a difference to the operating models of content production, there is a strange resistance. Actually, perhaps the resistance is not so strange. The reason that GitHub and Confluence get used off-label is because the techies, though they are unfamiliar with how content works, are familiar with those software packages. It’s easy for them to take their limited understanding about content production and match it to features that they think will get the job done.

However, the assumptions about the complexities of content generally fall short of reality. It’s time to involve the content people, to get an understanding of what they really need, and then look further afield for software that actually does what content people need it to do.

The challenge to vendors is to stop limiting their potential market by defining a too-narrow set of content genres that the software can handle. The business benefits are eventually user-facing – better user experience, faster time to market, and so on – but the operational benefits get ignored in the process. The business benefits are hobbled unless the operational side is activated. The same functionality that allows for publishing variants of technical manuals is the same functionality that allows for creating easy variants of training material, marketing proposals, sales contracts, and many other non-technical documentation.

There are single-purpose systems for proposal management, contract management, and so on, but limiting a system for production-grade content to a single genre does not do the software justice. Take a page from conversational clouds. These AI-driven chatbots could apply to multiple industries, and are described for what they can do across many verticals. 

As the complexity for producing and delivering content increases, so does the need for powerful tooling upstream from delivery. It’s time to alleviate the pain of managing content, not just at the delivery end but throughout the content lifecycle. The tools are there, and the market is certainly there; the challenge is getting the offers and benefits to align.

---