Learning objectives
- Understand relationships and the forms they take
- Identify the five "shapes" of content
- Explain why a CMS can be well- or poorly-suited to a shape
- Reason about the granularity-versus-usability trade-off
- Appreciate why "content exists in relation to other content"
In Lesson 3 we built content objects out of types and attributes. But a single object rarely stands alone — a blog post has an author, a product sits in a category, an article links to related articles. The connections between objects are as much a part of the model as the objects themselves.
1Relationships
An explicit or implicit link between two content objects. Relationships give content much of its behavior, appearance, and context.
Relationships take several forms:
Reference attribute
An attribute whose value is another content object — a Blog Post with an "Author" attribute pointing to an Author object. The cleanest, most explicit kind of relationship.
Embedded object
An attribute value that is itself a content object, nested inside the parent rather than referenced elsewhere.
In-content link
A hyperlink inside a rich-text body pointing at another object — less structured, but still a real dependency the system may track.
Positional / implied
A relationship inferred from position (siblings in a content tree) or co-membership in an aggregation (two items sharing a category or tag).
A core principle: content almost always exists in relation to other content. Very rarely does an object exist in isolation, and its relationships often define its behavior, appearance, and functionality as much as its own attributes do. Managing those relationships — including "referential integrity," so you don't delete something another object depends on — is a central modeling concern.
2The shape of content
Zoom out from individual objects and your whole body of content takes on a characteristic shape — the general pattern it forms in aggregate, considered against how consumers actually use it. There are five common shapes.
The general characteristics of a content model taken in aggregate and considered against the usage patterns of its consumers. Different shapes have different aggregation and management needs.
- SerialOrganized in a line, ordered by some parameter. A blog (reverse-chronological posts), a tweet stream, a news feed, or a glossary (alphabetical). No structure beyond order.
- HierarchicalOrganized into a tree — a root with children, each of which may have children. The core pages of most informational websites (Products → Product A, Product B). Trees can be broad or narrow, shallow or deep. Navigation is often derived from tree position.
- TabularA single dominant type with a defined structure, optimized for searching not browsing. Picture a giant spreadsheet — a company locations database with 1,000 rows of address, city, phone, hours. Users search it by parameters.
- NetworkNo larger structure beyond the links between objects; all content is flat and equal, tied together only by links. A wiki is the classic example; a social network ("people" connected as "friends") is another.
- RelationalTightly defined relationships between multiple highly-structured types, like a relational database. IMDb has Movies with Actors, Sequels, and Trivia Items — and the relationships are enforced (you can't add trivia for a movie that doesn't exist).
3Matching a CMS to the shape
Different systems handle different shapes with different levels of grace. A few illustrations from the source material:
| System | Great at | Awkward at |
|---|---|---|
| WordPress | Serial content (blog posts) | A highly hierarchical help-topic database |
| MediaWiki | Networked content (wikis) | Running a blog |
| A relational CMS (e.g. Webnodes) | Tabular & relational content (and, incidentally, serial) | Highly-networked wikis |
Real websites mix shapes. A corporate site might have marketing pages in a tree (hierarchical), a dealer locator that's tabular, and a news feed that's serial — each section modeled differently. And "not suited to a shape" really means "not best suited": almost any system can be contorted to handle any shape, but doing so takes heroic development or produces a confusing editor experience (often both). Most mainstream CMSs deliberately aim for the middle of the road — strong at one or two shapes, capable of the rest.
4Granularity versus usability
We met this trade-off with the street address in Lesson 3; now we can state it as a principle. The more finely you structure content, the more you can do with it — query it, reuse it, reformat it, deliver it to many channels. But structure has a cost: tightly-structured content is harder to create and maintain, because editors must fill in more fields and follow more rules.
"The big advantage to structuring content is that it lets you repackage it in different forms. The downside is that it forces editors to approach their content like machines." — Josh Clark
Structure is a balance between granularity and usability. There's a temptation to structure everything to the maximum "just in case," but every additional level of structure increases the work of creating, managing, and delivering content. Let your actual, known requirements drive granularity — not hypothetical future ones. Over-modeling is as real a failure as under-modeling.
🔑 Key terms from this lesson
- Relationship
- An explicit or implicit link between two content objects.
- Reference attribute
- An attribute whose value is another content object — the most explicit relationship form.
- Referential integrity
- Ensuring you don't break or orphan objects that others depend on.
- Shape of content
- The aggregate pattern of a content body: serial, hierarchical, tabular, network, or relational.
- Granularity vs. usability
- The trade-off between fine structure (more power) and ease of authoring (less friction).
Review Questions
Test your understanding. Click each question to reveal the answer.