Office 2010 for Developers: Transcript from my training session

During the launch wave we spend a lot of time "readying" various teams around the company and externally about the new capabilities for developers in Office 2010. This is a topic of great interest across our technical field in particular, due to the multitudes of solutions that are built on Office to do everything from document automation to billable hours booking. I recently had to record one of my training sessions. Normally I'm not one to enjoy camera time (I'm much more comfortable behind one than in front), but there is a nice forcing function about these types of presentations that most software people understand (but rarely discuss.) This is a great opportunity to organize your thoughts. Nothing like having 45 seconds of someone's attention to get your message focused on the things that folks absolutely must understand.

As a Thanksgiving treat, I thought I'd pull back the curtain on that process a bit, and in the process unfold my story on what's new in Office 2010 for development. Hopefully this should be a fun post, but I suppose I'll hear it from you if it is or is not.

The format of this talk was as a Q&A interview-style discussion.

 

Gray can you tell me what's different about developing with Office 2010?

"We're investing heavily in this segment. There is a lot to like in Office 2010 for developers. These investments go far beyond VBA & Add-ins that people traditionally associate with Office development. We're moving toward service & data oriented development, focusing specifically on improving end user productivity with line-of-business applications. For the community of VBA developers & VSTO developer base, we are upgrading the environment to support new Office functionality, 64-bit Office and the Fluent User Interface."

What I'm omitting / not saying: The types of solutions and the types of developers for Office is quite broad, and it is a little challenging to summarize in a short "message" without the watery "changing the developer landscape to improve productivity through enhanced tools and services" or other change-the-channel-right-now speak. The fact is that between VBA, OBA, Open XML, SharePoint and other communities, there are tens of millions of people developing on Office in one form or another. We are very excited about that, and motivated to keep this community of folks happy.

 Can you give me a sense for what new features have been added in 2010 for developers?

"Developing successful productivity applications really involves the utilization of 3 core areas. 

Office is the best consumer of SharePoint solutions and new features in 2010 are designed to make SharePoint and Office light up in new ways. SharePoint lists, for example, can be taken offline in SharePoint Workspace, where InfoPath form templates are designed for interacting with those. Access solutions can now be fully migrated to SharePoint in 2010, to the point where Access is used by the designer to build and publish the solution, and SharePoint portals are the place where users interact with that data. BCS, a new feature of SharePoint for creating and managing read/write data connections to 3rd party systems, has a client-side cache and built-in functionality which allows applications like Access and Outlook cache and work offline with LOB data.

Interoperability for Office is a core priority - availability of Office formats and standards-based services connectivity for Office are two examples of how our investments are paying off. We're also improving the development experience for Office. Word Services and the Open XML SDK automate the document assembly that people previously did with VBA scripting of Word. The recent announcement of the PST format specification is a great example of how we're publishing more of our protocols & formats to encourage integration and interoperability with Office.

We're spending time improving the experience for Office development. With .NET 4.0, Office 2010 and Visual Studio 2010, we're doing good things like removing the dependency on the Office PIA's, to reduce the deployment friction. We have introduced a new Application Compatibility Program for Office 2010, to help migrate code from 2003 & 2007 to Office 2010. The compat tools and documentation are available for free, but also appear in several of our enablement channels, including DDPS, MCS, MDT and others. Some of you may have also seen the recently re-designed developer center for Office on MSDN."

What I'm omitting / not saying: That in many ways Office is becoming essentially a wide open surface for external data. BCS is a read/write connector to 3rd party systems. the Outlook social connector is an API to wire social networking feeds into your mail client. Office surfaces the new taxonomy / folksonomy data in SharePoint 2010. Workflow is consumed directly within client apps. Support for REST and LINQ make query-level tweaking of data / content so much easier. The Open XML SDK gives you element-level access to a document, the "File Save As" on a server that is Word Services uses the Word rendering engine that was actually built to work on a server. (the scripted client solutions were not designed to do that, evident by the hassle of managing unexpected dialog boxes and alerts in the VBA / Macro environment). Again, there are so many things worth mentioning here that it is hard to really pull together into a summary. The diversity of Office development is (not surprisingly) a reflection of the breadth of capability offered in the products.

