Content Types – Best new SharePoint 2007 Feature

June 22, 2006

Okay – best new feature might be going a bit far, but from my perspective content types are one of the best additions to SharePoint 2007. The funny thing is, they take a back seat to some of the sexier additions like Workflow and Content Management. Content types however play a critical role in both of these new features and many others. They are – in my opinion – the backbone of SharePoint 2007 and one of the new key concepts to understanding SharePoint.

Let me take a step back. What are content types? What content types allow you to do is identify a particular type of document or item (contract, specification, issue, task, etc), and then define all of the different aspects of that item completely separated from where that item might live within SharePoint. So for example, you might define a Contract content type. You would add fields to this content type such as contract type, date executed, etc. You would then associate this content type with certain document libraries such that when you uploaded a new document, you would specify that the document was a Contract and then fill in all the information for Contract content types.

Anyone who has ever run into the following limitations in SharePoint 2003 will immediately understand some of the benefits here:

  • Having to create multiple document libraries to hold different types of documents – but not because it made logical sense to store the documents in different libraries – but because you just wanted different meta-data for different document types.
  • Customized an issues list for your project workspace, then found yourself having to copy those changes multiple times for all the other projects you were running.
  • Created an extensive dev-intensive workaround to enable different document templates for different document types.
  • Published a custom list template only to realize a month later (and 50 new sites using that list template) that you left out a critical piece and that all lists would have to be updated with the new field.

Content types get around each of these limitations in a number of ways.

content-type-settings-tn.gifBut it’s not just objects and their field types that can be defined using content types, workflows can be associated to content types, retention policies can be applied, custom Word 2007 information panels can be created, the list goes on. So content types make it possible to define an object, define all of the fields for that object, associate the appropriate workflows, define policies, etc all irrespective to where that object will ultimately live within SharePoint.

Here are a few key points to mention about content types:

  • Content types are hierarchical. It is possible to define a content type which is based on another content type. The new content type will inherit all of the properties of the parent content type. This hierarchy can be as deep as you like.
  • Changes to the Content Type can automatically propagate to all lists and all child content types.
  • Each content type can have a different document template.
  • The list of content types will be displayed under the New menu within document libraries and lists.

Let me talk about why I think this is one of the best new features. First, it removes the discussion about taxonomy from a particular site or area of your portal. It encourages thinking at a more holistic level: “what are all the properties associated with a contract? What are all the various workflows we might want to execute on contracts?”. Thinking about contexts other than the specific site or list in question helps create a more scalable solution that can easily be adopted across your organization. Additionally, really thinking about the object in question helps ground the solution in the real world – not within the artificial confines of a site or particular site hierarchy.

content-type-inheritance-tn.gifOf course too much “high thinking” and not enough down-to-earth action can be death to any project. You can’t spend all your time interviewing every different department asking all the various ways they might interact with contracts. Sometimes you just have to take what you know now, implement it, and hope for the best. Which conveniently segues to the next reason I like content types so much: flexibility.

See, I can define a content type with what I know today, deploy it, and use it happily for months. Then, when I realize I left out an incredibly critical piece of meta-data, I can just update the content type, automatically propagate that change to all lists and sites using that content type, and I’m done.

This allows you to take a more iterative approach whereby you gain real-world user feedback and adapt accordingly. In the past, this kind of iterative approach would be extremely labor intensive without some sort of automated tool to deploy changes site-wide. Content types make this process possible without all the hassle.

The last area I want to talk about is general architecture. I have a developer background and to me the addition of content types and the way they work reminds me of creating an object model for a system. So for me conceptually, approaching a problem in SharePoint now is very much like approaching that problem using standard object-oriented techniques.

This is a good thing because there are a lot of inherent benefits in object-oriented thinking. It is a solid thought process and helps you orient yourself while wading through the requirements for workflow, meta data, retention policies, etc. It gets you thinking about where there is redundancy and whether or not that redundancy can be eliminated byway of inheritance. In the end you wind up building a more scalable and flexible solution.

