Deane’s Content Management Manifesto from 2001

I attended Intranets 2001 in April/May 2001 in Santa Clara, California back when I was the 28-year-old intranet development manager for a credit card company. I had been working in homegrown CMS for about five years by that point, and this was the breathless summary email I sent back to my co-workers on the last day of the conference.

It was my first ever conference, so I was a little giddy. At some level, I think I was trying to justify the trip. I had fought pretty hard for the budget to go, so I felt like I need to prove it was valuable.

The list of speakers I encountered here was pretty amazing:

I attended Martin White’s pre-conference workshop
Tony Byrne was here, pre-RSG (he worked at IDEV at the time)
One of the keynotes was Jakob Nielson
Tim Bray spoke on something (I don’t think I attended his talk)
Karl Fast presented; years later, he would speak at my own Now What Conference
Both Peter Morville and Lou Rosenfield were there; at the time, they were fresh off first edition of Information Architecture for the World Wide Web

I’ve annotated the manifesto a bit below. Anything in a shaded box (like this one) was added in June 2020.

“ActionContent” was the name of an in-house CMS we were working on. (I’m not kidding. That’s what we called it.)

Also, the old Intranets 2001 website exists in the Wayback Machine.

Subject: Deane’s Content Management Manifesto

All:

All right, after sitting through a half-dozen seminars on content management and about a dozen vendor pitches (they give you all sorts of toys for listening to them for 10 minutes), I’m ready to write down everything I’ve learned about content management in the last four days. Technically, there’s still tomorrow, but that’s a half-day and I don’t think there’s anything on content management.

Here goes…

All the seminars started off by defining “content management.” There are dozens of explanations which are on the Power Point presentations that I’ll download when I get home, but the biggest thing seems to be this:

“Content Management” as it’s currently defined is moving more and more toward Web Content Management AND Document Management in one system. This is because several traditional document management companies – primarily Documentum and FileNet – jumped into the content management arena and started incorporating traditional ideas from document management that had been around for years. This is good because, as you’ll see later, they’ve brought a lot of good ideas to the table.

The last presentation was given by an engineer who works for a company called DocuLabs. This company does nothing but test software, and they just finished a big round of content management testing. I pushed this guy on what content management actually encompassed, and he said this:

“Content management is making any type of content, in any application or framework, available via a Web browser.” I asked if it was enough to simply have the document open in its native application, be that Word, Excel, or whatever, and he said no – documents should be translated to a Web displayable format, or, in a controlled environment, users should have plug-ins and such that enable them to view content without leaving the browser.

So, with ActionContent, what we’ve built is really a “Web Content Management” system. This means that it works with content developed specifically for the Web, with final display as HTML in mind. What it doesn’t handle is Word documents, spreadsheets, etc. We would consider buying a separate document management system for this, but “Content Management” systems now are combining the two.

(Obviously, since we built ActionContent with external clients in mind, we never had any incentive to get it to handle other documents. But, as it starts getting used more and more on the Intranet, this functionality will be in big demand.)

This last presentation was an overview of several different content management systems, and the guy laid out some high-level “wish lists” for systems. He had a very specific list, from which he showed us a few items. I asked if we could get a complete copy of the list and he responded “If a horse made friends with grass, he wouldn’t have anything to eat, now would he?” Which pretty much meant that this is what he does for a living, so we’d have to pay for it. (Of course, by saying it that way, he got three hundred people to laugh at me…which sucked.)

Here’s the list. I’m not saying we should immediately build all these into ActionContent, but some of them are worth thinking about. (In this list, when I say a system “should” do this and “should” do that – what I mean is that this is what the various speakers said. I’m not implying that ActionContent is deficient and not a “real” content management system because it may or may not do these things.)

1. Template Creation

In any content management system, there should a process to develop templates to display content. We do this now. Also, content should be kept are pure as possible, which means completely separating it from presentation. We do this too.

I asked how far down the “development food chain” template development should go, meaning should we have a system for someone not trained as a Web developer to build templates? Thankfully, he said no. Other than some on-the-fly customization of the template (for instance, the ability to show or hide a certain column in a table), templates should be built by Web developers, and content should be written by content publishers, and never the two shall meet. This reinforces what we’ve thought all along.

Another big deal is apparently template management. By this I mean the versioning and selection of templates from a library or something. He was pretty vague on this, but in bigger organizations you can easily get thousands of templates, many of which will have been through dozens of development iterations. At some point you need to come up with something to keep track of them all. I don’t think we need this just yet, but the day is probably coming.

