Last week, I caught the tail-end of an interesting Twitter conversation between @martinstabe, @markng, and @chrised – regarding the inability of most Content Management Systems (CMS’s) to deal with various non-standard content types. This is an issue faced by every online publisher, and is felt most by more traditional publishers who tend to a) have an old CMS platform that was bought many years ago, and b) not employ many development staff to build out new features and functionalities.
A few key quotes from the conversation to kick off:
- By @martinstabe: “We’ve been building all of our data apps external to the main CMS, latest eg : http://bit.ly/bjRnEx #yam”
- By @martinstabe: “Inability to deal with structured data remains number #1 editorial CMS problem”
- By @chrised: “Is it a CMS issue? Might be better handled through data access + presentation plug-in?”
- By @markng: “structured data should be woven into news +advertising in a way that isn’t possible with external plugins and widgets.”
I also came across this Washington Post article, which bemoans their lack of elegant delivery of government data, and says their audience deserves better!
The Post knows it’s lagging. Old technology and short staffing are to blame. Raju Narisetti, the managing editor who oversees the Web site, said its decade-old content management system “can’t really handle a lot of the databases and open-access information.”
And its not just government data that causes problems. Using our semantic extraction technology, we are building a topic-based news portal for a great client, but have found that no mainstream CMS does what we want it to do. Content Management Systems are mostly orientated towards the management process, not the best delivery of news. To have fully integrated semantic data is as much a workflow issue as a delivery issue. All existing mechanisms are about augmenting the delivery in some way, mainly because workflow integration is too tricky. CMS’s are generally big, old and slow; therefore they are built to handle news as it used to be organised, that is, chronologically, by department or by source.
The fundamental issue is that CMS’s are too vertically integrated, much like newspapers. They have tried to solve the whole problem, and therefore have not been flexible enough to adapt to new nuances.
To keep pace with innovation in news format and content type, the best approach is to use use a “platform” approach where system elements can be quickly interchanged, and there are internal APIs to allow for flexible communication between layers.
When the content is separated from the presentation layer, it becomes just one of many possibly input options, alongside and potentially intertwined with government data feeds, externally aggregated content, semantic metadata, geodata, and much more!
Also, the website becomes one of many different output options. With a well-structured API it is quick to deliver new channels, interfaces, partnerships, and even to offer a content and/or data service via API to the wider development community.
The fact that CMS’s are too vertically integrated is an exact reflection of how news organisations find themselves. They have been so focused on the overall “content workflow > print production > distribution > advertising sales” process that they have missed the fact that that the publishing monolith is now broken up into several separate new markets, each with innovators and necessity to change. And that main issue when reorganising, is breaking the publishing process into separate spokes for content creation and content delivery.
News organisations are slowly realising that delivering “data as news” is vital to defend their position as the go-to resource for up-to-date information and analysis.
We are building some very interesting solutions to the above problems for several brands and publishers, and I will post further with more details about our approach and findings.