Some challenges in current DataPortability trends

February 11, 2008

In the last couple of weeks there have been a number of very positive steps forward for Data Portability in general and the DataPortability Project specifically.

These include wins by the OpenID Foundation, the IC report, the DataPortability Report and others.

A couple of trends, though, are causing me a little concern and may require a slight course correction before they spin out of control and fragment, rather than standardize, the ecosystem.

1. Tightly coupled OpenID Implementations

On Plaxo right now there is a ‘Sign in with YahooID’ button. This is effectively an OpenID login mechanism, except to remove the user experience complexity of OpenID, Plaxo has worked with Yahoo to make it easier by creating a direct relationship.

This seems antithetical to the promise of OpenID and could ultimately create another mess of tightly coupled vendor relationships that defeat the purpose of a single sign-on identity that any provider can provide and consume.

A more long term solution must be to improve the generic OpenID user experience or devise an education campaign to help users learn the new login process.

2. Google’s Social Graph API

While revealing an enormous usefulness in the existing XFN and FOAF data out on the web, Google’s Social Graph API also reveals a weakness in current XFN and FOAF implementations. Many users are not aware when XFN data is included around URLs they enter, much less when the URLs are marked as rel=me.

For example when Twitter asked me for my homepage, I didn’t understand that I was asserting a semantic link from Twitter to my blog that Google would later document and carve into stone as part of its implicit global social network in the sky.

As it stands, there is a real concern for user backlash as these APIs start being implemented and users find themselves presented with eerily accurate information about themselves magically appearing on websites without their ‘consent’.

Some sort of best practice text and/or iconography is required around fields that will be marked up with XFN – particularly if rel=me will be used to that users can make informed decisions about the type of data they provide and how it might be used. Perhaps even an opt out checkbox is appropriate.

This is probably a job for the Microformat community to dig into and solve. They should probably solve it quickly though.

3. OpenSocial++

As OpenSocial implementations role out, it’s becoming clear that there is no such thing as a pure OpenSocial container. Each container includes proprietary APIs and extensions that widget developers may choose to use.

Presumably these exist to differentiate each network and encourage developers to write enhanced apps for the environment.

The problem, though, is that developers need to write defensively for each custom API leading us to a place similar to browser compatibility hell. App developers will need to write and test their apps across every Container and will either have to hard code support for special APIs or keep their apps generic and ordinary.

Is this sustainable? Is there a better way?

If OpenSocial is going to be the Write Once, Deploy Many model for widgets, then the OpenSocial team at Google need to find a way to address this concern quickly.

4 Responses to “Some challenges in current DataPortability trends”

  1. Nick Lothian Says:

    “Presumably these exist to differentiate each network and encourage developers to write enhanced apps for the environment.”

    This makes it sound like this is a bad thing. No two social networks are alike, so of course each one will have features they want to offer that others don’t.

    As some of those features become more common I would expect they would push down into the standardized API, but ATM that isn’t appropriate.

    I don’t think that comparing it to browser hell is fair at all. Perhaps something more like SQL or RSS/Atom extensions is fairer – you get decent functionality without extensions, but for platform specific extensions you need to use platform specific code. As time passes, some of those platform enhancements become standardized.

  2. victor Says:

    Just want to share my experience on OpenSocial and Social Graph api.
    First, you can really write the same simple OpenSocial application for different social networks. I have tried with hi5 and Orkut and it works : excepted the version problem that will be solved when everybody will use the last 0.7 version, you can right once and put it everywhere (if you do not use specific extension🙂. And moreover, my application try to solve a dataportability goal : open and free you social graph and your friends list. I have to had other export features and security policy but I think the main idea is there.
    About Google Graph API : yes, with a Social Graph navigator you can really discover some information people perhaps don’t want to share, specific code to inform people about XFN tags is a good idea. We need to be able to decide if the link will be or not tagged.

  3. Chirs,
    The Yahoo Login thing does conern me. I do hope OpenID does not become another microsoft Passport. I can understand Yahoo and Plaxo wanting to me things easier of their users. Asking users to use and existing ID ( which is what OpenID is all about anyway ) to login is easier that explaining what OpenID is. The user may already have an OpenID but just not know it.

  4. Hi Chris, I disagree with your contention that the “Sign in with a Yahoo! ID” experience on Plaxo is antithetical to the promise of OpenID. First off, Plaxo has ensured that this doesn’t really preclude users from using a non-Yahoo! OpenID. In fact, you will notice that the familiar OpenID textbox is currently *above* the Yahoo! button. Hence, I don’t see how this is creating a “mess of tightly coupled vendor relationships”. Secondly, as you and the previous commenter have also noted, the button experience removes the complexity with using OpenID. We have really emphasized that we would like to enable mass adoption for OpenID and as has been stated in many places elsewhere, requiring users to remember and type in URLs as their identifiers has been a major blocker to mass adoption thus far. There isn’t much benefit in refusing to adapt user experiences at the expense of mass adoption, is there?

    I do agree with your point that user education is paramount. On that front, I believe we at Yahoo! do a better job of educating users about OpenID than just about any OpenID Provider today. We are actively thinking about pursuing other alternatives that make the OpenID experience easier and safer for users. What you see on Plaxo and other OpenID RPs right now is a good start, but I have a feeling we (the OpenID community) are going to evolve much further than that.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: