Facebook writes that “you can now incorporate Facebook Connect into your site in 3 easy steps.” The process is simple. First, you enter the name of your site and its URL. Then Facebook asks you to download and then upload a special file to your site’s main directory. And.. that’s about it. Once you’ve done that, Facebook will present you with its Playground — a list of code snippets you can embed on your site to round out the functionality, including Login buttons, profile photos, publishing items to News Feeds, and rendering photos of a user’s friends.

Deciding to put their little wizard to the test, I tried to implement Connect on one of my personal sites (note that I’ve never tried to implement Connect before so I really didn’t know what I was doing). And to my surprise, it worked: I managed to have a very basic form of Connect up and running on my site within all of two minutes. It will obviously take longer to make sure the new icons and buttons play nicely with your site’s design, but it’s really surprisingly easy.

Crunch Network: CrunchBoard because it’s time for you to find a new Job2.0

Want to reach more than 500 million users with your social app? OpenSocial is the key. The OpenSocial standard will allow you to build apps that work across a number of massive social networks, including MySpace, Orkut, Ning, hi5 and LinkedIn (complete list).

OpenSocial defines an API for developing social apps and was designed in cooperation with multiple social networks right from the start. Amongst many others, companies like Google, Yahoo!, LinkedIn and MySpace support the interface.

Editor’s Note: Looks like The Future of Web Apps will definitely sell out. Speakers: Twitter, Facebook, Google, Six Apart, digg / Kevin Rose, Mozilla, Dustin Diaz and more.

OpenSocial Tutorial

I’m going to walk you through building a simple chat application using the OpenSocial API. You can download the complete code for the application here.

If you want to follow our example in code, a few smaller preparations are necessary. These are necessary mainly because of the fact that OpenSocial development only really makes sense inside of a real social platform which provides the API. Isolated on your home desktop it makes little sense because the basic platform is only available online, from the inside (embedded into) the platform.

For our example, you need a free Orkut account (a valid Google account is also sufficient) and access to the Orkut developer sandbox. The setup of your Orkut account including access to the developer sandbox is described in the document OpenSocial-Tutorial for Orkut in the segment “Running your first Gadget”.

Because chatting without friends isn’t very exciting, it’s vital that you also add a few friends to your Orkut account. If you can’t get any of your colleagues to also register for the Orkut sandbox, you can simply create a second Google/Orkut account, open that one in another browser, add yourself (the other Orkut account) as a friend and then install the app as well.

If you want to program your own Gadget and also make changes to the example code provided, you need a little webspace, including PHP and a MySQL. The other preparations for this are documented in the Readme file in the download archive.

Google Gadgets as a Foundation

The basis for an OpenSocial application is a so-called Google Gadget, which could be familiar already to some developers from experiences with iGoogle, e.g.

A Gadget is an XML document and is merely the frame for an OpenSocial app.
An exemplary Gadget definition could look as follows:

<?xml version="1.0" encoding="UTF-8" ?>
<Module>
  <ModulePrefs title="Chat Tutorial">
      <Require feature="opensocial-0.8" />
  </ModulePrefs>
  <Content type="html">
      <![CDATA[
         // here comes our application code...
      ]]>
  </Content>
</Module>

The real application code is defined within the <Content> node of the Gadget and consist of HTML and JavaScript (while the embedding of Flash or Silverlight objects is possible too). All following JavaScript code snippets in this article belong inside of this <Content> node.

Initialize the App

Because we work with JavaScript within our Gadgets, at first we should wait until the page has completely loaded to be able to initialize our application cleanly. From Javascript frameworks like jQuery or Prototype you’re probably already used to getting informed as soon as the DOM is ready and we can begin with the initialization. Google’s Gadget-API also has such a helper function:

gadgets.util.registerOnLoadHandler(function(){
    load_friends();
});

Querying for Data in OpenSocial

An important part of our chat application is a simple list of our friends. To find out who our friends are (and how many we have) we ask our social network container (which is Orkut in our example). The corresponding JavaScript function “load_friends”, which we called on initialization, looks like this:

function load_friends(){
    var req = opensocial.newDataRequest();
    req.add(req.newFetchPersonRequest(opensocial.IdSpec.PersonId.VIEWER), 'viewer');
    var friends = opensocial.newIdSpec({ "userId" : "VIEWER", "groupId" : "FRIENDS" });
    req.add(req.newFetchPeopleRequest(friends, {}), 'viewer_friends');
    req.send(on_load_friends);
}