2. Contribution of Content

The biggest thing here that was content should be “submittable” from a wide variety of sources. Dedicated HTML submission apps weren’t at the top of the list. The general trend in the industry is to allow authors to develop content in anything – Word, Pagemaker, Power Point, etc. – and have it automatically converted for display on the Web. Getting stuff out of client apps like Word is apparently a big deal these days.

3. Collaborative Content Generation and Workflow

A content management system should have tools to allow collaboration on content development. This means that content items should support meta-data like development notes, where users can all view a piece of content and leave notes on how they feel about it or how it could be approved. It should also have some type of workflow system where content is walked around to the necessary people and “signed off” by them.

Another feature is to allow users to subscribe to a content item so they’re notified whenever it changes and given the opportunity to review the changes.

4. Library Services

This one got me thinking a bit. It dealt with things like check-in/check-out, rollback, and document histories. In ActionContent, what happens if two people try to edit the same content item at the same time? Right now this is a slim possibility, but as ActionContent sees more and more use on the Intranet, this WILL happen. The last one to the submit button wins, I suppose.

Also, what if some content is published and it’s bad? We can’t rollback because we don’t save the old version. Current content management systems will never overwrite content, they’ll just save a new version alongside the old version. Usually the newest version is the one displayed to the user, but at any time you can “rollback” the displayed version to any of the previous versions of that content item.

(Got me thinking – couldn’t you schedule content like this by creating “future” versions of the content item? For instance, have versions 9,10, and 11 out there, but version 8 is the current version. If 8 is bad, you can roll back to 7, and you can have automatically scheduled jobs to roll forward to 9 at a given time. Just a thought.)

This is really where the influence of the document management companies come into play, because these features have been available in document management for years.

5. Personalization

I won’t go into this too much, because it strikes me that this is a method of the implementation. Though it does bring up the point that a lot of systems on the market now handle everything from admin to storage all the way up to template languages.

Many content management systems have their own scripting languages and server-side rendering, that capture user IDs and display given content based on that. We work with ActionContent and we implement it with ASP, though technically we could use PHP or ColdFusion or any other language that supports COM. Not so with many of the systems today – you write the templates and the actual rendering scripts in some proprietary language.

Worse yet – one of them even has its very own Web server. You use that server, or you don’t use their system. (I choose the latter – anyone with me?)

6. Publishing and Delivery Management

This involves scheduled releases of content and the expiration of content, which I believe we have built into the system already. Do we have any staging capability? A feature of new systems is that users can see content as it would be displayed to the end user before it goes live.

7. Storage and Archiving

I don’t know how much of this applies, because it comes into play when you get so many content items that you actually move the older ones off to an archiving system, be it another database server or whatever. Some systems will handle this automatically, either to conserve production disk space or to limit rows in the production database to improve performance.

8. Reporting

Systems on the market now provide “hit tracking” on exactly what content items are getting hit by whom, and admin tracking to record exactly who has changed what and when.

There were some other points not in this guy’s “official list” that came up repeatedly over the weekend that seemed important:

Legacy Integration:

How many current and disparate apps that the management system can tap into, extract content from, and index content in?

Content Syndication Across Multiple Channels:

This may be a function of templates, but there are many different channels to distribute content – the browser, then WAP and wireless apps, print is still big, fax, voice, etc. How many of these channels does the content management system support natively – many of the better ones come with tools to automatically provide content in fax templates to fax content to people, wireless templates, text-to-speech, etc.

User-Supplied Keywords and Taxonomy Positioning:

Taxonomy, taxonomy, taxonomy – that’s all I heard this weekend. I finally had to go look it up. It basically means a hierarchical classification – a bunch of parent/child relationships. Yahoo is probably the classic example of a taxonomy. Also, our menu on the Intranet – that is how we have fit all our Intranet content into a taxonomy. There, feel better? Yeah, me neither.

Anyway, it’s apparently important to give the user some input on where his or her piece of content goes and is accessed in the big scheme of things. This can be as simple as letting them supply their own keywords that just write to META tags to ensure search engine hits, to letting them actually position the document into the “information taxonomy” themselves.

