Occasionally, I'll see this on someone's Facebook profile and it always gives me a chuckle:
I find it ironic that FB gives this as an option to describe your 'relationship status', while they give no such distinction for relationships themselves, and relationships (aka 'friends') are the currency upon which FB is built. For that matter, this is true of all social networks.
Relationships are indeed complicated, and yet they aren't treated as such by these services.
I preface this post by saying that I have never worked for a social networking service, nor have I designed or built one, nor have I ever had source code access to one's inner guts.
Despite this, I have the intertube blogger bravado to state that (a) all of today's social network services are fundamentally broken, and (b) I know how to fix them. I'll also explain why I think this is going to come to a head over the coming year or two.
First, the problem. There are three components to it, two of which really just complicate the first primary issue.
First: Relationships are things, not properties of things.
I believe today's SNs are defined with connections between people being just that, connections. In database parlance, you have a table of properties describing an individual, one of which is a link to a table of 'friends', where this is a list of pointers/IDs of other individuals in the SN.
What that means is that the relationship itself is just a pointer connecting two people. But relationships are more complicated than that aren't they? As a hint, when we discuss relationships we often use nouns, not only adjectives. More on this in a minute.
Second: Not all relationships are created equal.
They certainly aren't all "friends". Of course, if all you've got is a pointer, then you've limited how much you can differentiate between relationships. At least LinkedIn uses the more generic and neutral "Connections". At least this is a term that comes with less baggage.
Third: Having this flaw in the initial design results in kludgy solutions to resulting problems that may cripple the SN.
Software design flaws are, like many things, easier to see in hindsight. In the case of database design, one clue is the amount of bandaids. We see this happening today with FB's kludgy filtering tools. I want this person to be part of this list or that list, etc.
The current 'lists' approach that FB is using is basically a kludge that lets you segregate 'friends' into a couple different groups (e.g. personal friends vs work friends). I'd imagine that each pointer now has an added field of 'type' and this is used to filter functionality ('what kind of friend is this? the kind that receives only this kind of spam but not that kind').
This will only work so long though, and the more people want to overload functionality (what if I want another type, or I have friends I want to be in both lists, etc), the more the bandaids will become cumbersome to handle and for users to manage.
The solution:
As I hinted above, I beleive there are some clues in the grammar used.
For starters, Treat relationships as nouns, which means they are entities and constitute another table in the database design of the social network.
Relationships have attributes. They have a history, a beginning and end, different properties describing what they do/don't entail, and those evolve over time. e.g. Bob and Susan went to school together but only met in their 4th year, became co-workers later, belong to the same church, etc. These are the 'adjectives' that describe the relationship. Relationships can also be assymetrical.
There are verbs too. Certain actions or activities that are part of a relationship.
I'd imagine there'd be a couple ways of implementing this. Tables for different relationship types, or a huge table sparsly populated at the outset. The choices of how to implement this will present tradeoffs between complexity, storage requirements, possibilities, etc.
At the end of the day, there will be some sweet spot in the tradeoffs that will provide the right mix of expanded functionality vs ease of use and storage/compute burden.
I'll also guess what the main pushback is going to be:
(1) The compute and storage requirements will explode! The answer to this one's easy. Tough! Both are getting cheaper, so pick the right entry point and run with it. (Remember when everyone thought Gmail was crazy for offering unlimited storage?)
(2) It will be difficult and cumbersome for people to manage: Agreed. One approach might be to pre-populate defaults people can override, or to start with a basic 'connection' and a peel-the-onion approach through both management over time and learning through history.
It may be complicated, but that doesn't mean people don't want to make sense of it.
There are three reasons why this is going to come to a head.
First the collision/connection of social networks is going to lead to a need for additional filtering/segregating, and this is going to result in a lot of bandaids for SNs that aren't built to handle this need. We've all read stories about someone's FB photos being seen by coworkers, etc. This is only going to get more complicated as people's FB feeds get seeded with their Xbox gameplay achievements or their WoW guild's political chat. The bandaids may snap.
Second, this connection of social networks is only entering its first phase, a phase where individual identities are linked (e.g. My Xbox Gamertag and my FB profile). I beleive this will enter a second stage where other entities in the SN may be shared, like the relationships themselves.
For example, today (or when the FB/Xbox integration ships anyway), I have to belong to both SNs and then tell them both that this gamertag is linked to that FB profile. However, what if I want to be friends with someone on FB when I don't have a FB account at all, but DO have an Xbox Live account? Not possible with the current bandaid solutions, but possible if relationships are tracked separately.
There's a third reason this is going to come to a head, one that arguably going to be an issue sooner than the above one. This is that people will desire more than a 1:1 mapping between identity and persona. Today, most SNs assume that your persona is your online representation of your identity. (In fact, one can argue that one reason FB stole a lot of thunder from MySpace is that it had a looser coupling between identity and persona but thats the subject of another post). However, on some MMOs, someone (one identity) may have multiple characters they play (personas).
The clash between identity and persona is going to messy on a number of fronts. In some contexts (FB, linkedin, paypal, etc) we look for identity to be real-world concrete. In others (say, playing a frilly kitten-girl in a korean MMO) someone may be looking for anonymity. Worlds collide, etc. All the more reason we provide people with tools to manage these things, rather than just labelling everyone 'friend'.
Anyhow, as these three reasons become real issues, there's an opportunity to offer a better type of SN, and beat Facebook at their own game, by being the 'next-gen social network'.
Claiming that there's an opportunity to stop the Facebook juggernaut seems like blasphemy, but people's loyalties are fickle on the Internet. The list defeated undefeatables (MySpace, Everquest, Friendster...) is long. FB is no more immune than any of them were, and the coming problems and opportunities as SNs collide may be the disruption that allows someone else to better serve people's needs.
I'd like everyone to just get along as much as the next guy, but the first step toward that might be in admitting that we're not all friends. It's more complicated than that.
Labels:
AustinGDC,
Conferences,
Trends
