Content models have been around for several decades. Until recently, only a handful of people who were interested in the courage of content management systems cared a lot about them. Recently, they have been gaining more attention in the information architecture and content strategy community, partly due to the recent book by Carrie Hane and Mike Atherton. Design related content. The growing awareness of content models also shows how the concept can be interpreted in different ways when content models are mixed into broader discussions about structured content. And ironically, at a time when interest in content models is growing, some of the basic ideas about content models age poorly. I believe that the role of content models needs to be redefined so that they can better meet changing requirements.
This post covers several topics:
- How content models can be badly designed
- Define content models related to components
- Criteria for what content should be included in a content model
- Editorial benefits of content models
In my previous post, I advocated the benefits of separating 1.) the domain model for data about entities that occur in content, and 2.) the content model for expressive content. This post explains what content models should do. Content models have greater potential than they currently offer. To reach their full potential, content models need to redefine their purpose and construction, remove parts that add little value, and add new parts that can be useful.
Content models from a historical perspective
Bob Boiko is very influential Content management bible, published in 2002, offers one of the first detailed explanations of content models (p. 843):
“Database developers create data models (for the database schema). These models determine how each table in the database is structured and how it relates to other tables in the database. XML developers create DTDs (or XML schema). DTDs determine how each element in the XML file is structured and how it relates to other elements in the file. CMS developers create content models that perform the same function – they determine how each component is structured and how it relates to the other components in the system. “
The content models have not changed significantly since Boiko wrote this almost two decades ago. In fact, many CMS have not changed significantly during this time. (Many of today’s popular CMS date from when Boiko wrote his book.) Boiko compares the components of a content model with the tables in a database. By analogy, Boiko implies that a content model is the schema of the content – because CMS has served as a monolithic content database in the past. While content strategists tend to think about all content that comes from the CMS, this is no longer entirely true. Two major developments have undermined the priority of the CMS: first APIs and more recently diagram databases in which metadata is stored. Although very different, both APIs and diagram databases allow side-to-side access to data or text, often with a simple “GET” command, rather than having to go through a hierarchy of attributes used in XML and HTML DOM.
APIs allow you to get highly specific information from files that are located elsewhere, while diagrams allow you to combine different combinations of attributes as needed. Both are flexible just-in-time methods to retrieve certain information directly from multiple sources. Even though content now comes from many sources, content models are still designed as if they were tables in a conventional database. The content model is not a picture of what is included in the CMS. The CMS is no longer a single source repository of all content resources. Content models need to evolve.
The content structure does not only depend on the arrangement of the materials in hierarchies. Hierarchies still play a role in content models, but are often overemphasized. It is not so important to show how content is stored in a content model, as it may have been in the past. It is more important to show what information is needed.
Content models have great potential to support editorial decision making. Existing forms of content models don’t really capture the right elements. You can specify blocks of content that do not belong to a content model.
How content models can be badly designed
Content models reflect the expertise and judgments of those who design them. Designers may have completely different ideas What represents a content model and Why Elements are contained in a content model. Content models may capture the wrong elements. They can sometimes contain too much structure. If this is the case, unnecessary work is created and sometimes the content becomes less flexible.
Many discussions about content models relate to the relationship between blocks of content or blocks of text. These relationships are compared to the fields used in a database. Such familiar terms avoid shaky jargon. But they can be misleading.
Many content strategists speak of chunks as building blocks for content models. It is common to call content structuring “chunking”. It is accessible as a metaphor – we can think of a piece visually, like a piece of a bar of chocolate. However, the metaphor is still abstract and can create different ideas about when and why sharing content is desirable. People don’t agree on what a piece actually is – and they may not even notice that they disagree. There are at least three different perspectives for chunks:
- Chunks as coherent information units – They are independent of any context (perspective chunks of information).
- Chunks as discrete segments that the audience consumes – they depend on the audience context (perspective The Chunks of Meaning).
- Chunks as elements or attributes managed by the CMS – they depend on the IT context (the chunks of a database perspective)
Each of these perspectives is valuable, but somewhat different. Although it is useful to consider all of these dimensions, it can be difficult to optimize all three dimensions together. Each perspective presupposes a different reason for structuring content.
Information Blocks Perspective
If chunks are viewed as information units, this can lead to an excessive structuring of the content model. Since the block is context-independent, it can be loaded with many details if they are needed in a particular scenario. Unless specific rules have been written for each case in which the block is displayed, all information is displayed to the target groups that are in the block. In many cases this is an exaggeration. The audience only wants part of the information. Chunks are overloaded with details (often nested details) – the content model tries to manage field-level information that belongs to the domain model and that should be managed with metadata vocabularies. Metadata vocabularies allow extensive data to be viewed as needed (see Chapter 13 of my new book, No more silos: metadata strategy for online publishers). In contrast, content models often disclose all data at all times.
Another symptom of too much detail is when chunks are broken out to increase completeness. Some content models apply the MECE standard: mutually exclusive, overall exhaustive. While they are logically elegant, they make assumptions about what content is actually needed. For example, on a recipe website, each recipe can display allergens associated with the ingredients. This is potentially useful content. You can filter out recipes that have offensive allergens. However, it does not follow that each allergen deserves its own profile, which, for example, specifies all recipes that contain peanuts.
Sometimes content models add such details because it is possible and because it appears to be more complete. This can lead to page templates that display content sorted by minor attributes that offer little audience or business value. The problem is most evident when the content is to be encyclopedic and all details are in any combination. Some content models encourage the creation of collections of lists of things few people are interested in. Content models are most effective when they identify content to be accessed where it is actually neededinstead of pushing to a location, it may be necessary.
Perspective “lump of meaning”
Concentrating on the needs of the audience sounds like a better approach to avoid unnecessary structuring. However, if editorial requirements guide the chunking process, this can lead to another problem: phantom chunks in the content model. This is content that can look like blocks in a content model. However, they do not behave like in a content model.
The concept of chunks is also used in structured authoring, which has a different purpose than the modeling of content. Segmenting content is a valuable approach to content planning. The segmentation enables content to be created prioritized and content to be organized according to headings. It can help improve both authoring and the audience experience. But Most segmentations are local to the type of content being designed. Segments are not reused in any other way and certain values are not reused. The segmentation helps readers to understand the whole better. But each segment still depends on the whole that is to be understood. It is not a really independent unit of meaning.
Perspective “Chunks of a Database”
Chunks are also considered elements that are managed by a CMS – the fields of a database. These can be text blocks (e.g. paragraphs) or nested field sets (e.g. an address). However, blocks may not be the right entity to represent in a content model. If data (entity values) is defined as a block, it is bound to a specific presentation. If this data is burned into the content model as a block, the publisher cannot simply display some of the data if that is all that is required.
Nesting makes sense if there are dependencies between information elements. Ideally, however, the model should represent content elements that are independent and can be used in a flexible way. As mentioned in my previous post, content models can get confusing when they display the properties of the entities mentioned in the the content as attributes from the content.
If a content model’s focus is on blocks of text, other types of elements such as photos, links to video or audio, or news snippets can be excluded. In addition, only certain types of text blocks are likely to be components in a content model. Not all text blocks are reused. And not every text that is reused is a block.
General, Long blocks of text are difficult to reuse. They are unlikely to vary regularly like short labels. Although it is possible to specify alternative paragraphs to be presented to the audience, this is not common. The ability to use text blocks as components mostly arises when the same text block is to be used in different content types to support different use cases.
In summary, different people look at different sections because they are motivated by different goals for structuring content. Although all of these goals are valid, they are not all relevant for the purpose of content modeling. The purpose of a content model is not to break down content. The purpose of a content model is to allow different content elements to be assembled in different ways. If the model breaks down the content into too many parts or parts that are not widely used, the model is difficult to use.
It’s easy to break up content. It is much more difficult to combine content elements into a coherent whole. However, if done carefully, content models can give broader meaning to the content that is made available to the audience.
What exactly does a content model represent?
Because chunks are viewed in different ways, the elements of a content model need to be more precisely defined. Like Boiko, I will call these elements Components, rather than as attributes or as blocks.
Content models indicate content components that can be represented in different contexts in different ways. The components must be managed programmatically by IT systems. It is important that a content component is not a free text field in which everything can be entered, but may never be reused. A content model does not offer potential relationships between content items. It is not a planning or investigative tool. It should show the actual choices available to content creators to present to the audience.
Content components are content variables. If the block is not a variable, it is not a content component.
Imagine a content variable as a predefined variant of the content. If the content is an image of a product, the variants can be images that show different views of the product, or possibly different sizes for the images. The image of the product is a content component. It is a variable value. People usually view variables as data. You should expand their thinking. Content variables are all uses of content with the option of which version to use or where to use it.
A content model is useful because it shows which content values are variable. Content values are expressive if they vary in a predictable or regular manner.
A chunk is only a component if it meets at least one of two criteria:
- The component varies in a recurring mannerand or
- The component is reused in more than one context.
Content components can be either local or global variables. Content components are local variables when used only in one context. The component offers alternative variants or is optional in different scenarios. Content components are global variables if they can be used in different contexts.
We can summarize whether a block is a content component in a matrix:
|context||Value is fixed||Value is variable|
|The value is local for a context||No component||component|
|Value is global: used in more than one context||component||component|
Content components are the equivalent of the content model to the enumerated values of a domain model. Enumerated values are the list of allowed values in a domain model (sometimes called a controlled vocabulary or colloquially called a picklist value). Enumeration values are names of attribute choices – the names of colors, sizes, geographic regions, etc. These are small bits of data that can be aggregated, filtered, and otherwise managed.
In the case of a content model, the goal is to manage content items instead of data items. In general, the content is larger than the data. The components can be paragraphs or pictures. These components behave differently than the data in a domain model. Content values cannot be filtered (unlike data values). And it will rarely be that you aggregate content values. The advantage of a content variable is that rules are created when and where the component should appear.
Let us consider the variation in content according to three levels, which I will describe as repetitive, expressive and unmistakable. These terms are just terms that help us think about how fixed or variable the content is. They are not intended to be value judgments.
Repeated content refers to content that is fixed in place. It always says the same thing in the same way in a certain context. The meaning and style are fixed – there is no variation. For example, the greeting and jingle for a podcast can be the same every week, although the program that follows the intro is different every week. The greeting is specific to the podcast and is not used for other types of content.
Expressive content refers to how content variations change the meaning for the audience. Deviations in the selected components are taken into account. Variation can happen within Components and above different content that these components contain. Expressive content is also similar to a term in programming that is called expressions and evaluates values. For expressive content, the key question is to know what is the right value – choosing the right content variant.
If the content is different, no two content elements are the same. This blog post is distinctive content because none of the materials have been reused or are reused. The body of most articles is distinctive content, even if you can divide it into individual parts.
It is important to recognize that a content model is just one of the tools available to organize content structuring. Other tools include content templates and text editors.
Let us concentrate on the “body field” – the large text spot in many online content. It can be structured differently. Not every editorial structure includes content components. An article may contain a main paragraph. This paragraph can be based on certain criteria. It must be stated who the article is intended for and what use the article offers the reader. However, this note is specific to the article. It is part of the article structure, but not an independent structure that is used in other contexts.
The same article may contain a summary paragraph. Unless the summary is used elsewhere, it is not a content component. The summary can be standalone content that can be used in other contexts, although I’ve seen many examples of where this was done, which wasn’t a great user experience.
These sections of an article help readers understand the purpose of the content and help the authors plan the content. However, they are not part of the content model. Such segmentation belongs in the text editor in which the content is created.
Consider another example of a content block. Many corporate announcements affect the price of corporate stocks. At the end of each press release, companies routinely set a disclaimer for forward earnings. This disclaimer applies only to press releases and the wording is fixed. The disclaimer is not a content component that varies or is used in other contexts. It should be included in the press release content template.
|Type of text||variability||Where to specify or manage|
|Repeating||Consistent text for only one context||Template – hardwired|
|Expressive||The same text that is used in multiple contexts or regularly variable text that is used in at least one context||Content model|
|Distinctive character||All content is unique: not reused in different contexts||Structured guidelines in the text editor|
The content model is just one of many tools available to structure content in a broader sense. The content model only deals with variable content components. The content model does not define the entire structure of the content that the audience sees. The content model supports templates, but does not define all elements in a template or the organization of the wireframe. The structure of the authoring environment may be based on components that are available in the content model, but segments content characteristics that are not part of the content model.
What should be included in a content model?
Components are meaningful objects. They can change their meaning. You can create new meanings if they are combined in different ways. They are not simply empty containers or placeholders for presenting material.
Content models provide guidelines for two decisions:
- Where can a component be used? – the available contexts
- Which variant can be used? – the available variants
The components within a content model can have three variants:
- Media assets
Statements are sentences, paragraphs or sections that consist of several paragraphs. Structurally, they can be sections, side notes, labels, quotes, etc. Statements are often long blocks of text. In some cases, there are variations of text blocks for different audience segments or regions. In other cases there are no deviations in the text, but it is displayed in more than one context.
An example of how statements can vary in a single context would be if a statement on the customer’s legal rights changes depending on whether the customer is based in the United States or the United Kingdom. The content component changes.
An example of how an instruction can be used in multiple contexts is the disclosure of prices and availability. A publisher may need to insert the phrase “price and availability may change” in many different contexts.
A content component can be a phrase or a managed text fragment. Phrasing has become much more important, especially with the advent of UX writing. Some formulations are important because they relate to a great “moment of truth” for the audience: a decision they have to make or a notification that is important to them. Specific formulations can be developed continuously to reflect the voice and terminology of the brand and to ensure customer acceptance. It can be optimized through A / B tests.
In contrast to variations in statements that generally refer to differences in meaning or substance, the variations in wording generally refer to wording, tone, or style.
Some examples of managed phrases are:
The recent advent of design systems for UX writing promotes the reuse of text phrases. UX writing design systems can indicate a preferred messaging that corresponds to the editorial decisions on branding or performs better with the target groups. Although this is not currently common, e.g. Reusable text can be included in the content model.
Phrases may not be managed in a CMS. They can be in an external file that is called to insert the correct phrase. Again, the content model should not be limited to content managed by the CMS.
Let’s consider how phrases can be content components.
|Phrase type||Content variation?||Used in multiple contexts?|
|Thank you message||No||Yes|
Media resources offer a wide range of content variations. Different media resources can either represent different substances or the same substance in a different style. Different photos can show different entities or represent the same entity in different ways.
Because content models have been closely identified with text in the past, they have not always represented other forms of content such as media. Media elements are often stored in other systems and may not be considered content variables when authors focus on text in a text editor. As a result, media resources in a content-first process can sometimes be second-class citizens. Like phrasing, Media inventory is not currently displayed in many content models, but should do so.
Media resources include:
- Alternative pictures
- Optional videos
- Content widgets like calculators
Let us consider how media elements can be content components
|Asset type||Content variation?||Used in multiple contexts?|
|Hero image for service pages||Yes||No|
Editorial benefits of a content model
Content models allow content creators to focus on the scenarios where certain content elements are used.
Content models help content designers Decide what content is global content used in different contexts. And which content must work together with other content?
For authors, Content models operationalize previous editorial decisions and save effort. Publishers may already have an approved language for explanation. Certain phrases may have been tested and optimized so that text can be reused and not re-created. Content models provide the authors with instructions. You can choose from several options: for example, select one of these five images that relate to the rest of the content.
Models also offer the opportunity to improve the inventory of content components that are widely used. Notifications can display several different expressions that make sending messages to routine tasks more varied. A new phrase could be added to the model and tested. If it is well received, it can be added to the roster.
Content models enable better content management. Communication can take place by defining and managing content-related variations Optimized across channels. Content models prevent unplanned deviations. They help unify content resources that may be stored on different systems.
It’s time to increase the role of content models. When it comes to editorial planning, the right information is selected and presented correctly. Content models can capture variations in substance and style. Content models can do a lot to support editorial decisions.
– Michael Andrews
Note: We are not the author of this content. For the Authentic and complete version,
Check its Original Source