The Art and Practice of Content Assembly: Where IA and CMS Meet

There’s a murky space where Information Architecture and Content Management meet. This is a God-forsaken back alley where dirty deals are negotiated and where idealism and purity go to die. This is the place were your wireframes are sacrificed on the altar of your CMS.

The most common cause of death? Managing content assembly, which is the seemingly simple concept of getting multiple items of content into a group (an “assembly” – it’s both a noun and verb, in this usage; I’m stealing this from a decades-old Documentum concept).

The reason for grouping content together is usually always in order to have this content appear in the same location on your website.

This is trivial right? I mean, this happens all the time on every website.:

  1. A department subsite menu with a bunch of resources specific to that department explicitly placed in a hierarchy.

  2. A blog with a group of blog posts ordered from latest to oldest.

  3. A topic page about something with a bunch of disparate resources all related to that topic in order of relevance as determined by a content retrieval algorithm.

  4. A set of “related content” links under an article.

  5. A list of the “Latest News” headlines on the home page.

Wireframes are great for this – “we’re going to have this menu here, and these links here, and some related content over here…” etc. Information Architects just go crazy with this stuff, and they really should because that’s their job.

Sadly, my job is to make all that stuff work. When I see any listing of content in any form on a wireframe, I’m automatically thinking “how am I going to get that content to appear in that spot within the capabilities of this CMS?”

Doing this is so fundamental to any website that you might be saying, “well, sure…” But, when you dig into it, the ability (or inability) for a CMS to do this is a critical differentiator. And unless your site is like Wikipedia, essentially consisting of a single content item displayed with nothing other than intra-text navigation (hint: it’s not), then a huge part of integrating a CMS is figuring out how to associate content together in such a way that it can be displayed correctly.

If you’re a regular reader of Gadgetopia, then you might be thinking:

In a general sense, content assembly is about grouping content together into assemblies. These assemblies often have no relationship to your core content geography. They exist apart from and in addition to it. They are “mini” or “alternate” geographies.

(Note that content assembly isn’t concerned with intra-text linking. You can always just have a WYSIWYG field and let editors create whatever links and content they want in there. But to do that is to completely remove any benefit of having a CMS in the first place.)

That term – “assembly” – is purposely vague. An assembly could be anything – a category, a parent content object, a keyword, a query based on some property, etc. The operative idea is simply that you have something to which you can refer that will return multiple content objects, optionally in some specific sequence or internal organization.

Take this for example (lifted from a random wireframe I had on my laptop):

This is a simple image carousel, right? Sure, but in a generic sense, it’s also an assembly of content. And, as such, it presupposes a few things:

  1. You have some assembly that will return exactly four content items. (The carousel might allow overflow, so perhaps this won’t matter.)

  2. This assembly will restrict itself to content that will render correctly. In this case, it needs to be either a dedicated “Carousel Image” content object or some kind of content interface that always has a title, a subtitle, and an image.

  3. You can put this content in an arbitrary order. Items in the carousel are lined up from left to right, and if you want Content X to the left of Content Y, you need to be able to specify this.

  4. It likely has some permissions attached to it. This particular carousel was on the home page of the site, and one does not simply walk into Mordorand all that…

  5. What about workflow? The key here is subtle – there will likely be approval workflow on the individual items, because they exist on their own as news items or whatever. But there might also need to be workflow on the assignment to the image carousel itself, completely separate from workflow around them existing as news articles not in the carousel.

And these are just the raw technical requirements. You also have to consider how usable this process will be for the editors. Will they understand the method you come up with, or that your CMS offers? What training will be required to get them to understand how it works?

As a content management integrator, your time with wireframes is mostly spent answering questions like these:

  1. What assemblies are needed to render the content the way the wireframes dictate?

  2. Do the assemblies themselves need to be structured, either to have metadata attached to them, or related to each other in some way? Are they flat or hierarchical?

  3. Do the assemblies need any restrictions on content types, minimum members, or maximum members?

  4. Once the assemblies are identified, how will the content get “inside” of them? Is it an explicit assignment, or is their membership in a particular assembly derived from data or geography?

  5. Inside of a specific assembly, does the content need to be ordered in any specific way, or is it enough to just be an unordered bucket?

  6. Do the assemblies need to have any security considerations, either for placing content into them, or reading content out of them?

  7. Are certain assemblies mutually exclusive? Does the existence of content inside Assembly X mean it can’t be in Assembly Y? Alternately, does content need to appear in more than one substructure in a larger overall assembly?

  8. Will the assembly return the content in a raw, unaltered format? Or does it change the content in some way?