From this example we see how data queries work in OpenSocial:

In the first line we create a “DataRequest” object. All requests which we would like to have answered are appended to this object subsequently; in our example we first add a query for the profile data of the “Viewer” and then a query for his friends by calling req.add().

Because we work exclusively with JavaScript and HTML here, data queries are also carried out asynchronously through JavaScript (using AJAX).

It’s only in the last line of our example that the request is really sent through req.send(). It’s worth noting that, with this concept of querying, we can immediately take care of several data queries in only one request – instead of needing several AJAX requests and generating traffic and latency several times. Google calls this procedure “batch requesting”.

At the same time, looking at that code snippet, you can clearly see what it’s all about in OpenSocial: it’s about “people data” and the relations of the people to each other. Two types of persons are the most interesting, which is why the API defines them as constants:

One of them is the “VIEWER”. The Viewer is the (logged in) user who’s looking at the profile page on which our application is installed. The other one is the “OWNER”, which is the owner of the profile page on which the Gadget is installed. It is perfectly possible that the Owner and the Viewer at times are the same user – when the owner is looking at his own profile page, using the application.

In addition to Viewer and Owner, it is also possible to request data about other users by their user ID.

As we sent off our requests we had given an additional parameter to the method req.send(). This was the reference to the function “on_load_friends” which is used as a callback and is automatically called as soon as our request was answered and returned data. Therefore, we can access the results of our query – the person data we asked for – inside of the function “on_load_friends”:

function on_load_friends(data) {
    var viewer = data.get('viewer').getData();
    var friends = data.get('viewer_friends').getData();
    ...
}

Accessing our data through the method “get()” is necessary because of the “batch requesting”. While putting together the query, we had provided the strings ‘viewer’ respectively ‘viewer_friends’ as a last parameter. This was necessary because we wanted to request multiple data packages in one go – and of course we want to be able to distinguish them again at the end. Through data.get (’viewer’).getData () we get the return values which we had named ‘viewer’ when we put together the request.

Now in the next step we want to show our friends in a list:

friends.each(function(friend) {
    friends_html += '<div class="friend_name"> '+ friend.getDisplayName()+ '</div>';
});

Those of you who have already worked with Ruby or the JavaScript framework Prototype will probably know the “each” notation. The OpenSocial-API provides this function, too. We use it here to iterate through the records of our friends.

By calling “getDisplayName()” on each of our friends records we use a special function of OpenSocial.

Most data fields are specific for a certain platform. This means e.g. that a field called “hobbies” that exists on MySpace might not exist in another container like Orkut at all. To at least be able to show a display name – in any case, and on any platform – a sensible return value from getDisplayName is guaranteed by the API.

In other cases we should be more careful by explicitly checking if a certain field that we’re trying to access really exists:

opensocial.getEnvironment().supportsField(opensocial.Environment.ObjectType.PERSON, opensocial.Person.Field.ID);

With this line of code, we can check if there’s a field called ‘id’ for objects of type ‘person’. As soon as we know that our field of choice really exists, we can access it through “getField()”:

friend.getField(opensocial.Person.Field.ID);

A few specialities still have to be considered when sending a chat message:

function send_message(message, user_to, user_from){
    var post_data = { action: 'save_message', message: message, to_user: user_to, from_user: user_from};
    post_data = gadgets.io.encodeValues(post_data);
    var params = {};
    params[gadgets.io.RequestParameters.CONTENT_TYPE] = gadgets.io.ContentType.TEXT
    params[gadgets.io.RequestParameters.METHOD] = gadgets.io.MethodType.POST;
    params[gadgets.io.RequestParameters.POST_DATA] = post_data;
    gadgets.io.makeRequest('http://www.example.com/message.php', function(){}, params);
}

Our self-defined method “send_message()” is used to send an entered message via AJAX to a remote server. This remote server then saves the message in a database until it is picked up by it’s receiver.

Inside of this function, the Gadgets-API is used heavily. This is necessary because it’s not easily possible for security reasons to send a request to an other than the origin server with AJAX. Here the Gadgets-API steps in, which makes this possible through “gadgets.io.makeRequest”.

Other Possibilities

The OpenSocial-API offers some more possibilities. With the help of the Activities-API you can, for example, read or write activity messages for a user. Therefore, an application would be able to read or write activity messages like “Mike has a new profile photo” or “Martin and Linda are friends, now”.

