Content inventories







IAI Summary Question 1: To Content Inventory Or Not To Content Inventory

Inaugural Question of the Week for the IA Institute Member Mailing List

Leisa Reichelt of Disambiguity.com posted earlier this month against content inventories, positing that they immerse you in the status quo of the content types and approaches.

http://www.disambiguity.com/2006/05/why-you-shouldnt-start-ia-with-a-content-inventory/

Her position is interesting, but we'd like to hear from you about how you react to this post. How have content inventories affected your process and creativity on projects? Is completing a content inventory as one of your first major IA tasks good or bad?

Overview

The responses to this question gave a nice blend of ideas, mainly that the initial runthrough of the content at the start of a project can be thorough, but likely should not be the final, detailed audit.

Also, there is a desire to clarify the terms at work here. One person’s “content survey” is another’s “content inventory.” Or, one person’s “content inventory” is another’s “content audit.”

The responses to this question suggest the following continuum for the level of detail:

(Least detail) Content survey > content inventory > content audit (More detail)

Response Summaries

  • Content inventories inspire as much as strategy and users. Understanding content helps drives the content strategy and begins the modeling process for migration to a content management system.

    They key to avoiding content myopia is to look at content produced not only for the website, but also via traditional means, feeds, competitive research, and adding in the desired additional functionality.

    Look for ways to take content, add effective markup, and allow people the ability to build upon it – very Web 2.0.

  • Use content inventory as a preliminary analysis for a more formal content analysis. Then, the latter is a validation of the observed informal patterns.

    The existing content provides lots of insight into what has come before, informs your ideation for the project, and indicates where issues may arise.

  • This issue may be one of terminology – one’s “inventory” may be another’s “survey.” The original post may be saying not to complete a formal analysis/audit first, but rather to examine all the content without getting stuck in the current paradigm.

    An IA that becomes “indoctrinated” by existing content is not doing a good job. One way to learn about your client company (not the users) is to examine what content is on the site. Time and budget are factors here.

    The interesting thing here is the discussion around the differences, if any, between a content “survey” and content “inventory.” This shows that the practices is still in the formative stages and that there should be an agreement at some point in the future.

    In the end, which you do is determined by the project and the client (whether internal or external – ed).

  • Use tangible futures and backcasting; create inventories based on user needs (internal and external) and add ideas projected by the strategic direction. Compare the current to the future inventory for a gap analysis.

    Content inventories should be considered roadmaps, and it will become apparent when old content is not needed.

  • The idea is not to START a project with a full content inventory. Get a sense of the current content, but don’t obsess with the details. Doing so could create a vortex towards waterfall thinking.

    Sketch earlier to create artifacts and shared context. Many artifacts are much simpler to create and digest than content inventories - prototypes, comics, sketches, participatory design, games, etc. Numerous UX professionals are now doing so with much success, and the idea was promoted about 50 years ago - see Henry Dreyfuss’ 1956 classic "Designing For People."

  • Any artifacts related to design research will provide evidence and help quell (fairly common) debates about decisions that don’t need to be made. Besides a shared context and language, artifacts can serve as keepers of key truths and decisions already made. If the “truth” changes, the artifacts change. They serve as the shorthand of the vision.
  • Distinguish between artifacts and deliverables. While a deliverable is part of a projects contract, the artifact is an ad hoc piece of visual information necessary to illustrate a particular point.
Controlled Vocabularies in the Trenches

Victor jots down some thoughts about creating controlled vocabularies within the context of the design of a project he's working on. He discusses some real considerations and dependencies related to the development of a controlled vocabulary and implications for systems design. Here's some of my own thoughts/reactions, based on experience.

I've watched the controlled vocabularies of subject headings and company information grow within my organization (a corporate library services org.) over the last four years. The approach we've taken is sort of like a web services model or much like a vendor service, such as those where data aggregators provide indexed content with their own proprietary controlled vocabulary (e.g. Factiva). This seems to me to be a good model because it centralizes semantic tagging and creation of indexing terms in one place, while enterprise use at different levels of granularity. When following this model, you're still confronted with the issues of knowledge representation when developing your terminology, but the system considerations are separated. The design of IR systems using indexes benefit from documenting scope, domain, documentary units, indexable matter, etc. prior to implementation. I have this great unpublished text by Jim Anderson that serves as a framework for such documentation.

Here's a short description of our approach, which has been top down and bottom up. Our people created our CVs starting with close relationships with business units to develop a set of subject headings and a company authority list. They iterated through these lists using the top down approach, informing the list with their subject area expertise. Then they take the bottom-up approach and add/modify terms that reflect subject headings identified while doing the daily work of indexing (knowledge representation). For my org., this is a daily process since a team of indexers sifts through machine filtered data and applies more granular indexing or alters machine-applied terms. As the telecom landscape changes or as our indexing needs require, terms are added to the vocab's. We have one person who manages/develops them, and a few additonal subject area experts who work on development of new terms in new subject areas. User feedback informs changes along the way. The controlled vocabularies are offered up for use by disparate systems within our company to represent that corpus of indexed data, or slices of it, as desired.

As an IA, I generally work with our taxonomy specialists to create page inventories -- sort of like microscopic content inventories on steroids -- that specify combinations of index terms used to build content modules. As an example, I show a small piece of one of these inventories on my old and dated portfolio. This use of the term content inventory is not typical in our field, I know. What this really is, is a design document showing such things as rubrics of content modules with their associated labels, and database searches that use terms from a controlled vocabulary. Maybe I should present something on this process some day. It's really a hybrid IA and technical document, but it's a format my entire team uses on all data-dense sections of our site.

Incidentally, the taxonomy guys I'm talking about are presenting on this topic at an ARK seminar in NYC in November in case you're interested. They're really smart. Hopefully they will get to network a bit at this thing, because everyone in our group could get pink slips if the cost-cutting winds decide to blow in our direction.

Doing a Content Inventory

Jeff Veen's latest in the Adaptive Path essays is Doing a Content Inventory (Or, A Mind-Numbingly Detailed Odyssey Through Your Web Site), in which he talks about the process of taking stock of client data, mostly as a pre-requisite to building/deploying a CMS within an organization. Includes a link to download the Adaptive Path content inventory template. Related to this article is Janice Crotty Fraser's article in Web Techniques last year.

Taking A Content Inventory

This is where the rubber hits the road for me. In October's WebTechniques, Janice Crotty Fraser takes you through the process of doing content inventory Adaptive Path style, with IA techniques developed with Jesse James Garret. This is the jumping off point for a lot of information organization and taxonomy work -- the content inventory. It is the area where I've spent most of my time over the past year. There is truth in her observation that the work comes down to human hours and excel. A great read for people who want to learn how to use tools to make content inventories work for you and your clients. Here's how Crotty Fraser sums up: You need to know what you have to work with before you can organize it better. The inventory, above all else, helps you get to know the content deeply; this is as important to a re-architecture as understanding user goals and business goals. Make associations across groupings, identify redundancies, and slice it along a different grain.

XML feed