Stephanie Lemieux wrote an interesting post about the optimal amount of content types to use in SharePoint. This is an interesting discussion, because I’m now fixing the content type taxonomy for a client because the original design firm didn’t give them enough granularity in their content types or metadata. I discuss along these lines with every potential client explaining and justifying the time necessary to do a proper content type taxonomy.

Unlike the author’s recommendation in this post I would venture on the side of over-architecting then under architecting. Let me justify it by the following reasons.

Necessary Granularity

Creating content types that are generic work very well as parent content types that you can leverage the power of metadata inheritance on the children, but it doesn’t do justice to the variety of content most SharePoint instances contain. For instance, associating a content type entitled “News Story” to all sub-sites where a department can have their own content greatly increases content query complexity. You could add a metadata column specifying the department or query the library, but what if HR decides they want a custom expiration policy that the other departments don’t need? A new content type is necessary to support this.

Content Types for Each List/Library

Stephanie questions Shawn Shell in the article on a few points one of which being limiting a list/library to a single content type to avoid confusion to the user. First, it needs to be established that every list comes OOTB with at least two content types which are a folder content type and the generic content type for the content (document, item, etc). While you want to not associate a lot of content types to a library I see no reason a single content type to a library is a bad solution. I would be careful about creating 20 content types and then by apparent necessity creating 20 document libraries, because SharePoint provides us the ability to attach multiple content types. Shawn warns against this by being aware that the content types then guide classification. While it’s true that content type architecture has a direct relationship on classification you can’t make a blanket decision such as every content type deserves its own list/library.

Maintenance Complexity

Shawn makes a good point that content types are site collection bound and having to mirror content types between site collections can be an administrative nightmare. I attempt to mitigate this by ensuring that as much as possible that a certain type of content is bound to a single site collection. While this isn’t always the best solution, often a content type such as “HR Policy” will be bound to a single instance to store these content items to reduce content management overhead.

Choosing the Right Designation

I also believe that a lot of the confusion around where content goes in SharePoint can be greatly reduced when you take the time to correctly name both the list/library and the corresponding content types. Nothing makes me cringe more than a generic “Documents” library with nothing other than the default content types. The user is then forced into the same folder structure they had on a file share. While this might be an easy transition for an end user it’s not the optimal solution in the new SharePoint paradigm.

Conclusion

All of the people in this conversation wish to optimize the user experience of SharePoint as well as utilizing all the great capabilities inside of the platform. While each SharePoint IA is unique I would favor more content type granularity for the reasons stated above.