A so-called “Lifecycle event” can help developers gear into important points in the life cycle of an application. As a developer, you can for example, be informed when the deinstallation of a Gadget happens and take actions accordingly (by deleting old database entries, for example).

Another area of the API deals with data persistence. This functionality is exciting because OpenSocial apps – being “just a frontend” at first hand – come without their own backends and therefore have no database by default. Every social network can decide for itself to which extent it allows applications to persist data for a viewer.

The concept of “Views” is also an interesting part of OpenSocial development: An OpenSocial-Gadget can have different views. This depends on where the Gadget was integrated, respectively in which view a user is at this specificmoment. The current view can be requested at runtime so that, e.g., different functionalities can be offered depending on the currently active view of the Gadget.

Basically four different view types are defined in OpenSocial: The “Profile” view is active when it is viewed on the profile page of the user. The “Home” view is active when a Gadget is viewed on the personal homepage of the user (on which the above mentioned viewer and owner constants are always identical, because only the account owner has access to his personal homepage). The “Canvas” view is a view in which the Gadget is more or less alone on the page and therefore has a lot of space available. Finally, the “Preview” view has limited accesses and is intended for demo purposes.

Publishing your SocialApp

The development of an OpenSocial application always begins in a sandboxed developer environment where you can work on your application without interruptions. During this time, however, the app is only accessible to the developer himself (or other developers) – but not publicly to normal users.

Then – after some time of development and testing – when your SocialApp has a sufficient level of maturity and is ready to enrich the world, you can submit it to the respective social network to be checked and (hopefully) approved.

Though the submission process is a little different in every social network (as an example you find Orkut’s application form here), it always serves the same purpose: to put your submitted app through their paces.

If then, after several days or weeks, your application was found to be nice enough, it is included into the platform’s list of applications – and can be installed by all users of the platform.

Summary

Google’s OpenSocial-API only really offers the functionality that Facebook developers are already accustomed to. However, with OpenSocial, you can reach a wider and larger audience of 500 million people.

In day-to-day development, in spite of the wholehearted promise “Many sites, one API”, caution is advised: some of the networks don’t implement the complete specification or take awhile to implement updates to their APIs. Sometimes some minor differences in the API implementation force you to adapt to special situations (hi5, for example, requires the Gadget scaffolding to be a little bit more detailed).

The result so far that OpenSocial can present, however, looks good: excellent documentation, more than 30 involved social networks all over the world, and more than half a billion users.

Sponsor

Now, Ning Network Creators – that is, users who administer their own social network on Ning – can finally embed these apps and make them available for all the users on their custom social network. Among the apps launched today are a service that allows artists to sell merchandise from Sellit, a BlogTalkRadio app for podcasters, Huddle workspaces, PollDaddy polls, as well as WordPress apps to display blog posts and a Ustream app for live video streaming. A complete list of existing apps is available here.

While other social networks have obviously provided their users with access to these kinds of apps and widgets for a long time already, this is a major step forward for Ning. Ning, according to its own stats, currently hosts over 1.5 million different social networks (how many of these are active is a different question, however) and has about 33 million registered users. If Ning wants to continue to compete with Facebook and other social networks, it simply needs this kind of open development environment to provide its users with the right set of features, though it also looks like Ning actually has an Apple-like approval process for new apps in place.

Discuss

It’s an extension of something called the “finger protocol” that was used in the earlier days of the web to identify people by their email addresses. As the web expanded, the finger protocol faded out, but the idea of needing a unified way to identify yourself has not. That’s why you keep hearing about OpenID and the like all the time.

But those standards, while open, have failed to latch on in a meaningful way with the public at large. One of the holdups is that you have to set up a website or service you use to be your OpenID. It’s relatively easy to do, and you may already have one ready to go, but just not realize it. But it’s still kind of tricky to explain to a regular web user — wait, you login with your website?

But something everyone on the web knows is their email address. And they’re conditioned by services like Google and Facebook to use it as their identifier. The problem with it has been that it’s just a string of text, nothing more. You cannot attach information to it to let others know a bit more about you — something vital for true identification. Then idea behind WebFinger is that you should be able to attach any information you choose to your email address.

The excitement today is that a group of Googlers have apparently finally not only gotten Google’s support to pursue the project, but that they have started working the technical details. As Googler Brad Fitpatrick writes today:

In other words, we’ve eliminated both technical & political hurdles. We can now work on this spec, implement, push, try, rinse, repeat…. until we’re all reasonable happy.

