Office/SharePoint Building Blocks and Developer Stories

For the last few months, it has been my assigned job to think and write about Office and SharePoint development from a very high level.  I haven’t written any code (sadly).  Instead, I’ve been simply involved in a survey, first, of SharePoint 2010, followed by the Office 2010 client applications.  The first result of my efforts (as well as the efforts of many other individuals) was SharePoint Developer Building Blocks: Technologies for Creating SharePoint Applications.  For a variety of reasons, I delayed publishing anything until that article was written and reviewed by appropriate people.  But I’m going to take a different tack with Office client development.  Over the next 2-3 weeks, I’m going to first blog my thoughts on Office client development from an overview level, and then cover each of the Office clients in a separate post.  As with the SharePoint article, I’m going to focus much more on what you can do, and why you want to do it, and less on how to do it.  I’ll link to other videos, SDK documentation, Visual How-To articles, etc. that explain the ‘how’.

This blog is inactive.
New blog: EricWhite.com/blog

Blog TOCThis post is one in a series on Microsoft Office 2010 application development. These posts will be published in the future as part of an MSDN article. As usual, after the MSDN article is published, I’ll place pointers in the blog posts to the article on MSDN.

1. Office/SharePoint Building Blocks and Developer Stories
2. Overview of Office 2010 Application Development
3. Office Application Scenarios
4. Understanding the Three Approaches to Office Development using VSTO
5. What is the Difference between ‘Word Automation’ and ‘Word Automation Services’?
6. Understanding the Architecture of Office 2010 Managed Add-Ins and Customizations
7. Understanding the Difference between Custom Task Panes and Action Panes
8. Microsoft Word 2010 Developer Building Blocks
9. Comparing Excel Automation to Excel Services

So why the term ‘building blocks’?  I suppose the answer is that we haven’t found a better term.

From my limited perspective on the bottom of the heap, inside the Microsoft Office division, as new version of the products are being developed, the folks in charge have various meetings where they introduce new features in SharePoint or Office, and the common term that is bandied around is ‘developer story’, as in, ‘What are the developer stories for Silverlight and SharePoint’, or ‘What’s the developer story for AJAX and SharePoint?’  Then, the job of writers and others is to ‘tell that story’.

The term ‘developer story’ probably doesn't make sense to developers who are not inside the Microsoft bubble here in Redmond, but to me, the term ‘developer story’ is basically synonymous with ‘developer building block’.

One of the problems is that there isn’t any one thing that comprises building blocks.  In some cases, you code some declarative XML.  In others, you write C#/VB.NET code that uses a library.  In still others, you use SharePoint designer to put workflows together (workflows are essentially a declarative programming language).  Therefore, we couldn’t use the term library, language, programming interface, or any of the other terms that we use in taxonomies of developer technologies.  The same issue applies with Office client development.  There are specialized languages (VBA, Access Data Macros), COM libraries, .NET libraries that are layered on top of the COM libraries, declarative approaches, and more.  So building block is the term we’ll use.

When I’ve been examining first SharePoint, and then the Office client applications, sometimes it is a judgment call about whether some particular developer technology is listed as a building block.  My litmus test for this is ‘what do developers need to know about?’  To a certain extent, my judgment has been colored by my personal experience in coming up to speed as a SharePoint/Office developer.  If something confused me while learning about it, then I felt I needed to pick building blocks to prevent (if possible) others from having the same confusion.

In the next blog post, I’m going to write about the varieties of applications you can build with Office.  I’ll also define what an ‘Office client developer scenario’ is.

As I've been making my way through the vast subject of Microsoft Office client development, I've had many 'cool, I didn't know you could do that' experiences.  The best part of writing this series of blog posts is that it is going to be FUN to share those experiences.