Futurecat - Michael Karek

In June, we announced Project Hilo and promised a set of cool sample applications written in C++. At that time we released the first application in that series. Since then we have been busy publishing some articles that walk you through all the steps that go into developing that application (See Chapter 1 thru 8 here ).

This time we are back with the next application in the Project Hilo series. We call it the Hilo Annotator.

The Hilo Annotator provides basic image editing capabilities but more importantly it illustrates how to take advantage of the following Windows functionalities:

• Ribbon: To provide a modern, easy to use and easy to learn user interface.
• Windows Imaging Component (WIC): To display and manipulate images.

What’s more is that it even tells you more about the Windows Animation Manager and Direct2D that we have seen in the previous articles.

Feel free to download the source code for this application from the Hilo Code Gallery Page. The article introducing the Hilo Annotator app can be found here. As we did earlier, over the coming weeks we will be publishing a series of articles on the MSDN library that will walk you through building this application.

As always, you can also follow Hilo updates on Twitter @projecthilo. Stay tuned and code-on!

August marks the six-month anniversary of the public unveiling of our next-generation mobile phone, Windows Phone 7. Six months is an interesting bit of time; it can fly by, or it can feel like it’s dragging on forever.  The gating factor tends to be how much fun you are having.  For us on the Windows Phone team, it feels like just yesterday that we first introduced Windows Phone 7 to the world. Now, just a blink of the eye and phones will be on shelves.

All of the work of the last six months is certainly paying off, as just about every conversation we have with developers focuses on their strategy for generating more business with Windows Phone 7.  It’s amazing to see so many inspired developers looking to create experiences for Windows Phone 7. In fact, to date there have been north of 300,000 downloads of the Windows Phone Developer Tools.

These first six months have affirmed that a rich application platform based on the well understood Silverlight and XNA technologies, combined with great free tools based on Visual Studio 2010 and Expression Blend is the right approach for enabling developers and designers of all skill levels who are looking to capitalize on the opportunities presented by Windows Phone 7. Throughout the process, the developer community has continued to astound us with their creative ideas.  Their use of the unique Windows Phone 7 features – like our design system, Live tiles, and location and notifications services – demonstrate that the experiences a developer can build on Windows Phone 7 match their imaginations.

While our developer community has been busy stretching the capabilities of the application platform and developer tools, we have been working very closely with some amazing application and game developers to ensure that Windows Phone 7 customers have the applications they expect, across a wide swath of the categories they value. Here’s a just small sample of the variety of companies with whom we have been working:

Adenclassifieds, Allociné (including sister brands: Screenrush, Filmstarts, Sensacine), APPA Mundi Ltd, Artificial Life, Inc., ebay, Inc., Esurance Insurance Services, Inc, Flixster, Intelligent Touch Solutions Ltd., Jobsite UK (Worldwide), Limited, Kelley Blue Book Co., Inc., Le Figaro group, My Interactive Limited, Open Table, Inc., Pageonce, Inc., Panoramic Software, Inc., photobucket inc., REALTOR.COM® Real Estate Search  (Move, Inc.), Red Badger Consulting Limited, rising systems networks GmbH, Seesmic, Sequence Collective Ltd, TBS Field Mobility Solutions, The Associated Press, Touchnote, Trip Mate, Inc., Tx3 Solutions, vente-privée.com, Viadeo S.A

Of course, it’s not just the big names in development who are going to bring great titles to Windows Phone 7 customers.  There are many multiples more of lesser known developers who are looking to be in the Windows Phone Marketplace.  Large or small, all developers will have equal opportunity to capitalize on the first mover advantage of having their apps or games ready at launch.  In order to do that, there are a few things developers will need to do:

1. Register at the marketplace today
2. Finish you application or game using the Beta tools
3. Download the final Windows Phone Developer Tools when they are released on September 16^th
4. Recompile your app or game using the final tools
5. Have your XAP ready for ingestion into the marketplace in early October when it opens

The final tools will likely have some minor breaking changes from the Beta tools, so developers may have to fix some bugs that arise.  The final tools will also include several highly requested Silverlight controls which will make it even easier for developers to deliver high quality Windows Phone 7 experiences.  Also in the September 16^th final release, the panorama, pivot and Bing maps controls will all be available to drop into applications.