This challenge is a primary reason we invested in a re-design of MSDN. The "re-design" goes far beyond re-arranging the furniture on the site. New tagging schemes, SEO, information architecture are designed to get you to the answer faster. Having spent some time in the past few weeks digging into the PowerPoint OM, I very much appreciate the ability to navigate to key content (like the PowerPoint.Shape.TextFrame.Ruler object without having to use the search field.

Privately I worry a lot about how to strike a balance between discussing capabilities, features and categories of functionality. Level up too high, and it reads like marketing language. Level it too low and you risk people not appreciating the breath of the offering, and how much of the daily business productivity solution space that Office is capable of absorbing. When I see corporate developers trying to recode pivot tables in a web page, I scratch my chin sometimes and I wonder what we can do to help customers take more value out of what they already have sitting in front of them.

You mentioned VBA - is this still going to be supported in Office 2010? I keep hearing that it is going away.

"VBA is a very healthy and active community, and VBA is a very important part of Office, including the 2010 release. VBA is not going anywhere. In fact, we have upgraded VBA to support the new, native 64-bit Office client. We love VBA. Please continue using VBA."

What I'm omitting / not saying: . if I had a dime. VBA is something we take pretty seriously on the product team, for two reasons. The first and obvious reason is that countless productivity solutions are written in VBA. The number of VBA coders is likely in the tens of millions - that by itself should be a good reason to care about anything. But VBA is also a primary gateway to Visual Studio. Many VBA coders cross the bridge into more professional development. I am one of those (translating my Tandem / TACL skill set to the world of .NET). The Developer documentation team at Microsoft writing the material for VBA is painstakingly precise. The amount of energy they invest in understanding the needs, likes and dislikes of MSDN subscribers is incredible. By the way, if you're reading the documentation on MSDN, you should use the rating / feedback tools on the site. The teams use them more than you might think.

What are the gotchas that Office developers should be looking out for?

"The 64-bit transition is one that people are going to have to pay attention to. 32-bit and 64-bit solutions have to be compiled separately. Some of the 32-bit code will have to be updated for 64-bit. ActiveX and COM-based addins will need updating. Managed code should be fine, for the most part. Our application compatibility tools will help identify areas of your projects that need updating.

.NET 4.0 presents an interesting opportunity. If you've written an add-in that uses the Office PIA's, it might be time to upgrade that to .NET 4.0 and drop the PIA's - one less thing to worry about during deployment. We're also including the VSTO runtime for Office into the Pro Plus builds, this should make things a little easier as well.

Lastly, the Fluent User interface lands in all client apps now. Outlook, Project, Visio, SharePoint workspace, etc. So if you have an add-in for some of the 2007 or 2003 apps based on the buttons, it's worth paying attention to how they show up in the Fluent UI."

What I'm omitting / not saying: . not a lot really, other than to mention again that the App compat tools are a big deal and people should take advantage of them. They will definitely help. If I were to really expand the category, I'd say that folks should take a good look at what they've built and see if there is an opportunity to move some of the client-side scripting into SharePoint, particularly around documents. The environment is so much better on the server side to do that kind of work, we're very hopeful to see adoption take off quickly for it.

Last question, if you had to explain in one minute or less why companies SHOULD be developing on Office, what would you say?

"The average enterprise has 51 line of business applications, and presumably, each of those drives a set of applications. Imagine if you are an end user who is asked to work with even a fraction of those - think of how much investment is made in training people! Wouldn't it be better if everybody did all of their calendaring in Outlook - where they do the majority of scheduling already? Why do forecasting in a data grid on a web page? Why not do it in excel, where all the tools (like Solver) are available and can help users be more effective? Leveraging office as the user experience for business applications - with SharePoint or with other application platforms - makes a lot of business sense and makes users more productive faster."

What I'm omitting / not saying: . most CIO's get this. Office client may not be the first thing people think of, but when you put it into simple economics, it's hard to argue against. I have had countless conversations with architects that gravitate toward Office client as the landing spot because of the end user adoption issues. Office makes it very easy for people to get going. There are lots of great things to be done on the Web, and there is a lot of activity around that, for sure. But when it comes to measuring up on ROI, and when time to market counts, Office client wins, a lot. We might not be the ones wearing the hot pink tuxedo or the glow-in-the-dark dress at the dance, but we have the most dates, know the most dance steps, and we don't step on your toes.

Comments

• Anonymous
  January 01, 2003
  Anon, perhaps you should identify yourself here. Let me just say first that it really is great to see someone with the depth and experience you apparently have with Word programmability. I think you might be under the impression that the existing capability / extensibility in Office or Word is changing. That is not the case. Regarding the support issues, I'd say that enterprise-class technical support involves a fair bit more than "fix the popus up problem." Issues like security fixes, bug fixes etc matter a bit as well. I guess it is good news that you're not experiencing any of those things. Word Servcies is a feature of SharePoint Server, and given the momentum of SharePoint, it is quite useful to SharePoint customers who wish to do more with document automation. Given a choice, the overwhelming majority of customers will opt for a by-design server-side impelementation. Remember that the Open XML SDK is FREE, and that represents a good chunk of the document automation interface that will be used by our customers.

• Anonymous
  January 01, 2003
  Anon, FYI that the Save as PDF functionality has no programmability interface. But you are correct, there is an OM call to disable alerts. There are numerous reasons why the server-based version of Word is a better solution. One of those reasons, for example, is that the client version of Word can only run one instanace at a time. Word Services is capable of firing up as many as it needs. Conversions are also done without UI overhead, resutling in significantly faster throughput. No matter how fast your server hardware is, you can't get around this when you script the client. http://blogs.msdn.com/brian_jones/archive/2009/11/23/open-xml-sdk-word-automation-services-presentation-at-pdc.aspx You should watch this recording, I think it will help inform you on several areas of beneift.  

• Anonymous
  November 26, 2009
  The comment has been removed

• Anonymous
  November 26, 2009
  The comment has been removed