Getting the Right Level of Granularity in Your Content Map

Posted on | Leave a comment

  • What, exactly, do you include in a content map? It will contain objects that you will slot beneath towers. You don’t want to spend forever slotting objects, so what is the right level of granularity to record in the content map? I went through this exercise recently with a client; this example ought to help illustrate how to decide the right level of granularity for your own situation.

    At the outset, I tallied the many blogs and forums my client operates on their site. The client has 15 products which break up into 55 separate offerings. There was not a one-to-one relationship between the products and the blogs–there are 18 blogs.
    Additionally, there was not a one-to-one relationship between the products and the forums–there are 133 forums. This made me suspect that the blogs and forums were supporting certain cross-product behaviors in some instances. In other instances they were probably only about a particular product line. In this case, the behavior-related blogs may map to individual towers representing each behavior, but the product blogs may map to multiple towers representing all sorts of behaviors, depending on what is discussed in those blogs. The same went for the forums. As my associate Eric Fain put it, “There seems to be a huge potential to muddle things up and make slotting this content a living nightmare.”

  • Adaptive Server Enterprise
  • Workspace
  • Security
  • Eclipse and Open Source
  • SOA
  • Data Integration
  • Metadata
  • Mobility
  • Clusters
  • Web Services
  • Linux
  • AJAX
  • Company News
  • Kernel
  • Enterprise Information Integration
  • Virtualization
  • Master Data Management
  • ETL

So I thought about it. Usually I would just have an object called “Blogs” and one called “Forums” and they would represent all the topics, and I would slot them under towers where people might be doing things like “keep up with latest techniques” or “read the latest news.” However, here each blog topic could represent many different behaviors. Moreover, the existing content was not “designed,” and each topic supports many different behaviors. “Data Integration” might have blog entries about new techniques or perhaps a product release that helps make it easier to do. This made things a mess, but that’s part of the whole content audit exercise. You want to see the extent of the mess.

So in this case I decided we ought to write down all 18 blogs annotated with the topics and reasons they are written. We slotted those, which turned out to be mostly product-related, but each entry covered some different behaviors/towers. We were going to need a good tagging system to sort them out. Then we went through all 133 newsgroups and wrote down, for each, the topics and reasons again, but then we made affinity groups of these. That gave us a smaller number than 133 to deal with. Then we slotted the affinity groups. Again, there was behavior embedded in each entry, but since no tagging system was in place yet, we merely placed them under the towers where we imagined they might be discussing behaviors. Again, tagging will be necessary to sort them out into the new system.