The developer tools, controls and application platform are great, but we also recognize the need for smart training.  Just last week we released a course called the Windows Phone 7 Jump Start, delivered by two of our MVPs, Andy Wigley and Rob Miles.  It includes 12 hours of classroom training and supporting exercises.  We have also recently updated the Windows Phone 7 Developer Training Kit.  We will be releasing many more hours of training in the coming weeks and months. For the XNA developers, the XNA Creator Club announced today a new set of educational materials.

We’re also taking additional steps to make sure that the developer experience with Windows Phone Marketplace is even more friendly and intuitive. Ask any mobile developers about their biggest headaches and you are likely to hear about an opaque or non-existent app store ingestion process.  We’ve shown how we are making the process of building apps and games easier for developers, but that is only part of the journey. The next step is getting apps and games in front of customers.  The Windows Phone Marketplace continues our commitment to having a clear and open process for certifying apps and games.  To reinforce that, today we have posted an updated set of Windows Phone Marketplace policies.  Further, in the coming weeks we will be conducting a limited Beta test cycle of our app submission and certification process.  We’re also working on significant changes to our developer portal that reflects feedback from the community.  In those changes, you’ll see enhancements meant to simplify and streamline the path for developers to get the information they need.

So what does this all mean?  We’ve demonstrated that you can build a phone that doesn’t just allow developers to build apps, but rather one that enhances apps with unique features like Live tiles and a design system not available anywhere else.  We’ve shown that a phone isn’t there to just run apps, but rather to understand the full context of what customers are trying to do; integrating functions like maps and search and saving the state of apps so that customers can move between them without losing content or negatively impacting battery life.  Lastly, we aren’t just building a marketplace to deliver apps and games, but rather testing and certifying every one for quality and performance – all the while maintaining a fully open and transparent process to support the developer and their Marketplace success. Our rich developer ecosystem is creating a variety of quality apps and games that take advantage of the phone’s unique features and design.

How will you spend the next couple of weeks?  For the developers telling us how much fun they are having with our productive set of tools and APIs, launch day will be here before they know it.  Developers now know when they will receive the final Windows Phone Developer Tools (September 16^th!) and when they should have their XAPs ready for Marketplace ingestion.  300,000 tools downloads means quite a bit of imagination is going to be pouring into the apps and games that customers see on Windows Phone 7 this holiday season.  The clock is ticking.  Will you be ready?

Six weeks ago we released the 3rd Internet Explorer Platform Preview as part of the commitment we made at MIX10 to release updated platform previews approximately every 8 weeks. Today, we’re releasing the 4th Internet Explorer Platform Preview and with that sending the signal to partners and developers that now is the time to start getting their sites ready for Internet Explorer 9 Beta.

With this latest platform preview we’ve updated the demos on the Internet Explorer Test Drive site to give you a sneak peak of the sort of web experiences developers will be able to deliver on Internet Explorer 9.

Our new open and transparent approach with the platform previews has been invaluable for getting early and quality feedback from developers. As with previous platform previews, our focus remains on:

• Enabling the same markup to work across browsers
• Delivering all-round performance
• Through Windows and modern hardware, unlocking the next class of experiences for the web with hardware acceleration

Developers and partners have been excited to experience the new IE9 web development and design capabilities, including fully hardware accelerating all graphics and text through Windows, our new Chakra JavaScript engine, as well as our support for modern standards like HTML5, CSS3, SVG 1.1 and DOM. We’ve received more than 1,300 pieces of feedback from developers and made many changes as a result.

Dean Hachamovitch goes into much more detail about Internet Explorer Platform Preview 4 over on the IE Engineering Blog.

We’re delighted with the response from the developer community to the platform previews and – as Dean mentions– we have seen over 2.5M downloads of the Internet Explorer Platform Previews and over 20M visits to the Internet Explorer Test Drive site.

Between now and the Beta, we encourage developers to test their web sites with PP4 to make sure well they’ll work with the Internet Explorer 9 Beta and begin to reimagine what they can build when they have a browser that is architected to take advantage of your hardware through Windows.