Googler Brett Slatkin (incidentally, Fitzpatrick’s partner in making PubSubHubbub) explains to us that while it hasn’t been turned on yet, and that there’s still a lot of work to do on the spec, the idea is to go into testing mode soon. Fitzpatrick notes that there will be a small experiment going on internally with some Googlers’ Gmail accounts.

Without knowing much about the technical details behind it, the core idea behind WebFinger immediately strikes me as a good one. It’s taking something everyone knows on the web (your email address) and making it immensely more valuable as a way to identify yourself and information about you. Exactly what kind of information? Here are some of the ideas from the WebFinger Google Code page:

• public profile data
• pointer to identity provider (e.g. OpenID server)
• a public key
• other services used by that email address (e.g. Flickr, Picasa, Smugmug, Twitter, Facebook, and usernames for each)
• a URL to an avatar
• profile data (nickname, full name, etc)
• whether the email address is also a JID, or explicitly declare that it’s NOT an email, and ONLY a JID, or any combination to disambiguate all the addresses that look like something@somewhere.com
• or even a public declaration that the email address doesn’t have public metadata, but has a pointer to an endpoint that, provided authentication, will tell you some protected metadata, depending on who you authenticate as.

This is definitely something to watch for in the coming months.

[photo: flickr/chris owens]

Crunch Network: CrunchGear drool over the sexiest new gadgets and hardware.

It’s ironic that it’s Facebook that did it. Facebook is probably the most closed of all the major social networks (other than LinkedIn) and is so far ahead of everyone else in market share that traditional logic would argue that they have no interest in this kind of interoperability. This is the kind of step that was expected from networks more open and, frankly, far behind Facebook. Nevertheless, it has happened and it’s big news.

Sponsor

New Facebook users will now be able to create Facebook accounts using their Gmail credentials and existing users will be able to associate and thus log in with Gmail or any other OpenID account that supports “automatic login.”

That means fewer passwords to remember. Just log in with your favorite OpenID supporting account and don’t worry about one just for Facebook. Single sign on is just the simplest benefit though.

Presumably, the friends you bring with you in your OpenID account will be searched for automatically on Facebook. “In tests we’ve run,” the company said today, “we’ve noticed that first-time users who register on the site with OpenID are more likely to become active Facebook users. They get up and running after registering even faster than before, find their friends easily, and quickly engage on the site.”

Contact lists are the second simplest benefit of this kind of data portability, but other payloads are possible and that’s when it gets even more exciting. We’ll see what Facebook does to move the ball even further up the court.

Nothing is live yet and we haven’t been able to test out usability (we just got a press release about the forthcoming announcement at 1:30 PM PST, which is latehere.), but Facebook is very good about things like that and has been working with the OpenID community on usability (its biggest challenge) for months.

Expect MySpace, Digg, Twitter and maybe some Yahoo sites to start accepting OpenID from other companies by the end of this summer at the latest. It’s only a matter of time now that Facebook has.

Note: Jason Kincaid at TechCrunch argues otherwise:

“Facebook has really been a relying party since its inception – there’s never been a “Facebook ID” because you’ve always used your university Email (or more recently, your personal Email) to log in. So the site isn’t really sacrificing anything by enabling OpenID support. The likes of Google and Microsoft have built many services tied to their own proprietary accounts, and they’re going to be far more hesitant to give those up.”

We can see some strong logic here, but we also suspect there will be additional factors that emerge, like an increasing number of websites deciding to become OpenID providers so their user data can be used in Facebook, that will keep the current flowing in this direction.

Discuss

At the OpenID blog, David Recordon wrote this morning, “This means that Google users signing into sites… now have a much better user experience, one on par with Facebook Connect.” The screenshots below show the new login in action.

Sponsor

According to this morning’s entry from Yariv Adan on the Google Code Blog, the new UI “is designed to streamline the federated login experience for users. Specifically, it’s designed to ensure that the context of the Relying Party website is always available and visible, even in the extreme case where a confused user closes the Google approval window.”

The post continues with a specific use case. OpenID products company JanRain is using the new API in their RPX offering. The first step on the login page “is identical to that of the ‘full page’ version, and does not require any changes in the Relying Party UI,” read the blog.”

In addition to signing into sites using their Google accounts, users are also sharing specific data with the Relying Party website. The data shared can range from the user’s email, first and last name, preferred language, and country, to other information available through the Google Data API, including the user’s Contacts List, Web Albums, or Calendar.

