Content Modeling: A Master Skill: Rachel Lovinger did a really nice job on this content modeling article over at ALA earlier in the year.
I like how she breaks it down into three sub-competencies.
- The assembly model:The way content creators will put individual content items together to make webpages, campaigns, documents, or other content products.
- The content types:The various configurations of content that are distinct enough to be unique types in the system.
- The content attributes: The content and metadata elements that make up each type, including how they relate to each other.
This goes back to my post from last year: Varying Levels of Content Structure. I’d argue that there are further levels both above and below what she’s illustrated there.
For the first point – what she calls “The Assembly Model” – she also discusses some aspects of content geography, which we discussed in Content Geography: The CMS Feature Your Take For Granted.
(I also like the use of the word “assembly” here. Back in the day, when I was working with Documentum, they used “assembly” to refer to any group of content objects structured into a larger construct. It made sense as a metaphor. Since then, Microsoft has muddied the term by using it to refer to a compiled code object.)
She touches on another point which I’m sensitive to:
How tolerant are your content creators of laborious processes? If you ask them to take a lot of unstructured content and break it into dozens of distinct data fields, are they going to have the time to do it? If you’re lucky, maybe they’re already used to doing that kind of work, but try to avoid asking them to break up the content if it serves no functional purpose, because this can be very time-consuming.
Authors don’t think like database designers. They don’t mentally sub-divide their content into little boxes. When discussing this topic, I always seem to return to Josh Clark’s quote from an older post – To Structure or Not to Structure, which really sums it up well:
The downside [to structuring content] is that it forces editors to approach their content like machines, thinking in terms of abstract fields that might be mixed and matched down the road. The benefits often outweigh this usability cost if you’re going to present the content elements in multiple contexts and/or offer various sorting options with a large number of elements. If not, then I typically go with unstructured.
I’ve seen just as many problems from over-structuring your content as have come from under-structuring it. It’s a delicate balance. Take a look at the post on content structure for a list of guidelines I use, but I didn’t include what might be the most important one: what will your content creators tolerate? How you figure that one out is up to you.