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.

Lou Rosenfeld shares some more IA heuristics, this time focused on search.

The Dublin Core 2003 Conference is currently going on in Seattle this week. A couple of the attendees and I will be sharing our notes(and photos) when we've recovered(it's actually still going on). But until then, enjoy the conference proceedings online.

Heidi Adkisson is launching webdesignpractices.com this month. She has a sneak peek up for navigation practices (linked above).

Basically, the site takes her Masters thesis study of 75 ecommerce sites and makes it more accessible online. (For the impatient, you can download the 8mb pdf of Heidi's thesis).

I met Heidi at the IA Summit in Portland, and think that this will be a great resource for the community. I'm hesitant about considering common practice to be best practice (as gets implied in surveys like this), but it's good to consider if something really is a de facto standard, and what reasons your own project has for doing things differently.

The Western States Digital Standards Group (WSDSG) Metadata Working Group's best practices for using Dublin Core metadata elements is an excellent resource to consult when starting a project requiring metadata. The group came up with a set of guidelines for using Dublin Core during the development of a "Western Trails" digital library project. From the document's purpose and scope statement:

You can download the 1MB PDF from the Western Trails site.