Share via

My vision for the Windows SDK

  • Article

I wanted to share a recent email I sent to my manager about the my product, the Windows SDK. I thought you might be interested in how I see our responsibilities in the SDK, and how we should go about engaging you users. I'm very interested in hearing your feedback on it....

For the SDK in general, my vision is for an SDK in which our users help to tell us in what direction we should move. The most important thing to me is that we have a dialogue with our users and that they help to lead us in the direction they want the SDK to go. We must blog, attend conferences, do focus groups, visit users on-site, generally get a feel for what specifically we, as an agent of Microsoft and a representative of both the OS and VS, can do to help improve their experiences. An SDK is a suite of tools, and it's contingent on us to make the most valuable set of tools available for users as possible.

Around setup, the vision is, of necessity, very functionally based. I want a setup that allows for builds in any localized language, and which also allows for incremental updates using an easy-to-use update mechanism. I also want a setup that can serve to integrate all SDK content for users, whether from the Windows SDK, MSDN, Visual Studio or whatever.

All that said, we absolutely cannot and should not move away from the core features that our users expect from us. We must deliver quality documentation. We must have great tools that they can use to write better applications. We must have great samples that they can use to help learn and use APIs.

Bottom line is that we must not be arrogant and we must avoid the echo chamber effect. A release that delivers a set of pri 2 and pri 3 features, while neglecting the pri 1 features, will not help our users. A new doc viewer must not only be flashy and interesting and cool, but it must also make it easier to find quality API information and better search results and more content that is relevant to users' daily lives. Unfortunately, many of the pri 1 features may be dull. Getting search to work is a slow and grinding process. I know that very well. But users want it. They demand good search. They tell everyone possible, every time they are spoken to, that that want better search. And they are angry that we have not delivered better search. Search is dull, but it's also essential. And we must deliver it.

We must never lose sight of what our users really want. We can lead them. We can message them to be interested in things we care about. But in the end, we must give them what they really are asking for.

This is part of why the team blog is so important to me: a blog is a place where this dialogue can happen, where people can visit every day and get a feel for the sincerity of our interest in their long-term needs.

That's my vision for the Windows SDK moving forward. Do you think I'm off-base? Is my vision too small? Should we shoot for the stars more?

Comments

  • Anonymous
    March 02, 2006
    I think that one of the most important features is an easy to use update.

    I like how the web setup for the SDK is doing things now.

    :: shrugs ::
  • Anonymous
    March 02, 2006
    Glad you like web setup, that was one of my pet features.

    Updates have been on our long-term agenda, but seem to get bumped down the list by other features.

    What specifically do you mean by update? Something like using Windows Update? A website with the status of updates? Group email when an update is posted?
  • Anonymous
    March 04, 2006
    What always makes me feel strange is search.

    It seems your search technology uses just simple full-text search. So, when I ask some exactly specified API, it propose me many non-relevant items and the reference to API itself does not sits on top of list.

    I think, your search technology should be architected with search scenarios in mind. Of course, plain full-text search is a must. But for some scenarios it may produce not best result.

    Why users search SDK documentation? Propose 2-5 most common scenarios and 10-15 other not so commonly used. And then modify search algorithms to make that scenarios pleasant with your search.

    For example, user may specify property or method name. In such case you should show this item reference at a top. And other articles where that word used as normal word — somewhere lower.

    When user specify exact full name of type — direct user to exactly this information. And you should consider both C# and C++ notation, because C++ uses :: as namespace divider.