Advice for Emerging Platforms

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:

  1. Build real parts of your product on top of your object model and public API. This is the most important idea of all. A big reason why some extensibility scenarios in Office are hard is because the teams building the extensibility aren’t always dogfooding their own extensibility models. Real and important chunks of your product should be built on top of your extensibility model. At Micrografx, we built large pieces of our product on top of our extensibility model. We as developers fixed tons of issues and found the holes in the extensibility model because we were building on it ourselves. The result was a much more mature and stable extensibility model than could ever have occurred otherwise.
  2. Involve other companies and people that want to build on your platform early and often. Even better, rent some office space for them and let them move in down the hall. As they build solutions on top of your platform, they are going to have golden feedback for you. Live for that feedback.
  3. Schedule ad-hoc app building sessions. Schedule frequent app building events in your team. This is where everybody drops what they are doing for a day or two and tries to build various solutions on top of your product. This helps you give you an idea of what works and what doesn’t.
  4. Think hard about version to version compatibility. As a platform you want to make some guarantees to yourself and to your developer. To yourself you want to guarantee that a customer won’t get locked into an older version of your product because a newer version breaks an important add-in--thereby costing you sales of your new product. To your developer you want to guarantee that his important add-ins won’t break in a newer version thereby costing him or her the fire drill of having to go try to figure out why it broke. Think about picking some of the most popular solutions and also some of the lesser known solutions that have been built on your platform. Have a little compatibility lab that runs those solutions when you make changes and makes sure nothing breaks. In addition, start to plan what you want to add for the next version of the product and make sure there are places in your object model where you can easily add those new properties, methods, and events.
  5. Think hard about security. You don’t want to be a vector for viruses. My favorite anecdote in this area is a meeting I attended where Michael Howard spoke. He told about doing a review of a feature being proposed by a certain team. After the feature was described he said, “So essentially, you’re providing a really simple way for an attacker to run arbitrary code at full trust on any machine where your product is installed.” The feature was cut. Then again, don’t throw the baby out with the bath water. There are ways to safely allow programmability—I think VSTO 1.0 does this very well with its “no code runs by default” design. For more on this you should check out Peter Torr’s numerous security blogs on this subject.
  6. In addition to a traditional UI focused OM, think about a data focused OM. UI focused OM’s are great—gotta have them. Developers want to manipulate UI specific things like window layout, buttons, etc. But also think about providing a purely data focused OM. If you can separate your data from your view, you enable developers to do a lot more. Even better, let developers map schemas into your application and then code against their OM—the schema—instead of your OM. The piece de resistance—let developers use the data focused OM’s on the server when your client application isn’t even running.
  7. Strongly type your OM. Developers have grown very dependent on Intellisense. There’s nothing more frustrating than to have a method that returns an object and then try to figure out how to cast that thing back to a typed item. I know there are times when this seems to make your life easier as an application platform developer—but think about the misery it causes the developers using your platform.
  8. Strictly follow a standard. Name things consistently and clearly. Follow the .NET class library design guidelines if designing managed APIs. Use FX cop
  9. Don’t be stingy with events. I know application platform developers are afraid to have a lot of events because they are worried that some third party developer using them will write a lot of slow code in the event and make the product look crappy. You can mitigate this by providing scoping of your events. For example, the “Worksheet_Change” event in Excel is an example of a badly scoped event. Most developers that handle this don’t care about 99% of the changes that happen in the Worksheet—they typically only care about a very small area of the spreadsheet. Let them register an event that only fires when that area of the document changes. In FlowCharter we had a mechanism where for a click event on a shape you could register:

- 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.

  1. Let me get down and dirty with your UI. Let me integrate my UI into your UI. Let me take over a window. Let me modify built-in UI. Worried about letting people do this? Build your own features on the APIs you use to expose this. Exercise and test those APIs. The example I think of here is the Photoshop plug-in architecture. Would plug-ins have taken off in Photoshop if Photoshop itself wasn’t shipping it’s own plug-ins as part of the product? Yes—I know, I’m harping on #1 again. It’s important.

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!