Many developers identify and document developer scenarios while designing software before writing functional specifications. Sometimes this process consists of the construction of ‘story boards’ that show how the user moves from point A to point B to accomplish a specific task. Sometimes you may do formal use-case analysis. You may even mock up a scenario using PowerPoint or a modeling tool. In most development organizations, you write a formal specification that outlines and details the scenario.
This 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.
- Office/SharePoint Building Blocks and Developer Stories
- Overview of Office 2010 Application Development
- Office Application Scenarios
- Understanding the Three Approaches to Office Development using VSTO
- What is the Difference between ‘Word Automation’ and ‘Word Automation Services’?
- Understanding the Architecture of Office 2010 Managed Add-Ins and Customizations
- Understanding the Difference between Custom Task Panes and Action Panes
- Microsoft Word 2010 Developer Building Blocks
- Comparing Excel Automation to Excel Services
There are a few general types of scenarios.
Scenarios that retrieve external data from a line-of-business system and surface that data for users. In these scenarios, you typically will generate documents, spreadsheets, or presentations from that data. For example, you may provide an approach for sales people to pull sales projections and results from a server to create a status update PowerPoint presentation for a sales meeting.
Scenarios that make it easier (or perhaps simply possible) to accomplish a specific task. You may have a mathematical optimizer written in FORTRAN that performs some heavy-duty number crunching, and integrates the results into a spreadsheet or word document.
Scenarios that augment the experience for a user. You may build a system that retrieves reference material automatically for specific content in a document or spreadsheet.
Scenarios around document generation. You may generate hundreds or thousands of Open XML document based on data stored in SharePoint lists or external systems, and then convert to PDF and print them.
Scenarios around process and procedure. Scenarios can be as simple as a document approval process, or can be as involved as shepherding a RFP through generating a proposal to signing of a contract.
These are a few examples of varieties of scenarios, but, of course, there are many more. You implement each developer scenario by using one or more Office developer building blocks. Of course, as systems designers, you must determine your own scenarios. Then, your task is to be familiar with the available building blocks that you can use to implement your scenario. In many cases, you have more than one option; each option has different characteristics, and one option might suit more than another for a particular scenario.
The building blocks vary for each Office application. Word and Excel have the highest number of building blocks, which makes sense due to their heavy usage and large number of scenarios where you want to extend them. In this article, I list the Office developer building blocks for each of the Office applications. I explain the use case for each building block, and provide links to further information to help you get started.
Developers typically extend a single Office application at a time. You may need to extend Word 2010 to enable certain content authoring scenarios. You may need to extend Excel 2010 to enable high-performance calculations that would be difficult to implement using just Excel. You may need to enable sales people to build PowerPoint presentations that are directly targeted towards the specific customer they are seeing that day. For each of these specific scenarios, you typically extend a single Office client application. There are some scenarios where you need to work with word-processing documents, spreadsheets, and presentations simultaneously, such as the scenario presented in Assembling Documents on SharePoint 2010 Sites by Merging Content from Excel, PowerPoint, and Word, but for most scenarios you extend only one or another of the Office client applications.
Development of an Office application is singularly different from other types of development. From the developer’s point of view, the Office clients comprise a framework – a large framework with a remarkable set of capabilities, but first and foremost the Office clients are end-user applications. This impacts our development in interesting ways.