Okay – so all of that sounds great but there must be some drawbacks right? Well yes actually. One of the drawbacks in my opinion is that when you create a field for a content type, that field is called a site column and is global in nature. Well not really global – it is available for all lists and content types within the site it was created and anywhere below that in the site hierarchy.

If you’re a programmer (if you’re not, sorry; it was the best example I could think of), imagine that you have a method in a class and within that method you need a variable foo. So you define foo within the method and that variable is only available to that method. If you defined that variable outside of the method within the class, that variable would be available to all methods within that class. And if you defined the variable as protected, that variable would be available to all sub-classes inheriting from this class. This is the way fields created for content types work. When you define a site column on a content type, that site column becomes available to all other content types within the same site or lower in the site hierarchy.

Why is that a bad thing? Well quite simply two site columns can’t share the same name. So if you have a site column called “status” on a task, and you want another site column called “status” on a document, chances are you don’t want the same values for both. One of these two site columns is going to have to get a new name – “task status” for example.

All in all this is a bit of a nit, but it’s an annoying nit. And it would have been relatively easily solved implementing some sort of namespace-type solution.

So to summarize, content types enable us as SharePoint developers and implementers to develop solutions which better map to the real world by defining the types of information our users manage irrespective to the location in which it gets stored. They enable us to do this in a way which is very flexible and can be changed easily moving forward. This flexibility allows us to focus on delivering usable solutions quickly without sacrificing scalability. And that’s a great thing.

Advertisements

7 Responses to “Content Types – Best new SharePoint 2007 Feature”

  1. Prasant Says:

    Really a great blog. I was trying to figure out the content type for last few days and now things are clear.

  2. Jim Lesinski Says:

    Hello,

    I liked your article and it really helped me to understand content types. I did some testing in development and I am wondering if it is possible to create a content type at the MOSS level and have it trickle down to all WSS team sites? It seems only possible at the WSS root and trickles to all child sites.

    Thanks,
    Jim

  3. glen Says:

    Jim,

    Content types will trickle down to all sub webs as long as they are in the same site collection. So it’s possible to create a content type at the root, and then use that content type on webs within the same site collection beneath that root web. This can be done at any level in the hirearchy and all child webs can use that content type.

    Content types do not cross over into different site collections however. In fact, for the most part, nothing really crosses from one site collection to another. So if you are creating sub sites as different site collections, these sites would not pick up content types in the “root” portal.

    One option would be to create your content types as “features” which are installed on the server and available to all site collections. These could even be activated automatically using feature stapling. I haven’t done this myself so I’m not sure what issues you may run into, but in theory it should work.

    Glen

  4. Zandy Garrard Says:

    Glen,

    Nice write up on Content types…clear and concise – I like it. I’d like to add a particular nit on content types which I would love to see if you have a solution for. We have a slew of existing documents out there (lets call them proposals). We are building a new portal and I am going to create a content type called Proposal and have various pieces of metadata that accompany this content type (e.g. client). However, the only way that I can create a document of type “Proposal” is to hit the “New” button and choose Proposal as the content type. Which means that all those proposals that have already been created cannot be uploaded as “Proposals,” correct? If you know of an easy way to get them in as Proposal content types without having to recreate them as new Proposal documents, I would love to hear it.

    Thanks!

    Zandy

  5. glen Says:

    Zandy,

    It is possible to change an item’s content type after it’s been uploaded. I know for sure this works when there are multiple content types associated with a single document library – you can select which one is associated with a particular item. In fact, Content Type becomes a column that is added to the list/doc lib that can be edited just like any other column.

    This approach wouldn’t automatically apply any kind of document template you may have of course, but it will work for metadata.

    Glen

  6. Campbell Says:

    Excellent article. Thanks a lot. I am at the architectural stage of dveloping a web site and am new to WSS 3.0. I knew I needed to learn about content types, but was having a hard time really grasping what they are. YOur article is very clear and was very helpful.

    Thanks again.

    Campbell


  7. […] Content Types – Best new SharePoint 2007 Feature « Look alive … […]


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: