Content Model
Having defined the way users would see the site and how administrators would work with
the content, we had to define the business rules that would control not only what the user
saw in each section, but also what the administrators would be able to add in each
section. In the user view we used a sitemap and in the Admin view we used a tree
structure, but neither of these approaches was effective in capturing the business rules of
what content could go where. It was important to capture the rules in a manner that had
enough detail for the developer to work with but was also easy enough for the client and
designer to understand.
Traditionally, sites with a database are displayed using a sitemap and a line to a database.
The details of the database are defined separately in a schema, which in itself has
different views: for example, table definition and relationship diagram. We needed to
combine the sitemap with the content types and show the relationship between them and
other parts of the site.
After several attempts at trying to combine the sitemap with database schema type
diagrams, we decided to adopt a different approach that started with the content rather
than where the content went. Adding to this, we borrowed from Peter Coad's approach to
object modeling in color (Java Modeling in Color with UML, Peter Coad, Eric Lefebvre,
Jeff De Luca, Prentice Hall). The end result is what we call a content model.
To create the content model, we start by representing each content type at the top of the
page, each with a different color. We then represent each of the main sections of the site
underneath. The next step is to draw a line between the content type and each section that
the content type can appear in. This establishes the rules of what can go where.
Once the main rules are defined, we look to capturing when content should be published
in two places simultaneously. In the following diagram, a news article stored in the
speeches section is also published on the home page. A publication stored in the LCA
section is also published in Publication under the LCA sub-section.
Original Content Model
Final Content Model
This approach proved to be quite powerful. It was easy for the client to understand the
relationship between the content and the site. At the same time, the developer was
provided with a high-level view of the relationships that would be implemented within
the CMS.
In the same way that an object model captures the objects within a business domain and
how they work together, the content model brought together the content, the site, and the
business rules in a single effective representation. Because the content model brings so
many elements together, it is the most important part of the specification to get right.
Get the content model right and everything else will fall into place.