As we migrated to Microsoft SharePoint 2007 this last year, there were some obvious pain points.  It is a lot of work migrating content from one system to another. Even though we were only moving to a newer version of the same program, it had a lot of new features we had to learn.  Making this change also gave us the opportunity to work in improvements to our “Dewey Decimal System” for our library structures. 

I now have even greater respect for librarians that have to perpetually give order to the unordered universe of human thought and endeavor in trying to make a library and card catalog practical.  We are facing many similar issues.  It is like a music collector or music writer trying to describe or categorize a type of music – how to define a genre?  What if the music fits more than one genre? How many sub-genres are acceptable?  Do you put a song (i.e. piece of content) into more than one genre or do you create a new genre that encapsulates both?  Or maybe you add two or more genres to the song, giving it more than one ‘genre’ value it can be filtered by.

Ok, so that doesn’t sound too hard.  But how do you keep the library from breaking when it grows exponentially?

Metadata and filters that are too specific can be too limiting.  The result is that you might as well hard code the asset into the template file.  But if the metadata is too vague (such as not having enough columns and values filled in), the content may pull into the wrong message.  We need to make sure we filter on enough unique values so that content remains accurate while the content libraries grow.  When working with this kind of complexity, it is easy to see why people can get doctorates in the field of ‘information science’.

It does take more set up time and more pre-planning to create these libraries in such a flexible fashion. But the long term payoff is well worth it.

The metaphor for our Content repository is aptly called a library.  In setting these up, we have to take the client company’s whole infrastructure into account.  We create a content library that is organized to grow and remain flexible.

It is like creating a Dewey Decimal System.  We have to categorize the type of content, who can access it, and finally what type of person will be the recipient.  We create a lot of metadata for this.  It can take a while to set up initially, but once it is running, it can be quite powerful.  It is rewarding seeing this functioning across various product lines or markets to pull in content that is still timely and relevant to the customer.

We can pull documents like PDFs, DOCs, and PowerPoint presentations.  We can pull in images and videos.   Pulling in text strings and HTML blocks means we can create more flexible and dynamic HTML templates.  This can help our efficiency quite a bit.  If we have to update a string across all templates for a client, we can just update the string once in the library instead of editing the text in each template file.  The same goes for updating hyperlinks. 

The power in this is especially noticeable when working to localize messages and content into different languages.  We can put all the localized content and text strings into SharePoint and then simply filter on the Language metadata column.  This means we can create one message that lets you choose the language and then all the content is rendered in that language.  All the XML & XHTML code is done just once, instead of creating XHTML files for each language.

It is easy to recognize the benefit of using these dynamic content library structures.  We see metadata being used every day – for search results when shopping online; metadata added by default to image, audio, and document files; and it is used in targeted ads.  When making a business case for a project, how much time and resources do you allocate to creating a robust metadata infrastructure?
Next up:  Feeding the Library – what happens when you feed the library lots of content?