So, after a few high-powered days of Microsoft Office development I can look back on a week well-spent. I got amazing feedback on the preconference which Ted and I did, as well as the CLI304 session on using Open XML and VSTO to support your document based processes. First of all let me thank every last one for being such a great crowd to talk to. I had an extremely good time at the Office Developer Conference 2008, and given the feedback I expect you to have had the same. If you haven't done so already, please take the time to fill in the session evaluations at the ODC website. It is the feedback that allows us to improve sessions in the future (I learnt something about a 'p' word, do know I was referring to cats, nothing else J).
Now to get into my high-speed, lots of fun, running in overdrive session on Open XML / VSTO I delivered… Main feedback is that it was somewhat overwhelming (so much cool stuff, so little time J), so this post is dedicated to providing you with the overview of what the session was about, and my next one shows code so you can repeat this yourself.
So, let's get going….
Basically the session was about how to generate documents in such a way that allows artists, industry experts, and IWs to work together to create a consistent set of content that can be pushed out to your customer through client- and server-side generation. My ideas on this went something like the following:
Artist Templates
First of all each document your company creates needs to basically look good. Which is where an artist would come in to create something I called an artist-template, because I lack the expressive capability to provide better wording for that. The artist template can contain logo's, addresses, perhaps a cover-page and page numbers, depending on the goal of the artist template (I had split the goals into template types such as 'large document', 'small document' and 'letter'). The artist template was stored inside SharePoint to allow for the addition of meta-data ('large document'), the use of workflow to provide process around the artist templates, versioning of templates, and the whole shebang of features that SharePoint provides.
Building Block Templates
Now the second deal was about structured content. If you take a large organization there are field experts who are there for their specific set of knowledge (like a medical expert who consults in processing new medical insurance requests for the Contoso Medical Insurances firm). The IWs who are the one communicating with the customers and who are the ones actually processing documents are not likely to be the ones holding the key knowledge that drives their day. In order to provide structured content to be used by all IWs you need to have the field experts maintain their knowledge in such a way that an IW can use that for creating the communicative documents they send to the customer. How to do that? Building Block documents and Content Controls will be the way to go, more on that in a minute. Besides technical correctness, a document needs to be well formed, conform to legal standards etc… My idea around this is that a document is built up out of semantic pieces of content which flow together to form the final picture that your customer sees. The basic layout of a document take part in the semantic structure (a document has an opening, body of content, and closing). The content can then be further split up into semantic areas. The cool thing is that you can use the Content Control feature of Microsoft Office Word 2007 to provide this semantic structure right in the document, and operate on that using code (something I didn't show too much of given the little time I had).
So, a reply to someone requesting a medical insurance might be semantically structured in the following way (simplified of course, let's call it semi real-world J) In this sample the customer requesting insurance is asked to undergo an extra medical check before he can be insured. This is due to the customer indicating that he suffers from what-ever medical condition that the insurance company wants to have checked further before going forward.
Of course when the customer has no medical conditions to check upon further, the semantic structure changes somewhat.
The thing to note here is that document semantics form a tree structure. This will later allow you to provide contextual UI inside the tools used by the IWs to create the document. Another thing to note is that each piece of the semantic structure also defines a tree of data. For instance, the opening of the letter (Dear Mr Customer) needs to know the customer name and gender to be rendered correctly. I didn't really go into this during the session, but my approach would probably first go into the organization to see what semantic bits are there, and see what data they define, and define a model for coupling the two in some neat fashion).
Each of these blue squares in the image above would be a separate building block that you can use, and inside the 'Response' block you can use the 'Outcome', 'Reason' and 'Task' blocks. I choose to have a separate Microsoft Office Word 2007 document for each building block, which are again stored in a SharePoint based repository for handling workflow and versioning.
Still with me?
Document Templates
The structure that is defined in the image above is not created by a field expert, they only have the required knowledge for creating a single block, but not the knowledge on how these blocks should be combined to facilitate in the creation of the 'real' documents used by the insurance firm. That's where the third guy comes in. The document manager knows that the organization needs a document to respond to insurance requests, and has detailed knowledge on the semantic structure of that document. They also know that such a response to insurance requests is a 'small document' type of thing, so they know which artist template to use. What you can now do is create a simple wizard interface (preferably one that operates from right inside the Office 2007 workspace) that allows you to select the building blocks you want to use, and which allows you to create the semantic structure out of the building blocks created by the field experts earlier on.
The following two pictures from the slide-deck gives you an overview of the process I just described:
So, now the only thing to do is implement this beast. If you take a look at Microsoft Office Word 2007 there are three key enabling factors which makes your life a lot easier, and which allow the key stakeholders (artists, field experts, document managers and IWs) to work from right inside their favorite environment which I'll leave to your imagination)
Document Building Blocks
The first very cool thing you can now do in Word 2007 is take a part of your document and store that inside a container (a dotx template file) which allows you to copy that content into new documents in an easy and reliable way. This is called a 'document building block'. Using the out-of-the-box experience you can insert the building block from the Insert tab on the ribbon, or you can insert a Content Control into the document and select the blocks using that Content Control. The cool thing is that the Content Control can be stored as part of a building block again, which allows you to form the tree structure I showed earlier in this blog post.
Content Controls
So, you know that a Content Control can be used to pick a Document Building Block, but what is a Content Control exactly? It is sort of similar to a bookmark, but only on steroids. A Content Control provides you with the option of providing a user interface (drop-down list, date-picker), right inside the document. Content Controls can be tagged to work with them through code, and they can be locked to prevent accidental removal (which would break the semantic structure of the document). You find Content Controls on the Developer tab in the Word 2007 ribbon (The developer tab is hidden by default. To show the developer tab, open the Word options).
Data-binding
Data-binding is something that you can do in ASP.NET, Windows Forms, and other platforms, and it has now made its way to the Office platform as well. You can data-bind certain content-controls like a date-picker, and this will make your life for working with data in the document a whole lot easier. I didn't go into detail on this during my session, and I'll leave it out of the discussion for now.
So that's it for the basic background of my session, my next blog post will explain the code that I created to support this process.