Partager via

Windows Live Contacts Gadget Beta Release

  • Article

I'm pleased to announced the beta release of a new kind of web component:  the Windows Live Contacts Gadget!

What's it for?

The contacts gadget is client-side JavaScript that enables end users to use their Windows Live contacts (from Windows Live Mail/Hotmail and Messenger) with third party (non-Microsoft) web sites, conveniently and securely.  The gadget works with any web server, most browsers, and doesn't require reams of license or partnership paperwork with Microsoft.  You don't have to assimilate your web server into the Microsoft collective in order to play with Windows Live contact data.

What's the benefit for end users?

Convenience and confidence. If you're shopping for flowers for Grandma online, it's much easier to tell the contacts gadget to give Grandma's postal address to the florist site than to type in her address each time you visit the site. 240 million Hotmail and Messenger users have already amassed some 14 billion contact records. Wouldn't it be nice if you could use your contacts for things beyond just Hotmail and Messenger?

What's the benefit for web sites?

Higher completion of orders (by making address entry easier), low setup cost, and new app scenarios.  Wouldn't it be nice if your web apps could tap into those 14 billion contact records?  (With end user approval, of course)

What's special about it?

The contact gadget aggregates UI and contact data across multiple domains without requiring any special server support - it's all done on the browser client, in JavaScript.  Normally, if you wanted to splice data from another server into your web page, you'd need to implement some sort of logic on your web server to handle relaying the data from the other server to your browser through your domain.  For sensitive data you'd also need to work out some agreement with the data provider so that your server could access the data on behalf of the end user. 

If that were easy to do, then everybody would be doing it, right?  In truth, it's a royal pain in the neck, and a little scary on the security front.  As a result, the web today consists of a forest of isolated silos.  Users can move freely between sites, but they can't take their data with them.  Each site has its own login system, another username/password for the user to keep track of, another collection of user preferences to configure, and another island of the user's data that can only be used with that site.

The Windows Live Contacts Gadget is a step in the direction of user data accompanying users as they wander freely between web sites.  The data is within easy reach of the user, but not available to a web site until the user selects exactly which data to submit to the web site. 

How does it do it?

It's really quite simple, actually:  magic.  Or pretty darn close to that in the severely constrained world of JavaScript. Cross domain scripting (XSS) is generally associated with "exploits" but in the contacts gadget we're using valid DHTML techniques to build secure, user-controlled data sharing.  Since one end of the data channel can't see the other end, this general category of XSS has picked up the nickname "wormhole" in the JS community.  It's a fun metaphor and moniker, but if anyone says "Voyager" or "quantum singularity" I'm going to have to hurt somebody!

How do I use it?

Check out the two sample apps on the Windows Live Contacts Gadget intro page on dev.live.com, as well as the Building a Mashup with the Windows Live Contacts Gadget and Virtual Earth article just posted to MSDN.  I'll be posting more examples and walkthroughs this weekend.

It's a Beta

Keep in mind that this contacts gadget is a beta release.  It has a few rough spots that we're still working out, but shouldn't prevent you from trying it out or even brainstorming what you can do with it.  We plan to push out updates early and often as we fine tune the hoop-jumping that goes on behind the scenes. 

The API is stable and not expected to change for release.  (There's only one function in the API - how hard could it be?)  File names and URLs should be stable during beta, but all the URLs will change for the 1.0 production release.

I'm a little pressed for time at the moment, so I'll wrap up this first post now and do a few more posts this weekend when (hopefully) the deployment drama has subsided a bit.

Comments