Understanding connection types across social networks

My company is hard at work in the final design stages of a Web service which has an enterprise social flavour. In the throngs of a design session this week, we got talking about “handshaking” on social networks – the whole process of inviting people to be inside one’s own sub-network, accepting/declining invitations and how that shapes the information that is shared.

We talked through design patterns from well-known websites and realised that there’s room to sketch out the different models and think about how they are/aren’t relevant to the system we’re designing. It was interesting to consider how these patterns shape our entire experience of different social networks and I thought it would be worth sharing some of our reflections.

Connecting: The reciprocal two way connection

For many people, Facebook was their first experience of socially networked sites. Facebook creates a reciprocal two-way connection: both parties have consented to be in the relationship. ‘A’ invites ‘B’ and ‘B’ needs to accept the invitation from ‘A’ in order to create a connection. Broadly speaking, ‘A’ then sees what ‘B’ posts and ‘B’ sees what ‘A’ posts.

Naturally, if either A or B choose to ‘unfriend’, the entire relationship disintegrates and neither party can see each other’s posts.

Other examples: LinkedIn, MySpace, Foursquare, Gowalla

Following: The loosely coupled pair of one way connection

Twitter wasn’t the first social tool built on the one-way connection, but it was the one that captured the imagination of people beyond the tech industry. ‘A’ follows ‘B’ and sees ‘B’’s posts. There is no compunction on ‘B’ to follow ‘A’. It is a simple, one-way relationship.

If ‘B’ chooses to follow ‘A’, it becomes a loosely coupled pair of one-way connections. Loosely coupled in as much that ‘A’ could choose to unfollow (disengage) ‘B’, but ‘B’’s follow relationship of ‘A’ will still remain.

Other examples: Most forms of blogging, Posterous, Tumblr, Yammer, Instagram, Flickr

Circles: Google+ blurs the lines

Google+ blurs the lines somewhat. Relationships can be a reciprocal, two-way relationship or a loosely coupled one-way connection.

G+ reciprocal two way relationships
‘A’ puts ‘B’ into a circle. In real-world terms, this means ‘A’ wants to share something with ‘B’. If ‘B’ puts ‘A’ into one of their circles, then a loosely coupled reciprocal relationship is created. When ‘A’ shares something with the circle, ‘B’ is in (or publicly), it will appear in ‘B’’s stream and when ‘B’ shares something with the circle, ‘A’ is in (or publicly), it will appear in ‘A’’s stream.

G+ one way connections
‘A’ puts ‘B’ into a circle but ‘B’ chooses not to put ‘A’ into a circle. In real-world terms, ‘A’ is wanting to share with ‘B’, but ‘B’ doesn’t really want to deeply engage with ‘A’. It’s a Twitter-style scenario, ‘A’ will see posts which ‘B’ posts as Public, but not when ‘B’ posts to specific circles.

What’s Google’s big idea?
Google’s argument is that catering for both scenarios in a single Web service is more reflective of real life. We have circles of family, friends and colleagues we have deep engagement with. People who placed each other into circles and are using Google+ to deeply engage with each other. We also want to get content from other people – writers, luminaries, influencers of some description – where we don’t expect them to choose to engage directly with us.

Taking the handshake challenge

It seems there’s a pattern emerging. Services designed for deep person-to-person engagement tend to use reciprocal connections. Services built around sharing content, in all sorts of forms, tend to use loosely coupled one-way relationships.

Enterprise social is an interesting anomaly – it’s about deep engagement but within the context of an existing walled garden (i.e. the enterprise). The invite/accept model may seem more relevant but it would likely be counterproductive to create the notion of being able to decline a connection within the context of a work environment.

Design decisions need to be driven by requirement. The type of service being designed will inform the decision around the handshaking pattern.

So where did we end up with our design decision? Well, we’re building an enterprise social network component so we’re working up a model based on loosely coupled one-way connections.