IEvangelist's biggest challenge

Sweet, the post about the IE job has been up for two hours, and already the blogsphere is making it clear why it will be a great challenge to tackle.

David Betz:

James Avery:

Do we need a strong evangelist, or what?

We were pretty quiet about IE for a while.  A long while. We're starting the process of making up for that long, dark teatime of the soul.  The IE team is blogging.  There's a developer center, and a community home.  But still, we have a lot of work to do to win back the respect of the community.  How's that for a challenging job!

I'm not on the IE team, but I spent the first 4 years of my career at Microsoft doing development work on projects that delivered their user interface via IE.  Here's what I remember as the "principle" of IE, to use David's words: Empower developers, and make it possible for devs to build great user experiences.

I have no idea if that's what the marketing guys would say is the soul of IE, or even the dev team -- I'm sure there are loads of IE team members who worked on the end-user browsing features who'd say user experience is the soul of IE.  But, as a dev, I loved that IE was focused on helping me.  Is it too bold to assert that a significant amount of the programmability we find in web browsers today was driven from IE's soul as a developer platform?  Here's what I remember fondly from the time in the late 90's when I was working with IE:

  • IE 3 COM/component model.  Using IWebBrowser for the first time was an amazing experience -- there was an IE window, running inside my app!
  • DOM/DHTML -- real DHTML and a real DOM, that let me programmatically reach into the element tree and tweak it to my heart's content.  Again, all easily accessible from any Windows app via lovely COM objects.  My recollection is that IE 4 really pioneered this notion of a full featured programming API for the browser (I don't think Netscape's Layer + JavaScript stuff was as complete a solution?  If I'm wrong, someone will correct me ;)
  • ActiveX -- The ability to embed a full featured Windows app in a web page via an ActiveX control was amazing.  Did it have problems?  Sure, and we're working even today to improve the situation, as evidenced by the features in XP SP2 and newer approaches to embedding Windows code like WinForms User Controls.  But when ActiveX came on the scene, it was really an amazing tool for a developer to have at their disposal.  Maybe this is a sign that in the old days, IE was too focused on enabling developers.
  • XMLHTTP -- It's all the rage now in the context of AJAX, but it came together 5+ years ago when teams at Microsoft focused on how to improve the developer experience for building responsive, asynchronous web apps like Outlook Web Access.

Of course this is all sort of ancient history by now.  The challenge for the IEvangelist will be to reconnect with what the soul of the IE team is these days, and make that visible, accessible and understandable to the rest of the world.  James asks a great question -- what promise is there that the IE team actually has a set of principles and will stick to them for years to come?  If you interview for the job, I will make sure you get to talk to senior folks in IE land.  You can ask them that question yourself, and decide for yourself how much credibility they have.  And you can challenge them -- as evangelist, you are a voice for the community inside MS, your job is to understand what the community needs to succeed, and convincing the product team to make it happen.

If this is the kind of challenge that gets you excited, you know where to go ;)

[updated: minor edit, and added a new category tag]