For a few years now, I’ve been talking about a technique that everyone can leverage to get metadata into SharePoint — without the users having to do something different than they normally would. I’ve talked about the general principles in the whitepaper I wrote for Microsoft “Managing Enterprise Metadata with Content Types.” That whitepaper is focused on understanding how SharePoint’s search features can be activated for use with the metadata that users enter — and it walks you through a step-by-step process for creating a word document that uses quick parts to enter metadata. For those of you that haven’t seen it, a quick part in Word sits on the surface of the document. When a user enters information into the document, the information is copied into the properties by Word. When the user isn’t hovering over the content, you can’t even tell that the text isn’t just normal text in the document. Take a look at the following which has four QuickParts on it. I’ve clicked in the one for First Name:
The net-net is that this is a quick way to convert a paper form put together in Word into a “smart form” that can be used online.
I’m often asked why I’m not talking about InfoPath. There are a few reasons, not the least of which are the issues with getting InfoPath to play nice with my content types on SharePoint. However, the other reality is that not everyone can use InfoPath. Either it’s not installed, licensed, or it’s not licensed for Forms Services on SharePoint. The final reason is because most folks know that InfoPath is SUPPOSED to handle data. It’s assumed that you can copy properties to SharePoint and back. InfoPath is much more powerful and is essential when you need a one-to-many relationship in the data. Forms like expense forms are much better in InfoPath than Word. However, there are a ton of forms, like vacation requests, which don’t need the one-to-many relationships that InfoPath would provide. It’s easier to teach end users one (or two) new things about Word documents and get forms than trying to push them into a new forms technology.
Historically, the problem with using Word documents has been that the techniques outlined in the whitepaper was only shown through the UI. I hadn’t shown how to bundle the work that was done in the Web UI into a deployable content type via a WSP package. I first started demoing this at TechEd EMEA November 2008, however, the approach I was using had a problem. You still had to upload the template after deploying the content type because of a defect (confirmed) in SharePoint. The short is that SharePoint was mangling the document when the content type was associated. However, with the help of some friends in customer support we’ve got a work around.
Typically when I’m creating content types from content types I’ve developed in the UI, I use Andrew Connell’s WCM STSADM command extensions and then strip a few things. His tools extract the exact XML in the definition of a site column. This includes the attributes for Version, StaticName, and SourceID. These aren’t attributes that should typically be set. Version isn’t supported at all, StaticName is only for the office clients, and SourceId is supposed to be set by the framework to the feature that created the field. SourceId is supposed to help you work back to the feature that created the fields. Well, as it turns out if you set this field to be the same as the sourceId for the fields that you added in via the UI, SharePoint doesn’t mangle the document template. (So leave the sourceId in — for this case only).
With this new piece of data you can create the form in the UI using the method in the whitepaper, extract the site columns and content type, create a feature for the site columns and content type, create a feature to deploy the template, and deploy them in a WSP.
There is one remaining issue. One of the things designed to help users enter metadata gets in the way. The Document Information Panel (DIP) is designed to help users remember to enter metadata. It is displayed when the user creates a new instance of a document. There isn’t a way to suppress this out of the box. Even if you go in and set a macro on the template to hide the DIP it won’t work — because the DIP is loaded asynchronously and is displayed after the AutoNew macro in Word. I believe it should be possible to create a DIP that does nothing but close itself, however, I’ve not had a chance to test it. For now, I’ve just been telling people to close the DIP manually. The DIP can definitely take up some screen real estate if you don’t.
If someone develops a technique for creating a DIP that closes itself send me an email and I’ll link to it from here.