If you want to try it for yourself, you can visit the Internet Explorer Test Drive site, download Internet Explorer Platform Preview 4 and try some of the new demos like IE Beatz, Psychedelic Browsing and Hamster Dance Revolution.

Last night I spent some time with IE Beatz and came up with this beat. If you can do better – and I’m sure you can – why not post in the comments!

With the Windows Phone Developer Tools in Beta and Windows Phone 7 in Technical Preview, now is the time for you to build Windows Phone 7 apps in earnest. We have refreshed our developer documentation to help you build those apps, and we have two, new design-focused documents to help you make them look beautiful.

First up, the UI Design and Interaction Guide for Windows Phone 7 v2.0 has been updated from the ground up for beta. With additional information and a new layout we hope you will find more readable, this guide provides detailed information about UI elements and controls, UI system behaviors, and the interaction model for the touch interface based on the design system internally named Metro. Designers and developers should read this guide to learn about the dos and don’ts of UI implementations for their Windows Phone apps. We’ve made it easier to find specific guidance by putting it in bold in the right-hand column of each page.

Also available are the Design Templates for Windows Phone 7. These are a collection of 28 layered Photoshop template files and the Segoe WP font family that can be used to create pixel-perfect application layouts, to help guide UI development, or to pitch an idea. These design templates showcase many controls that are a part of the Windows Phone Developer Tools Beta. They also include examples of controls that are a part of Windows Phone, but are not available as a part of the Windows Phone Developer Tools.

Let us know what you think. If you have suggestions or feedback about these design resources, please email us at wp7des@microsoft.com and help spread the word – if you find these resources helpful, please tweet about them.

Today we are announcing availability of Messenger Connect () beta. Messenger Connect allows users to communicate, share, and connect with their Messenger friends on other websites. It is a flexible, yet prescriptive set of APIs to help create intuitive experiences that can be tightly integrated into a website or another app. Windows Live users Messenger, Hotmail, and SkyDrive users can opt in to provide access to their identity (sign-in, profile, relationships, and additional user data), share updates about the things they’ve done via Messenger social, and chat with their friends, all from within the experience of another website or app.

The unique value of ”connect like” products for web sites and apps isn’t in the technology (read all about the glue), but rather in the audience that can be reached and user connections that can be made. Hundreds of millions of people will be able to connect what they do on their favorite websites with the new Windows Live user experiences – the new Windows Live Hotmail, Messenger (+iPhone), SkyDrive for your photos and Office docs, and the new Essentials beta – all great new experiences that Messenger Connect now enables partner websites to connect to.

What you can use Messenger Connect for

Messenger Connect enables three core scenarios for websites and app developers:

• Identity – makes it easy for users to sign in and sign up to your web site using their Windows Live ID
• Social distribution – lets users share the things they do on your website with their friends. Activities appear in Messenger, Hotmail, and across Windows Live properties, and other places Messenger social is displayed (including Windows Phone 7 and the very popular Windows Live Messenger iPhone app)
• Realtime shared experiences – lets users share an experience in real time with their friends

What’s new in Messenger Connect

Many of the components that have evolved into Messenger Connect have been around for several years (Messenger Web Toolkit, Live ID Web Authentication, Delegated Authentication, and the Windows Live Contacts API), but this is the first time we’ve delivered a suite of standards-based, self-service APIs as a package. To understand how Messenger Connect works, from authorization, to the different interfaces and controls, to the emerging standards/specifications we use (OAuth WRAP, Portable Contacts, ActivityStrea.ms, and OData), check out this post.

Below are some screenshots from a website that is using Messenger Connect through a Gigya integration:

Working with the industry

Over the past few months we’ve worked closely with industry leaders from a technology, policy and scenario perspective. The feedback we received from these partners has been critical in the development of Messenger Connect – it has directly helped shape our development so far, and your feedback can help shape our development in the future.

Over the next couple of months, as we expand the beta, you will see many more partner sites go live.

Getting access and the future

Messenger Connect is now open in beta form to any developer or website for the core scenarios outlined above (more info). We’re working hard to deliver additional scenarios, and will ship a final release later on this year. You can get more info here and if you have feedback, check out this forum post. Also – be sure to subscribe to the Windows Live for Developers Blog – that is where we’ll be posting lots of developer and user experience related details about Messenger Connect.

