Daniel Bachhuber shared an interesting post last week, about the bifurcation of content management and delivery. Or, in humanspeak: managing content and displaying it are really two separate things, and they’re usually bundled in what we call a content management solely because the management part is considered to be a trivial thing (just some text boxes to enter and edit content and a way to slap tags on your content) or because we want something that works out of the box, without having to mix-and-match different components.
I wouldn’t call what’s happening with CMSes a bifurcation though, like Deane Barker (the author of that blogpost) does. It’s more like having ten different little back-end pieces, with a single presentation layer that can create a uniform experience out of such a mess of individual parts.
Which raises an interesting puzzle that neither Matt Waite, Sean Blanda, Matt Thompson or Ian Bicking, the gurus of the post-CMS world, seem to be talking about. And that question is: what would the ideal web delivery platform look like if our priority was to help us piece together different components, not build everything into a single app like, say, your average Drupal install. Existing CMSes aren’t built for that kind of environment, so we don’t just need to complement the CMS by leveraging different best-of-breed tools each with their specific focus, we actually need to replace the CMS with some kind of presentation layer software that’s better suited to the new distributed reality.
But what’s the role of that new kind of CMS, or presentation management system or web publishing tool or however you’d like to call it?
First off: presentation tools can have a vastly reduced scope. Little apps are or will be taking care of all sorts of things that traditionally a CMS would do, like categorizing content and managing comments. In particular for newspapers, content creation will probably happen elsewhere, too, and it’ll be stored in a platform-neutral way, because that way the same content that ends up in a CMS can also be used in print.
And secondly, the defining feature of a great post-CMS system will no longer be how well it manages content or even how easy it makes it to produce content: we’re taking care of that stuff elsewhere. Instead, the most important criteria in deciding the worth of a web publishing tool become:
- how well it can aggregate and sometimes manipulate or clean content from a ton of different places
- how well it plays together with external apps
- how fast it is and whether it can cache bits of content that take a long time to load
- how easy it is to apply a consistent visual theme to that content
“The home page is merely a master aggregation of this confederation” as Matt Waite argues.
Among newspapers, The Guardian is perhaps furthest along the CMSless path: many parts of their website are driven by a whole bunch of search queries that fetch information from an internal search engine, which in turn grabs its content from an internal content creation tool (the vestige of what you’d traditionally call a CMS), plus a theming layer to display those search results in a pretty way.
So what the future needs are powerful content ingestion tools and quick and easy ways to display that content in the style that you want, not yet another CMS. That’s what I’m betting on.
6 comments
After reading your reaction, the question I have now is this: does this presetation application live under the control of every news organization, or on the user's desktop?
Really, what I think we're talking about here is the personalization holy grail. What I'd love as an end user is a way of recording everything I consume so I'm only introduced to the most insightful, freshest information. And not bashed over the head with repeat headlines on the news of the world whathaveyou or similar.
Related: I watched the BBC for a couple of hours while I was sick last week and could not believe how often they repeated the headlines.
The dream for me as a user is a personal data store tracking my reading habits that I can present to each website. I don't know how much of a foul ball reality that is.
Maybe we should fix commenting first to keep commenters on point? :)
I'm on board with some of the ideas, especially that systems need to allow for exchange, but I think post-CMS is premature or maybe unwanted.
The hard part is that we have not yet settled on the kinds of units of data that will make up media and how to add useful metadata effortlessly.
So before we move away from "managing" we must explore what it is to create, manage and present.
On the larger scale, CMS's may become less sexy, but the way large sets of data are stored will very much affect how programs can talk to each other. As we move toward the we semantic web the role of a good CMS will shift to being able to not only capture the story of the user, but tie the story to other useful data from other pools.
Finally, CMS's have proven highly extensible so far. Let's see where developers pull these elastic systems next.
Oh, and shout out to Sean B and Matt T!
@Daniel: on a somewhat related / somewhat unrelated note, what I'd really love is if the industry could agree on a common format to indicate follow-ups, corrections and updates to a story (e.g. a rel='updates' feed on a story page), coupled with a GearMonkey script that autofollows update feeds for every page you've been on for longer than a minute and displays those similarly to Facebook notifications or in a daily/weekly email digest.
Instant fresh information about all the stuff you've shown you care about in the past. Me want.
@Ben: premature? Most definitely. We're talking 5-10 years down the line, but I think it's coming. I would disagree, though, that CMSes have proven highly extensible: you can coax pretty much anything out of a Drupal install, but that doesn't mean it'll actually be any good at any of it — that's why so many people have a love-hate relationship with their CMS. We can either try to extend CMSes yet again to accomodate a new way of doing things, or we can start afresh and throw away a lot of harmful preconceived notions of what a CMS should be like.
I very much agree, though, that we can't forget about the management side. It's just that 15 years of CMSes have given us little more than tags and categories and custom fields. A split between management and presentation applications may encourage more innovation in the content management sphere.
@Stijn I actually agree with the extensibility critique. I think devil's advocate got the best of me there.
And a split could be a very good thing IF that split includes a robust middle layer of both software and people working to make sense of the presentation of the data.
In that sense, I believe the post-CMS CMS will be what we currently think of as aggregation, social layers and curation.
Hi @daniel, I wanted to share that there are a bunch of companies building personal data stores :) yeah! Two of them have a particular focus on supporting people "tracking reading habits" via the web. egoArchive and Azigo. Azigo explicitly wants to support users sharing their preferences with publishers to allow for permission based targeted ads basically. This is an alternative to third party cookie tracking as the way to know who a person is and what they might be interested in.
The BBC is also doing some incredibly forward-thinking work in this area. For example, if you read about they way they used semantic data to pull together their World Cup coverage, you'll get a sense of the tip of the iceberg of where they're hoping to go in the future with these kinds of RDF-based collections of content.
Beyond that, though, you're right about the need to explore beyond the monolithic CMS approach. I'm surprised that more Django-istas haven't explored a distributed approach, given that the whole 'micro-app' philosophy is kinda' baked into the core of Django (i.e., the Django Admin app, etc.).
Having purpose-built apps that either play nicely together (an 'app swarm'?), or that provide a standard http-based API, makes more and more sense as the speed of innovation accelerates, and the need to quickly develop new functionality increases.
-- Philllip