Is your content having an identity crisis? Does it know what it is?
When elements of content become individual entities, separate from the environment in which they are presented (which is the whole point of a CMS, but that’s another story), the need for awareness of these dependencies becomes critical to the “management” part of the CMS.
Most vendors will tell you that their systems are aware of content dependencies: if you create a new page, with an image in it, publishing the page will also publish the image. Hey, the page is aware of what its dependencies are; what more could you want?
Two sides to the story: who needs who?
Real dependency awareness is far more than the fob-off version many vendors claim in order to tick this box. Yes, a parent element needs to know what child elements it requires to present properly (top-down dependency). But, as with most things, there are two sides to the story.
Dependency awareness comes into its own when the child element is aware of all the parents it may have (bottom-up dependency). When you delete the above-published page, should you delete its resources, or are they still used elsewhere? Only when aware of every place it is used can a resource know if it is orphaned or indispensable – only when there is bottom-up awareness, as well as top-down, can a content management system keep itself clean.
It’s a workflow thing
You might think this is just a nice-to-have: that I am pushing functionality your CMS can do without. After all, you have survived without it so far. If all you use your CMS for is a blog, or a micro-site, then it is a feature that you probably don’t need. If, however, your CMS drives a more sizeable – multi-channel – site, and you cross-sell between parts of your information portal, then bottom-up dependency awareness is the balm to ease many of your workflow headaches.
The authoring process
When editing an element of content, it is important to know where it is used, and in what context. That information will determine how you edit it. Will you need to fork the content, with some instances being changes in one way, and others following a slightly different route? If we are reusing content – as we should – this awareness of everywhere an element is used becomes critical to good management. (It becomes even more interesting when the awareness can flow through contextual filtering or custom functionality.)
This also applies to content removal – if you remove an element from a page, is it used elsewhere, or is this the last instance of use? Keep or discard?
The publishing process
The act of selecting one element of content to promote to live should also trigger promotion of any top-down dependencies, irrespective of where they are within the content store. This top-down dependency promotion must be recursive, too. The benefits here are immediately obvious: one action triggers the process; the content manager does not need to individually select everything that needs promoting.
The effect on workflow of bottom-up dependency awareness is two-part.
The first is the simple one of keeping a clean house: keeping assets when one top-down dependency is removed, but another still exists, but removing then when the last page that used them is gone (bottom-up tells the content that its last dependency is removed).
The second part applies specifically to sites that employ front-end caching: when a resource is changed, every page that uses that resource will need to have its cache cleared. With bottom-up dependency awareness, this is painless. Without, it requires either the entire site cache to be rebuilt, or someone to manually track the dependencies and indicate all the items to be cleared from cache; neither of which options make any sense.
Why is it so hard?
On the surface, providing bi-directional dependency awareness shouldn’t be too hard. It’s a data reference. The system is full of them already. So why do most CMS’s struggle with this issue?
The first reason is one of poor data design. If the dependency reference is a part of the parent, then finding all references to a child would require parsing the entire data store (think unacceptable performance). This could be overcome by including the bottom-up dependency reference as part of the child, too, but that would involve data duplication: a programming cardinal sin.
Poor context model
For those CMS’s that use a rational (relational) content model which allows the dependency to be studied from both sides, one failure point is likely to be in following dependency through contextual filtering. The issue here will usually be that the contextualisation model does not match the content model: it is a layer that works on its own logic, so the two parts cannot communicate efficiently.
The third issue is perhaps the most prevalent: implementing the technical mechanisms to make use of dependency awareness (for publication), or intuitive interfaces that can display complex dependencies (for authoring) is a lot of work. It may well be one of the largest single pieces of work associated with developing a content management system. And, because no one else is bothering to do a good job of it, everyone thinks they too can get away with removing it from scope in order to get their product out in time. The workflow experience of those tasked with managing the content is not given the consideration it should be. (I am giving all CMS vendors the benefit of the doubt here and assuming they actually considered these needs…)
Depending on dependency (the conclusion)
Content management is not exclusively something you do to your content; your content should assist you in this. Your content needs to self-manage. Bi-directional dependency awareness is the mechanism that allows your content to know itself.
Are all vendors as bad as each other on the dependency awareness front? No. Some can just about handle a top-down dependency when the child is a part of the parent’s definition, whereas others only fall short on contextualised bottom-up dependency. (I have yet to see a CMS that handles dependency awareness through its context engine, and through custom controls.)
If you are selecting a CMS (for a large site), then ensuring dependency awareness should be high on your requirements checklist. The pain of fighting for this will be far less than the pain of poor workflow experience if it is lacking. And do not accept a vendor’s claims regarding this – get a demonstration of it from the authoring and publication perspectives.
If you are a CMS vendor… Stop cutting corners. Full dependency awareness is critical to maintaining a clean information environment in a contextual world. Or keep cutting them, and put yourself out of business.
Content’s identity crisis, by Chris Shipton – @ChrisShipton