MTS07: Pete LePage on IE7

Pete is a Product Manager on the IE team. His title is “Product Manager, Web Tools.”

I asked Pete to clarify the hierarchy of the IE team because I seem to have met so many different “Product Managers” on the IE team.

The Program Manager is the key writing the spec for how a product should work. That’s Chris Wilson’s role; his official title is somewhere between “Program Manager” and “Architect”. The Product Managers (like Pete) are responsible for making certain end-to-end scenarios work. Pete is one of four Product Manager responsible for IE; Pete’s role is to make sure IE is a great web developer tool.

“The IE team is not about crushing the competition, its about embracing open-standards about making life easier for developers.”

Q: You are aware that your peers are saying things that “crushing the competition”, right?

I am, and I wish they wouldn’t.

Every time we make a change to make IE more standards compliant, we risk breaking the web — we have 500,000,000 users. There was a lot of chatter about how many sites are IE-only and that locks out other platforms, etc. and Pete said, “When you find something like that, tell me, because I’d like to help them fix it.”

There was some talk about Microsoft’s tools encouraging folks to write IE-only sites, but Pete and others pointed out that modern versions of Visual Studio encourage developers to target web standards (though they can be used to target IE-only features).

Someone joked, “Hey, can my mom call you when IE is broken?” Pete mentioned that his mom calls him for support. He pointed out that Microsoft has a free IE7 support hotline that any user can call. (He didn’t know the number.)

He did the Don Box open up notepad thing and wrote down a bunch of the questions the group has:

Q: What do you want to see next?

Pete started out pointing out that they hired Molly H. to bring more respected influentials in-house to influence standards. He also pointed out that they take the CSS spec seriously and all have printed versions they read. Folks chimed in with various wants:

• improved support for unencumbered media formats, like OGG
• canvas tag and stuff from the WHATWG
• an easier add-on model than COM
• in-line search like Firefox

Q: How often do we ship, and how do we deal with WU/AU?

“We committed to ship every 12/18/24 months. We’re still behind that commitment and you can expect to see regular previews and releases of IE.” And lot of folks complained that the IE7 auto-patching feature is automatically applied before many users had a chance to to decide, such as in corporate environments. Pete asked, “What would you have us do differently?” He pointed out that we knew in advanced that it was coming and it arrived when MSFT said it would. The complainers on this issue didn’t really come up with any coherent feedback on what to do differently.

Q: When are you going to switch to the gecko engine?

“We are using Trident, its very baked in to our system.” He mentioned that using a JS engine other than Trident’s is very difficult. I chimed in and asked if they were considering integration with Tamarin or at least ensuring compatibility with the flavor of ECMAScript that Tamarin supports. I asked what he thought of JS2 (ECMAScript 4) and Pete replied that he was a bit worried about the impact that revising the JS runtime to such a large degree (to support JS2) would have on existing JS code.

Q: Prioritizing incompatibility issues

Pete talked about Quirks versus Standards rendering models. I asked if there was a way to see what mode the page is rendered in. He said there wasn’t — I asked him to add it.

Q: How are we contributing back to open source?

“We’re a closed source proprietary browser and that’s not going to change anytime soon.” The questioner clarified that he wasn’t talking about open-sourcing IE, he was talking about leveraging the community to fix issues in IE. Pete said that they are getting more involved in the standards bodies, they went down to San Jose and did a panel with Opera (Hokum) and Firefox (Mike Shaver) at the Silicon Valley Web Builders User Group, and so forth. He also pointed at that they are participating with people like Molly and being at cutting-edge conferences that aren’t MSFT events, etc. He asked the questioner, “Are there better ways to do that?” The questioner didn’t proffer any ideas.

Another questioner suggested that MSFT hire someone to work on Firefox and other browsers to be a liaison between IE and those projects to suggest features/patches, etc. that MSFT apply to IE. “I hope you have seen with IE7 a significant increase in our commitment to standards, and as future versions ship, you’ll see more of that.”

Folks suggested that the IE team should come forward and tell the community what changes will impact the user base in advance. I pointed out that the IE7 team actually did a great job of this, but told them that they should be more open about plans to support emerging web standards like the canvas tag and not hide behind patent policies issues, but then… I caught myself mid-stream recalling the recent Apple canvas flap (with Apple claiming a patent on canvas) and Pete looked at me and smiled. “Exactly.” This was a bit of a watershed event for me as Chris Wilson’s complaints about the patent policy of the WHATWG being incompatible with MSFT (as compared to W3C) suddenly seemed prescient. I’m not a lawyer, so I’ll beg off further speculation on this point, but it shut me up really quickly on the canvas support issue.

Q: How are we getting to a standard everyone can use?

They are joining the new W3C committees on HTML, including the new HTML Working Group. Someone asked if they would stop adding proprietary features and just “community” features. Pete said, “We’ll always have proprietary features, but we’ll also support web standards.”

Q: How could we create detailed function specs and docs for developers on the behavior of IE?

We asked Pete to provide detailed specs on how IE works to cover situations like, for example, when IE caches and when it doesn’t in the context of dynamic requests, and so forth. I asked Pete if they could provide some sort of liaison to the community who in cases like this could look at the source code and provide detailed documentation on how a particular aspect of IE behaves. He agreed this would be cool and in chatting with him after the session, he thinks they could make this happen. Wow, imagine a world where instead of having folks bang their head against the wall over and over MSFT could actually tell us exactly how detailed aspects of the browser work. There are some problems with the concept, to be sure, but…

In after-the-prezo chit-chat he also mentioned that MSDN is getting a makeover in the next few months.

We also told Pete that better debugging tools would be huge. In particular, I told him that the lack of visibility into the memory management of the browser makes developing large-scale Ajax apps a huge pain.