(Incidentally, I’ve sat through three or four vendor presentations of systems that will automatically categorize all your companies information for you. These systems will actually read all the documents and figure out what they have to do with and where in the taxonomy they should go. They seem to work remarkably well. Sadly, their price taxonomy would have one parent category of “Expensive” with three children of “Pretty Expensive”, “Damn Expensive”, and “The Zero Key Obviously Got Stuck When Entering the Price”.)

Search Engines

Obviously, this is the most basic concept. All the content in the world is worthless if no one can find it. Many systems come with search engines built in, but buying one separately is a perfectly acceptable way of handling it.

In the end of this guy’s presentation, he presented the four content management systems that they considered “notable” and better than the 20 or so they evaluated. They were:

Broadvision
Documentum
OpenText
Vignette

I have more information on the four of them, with all their strengths and weaknesses (Broadvision is the one that comes with a proprietary Web server) in a Power Point presentation.

After learning what I have, here’s where I think ActionContent really shines:

Simplicity of Template Development

The learning curve on some of these products is outrageous. On the subject of Vignette, one speaker said that the company “operates on the assumption that we all have a battalion of developers in suspended animation somewhere.” One of the bullet points about Vignette under “Challenges” in that last presentation was “Extensive application development required.” We know ASP, COM, and SQL. We can – and have – put together templates in minutes. We don’t need a proprietary language or Web server to run our system.

Extensibility and Expandability

With these other products, I kept thinking that we’d get trapped in a box. What if we wanted to do something outside the box? Could we do it? We built ActionContent, we own it, and we’re familiar with the source code. If we want it to do something different, we can do that, where we’d be stuck with another product.

For a great example of this, look back over all the cool features I mentioned that other products have. We can pick and choose from these. Why? Because we built the system, we know exactly how to change it to do what we want it to, and we’re not afraid to get our hands dirty and do it. Ever try to change the oil on a Ferrari? Me neither.

Cost

I’ve been so shell-shocked at the dollar amounts that have been thrown around this weekend that I actually bought a can of Coke for $59 this afternoon and thought I got a good deal. For a shrink-wrapped system, you start at five figures and get into six very easily. Half a million dollars is not far-fetched. What do we have into ActionContent? Maybe $10,000 in development time? And look what we’ve been able to do with it.

The bottom line is that I really think we’re on the right track with ActionContent. The biggest indication of this for me is that I didn’t see one thing this weekend that made me go, “Oh wow, we really have to have that. How have we gotten by without it?” ActionContent does what it does very well, and I don’t think a shrink-wrapped system would do any better at 90% of what we’re doing.

However, there is 10% worth of bells and whistles – some very elementary, some debatable – that we should probably think about putting into the system. I’m very interested in some of the Library Services I mentioned earlier. As use on the Intranet expands, we’re going to need things like version control and rollback.

Also, the current system could use some work in the usability department. I say this not from any content management seminar, but from several of the usability workshops I went to. The admin side of ActionContent is very good (and development-free, thanks to Chris), but we’re Neanderthal Web developers. Sure, it makes sense to us, but we have sloped foreheads and our arms drag on the ground when we walk, so we’re not like the average Joe. The Intranet is going push content publishing more and more into the hands of some very non-Web experienced people, and the current interface may send them into shock.

From what I’ve learned, I also think that the whole system would be bound together and served quite well by a first-rate search engine (man, that T-shirt the FastSearch people gave me is really going to pay off for them…). I think a search engine would bind the entire Intranet together – content management, file shares, message boards, current HTML, etc.

As the search engine takes off, META tags and keywords are going to be very important, so it would help to let users enter things like that.

Finally, do we have any collaboration aspects in ActionContent? Primarily, could a content publisher tell someone, “Hey, go look at this content and tell me if you think it’s ready to go.”? If not, this would be nice to have as well.

In the end, I think we need to scale back of “expectation of talent” we have for the average ActionContent user. As far the Intranet is concerned, this user is not going to have any development experience, may not have much Web experience in general, and may even be something of a computer novice. Additionally, this user is going to be prone to make mistakes that we need to be able to recover from, and will likely make content development and publishing more of a team-based, collaborative effort than we’re used to. We have to be able to support these people.

Okay, that’s it. I just checked and this diatribe is pushing 3,000 words now. I hope a few hundred of them make sense. Let me just finish by saying that the more I learned about content management in general and about specific systems, the more I appreciated what we’ve been able to do in-house. I believe in ActionContent even more now than I did when I got here on Saturday. More power to us.

Deane