Web Publishing
Placed vs. Dynamic Content
by Theresa Regli and Christian Donner
29-Jul-2005
As any content management practitioner knows, there's a hundred ways to "skin a cat," or, in our case, implement a Web CMS. This can lead to heated -- but healthy -- debates about the best ways to display content on specific pages or areas of a website.
At a high level, there are at least 2 models for where and how content from a CMS appears on a website, both of which are suitable for different use cases. While one company's requirements might dictate a completely dynamic, database-driven publishing model -- fueled by metadata and made possible by complex queries spread across dozens of templates -- another's might call for something far more simple, where authors can deliberately choose where content goes on a site.
Both models require a content repository, but they differ in complexity and ultimate value. The former model -- which I'll call "dynamic" content -- requires extensive technical design, implementation time, and contributor savvy, but is essential for organizations that wish to maximize the value of their content. In the latter instance -- a "placed" content model -- the CMS acts as more of a versioning and workflow tool, enabling users without HTML skills to easily keep a site up-to-date.
"Placed" Content
Let's look at the latter model first. In order to place content on a specific location of a Web site, the content manager must provide the content asset with additional information. The content asset must "know where it belongs". This can be done in multiple ways, from simpler to complex:
- Managing a "page" item that lives in a folder-based tree of content that mimics or represents website directories.
- Storing a reference to the site location with the content asset in the data repository. For instance, the content manager would select a destination page from a drop-down list while he creates or edits the asset;
- Assigning a piece of content to one or even multiple places in a navigation tree, and thus have it appear in specific places on the site.
Since most real-life sites require that a content asset can be placed in more than one location, a many-to-many association is necessary. From a technical standpoint, this is a table or some other look-up in the data repository that contains references between content assets and locales. Taxonomy categories then map to pages on the web site and can provide a useful layer of abstraction between the site navigation and the site taxonomy, although by categorizing a content item, the author is also "placing" it, assuming she is aware of the relationships between categories and pages.
Taxonomies are often complex, and to facilitate more intricate placement of content there may be multiple taxonomies that overlap each other, or content that relies on multiple categories at different levels of the hierarchy in order to be placed, as the following example shows. This allows users to arrive at a certain content asset via different paths.
Figure 1 - Site with complex navigation (click to enlarge)
The user arrived on this page by first selecting a region/language (Japan/English), then a main category (Indices), then by drilling down 3 levels into Equity (Global Indices -- Global 1200 -- S&P 500) and finally by selecting the type of content (s)he is interested in (News & Analysis). The content on this page is a subset of the News & Analysis that would appear had the user selected News & Analysis at the top of the left-hand menu.
Let's look at a concrete scenario, with a relational database as the example repository. The content manager created an article with the ID "001". The title is "Message from the CEO". The content manager would like to place this article on the Corporate News section of his site. Via the CMS interface, the content manager can create a row in the Article/Taxonomy association table that links article 001 to Category "Corporate News". In the taxonomy table, this category has the ID "537".
Figure 2 - Placing content through association
If your CMS does not offer such functionality out-of-the-box, it could conceivably be extended to do so. The following two screens show just such a customization. The article classification screen requires 3 steps to be completed. The user is currently looking at step 2. The content of each list box depends on the previous selections. Only valid combinations are displayed.
Figure 3 - Site section and content type association
The region selection consists of 2 steps. First, the user selects a locale (a region/language combination that the site supports) and then (optionally) one or more countries. This allows site users to search for content that is relevant to their geography.
Figure 4 - Locale and geography association
Pros and Cons of the "Placed" Model
The primary advantage of the "placed" approach is that it allows the content contributor to retain a sense of control over the web site. Because content must be placed somewhere specific, the content manager is aware of where it is, and makes a conscious decision where to put it. There are no "surprises."
From an enterprise standpoint, however, the placed approach can ultimately require more time and resources to support. Authors must take the time to decide where content goes on the site, just as they would if there were no CMS in place. The placed approach also limits the potential richness of content relationships that can be achieved with more purely semantic applications. For example, a content manager in the marketing department might not be aware of how one piece of her content relates to a piece of content created by the product management group. Yet, both pieces of content might have references to the same subject. In a purely "placed" content environment, these two pieces of content remain unassociated, leaving the end customer to figure out how to traverse from one to the other.
"Dynamic" Content
Dynamic content, on the other hand, is not directly associated with a navigation target, such as a page of the site. Instead, the content manager provides metadata information about the content in the form of labels, or meta tags, which in turn are leveraged by the CMS or Portal / Web Application for display purposes.
The presentation layer must contain logic that can retrieve content with meta tags that match a given navigational element. For example, to display content in the Corporate News section of a site, the query may look for assets that contain the meta tag "corporate," as indicated in the following example.
Figure 5 - Targeting content through meta tag matches
This requires a certain understanding on the part of the content manager who does want to bind content to a specific website location. He must know the nature of the queries for the various templates in order to use the correct tags and enable the desired content to display in the correct place. The content manager in the above example picks the meta tag "corporate" from a list, with the knowledge that the presentation layer will display articles in the Corporate News section if they contain the meta tag "corporate."
Pros and Cons of "Dynamic" Model
The primary advantage of the "dynamic" approach is that the effort to maintain the site is minimal: tagging content is the sole action that is required. There is no need to "place" each piece of content on a given page or decide where it belongs in the navigation. Essentially, the logic in the presentation layer (a.k.a. calls to the repository to retrieve content that gets displayed via CMS templates) decides where the content should go, based on the nature of the content itself. The calls could be, "retrieve all corporate news articles in the repository," or "retrieve all corporate news that is also related to the new widget product debut." This approach allows for a rich experience of interrelated content.
The main disadvantage of this approach is that it is quite a dramatic change in the paradigm of content publishing, and can be challenging for content managers or organizations where there is a highly dispersed publishing model (more than a few content contributors). Oftentimes, changing to a dynamic content publishing model requires more extensive training up-front and requires the content managers to have at least a basic understanding of the logic that drives content display.
Sometimes, content managers end up tagging content with tags specifically for navigational purposes rather than for the intrinsic attributes of the content ("I want it to appear here, so I'll fool the system to make it so, even if I'm using a meta tag that doesn't apply"). Also, the dynamic content model requires managers to have trust in the system: you can't be sure to preview all the potential pages or places the content might show up, because there may be places you don't realize it will.
In the dynamic content model, the site tends to take on a life of its own -- which can be seen as an advantage or a disadvantage. For certain enterprises such as media or entertainment companies, it is worth reaping the benefits of allowing the CMS to associate content based on metadata attributes, as it will show relationships between content items that the content managers may not have known even existed.
It's not unlike letting your CMS play a game of --The Six Degrees of Kevin Bacon: while a content manager might not think that Charlie Chaplin and Kevin Bacon can be tied together, a CMS could dynamically generate links that allow a user to click from the movie "Limelight" (in which Chaplin appeared) to a biography on Norman Lloyd (who appeared in "Limelight") to a summary of "The Adventures of Rocky & Bullwinkle" (in which Norman Lloyd also appeared) to a biography of David Alan Grier (who appeared in "The Adventures of Rocky & Bullwinkle") to a page about "The Woodsman" (in which both David Alan Grier and Kevin Bacon appeared). Needless to say, a CMS is far more likely than a content manager to uncover this sort of complex semantic relationship.
However, for highly regulated industries such as health care and financial services, allowing the system to freely associate related content and display it to the end user in different settings without undergoing an approval process is clearly not advisable.
Combining "Placed" and "Dynamic" Content
For many organizations the best approach will be to apply a hybrid model, allowing content managers to place content on certain pages, while allowing content to place itself in others.
Figure 6 - Hybrid content selection
For instance, content managers may wish to hand-pick content that appears on a site's home page, while they feel confident about automating the display of content in the Corporate News section through the use of a meta tag. The example above shows how this would be reflected in the data.
A site implementation can offer both features because they work separately and independently.
Conclusions
The implementation of either approach -- "placed" content or "dynamic" content -- poses its own technical challenges, and the customization of Content Management Systems can be difficult and time-consuming. In order to determine which model works best in a given situation, it is necessary to carefully evaluate the publishing process and the needs of the content managers.
At first glance, managers tend to like the idea of "intelligent" content powered by metadata and not have to worry about placing each asset. However, the high level of data organization and quality required for this approach may not be achievable and it may become necessary to change the model in mid-stream. Be sure to focus on the needs of the content managers and their publishing process, as that will determine which model makes more sense for the organization.