Communication and sharing has emerged over the past few years as a critical element making experiences more personalized and compelling across the web. Lots of sharing is done asynchronously (via activity feed or email), but for some things you want real time sharing (it is tough to view photos or watch a TV show together asynchronously ). The challenge is: how do you know when your friends are available to engage in a real-time sharing experience, knowing the “presence” of your friends is important because it can shape how you engage with them. Having an always-on real time client is essential, because the likelihood of both users being on the same website at the same time is low except for very special circumstances. Connecting to a persistent chat client via a third party website is necessary to deliver on these scenarios.

People want to be able to share experiences like inviting a friend to a site in realtime, chatting with their friends without context switching, and see who else is on the web site. By integrating Messenger, the #1 most used free instant messaging service in the world (see some staggering stats) into your site you will be able to:

• Let users connect with their friends in a differentiated, more personal mode of communication
• Reach their friends no matter where they are, on your web site, on their phone, in one of the many Messenger clients (Windows, Mac, iPhone, etc.)

By adding real time experiences to your site, you are in essence making the site do something it didn’t do before, and conversations are “sticky”, therefore user engagement will go up.

Some shared experiences you can add to your site are:

• Targeted (to one person or a few people), real time sharing of content. An example of where this is useful is sharing a picture that you want to discuss, or collaborating on travel plans – things that require realtime action by the other party.
• Creating immersive experiences and reducing context switching – if someone is watching your glorious full screen video or playing an immersive game, they may be worried they’ll miss conversations or not be able to chat with their friends, embedding chat in your media consumption or game play experience will reduce context switching.
• Rendezvous (are my friends on this site?) – for high traffic properties such as live streaming events or video play back, being able to tell if your friends are on the site (after opt-in of course) can drive more time on the site and shared experiences.

Implementation Options

There are a range of implementation options ranging from simplest (least amount of time to code) to most flexible:

Sharing Badge – the sharing badge can be added to a site with just a few lines of HTML and can allow users to publish/broadcast to Messenger Social or IM content to one of their friends

Chat control for real time events – to allow users on the same page to leave real time messages for each other. Users will be able to see the messages from their friends and others on the site.

UI Controls – a set of JavaScript building blocks which can be combined to speed up development. These controls can be easily skinned using CSS and extended using JavaScript. Try the Controls Playground.

JavaScript Library – the most advanced and most powerful way to integrate real time experiences into your site.

To get started adding real-time shared experiences so your site, check out this documentation.

Angus Logan (@anguslogan)
Senior Technical Product Manager
Windows Live

There are over 500 million Windows Live IDs that are used every month. That is a lot of users who can sign into web sites. In addition to base level authentication you can also pre-fill registration forms with things such as the user’s email address, so that information doesn’t need to be manually typed again and again (remember this video?). Users are able to quickly sign in and sign-up without needing to enter a username and password. Many users will already be signed into Windows Live (e.g. Hotmail) so they won’t need to enter their password again and can effectively sign into your web site in 2 clicks (1 on the in the page, 1 within the popup window).

There are several additional things we’ve been working on from a user experience perspective. We’ll cover these in more detail in subsequent posts but they include:

• Conditionally showing the sign in button if the user has recently signed into Windows Live ID (more technical info)
• Registration forms can be customized based on the email address the user entered. E.g. if a user typed @hotmail.com (or any other email address in a Windows Live namespace) the registration form could be tweaked to encourage use of Messenger Connect (more technical info)
• Inbound traffic such as email marketing/invitations to @hotmail.com addresses or Messenger social updates could include some parameters to tell the web site “the user came from Windows Live” to encourage them to sign in/sign up quickly using Messenger Connect (remember when Plaxo got 92% conversion?)

For more information about the underlying technology of authentication, see this post or this page.

My contacts/relationships are part of my identity too

Another thing we’ve heard from customers, and observed on the web, is that customers want to be able to automatically find their friends on a web site or be able to invite them to a site via email. Historically the Windows Live Contact API enabled users to take their entire address book with them to another web site for the purposes of friend finding (indexed by email) and friend inviting (by sending an email), or in very specific circumstances migrating their address book.

