Looking back, moving forward

I'm back at work after a wonderful three week vacation, most of which I spend in sunny Orlando, Florida. Orlando is a wonderful city, full of fun activities for families (my kids are 15, 13 and 6, and all three were seldom bored). The one warning I would have is for those of you who live in cities like Seattle is that there's no way you can be ready for the heat in Florida in August. In Seattle, it's hot if the temperature gets above 80 degrees. In Orlando, every day was about 95 degrees with a lot of humidity. We wimpy Seattle folks have trouble dealing with that heat, and walking around some of those theme parks was almost oppressive.

It's nice to be back in town, "tanned, rested and ready" as they say. It's also cool to get back and have us be pretty much buttoned up for our RTM release. Most every feature of setup for RTM is now in place now that the setup dev has added some very nice and slick ways of determining used and available disk size. That means that our setup options screen has evolved from being a decently functional page to one with some very nice widgets in it, including one that determines disk size using a standard .NET 2.0 control. If you're interested, I'll ask Paul to elaborate on his control when he gets the chance.

We really only have two more pieces to get in place for RTM, though one is really not planned to be ready for RTM.

The one we have to have for RTM is our SQM data. SQM is a way that users can anonymously send data to Microsoft on the way you use our products. After opting in, if you hit a certain datapoint in your application that's been flagged by the app owner as important, that data is stored in memory as a data blob and then sent to Microsoft. We use that data to help drive changes and improvements to our product. The cool thing to me is that SQM enables us to get better real-world data than what we have now in the SDK. Right now much of our data is anecdotal and extrapolated. Many times we'll go into meetings and refer to newsgroup posts as reasons for us to make changes. However, there's no way of knowing if a newsgroup post is representative of what our users are actually seeing, or if it's one fringe case. SQM data will allow us to take a cross-section of users to get datapoints that are much more representative of what people are seeing and doing.

By RTM we're hoping to track how often users are selecting custom setup options for the SDK. Right now we offer about 20 choices in the setup options screen, but the policies around that are pretty much run internally by our team. Some of the work may be driven by other teams around Microsoft, but we don't have a clear idea as to whether we're providing choices that are meaningful for you. SQM data will allow us to see how many of you actually click those little boxes and how many of you ignore them.

In the future, we see SQM as a way to help drive the future direction of the SDK. We really do want to optimize the Windows SDK for our users, and SQM will allow us to do so.

The other major work to get done is to release the Windows SDK in a localized form in Japanese. We are working at localizing the setup screens and a subset of docs at a minimum. As far as I know, this is the first time we're releasing a localized version of the SDK, so this is an especially exciting task for me to work on. I'm looking forward to sharing more about creating a localized SDK as we move further down the line.

One other nice thing about being at this point in the release cycle is that it allows us to begin to thing about the tasks we want to accomplish post RTM. We know we'll be delivering an SDK for Orcas, and another for the product code-named Longhorn Server. If you have an opinions on how you'd like those products to look, please be sure to let us know. We really do listen to our users.

Comments

• Anonymous
  July 15, 2009
  i wanna go for a vacation in floridaorlando for aweek