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 blog is inactive.New blog: EricWhite.com/blogBlog 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.
There are a few general types of scenarios.
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.