We believe in these scenarios, they are important, and we think they add value to users and partners. However, we also believe in sharing the minimum amount of data required to let a user complete a desired action (more info). To that end, in the near future, we will deprecate the existing Windows Live Contacts API and remove email addresses from the Messenger Web Toolkit JavaScript Object Model. We will post more information regarding the specific timelines and what this means if you are using these interfaces. Moving forward, access to the entire address book (including email addresses of a Windows Live user’s contacts will be restricted (more info). We are working hard on building public APIs (subject to the Terms of Use) to enable the find my friends by email address & invite via Email APIs – look for another post on this topic in the near future.

Angus Logan (@anguslogan)
Senior Technical Product Manager
Windows Live

Messenger social is the “newsfeed” which is associated with a Windows Live user and shown to their Messenger contacts across Windows Live, including Messenger and Hotmail. The new Messenger full view is optimized for showing users their friend’s activity across a range of sites. For a limited set of partners (Facebook and MySpace today, LinkedIn coming soon) it allows users to comment inline back to these sites. For others, it allows users to share activities with their friends in Windows Live and enables users to click through to partner sites.

The simplest and most unique is the Messenger Connect sharing badge. This badge operates like other sharing badges, resulting in a social update. If the user chooses to; they can send an instant message to one of their Messenger contacts and have a conversation in real time about the content.

An individual entry in the newsfeed (aka activity) is known as a social update in Messenger. There are many different types (~ 20) of activities (e.g. pictures, comments, ratings), and when clicked they drive traffic back to the partner’s website.

The supported templates will be evolved on a quarterly basis as new activities become popular. Messenger Connect uses the ActivityStrea.ms format which is an emerging specification for making user activities portable.

A screenshot of the new Windows Live Messenger in full mode, activities appear on the left hand side

Screenshot of Messenger social in the Windows Live Messenger for iPhone

For a website to publish to Messenger social, push (via JavaScript and REST) and pull interfaces exist. The pull interface can be done with existing RSS or Atom feeds with minimal modifications. Below is an example of a comment and the corresponding Atom feed:

<?xml version="1.0" encoding="utf-8"?>
<feed xmlns="http://www.w3.org/2005/Atom"
 xmlns:activity="http://activitystrea.ms/spec/1.0/"
 xmlns:thr="http://purl.org/syndication/thread/1.0"
 xmlns:media="http://purl.org/syndication/atommedia">
  <title>Title of the feed</title>
  <id>http://www.contoso.com/profileid</id>
  <link rel="alternate" type="text/html" href="http://www.contoso.com/profile"/>
  <updated>Mon, 10 May 2010 14:12:21 GMT</updated>
  <entry>
    <id>http://www.contoso.com/profileid</id>
    <title>Cool Stuff</title>
    <published>Mon, 10 May 2010 14:12:21 GMT</published>
    <updated>Mon, 10 May 2010 14:12:21 GMT</updated>
    <link rel="alternate" type="text/html"      href="http://www.contoso.com/link_to_content"/>
    <content type="html">I think this is cool</content>
    <activity:verb>http://activitystrea.ms/schema/1.0/post</activity:verb>
    <activity:object>
    <activity:object-type>http://activitystrea.ms/schema/1.0/comment    </activity:object-type>
      <title>Cool Stuff</title>
      <link rel="alternate" type="text/html"        href="http://www.contoso.com/link_to_content" />
      <link rel="preview" type="image/jpeg"        href="http://www.contoso/thumbnail.jpg"/>
      <summary>I think this is cool</summary>
    </activity:object>
  </entry>
</feed>

To let your users share activities from your site with their friends in Messenger social, visit this page. Additionally, if you know what the next big social activity type will be, leave us a note in the forum.

Angus Logan (@anguslogan)

Senior Technical Product Manager

Windows Live

The primary goal of Messenger Connect is to help web sites & apps grow their traffic and engagement, at a reasonable cost. To that end, the technical implementation and business terms have been designed to be predictable for web developers and marketers who are familiar with the social connections domain.

First question I get asked: Is Messenger Connect standards based?

We’ve tried to make Messenger Connect as easy as possible for developers to implement. Where possible, the latest emerging specifications and standards have been implemented and Microsoft engineers are actively involved in the community to help evolve the technologies which enable the relatively new use case of social connections. Some of the technologies we have implemented or contributed to are: OAuth WRAP, Portable Contacts, ActivityStrea.ms, and OData. What about the next big thing? As new technologies are created, and developers ask us to implement those technologies, we will work with the community and evaluate adding them to the mix.

Implementation options

Messenger Connect can be used on web sites (and other apps) to provide Windows Live users access to their information and communicate/share with their friends. This access to information and friends is made possible by several types of programmatic interfaces:

1. Badges – simple HTML tags that can be added to a page
2. JavaScript APIs (including user interface controls) which execute within most popular browsers and talk directly to the Windows Live services
3. .NET APIs which can be used in server-side ASP.NET code or in rich client applications
4. RESTful services end points which can be called in a server-to-server manner

Badges

Some developers don’t want to write JavaScript or server side code. That is OK. Our sharing badge can be simply added to a page in a few lines of code.

<a href="http://profile.live.com/badge?url={your URL}" title="Share with Messenger" target=”blank”>  <img style="border-style:none; vertical-align:middle; margin-right:4px"      src="http://img.wlxrs.com/$Live.SN.MessengerBadge/icon16wh.png"      alt="Share with Messenger" />Messenger</a>

Try it: Share

Consent, access, privacy, data rights, revocation

We recently posted about the privacy aspects of Messenger Connect (read it here). We strongly believe that users own their data and they should be able to share or access it from the websites and applications they want to. Web sites cannot access any of a user’s non-public information from Windows Live without prior consent (see the experience below) from the Windows Live user. App developers are encouraged to only request the bare minimum of permissions required to complete the desired scenario in a just in time manner (E.g. if a user is signing up, ask for their profile, if a user is adding something to their calendar, ask for calendar write permissions). If a user chooses not to grant permission for the site to access what they requested, the web site must handle the exception flow and reduce the permission requests, or explain why those permissions are required.

If the user leaves the “Remember this connection” checkbox checked (it is checked by default), the web site will be granted permission for 1 year (or until the user revokes the permissions). If the user unchecks the “Remember this connection” button, the web site will get access for 3 hours. At any point in time the user can browse to http://consent.live.com and revoke the permissions they previously granted the web site. After the token expires, or the user revokes permission, the web site would get 401 Unauthorized errors when trying to access the data, and would need to re-request that the user grants permission.

• The web site renders a “sign in” button either manually by creating HTML, or using the wl:signin tag. If the web site uses the wl:signin tag (more info), an additional attribute can be added to only show the sign in button if a Windows Live cookie exists.
• The user browsing the website (e.g. www.example.com) and sees a Messenger Connect button and clicks Sign In. To ensure the most Windows Live users know they can “Connect”, the iconography used for button will be aligned behind a single brand used across all “non-Windows Live” web sites (i.e. the current Hotmail / Messenger / Windows Live / SkyDrive brand fragmentation will be reduced in “off-network” scenarios).
• A popup window is opened which includes the partner’s logo, a link to their Terms of Service and Privacy Statement. The partner must clearly outline in their ToS & Privacy Statement what they will be doing with the permission granted by the end user.
• The user can click “What will I share?” to see each individual permission the partner is requesting.

• If the user grants permission, a token is returns to the site, and the window will be closed.

One a website has been granted the appropriate permissions and has received the token, access to the user’s Windows Live data & services is possible through two interfaces: JavaScript & RESTful interfaces.

The permission granted is for 1 year (unless the user unchecks Remember this Connection). If the web site wants to access the Windows Live resources without the user being present, or without the user seeing the Messenger Connect consent screen again, the token should be stored alongside the user’s profile in the partner’s website.

If the user changes their mind and no longer wants the web site to have the ability to interact with their Windows Live account, the user can go to http://consent.live.com to revoke permissions at any time. If the partner tries to interact with the user’s Windows Live account after consent has been revoked, they would get “unauthorized access” errors and would need to re-request access from the user.

JavaScript libraries & user interface controls

Adding a script reference to the Messenger Connect dynamic loader enables access to a wide range of Windows Live data and Messenger features, including IM conversations. Developers can choose to use the data objects only or can add UI elements such as <wl:signin>, <wl:userinfo> or <wl:bar> to their page. You can experiment with the data model and controls hands-on using our new interactive SDK at http://isdk.dev.live.com/.

RESTful service endpoints

A set of cloud endpoints are available to web sites and applications for the purposes of accessing and managing user data. Generally the RESTful service endpoints will be used for web sites that want more of a “roll your own” approach to data access. Additionally, the RESTful endpoints are useful for sites that want to access the user’s data while the user is not present (for example: out of band processing of data – each week the website could make a call to Windows Live to download a user’s address book to see if some of their Windows Live friends have joined the web site).

These endpoints are multi-headed (the data is generally available in several formats), and can be queried and sorted. If developers prefer the data to be returned in several formats this is easily configurable using the $format query string key (for plain XML $format=XML, for JavaScript Object Notation (JSON) use $format=JSON, the dynamic formatting is also applied to emerging specifications/standards such as $type=portable). Additional formats for representing user data will be added based on partner feedback.

The RESTful service endpoints are also intelligent and most data-types exposed will support filter, select, orderby, and count the protocol used is the Open Data Protocol (OData).

Developer tooling

To make it easy for developers to kick the tires, we’ve created a few tools: the Controls Playground, the API Playground, and the REST Explorer – these tools will evolve over time as we see where developers need help. In a future post we’ll share details about the statistics which will be available from the application management portal.

The Controls Playground lets you quickly preview the Windows Live UI controls in action, customize controls and see results in real-time and also generates markup for these controls for you to copy, paste in your application.

The API Playground lets you try out the API service to see what type of interactions are possible:

• Select common tasks such as adding a new contact to Windows Live, and preview the code
• See common API usage patterns
• Run API code, using sample data, and see the output in real-time
• See the underlying REST HTTP traffic including request and response

The REST Explorer lets you interact with the RESTful endpoints directly against your own Windows Live ID.

If you have any questions about the different ways of developing with Messenger Connect, please visit our forums.

Angus Logan (@anguslogan)

Senior Technical Product Manager

Windows Live

Last week Omar Shahine blogged about our new privacy features in Windows Live, where we’ve made some improvements that we hope you will appreciate and find both powerful and easy to use. We also recently announced Windows Live Messenger Connect, an exciting new feature set that enables you to easily connect to Windows Live from third party applications and lets you take your Windows Live experience and data, with your consent and at your discretion. Additionally, we also announced the new Messenger (try it now), which provides the most complete picture of what your friends are doing across your social networks and other sharing sites, including comprehensive integration with Facebook, LinkedIn, and MySpace.

We believe that you should be able to choose to take your Windows Live data with you when you travel the web. Messenger Connect allows you to do that by providing a way to sign in to third party web and client applications using your Windows Live ID. Messenger Connect allows you to bring your Windows Live profile and contacts with you; easily share with your friends and enable Windows Live Messenger-based chat within third party applications; and access your photos, calendar, and more. In order to enable third party applications to ‘connect’ and interact with Windows Live accounts, we needed to design to help to ensure that customers’ data is protected and accessed in a manner consistent with customers’ expectations and desires, as well as enable great partner experiences. These principles guided our design work:

Principle 1: Data portability (you own your data)

As a top-level principle, we believe that customers own their data. Your identity and profile, your address book, your newsfeed, your photos, your documents: as a Windows Live customer, you own all that data. So you should be able to take that data with you. Our role is to help you protect your data, help you make informed decisions about how your data is accessed and updated, and help you port your data to other places like the PC. That means that if you would like to access your Windows Live data from a different third party service, or even take your data completely to another service, you should be able to do that. To enable this, we give you ways to export your data from Windows Live into common formats, so that you can import it to wherever you like, as well as in many cases make this more seamless with direct integrations with partners. In a world where people are connecting services back and forth from each other, this can be complex. Just to be clear, when you connect one of your social networks (like Facebook, MySpace, and LinkedIn) to Messenger, any of your data or your friends data made available to Messenger via those connections is governed by our partners’ policies and our agreements with them.

Principle 2: You have control over your data

As Omar discussed in his post, customers should be able to easily control who has access to their data in Windows Live. You entrust Windows Live with your data, and it is only available and accessible within Windows Live. But we also know that you may want to be able to access your Windows Live data in the third party applications or websites you use. For example, you may want to share your photos or other non-public data with your friends. We make it possible for you to do so, but you have to give us your consent first. And, if at any point, you decide you would like to revoke a partner’s access to your data – you should be able to easily do so.

Principle 3: Right data for the right scenario

We believe that third party applications that access Windows Live should only access the minimum amount of user information required to complete the desired scenarios. For example: if a web site only needs permission to publish social updates, they shouldn’t also request permissions for reading photos.

Messenger Connect: Making my data and my friends data available in a responsible manner

There are cases where challenges and tradeoffs between privacy and data portability exist. An example of this tension is where a customer would like to share their complete address book with a third party, and that address book contains information such as email addresses and phone numbers. The contents of my address book are a combination of “my information” as it is “my address book” but may also include my friends’ email addresses and phone numbers. These shared data ownership scenarios are complex and have informed our design choices.

Independent of the information type or service access being made available, we have been working to replace unauthorized “screen-scraping” models, which require customers to share their usernames & passwords (“credentials”) in an unsecure manner with many sites, with the use of safer, legitimate APIs. The use of legitimate APIs and clear user consent flows have been important across the industry as they provide a safer alternative to requiring customers to share their credentials with third parties. Moving third parties away from screen scraping and the practice of asking users for their credentials without the use of APIs that use delegated authentication (more info) is important because when you share your credentials in the clear these websites can now act on your behalf. Even if a web site is not malicious, your credentials could be exposed if the third party service is compromised. Use of APIs helps to promote customer credential security, enables selective disclosure of information and the ability to revoke access.

To help us safeguard customers’ privacy and enable partner scenarios, we’ve created two distinct tiers of partner access policies. Both tiers require explicit customer consent, and follow the same security model, but are available for different group of third parties.

1. Public APIs: Our “Public APIs” are available to all developers and third parties to access in a self-service manner. Appropriate use is governed by our Terms of Use and Terms of Service, and is monitored for abuse reported by customers. Third parties can sign-up for access through our application management tool at http://manage.dev.live.com.
2. Restricted APIs: Our “Restricted APIs” allows third parties to access more sensitive information on behalf of customers. Therefore, these APIs are reserved for a select group of third parties explicitly approved by Microsoft, and meet clear and consistent criteria.

It is worth noting that within each policy tier, we have provided many ‘granular access scopes’, which allow third parties to request access to specific sets of data to complete a specific scenario. You can learn more about these scopes here.

The experience

So, let’s take a quick look at what the experience looks like when connecting with third party applications through Messenger Connect.

Sign-in and consent. When you click a Windows Live ‘Connect’ button on a third party website (explicit customer content is required), it initiates the sign-in and consent experience.

The initial screen provides you with the ability to sign in with your Windows Live ID, and learn about the level of access the third party application is requesting.

Making informed decisions. When you click the “What will I share?” link, you get detailed information about the specific pieces of data and capabilities the application is looking to access.

Managing access to your data. At any point, you can edit your permissions for any third party application within Windows Live and revoke its access to your data.

Reporting abuse. In addition, we provide “Report abuse” links from the Windows Live services so that you can inform us of any application that may be violating our Terms of Service, or generally behaving in a way you find inappropriate. In extreme circumstances, we also have the ability to suspend or revoke a third party application’s ability to use Messenger Connect, thus automatically revoking any permissions a customer granted the third party.

I hope this post has given you some insight into how we approach your privacy in Messenger Connect. As Omar previously noted, this is a challenging problem with many complex dimensions, and one that many in the industry continue to struggle with and refine. We are committed to continuously listening to our customers and partners, and together improving the experiences, technologies, and policies.

Angus Logan (@anguslogan)
Senior Technical Product Manager
Windows Live