Jeff just announced on Inside Windows Live that Messenger Connect is now out of beta. In this post I want to give you some context on the technical changes. These changes are the result great feedback from the 2500+ people who participated in the beta and a couple of months of development time. We focused on: Making it easier to get up and running, easier and faster development, and delivering some core scenarios based on feedback.
Easier to check out
If you are new to a service you want to: understand what it can do, kick the tires, and get access quickly. We revamped dev.live.com so you can more quickly determine if Messenger Connect is something you want to add to your site. Seeing-is-believing, so we added a few links to small sample sites (try them: identity, sharing badge, chat control).
During the beta we got a lot of the questions about which permissions (scopes) web sites can ask consumers for. Some scopes are “restricted” and they are technically available in the platform but were not made available to all companies for various reasons (security, privacy, supportability, etc.). We hadn’t done a great job of making it clear which ones were widely available and which ones were not (in line with our data portability & privacy principles) – so we rewrote the Messenger Connect Scopes page to appropriately set expectations with developers.
Once you decide to add Messenger Connect to your site, we wanted to make that easier to do, so we created some new tools. For the sharing badge (which doesn’t require registration via our developer portal), we now list all the “aggregators” that include the Messenger sharing badge. We also built a small prototype tool to demonstrate how you can generate the code to add the badge to your site. This prototype does some interesting things like only showing the sharing badge for specific browser locales etc.
If you are using functionality like identity, social distribution, and in page IM/chat, you must have a Client ID – you can now get a Client ID via the developer portal without requiring acceptance into the beta. You can just go to https://manage.dev.live.com and sign in with your Windows Live ID, and create a Client ID. During the beta we had limited access and were periodically onboarding developers.
Easier to adopt and integrate
We spent a lot of time thinking about how we can make it easier for developers to complement their websites with a Messenger Connect implementation. To do this we focused on the questions and suggestions from the people who participated in the beta. We wrote a new developer guide, which outlines how you can start building applications that integrate with Windows Live.
Whilst coding, developers like to run code over and over again, tweaking it a little, but services need throttling limits for overall service stability. To overcome these conflicting requirements, we created the debug endpoint which has very high throttle limits. You can code away and publish tons of activities without fear of a throttle limit error messing with your development mojo.
For sharing user activities into Windows Live, ActivityStrea.ms is super powerful specification, and we love it. But the format itself isn’t the prize – your content (or user activity) and how it appears in the user experience is. We support ~20 different templates, but knowing which will appear best in Windows Live and get the most amount of clickbacks is sometimes difficult. That is why we created the ActivityStrea.ms template selection tool which helps you select the template, see the code, see how it is going to be rendered in Windows Live (and which parts of the ActivityStrea.ms get rendered where), and try it out.
Partners using Messenger Connect for identity and calling the Profile API gave us feedback that multiple calls were required to deliver mainstream scenarios (such as: get the user’s name, email address, and profile picture). To make this easier we condensed the response for the Profile API and also made the avatar available without authentication (of course user consent is required).
More complete, and consistent with our data portability and privacy principles
During the beta we heard about 2 things which were blocking adoption: 1) I want to be able to email the connected user’s friends, and 2) the chat control is cool, but moderation is required.
Given our view on data portability and privacy, instead of sharing the connected user’s friends’ email addresses, instead we created an Invitation API. This API enables web sites to send out email invitations on behalf of the connected user to their Windows Live friends. This increases deliverability and also conversion because it is sent on behalf of the connected user.
The Chat Control is a good way to harness the power of digital flashmobs (where lots of people will be on the same site at the same time) and will want to be able to chat or comment on an item in realtime. The comments aren’t persisted but they are visible in your site. We added after the fact moderation of the chat control. You can enable a chat moderator to delete messages, view a larger message history, and block users from posting.
Analytics are a key part of any project. In this release we have added more analytics reports and ways for you to see exactly how your Messenger Connect implementation is performing.
Finding where to invest and where not to
Based on feedback from early adopters, the strongly typed Messenger Connect .NET library has been discontinued. Future development efforts in this area will focus on samples that work directly with our REST-based web services.
Just the beginning
This release was driven by our beta participants because they gave us great feedback. If you think there is something we should do or change, please spend some time in our forum dev.live.com/forums.
Angus Logan
Senior technical product manager, Windows Live
More...