FRONT - A Strategy, Design and Technology Studio

His talk reinforced a core theme of this year’s Web 2.0 Expo: online services need to integrate with users’ existing social networks if they want to succeed in the long term.

Online Social Systems

A year ago at Web 2.0 Expo I took part in a workshop about online identity and the social graph with Chris Messina, Lane Becker, Ben Metcalfe and Matt Jones. It was a challenging discussion - there is nothing straightforward about the way that people categorise their private and public lives, or the people they count as family, friends, acquaintances and strangers. Love and friendship is a spectrum, a graph, not a set of post-boxes into which we can neatly file the people in our lives.

Much of this complexity remains. Social services encourage the grouping of people into arbitrary categories - followers, friends, family, contacts, without a shared meaning for any of these terms. This might not be a bad thing, but at the very least social services seem to encourage us to behave in ways that we don’t in the “real world” - are they all really your “friends”, do you want to be equally open with all members of your “family”?

Why Can’t We All Just Get Along?

So, while the online social spectrum is still a little clunky, the last 12 months have definitely seen a change in the practicalities of integrating people’s social systems into online services. Joseph Smarr of Plaxo gave us the highlights, and key recommendations:

1. Stop asking people to sign up for your service . Where possible you should acknowledge that your users have probably already define who they are and who their friends are, elsewhere.  Try to use systems like Facebook Connect, Google Friend Connect, MySpaceID to validate their identity.
2. Don’t create your own, new API to validate users’ identity. There are many well develop systems in existence, such as oAuth, OpenID which, while still evolving, provide a solid architecture for user authentication. Don’t try to re-invent the wheel, use the principles of these systems to offer something that’s likely to be familiar to users, and to save yourself time and effort.
3. Don’t “scrape” for contacts. You should avoid asking users for the login details of their other online accounts (like their email account) so that your service can try to import and identify friends and contacts. Why? It’s rude and insecure (you’re basically asking to look in their underwear drawer), prone to break at any moment (if Gmail changes the format of their address book, your service will fail) and you need to constantly maintain your import tools. Try to use a robust, out of the box API or validation scheme to politely gain access to users’ information
4. Don’t lock in data. Where your service extends the user’s profile, or collects data about them, let the user take that data elsewhere. Basically, your service should play nice with others. There’s no point in implementing a flexible, integrated authentication scheme if you’re going to wall-in the data you collect in your service. Build an API around your users’ data using a recognised standard; set the data free

So, that covers most of what Joseph talked about. A very useful talk, one we need to take serious heed of as we build more complex, user-centred services for our clients.