By Deane Barker | April 11, 2009 | 3 Comments
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:
- Publish Date
- Expire Date
- Effective Date
- Intended Audiences
- Subject (a taxonomy assignment, perhaps)
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.
- 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.
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).
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.
What Links Here
I’ve gone through your soccer scenario several times with Scouts. We’ve got all these interesting ways to present information on the web (Yahoo Groups, Google Groups, WordPress, PHP Forums, Wiki, etc.). After trying several things, the general consensus was that people didn’t really want a site to go to all that much. They preferred the push method of communication.
The reality is that there are Enterprise Content Management Systems out there that are addressing exactly this scenario. The first issue revolves around how to store the “content” or in your scenario the “announcement”. In previous incarnations of CMS’s content was stored in a proprietary format or in a DB. Over the last few years a standard has emerged (JSR 170/283) . The Java Content Repository now in its second version (JSR 283) is driven by the ability to store and retrieve content easily and in a presentation agnostic manor when used in conjunction with Apache Sling
also have a look at http://www.day.com
I think the web content management segment of the content management market is way ahead of Enterprise Content Management (ECM) in this regard. ECM has roots in document management (files in MS Office formats to most people) which are the absolute worst at storing format along with the content. Most web content management technologies have a presentation layer that does the work of taking structured information (with elements like you enumerate) stored in the repository and rendering to different output formats. ECM has no formal rendering service. Typically what you get some transformation that creates copies of the file (renditions) in different formats.
Most WCM systems can be (and have been) easily modified to produce outputs in various HTML views (printer friendly, mobile friendly, etc.), plain and rich text emails, and RSS. Compare that to the frustration you get when someone uses SharePoint to send you a blasted MS Word attachment that you can’t read on your iphone.