I have added WebFinger support to Ident Engine. You can now enter a Google gmail email address as a starting point for searching someone social graph. This only works for email accounts who’s users have published a public Google profile page.

Google’s profile pages are a good starting point to search the social graph. Google have design the profile entry to encourage user to build strong “elsewhere on the web” list of their other profiles pages across the web. These links are then marked-up with rel=”me”

I used DeWitt Clinton WebFinger client which has a good JSON API.

The latest update to Ident Engine includes a number of performance improvements. The first is the use of CSS sprites to display website icons. Ident Engine can make a lot of web connections which are often queued by the browsers. Grouping all the icons into a single file helps with download speeds and improves the redraw of the HTML pages.

Icons drawing tests

The Ident Engine JavaScript files are quite large so I have compressed them using Yahoo’s yuicompressor. This has reduced the files sizes by over 20%.

I have also added a number of new social media sites:

• 43places.com
• blippr.com
• cliqset.com
• joost.com
• netvibes.com
• plurk.com
• soup.io
• smugmug.com
• twitpic.com
• ustream.tv
• viddler.com
• wordpress.com
• live.xbox.com
• xing.com
• profiles.yahoo.com
• yiid.com

I just given a talk at Codebits in Lisbon in which I explore the reuse of social media data using Ident Engine. I walk through how you can combine Google’s Social Graph API date with other open data sources like RSS and Microformats to provide a wealth information about your users.

Icons will help users quickly scan lists of social media sites. However, pulling favicons directly from sites is a lot more challenging than you may first think. Google have provided a simple API to do this.

http://www.google.com/s2/favicons?domain=flickr.com

The only draw back I have found with using Google's favicons API is that all the icons are on white backgrounds. I have created a set of PNG favicons with transparent backgrounds for the 70 social media sites which are part of the Ident Engine download or you could try Paul Lloyd's beautifully designed set of Social Media Icons.

When creating an "elsewhere on the web" listing try and make them as easy to read as possible. Full URLs or even domain names are hard to scan read, always try and use the site name, i.e. http://www.flickr.com/people/glennjonesnet/ is displayed just as Flickr (glennjonesnet). It is important to display the username to reassure the user that you have found the right account.

The Ident Engine will accept 4 different ways of inputting a web account address

• http://twitter.com/glennjones
• twitter.com glennjones
• twitter glennjones
• glennjones@twitter.com

There is currently a lot of discussion about finding the easiest way for a user to describe their ownership of a web account. Most systems currently provide a URL that represents an individual, but these can be long and hard to remember i.e.:

• http://twitter.com/glennjones
• http://upcoming.yahoo.com/user/62673/
• http://www.mybloglog.com/buzz/members/glennjones/hcard
• http://www.linkedin.com/in/glennjones

The OpenID community has found that asking users to type in their full URL causes some user experience issues and often creates a barrier to the user.

Any type of web identity discovery system needs two visible pieces of information to work. The DNS name of the service to query and an identifier for the user. The hidden third element is the context of the query i.e. we are searching for information about a person and not some other type of entity.

To facilitate easy parsing it is useful to have a delimiting character that divides the two pieces of information.

How you then construct the input string to identify an individual is less of a technical problem and more an issue of ease and convention. The one I personally find easiest to use is an abbreviated version of the URL:

http://twitter.com/glennjones becomes twitter.com glennjones

The pattern is the web sites DNS then a space and then the user identifier i.e. username. With a closed system like Ident Engine you can go one step further and accept just the name for the website.

The other pattern gaining traction at the moment is the Webfinger email structure. This aims to make the most use of the fairly well ingrained understanding of how you construct an email address and translate that convention into creating an address for any web account:

http://twitter.com/glennjones becomes glennjones@twitter.com

This works best when there is a corresponding email account but can feel a little strange where one does not exist like the Twitter example above.

I have yet to find any publically available user research which backs up either approach.

As well as helping to manage the source code Google's Code site provides a number of other features such as an RSS feed for change notification and an area to raise issues. In the future if people wish to contribute to the development of Ident Engine the site will enable collaborative working.

http://code.google.com/p/identengine/