If I was to go work for another team inside Microsoft right now, I think the team I’d be most tempted to work for is the Outlook team.
Why?—because in my opinion at least, Outlook is the next big emerging developer platform at Microsoft and building developer platforms is fun and exciting. Think about how many millions of people spend their days “in Outlook”. If I were in a corporation building a solution for these people, I’d want to build it in a way that’s tightly integrated with Outlook. I’d want to present corporate data there, track tasks there, integrate with contact data, integrate with calendaring, etc. I’d want to turn Outlook into the portal where my users get stuff done.
Certainly this is already being done today—I love plugins like NewsGator (written in managed code baby!) that integrate with Outlook. The activity in this area is amazing. For example, try watching the slipstick.com feed for a while and see all the cool third party software being developed for Outlook.
The problem is that integrating with Outlook is harder than it should be. Despite this, people are navigating around the occasional land mines in Outlook add-ins development and getting it done anyway. The Outlook team knows this and they are working to improve this—so this is the part where I give unsolicited advice. This advice is not really just specific to Outlook but most of it is applicable to any application that wants to be the next emerging platform and attract developers to it.
First a little background. In a previous lifetime, I worked on a product called iGrafx FlowCharter Professional at a company called Micrografx (now owned by Corel). A big part of my job was to work on rewriting the object model of FlowCharter from scratch. We also created a set of lower level APIs to let you deeply integrate add-ins into the program—and we enabled all sorts of cool things like providing your own alternate views of the diagramming space, creating new app level windows, you name it. Once we shipped, we received the Visual Basic programmer’s Journal Readers Choice Award for our efforts which I was pretty happy about. As a result of that effort and my subsequent work on VBA, VSA, and VSTO I’ve encountered some ideas that can help you when trying to be a platform:
- At an individual shape level—I want to handle the click event for just this shape
- At a “shape type” level—I want to handle the click event for all shapes that are squares.
- At a document level—I want to handle the click event for all shapes in this document.
- At a document type level—I want to handle the click event for all shapes that are in documents of type “organizational chart”
- At an application level—I want to handle the click event for all shapes that are ever created in this application.
And now a caveat for those who are discouraged after reading through all these points—It’s OK to start small. Witness the euphoria over OneNote adding a very simple extensibility story. A couple ideas here—find out what developers really want before building everything under the sun (see 2). Instrument your API during development and measure what APIs commonly get used and what APIs almost never get used—the one’s that never get used might be ones you can remove and make the development experience simpler. You might find that focusing on 6—building a data focused OM first—will give you more bang for your buck.
Now go out and make your application into the next emerging platform!