Note that all of these questions pretty much have to be answered with a CMS in mind because the answers will be different for every CMS. Remember when I said that this is where IA and CMS meet? It’s true – this is where the rubber hits the road. This is the moment where you realize whether your CMS is up to task or not.

(Can any non-specific-CMS generalities be made about this discipline? Yes, and most of them are in this post. I don’t say that to pump up the importance of this post, but rather to reinforce the fact that there are precious-few generalities in this space. The discipline of content assembly is directly at the intersection of IA and a specific CMS.)

With any CMS, there are usually a bunch of ways to do this, and the more options you have, the better, because each method has advantages and drawbacks.

Here’s a brief survey of some of the more common methods of content assembly.


    Content Geography

    In this situation, you put content in specific locations – you have an explicit geography which you use to place content. The existence of content in a specific location with other content is what binds it together. For example, you have a location in your content structure for Topic X. You put all content related to Topic X in this location.

    In this case, our content geography and our assembly are the same thing.

    Geography as an assembly seems a little odd, because systems with a strong geography make it so core that it doesn’t come across as a “mere” assembly method, but it fits all the characteristics of one, both in theory and practice.

    It has benefits and drawbacks:

    Structured Categorization

    With this, you assign content to existing categories (really, just generic assemblies, but we’ll call them “categories” here since that’s a much more relatable term)

    These categories exist in a separate structure, most often a list or tree. You check a series boxes or something to put Content X in Topics X, Y, and X. The assignment for content to a specific category is completely independent of where that content lives in the content structure.

    Keywords or Tagging

    This is a lot like categorization, but there’s no pre-defined structure of categories – editors just make them up on the fly. (I’ve argued in the past, in fact, that keywords and tagging differ only in interface.)

    (The patterns around keywords/tagging and categorization are very similar, so all the idiosyncrasies of the that structure apply to this one as well. The following are in addition to those.)

    Parametric Association

    This is where content happens to be in a assembly because of some property it possesses – a content type, or a value of some property ( “a parameter,” hence the name “parametric association”). No one proactively put it in the structure. Rather it got there because of what it is.

    In a lot of cases, this provides an alternate, less-permanent geography that you can use for different things. It can flatten a tree, for instance.

    The content still “lives” in its core geography, but this particular assembly puts it in a different “shape.”

    In this case, the assembly is actually a query. Most likely, the query is executed at the time of retrieval (barring any caching), and it returns the content that matches at that moment.

    Perhaps you have a master news list, and something will appear on this list if it’s of the “news article” content type, no matter where it appears or what category it’s in.

    Structured Referential Assembly

    This is when you define an assembly that content can be grouped into by reference.

    Your CMS might have a menu system, for instance, which you populate by pointing menu nodes at content – Drupal is fundamentally defined by such a system. Ektron used to have a handy system of “collections,” which were just lists of content – you added content to the collection, and manually ordered it.

    This is the most obvious example of an assembly apart from your core geography. In Drupal’s case, it draws “order out of chaos.”

    The actual geography might just be a big, unordered bucket of content (the anti-geography?). However, the assembly (Drupal’s menu, in our example) takes that stuff and puts it in some semblance of order. It still “lives” in a big mass, but the assembly is how you refer to it (usually for your navigation).

    But organizing any content in a serial or hierarchical assembly is simple. What’s harder is when you can specify content types and specific ways that this content has to fit together to form a valid assembly.

    There’s a lot of absorb here, and knowing which assembly type is the right one to use is purely a process of (1) experience (by painting yourself into a corner by picking the wrong method too many times), and (2) intimate knowledge of your particular CMS and what it offers.

    You don’t find many sites of any significant size using just one method of assembly. Most sites use dozens, and there’s often confusion between the methods – you do use Method X for Menu X and Method Y for List Y and Method Z for Topic Page Z. Except on every simple sites, it often gets messy quickly.

    Sadly, There is no Grand Unified Theory of Making Stuff Appear Together in Some Location.

    If only.

    This is item #70 in a sequence of 357 items.

    You can use your left/right arrow keys to navigate