An interesting discussion today with a developer friend of mine (who happens to work outside of Microsoft) lead to a question I've actually been asked a couple of times before: Why didn't we keep investing in the 'webview' feature of Win2K and below? Why did we replace it with the non-hackable "common tasks" pane in Windows XP?

[Some background: "webview" originally came about with IE4 development (AFAIK - if anyone remembers better, feel free to correct me) and basically hosted the mshtml engine in a sidepane of Explorer. It allowed us to do things like host a little image preview if you had a picture selected, or tell you how many files you had selected and how big they were. We provided some simplistic (and let's be honest - not so great) UI to edit this up a bit, and enterprising individuals easily found ways to add their own templates and HTML here. It was a neat little hackable space in Explorer with a number of limitations, and some people like that sort of thing.]

There's two answers to the questions, a long one and a short one. I'll start with the short one and you can skip the rest if you want. The short version: Because the priority for XP was to build a great task-based user experience that worked well, looked good, and functioned properly, and the old implementation was just not up to the task.

The longer version of the answer is: It's because there's only so much time to design, write and test so much code. See, the reason this particular question is posed is because it's inevitably followed up by "I wanted to build cool XYZ thing, and you guys were on the path to let me do that!" Basically, people want to build their little add on bits and use that piece as some extensible architecture of the Shell. There's nothing inherently wrong with this desire: people want to leverage pieces of Windows (or anything else) to add some functionality, create some feature, or just make it customized (to some extreme) to their tastes. This becomes more burdensome in some ways as it becomes platform. Either way, what happens is that you begin to make the tradeoffs:

  • How hard would it be to build this feature?
  • What are the costs involved in making it a robust platform piece?
  • How many developers/ISVs/etc will take advantage of it?
  • How many users will benefit (and by how much)?
  • And most importantly: What are you willing to give up in order to do it?

The truth is, these are hard questions that need to be asked of every feature (in every product, at every company, etc.). The difficulty in answering this can vary a fair amount. Like pretty much anyone would, we try and put the smart people on these problems, have enough people ask the questions (and figure out the answers) and make the appropriate call. When you are discussing the Windows Shell, they can take on some extra weight - there are literally hundreds of millions of people to please. That's not to say there aren't other projects facing the same hurdles, but to put some perspective around it. How do you make sure to balance everyone's needs and provide what they want? What is the minimum bar necessary, and what is overkill? For example, if we continued to develop 'webview' would we have had the manpower/time/etc to do the Start Menu work? Just what the heck would it have costed to continue developing it?

In the end, for Windows XP, we made a couple decisions (as you can clearly see if you are running it). We kept support for 'webview' where we did not replace it completely (in our estimation - you can clearly disagree :)) and so on. Software is never just cut and dry, right? :)