Content Geography: The CMS Feature You Take for Granted

There’s a weird aspect of content management that I see come popping up again and again: spatial context, or content geography. What I mean is that content “lives” in some place inside the repository. A lot of systems (though not all) have this sense of “place.”

I’ve discussed content trees at length before. In systems following this pattern, you have a tree of content – all content is in some parent-child relationship, and part of a larger overall structure.

In these cases, content has a place. The content tree forms what we’ll call the “master geography” of the system. It’s a large, obvious, accepted structure that forms implicit relationships between content.

If you take Page A and Page B, they have some spatial relationship, and given the hierarchical nature of content tree-based systems, it becomes most natural to talk about this in terms of genealogy:

• They could both be children of the same parent, making them siblings.

• One could be a parent of each other.

• They could be cousins – their parents are siblings of the same grandparent.

• In a larger sense, they could be “closely related” to each other, or “distantly related” to each other, by virtue of being flung all the way across the tree.

If you don’t have a content tree, but instead have a folder structure (of which I’m not a fan) a la Ektron, you still have a sense of place. Items could be in the same folder, down the same branch, all the way “across” the repository, etc.

The bottom line is that in a lot of systems, you have this sense of geography – content is “put” somewhere, and you use this knowledge of its place to make value judgments about its relationship to other content.

Why is Page A in this place and Page B in that place? What differentiates the places? Usually it’s based on navigation and menuing. (Related: Menuing in Content Management: Implicit vs. Explicit)

But what if our system has no content tree or folder structure? What forms its geography?

Drupal is the prototype of the “big bucket o’ content” systems. By default, content in Drupal has no place. Some modules can super-impose some sort of geography onto Drupal, but what I found so damn bewildering about Drupal for the longest time is that there is a big amorphous pool of content, into which everything is thrown.

(Ask Adam about this sometime – I bothered him incessantly about this concept. I just couldn’t wrap my head around it, to the point that I wrote a blog post about my frustration.)

The way that a system like Drupal injects geography is through menus. You group content into menus, so Page A and Page B might be children of the same parent in Menu A. For your site, you may decide that Menu A is the main menu of the site, making this your master geography. But Page A and Page B may not be anywhere close to each other on Menu B, and what does that mean? What makes Menu A the master geography, and not Menu B? Just because you say so?

What do we call a system that allows you to create multiple, independent geographies of content, yet has no designated, accepted master geography?

What drove me nuts about Ektron for the longest time is that it has both – it has a folder structure, and it has explicit menus. So what is the single source of truth on content geography: the folder structure or the menus? I would call the folder structure the master geography, but since it wasn’t a true content tree, you couldn’t really use it for navigation very well.

(In fact, I was told by Ektron support on more than one occasion that the folder tree was never meant to define navigation. This irritated me in later versions when they tied breadcrumbs to folders, thus sort of saying “okay, now the folders should be used to define navigation…”)

So, in the end, I needed to use Ektron menus for navigation, which made them master-ish…but the folder structure imparted more geographic-ness…and, you get why I got frustrated.

(On top of this, Ektron has a taxonomy system too. And content collections. So, if we have a folder for “Employee News,” a menu for “Employee News,” a taxonomy node for “Employee News” and a collection for “Employee News,” and all four of them group different content…then where the hell is the Employee News, exactly?)

I guess, no matter what the system, you, as the CMS architect, need to have some single source of truth on geography. If the system doesn’t provide a strong content tree or folder structure, you’re going to need some way to figure out how Page A and Page B relate to each other. What is your master geography?

Whether you acknowledge it or not, so much context is drawn from geography. In most cases, it’s navigation, and this has a huge effect on how your site plays out.

What prompted this post is that I was re-reading a section In The Polar Bear Book the other day. Rosenfeld and Morville were discussing types of navigation. They differentiate between these two:

• Local Navigation

• Contextual Navigation

The former, they say, allows the user “to explore their immediate area.” There’s that concept of geography again – “immediate area.”

But for Contextual Navigation, they’re talking about what they call “associative navigation,” which are menus like “More Employee News” or “More Articles Like This.” Content that is somehow related to the main content of the page.

However, note that they have implicitly set apart the notion of geography. Local Navigation is based on geography. Contextual Navigation is based on any other type of relationship. Whether they meant to or not, they set geography apart as a special type of relationship, and one that’s apparently so basic as not to need elaboration.

This is what got me thinking about master geographies and how ingrained they are in most of the systems I work with. Can this be limiting? Occasionally, but not usually. Having the system define a master geographic structure is valuable because it gives everyone a common reference point for that CMS. When using Episerver, you know that the content tree forms the geography of the site can is the default reference for discussion of place.

However, there is also value in being able to create alternate geographies, which are common in the explicitly menued systems like Ektron. (That system in particular, as noted earlier, might have too many alternate geographies.)

The best of both worlds? A clear, accepted master geography in the form of a content tree (not a folder tree) with a solid option for creating alternates as needed. Who does this really, really well?

(Episerver is close, but it doesn’t have a good method for creating ad hoc hierarchical geographies like Ektron’s or Drupal’s menus, which is unfortunate.)