Beyond Web-Centricity in Content Management
Here’s the problem with Web content management: sometimes we (as Web developers) get too caught up in the “Web” part. Sometimes we get very Web-centric about our content, when we really should be looking at content from a completely presentation-free perspective.
(Fair warning: if you’ve working in ECM – enterprise content management – to much of any degree, this post is going to be a review.)
Consider an intranet. A company decides it needs a centralized “announcements” system – a communication vehicle to get information to various people in the company.
So, they grab some Web content management system and start adding “announcement” pages. In doing this, they need to specify things like menus and META tags and other Web-centric things. It is, after all, a Web content management system. We’re Web developers, and this makes sense to us – we view “the page above all.”
But, is this is the right way to do it? It strikes me that an “announcement” in the context of the enterprise doesn’t necessarily correlate to a Web page. It’s really a pure…nugget of information, uncorrupted by presentation. It has properties like a title, a body, an author, etc. that are universal. They transcend presentation.
So, what do you call a piece of information, unencumbered by concerns about its final destination(s)?
I think you call this – gasp! – content.
Dealing with our announcement in its most pure form, we can isolate the properties of it that are about it, rather than its presentation:
Title
Body
Publish Date
Expire Date
Effective Date
Author
Intended Audiences
Subject (a taxonomy assignment, perhaps)
Tags
These are all properties of the content that have nothing to do with how the content should appear in any particular medium. They are universal properties.
Now, I know what you’re thinking – isn’t this just the classic concept of separating content from presentation? Well, yes. But as Web developers who spend most of their time in WCM, we’re always viewing presentation through a Web-centric lens.
Why do we want to separate content from presentation? So we can make different content appear in different places on the site. Or so we can re-arrange a template without having to change any content. Or so we can have our designers work on HTML-ish markup while we devise a method to drop the content into to it.
But what if a page on some Web site isn’t the primary method of presentation? What if the content isn’t destined for a Web page at all? What if it will be consumed by end users in a half-dozen different formats, none of which involve a URL-addressable bit of HTML?
Back to our announcement, let’s consider for a minute all the things that could happen with that content. Assume, for this discussion, that this piece of content is about the north parking lot being closed on Friday for re-surfacing.
It could…
appear on the intranet.
be emailed to an internal mailing list.
be syndicated in an RSS feed.
be emailed to a third-party (the contractor, perhaps?)
be posted to an internal calendar.
be published in a department’s print newsletter.
appear on various LCD TVs around the building.
appear in other system – an interstitial login window (“Important Announcements!”) when customer services reps sign in, for instance.
be transmitted to other parties via a Web service or other method (press releases go to PRNewswire or something)
be sent to mobile devices via SMS.
Of all those options, only the first one has anything to do with a Web page.
In this case, what you want to see is the “announcement” be handled as pure content, then editors can add “presentations.” These presentations represent appearances of that content in various places and various media.
Each presentation has type-specific information that needs to be collected – information that’s not specific to the content itself, but specific to the medium in which you want the content to appear.
For example, if we have our pure announcement about the parking lot resurfacing, we can then choose to expose it to various presentation layers
We want it to appear on the intranet, so we add a presentation for that.
Presentation-specific properties: the section it should appear in, the title that should display in the navigation
We want it mailed to all staff, so we add a presentation to an internal mailing list.
Presentation-specific properties: the mailing list to send to, the “from” name and email, the priority
Our IT group uses RSS feeds a lot, so we add an RSS presentation
Presentation-specific properties: a list of RSS feeds it should appear on
We want it to appear on some of the flat-panel TVs in the building, we add a presentation for that,
Presentation-specific properties: the locations in which it should appear, the frequency of rotation in those locations (we decide to double the frequency on the flat-screen behind the receptionists desk in the north building – the building with the most people who park in that lot).
In this sense, we’ve created our pure bit of content, then we’ve linked it to several presentation mediums. Each presentation requires specific information about how to present the content – for instance, the intranet page needed META keywords, whereas the mailing list required priority.
Admittedly, all of this is a little specific to the enterprise. In a larger company, there are a lot more opportunities for presentation. There are mailing lists, and print newsletters, and the flat-panel TVs, and such.
For a public Web site, we obviously have HTML and RSS, and often email as well, but that’s about it.
However, here’s the story about how I came to write this post which will demonstrate why this is somewhat important for Web developers –
I was contemplating a new Web site for my son’s soccer team. In discussions with the parents and coaches, however, I discovered that very few of them would actually use it. They were used to getting information pushed to them over email – the coach would send these emails to about 40 people with all the details about the next game or practice.
It struck me that I could build a greatest Web site ever, and it would still be a huge step backwards. No one would check the Web site, and the coach would still be sending emails to people. It turned out that, contrary to my first Web-centric instinct, email was the primary presentation for the content, not a Web page.
Along these lines, I got the idea that the coach wasn’t sending emails or creating Web pages – he was creating “announcements.” This was a pure form of content, unencumbered by the actual presentation media it would end up it (and it would likely end up in more than one – email and Web for sure). In this case, it needed to be presented in email first, then perhaps archived in some searchable HTML format second.
For most Web sites, is this level of abstraction practical? Probably not. Gadgetopia has only two presentation methods: HTML and RSS.
But, especially in the enterprise, content has much greater reach and can appear in so many other forms that dealing with the content on a purely informational level can really help put it in perspective.