The Four Disciplines of Content Management

By Deane Barker on November 24, 2007

A lot of stuff gets lumped under the heading “content management.” In my experience, however, all the technical activities under the banner of content management can general be broken out into four disciplines.

  1. Content Modeling
    This is the concept of getting your content to “fit” into a structured content management system. It’s the process of defining the content types, their attributes, and their relationships to other content.

    This normally a background, development-type activity. Your average content creator will not be involved in it, and — unlike the other items in this list — it’s a one-time, non-iterative type thing. However, it’s critical and it will affect everything after it.

    (See also: Open vs. Closed Content Management, The Content Tree, Discrete vs. Relational Content Modeling)

  2. Content Creation and Editing
    This is the process of actually creating new content — the interfaces and procedures users invoke to make something out of nothing, or to change content already in existence. It naturally subsumes some of the content modeling (how content is modeled will affect how it’s created), but also encompasses things like the quality and capabilities of the WYSIWYG editor and the usability of actually getting a content item into edit mode.

    (See also: A Lack of Basic Text Formatting Skills)

  3. Content Management
    This is the everything that happens with a piece of content after its created and until it dies. This includes the permissions, workflows, versioning, check in/out, task management, reporting, archiving, administrative searching, language translation, and any other action involved in keeping this content relevant, current, effective, and general under control.

    This is the real “management” part of content management. This is the stage in which content will live for 99% of its life. Yes, modeling, creating, and publishing it is very excitng, but those are all “point” activities — they generally occur at a single moment in time. At all other times, content falls under the banner of “management.”

    (See also: The Value-Add Side of CMS)

  4. Content Publishing
    This is the process by which a piece of content goes from somewhere in your repository to a URL where it can be consumed by an end user. This includes the templating system that generates the HTML (or any other renditions), and the process by which the content is made available at another URL, whether that be as simple as changing one field in a database, or as complex as generating a file and transporting it somewhere.

    (See also: Content Publishing Models, The Site Access Pattern and the Joy of eZ)

Note that these are technical items only. This doesn’t include the basic concept of conceiving, writing, and editing the actual content.

(See also: What Content Management Won’t Do)

To make a really effective content management system, each one of these pieces has to be well-done. Too many times, I see a system do really well at one, and fall down on another.

These are the four central disciplines of content management. Screw one of them up at your own peril.

Gadgetopia
What This Links To
What Links Here

Comments

  1. Well done Deane. I like the way you make clear that these 4 phases of content management are different jobs, to be done for different people. Especially for content modelling which is not often mentionned.

  2. I find that “content consumption” extends content publishing as the 4th piece to include not just the process of pushing content but also forces us to think about consumption via appropriate dissemination mechanisms for each content type.

  3. I use similar groupings, but call “content modelling” “content organisation” and include versioning and archiving as a fifth group.

  4. As to the content language translation: Could you write some more about it? What are the common used methods? What you consider the best? I’m thinking about that now and stumbled upon some problems. My first thought was to place the translation strings in the database to allow for dynamic translation of the content text and the GUI itself [menu items, taxonomies, system messages etc.]. But it comes out that at some periods the database isn’t available [at installation process, updating proces, maintenance mode, or simply when the DB server is down]. So I decided to use text files instead [but what is the best? *.po files? *.mo files? flat files with separators? something else?], so when the DB is down, the translations are still available. But it brings another problem: those files are static. Changing them dynamically [inserting/deleting from the middle] would be a hit for the server. And loading the whole file to use only a few strings isn’t good either :P

    The article about this would be really usefull :-J

Comments are closed. If you have something you really want to say, email editors@gadgetopia.com and we‘ll get it added for you.