Adan writes, “Google strongly believes that the data our users trust us with belongs to them and should always be available for them to use. By providing users with more secure means to share their data, they can benefit from a much more streamlined, personalized and socially relevant experience when they log in to trusted websites.”

The new process also allows a streamlined conversion process for Relying Party websites.

Discuss

Let me take a step back. OpenID is a distributed single sign on solution that allows people to sign into different services with the same login credentials. There are two ways companies/websites can participate in the OpenID framework – as “issuing parties” or as “relying parties.” Issuing parties make their user accounts OpenID compatible. Relying parties are websites that allow users to sign into their sites with credentials from Issuing parties. Of course, sites can also be both. In fact, if they aren’t both it can be confusing and isn’t a good user experience.

All the big guys are now Issuing Parties, which allow their users logging in all over the Internet with those credentials. But none of them accept IDs from anywhere else, so anyone that uses their services has to create new credentials with them. It’s all gain, no pain. There are two exceptions – AOL Mapquest and Google’s Blogger – but for the most part the big guys are issuers, not relying parties. And that has led us in the past to accuse them of exploiting OpenID for their own benefit without giving back to the community. See our post Is OpenID Being Exploited By The Big Internet Companies?

Facebook has been a wild card with OpenID. They’ve talked about adopting it eventually, but their Facebook Connect product has actually muddled the situation – Facebook actually competes directly with OpenID when allowing users to sign in to third party sites via Facebook Connect.

Now that’s going to change, and we’ll soon see users have the ability to sign in to Facebook using, say, their MySpace credentials if they choose to. I like the thought of that.

But it still may be a while before we see the other major players take similar steps. Facebook has never really had notion of a user ID – you’ve always logged in with your Email address, which could have come from any number of other services, so Facebook isn’t really sacrificing much here. Instead of a user name, Facebook members are assigned a meaningless user ID number (though they’re experimenting with vanity pages).

Contrast that with Yahoo and Google, both of which have built up their own login systems, which can be used across multiple services using a single persistent account name. Users benefit because they can seamlessly jump between services, and Yahoo and Google get their users to stay within their own suite of products. There’s a good chance they’re not going to give that up so readily.

Crunch Network: CrunchBoard because it’s time for you to find a new Job2.0

Called Portable Contacts, the technical spec offers a standard, interoperable way for social networks to serve up your friends lists to anyone you give permission to access them. This should allow application developers to innovate on top of your social connections much more efficiently.

Sponsor

According to the Portable Contacts website:

we’re seeing major Internet companies making contacts APIs available, such as Google’s GData Contacts API, Yahoo’s Address Book API, and Microsoft’s Live Contacts API (with more to come). Not surprisingly though, each of these APIs is unique and proprietary. We believe this creates the ideal conditions for developing a common, open spec that everyone can benefit from.

Why is This Important?

The social web works best when it’s truly social. New applications that use social sharing can be much more useful when new users can port in their existing network of friends and see who they know is already using a site. That’s much better than starting cold.

These types of standardized approaches to passing that data are secure (that’s good) and allow developers to write code once to use all the supporting sources of data. You’ve heard the old illustration about railroads? When all the railroads in the US accepted a standard size of rail, all the trains were able to travel much farther than ever before. That’s where we’re headed with all this information on the web. When we give it standard methods of transport, it can go further and do more than ever before.

That’s a pretty big deal and it’s fantastic that Google has moved to support the Portable Contacts standard. Hopefully sometime soon everyone will and then we’ll wonder what took the web so long to enable social interoperability.

Discuss

Sharing with Friends, Now Even Easier

Earlier this week Facebook released Facebook Connect for iPhone, which allows us to connect iPhone apps to the Facebook web site. Facebook Connect for iPhone is a set of classes that can be added to your xCode project and used to ease the process of logging into the site, granting extended permissions and posting status updates to the feed.

The documentation and the video provided by Facebook assume a certain level of experience creating Facebook apps. The process of creating an App, and creating Template Data for Feed stories was only briefly covered and not explained in their documentation. I’ll provide a little more background on those tasks here in part one.

Clearing Up UI Confusion:
In part one, I describe using the Facebook Connect for iPhone SDK. In the sample application provided by Facebook, a Get Permission button checks to see if the user has granted the appropriate extended permission to the application. It is a permission to post status updates. The permission needs to be granted only once. If the user clicks the button after permission is granted, they see this message: You have already granted this permission to the application. This begs the question, why display the button after permission is granted?