![[info]](http://p-stat.livejournal.com/img/userinfo.gif){kind=small}
This is Not a Brain Surgery
Jan. 28th, 2008
10:48 pm - how to develop a killer facebook application
Facebook applications are the latest trend. Now everybody has to have one. Unfortunately, many people do not understand how to design a good facebook application. The usual approach is to take their web site and squeeze as much as possible of its functionality into facebook application. This is usually a very bad idea.
Let us take as an example FlightStats. They have a pretty good web site with useful tools. They know how to track flights and seems to be doing it well. Now let us look at their facebook application. It is just a scaled down version of a web site.
When you design Facebook application you need to aim to please two audiences. The first is obviously a user who has installed the application. He will see it on his profile page and can use it to access some information or to do something. The second, the most important audience, is his "friends" - people who visit his profile page.
The value of putting every piece of information which user might ever need to his facebook page is dubious. You have to be seriously addicted to Facebook to make it your main window into the world and prefer feature-stripped and scaled-down facebook applications to real web sites, which are just one click away in the very same browser which you are using to access facebook. Call me old-fashioned, but I would rather go to google.com than install and use Google search widget on my face book page. So the first question to ask yourself is: what are the reasons for profile owner to keep your application on his profile page? How it is useful to him or her?
When we are talking about profile owner "friends" we should consider, whenever they are interested to see the application on somebody else profile page. For example, if I am to add Flight Stats application, would my friends be interested to track my mover flying to visit me for Christmas? Thus, the second question one should ask yourself is whenever the facebook application you are developing will be interesting or useful for other people to see on user profile.
By now you can probably figure out how to design good facebook application. Keeping these two audiences in mind and trying to present useful functionality to both of them (which does not have to be the same! The application could look and behave differently depending who is using it - a profile owner or a visitor).
If you are serious about developing not just good but great applications you should find a way to explore unique advantages of the facebook platform. Ask yourself, what it is you can do on facebook which you could not do on your regular web site? Most obvious thing is to explore users social graph. For example, you can try to build features engaging user friends. Take a closer look at the most popular applications out there. They all engage users in this manner: leave a message on somebody's wall, send somebody a virtual gift, take a compatibility test together, challenge your friend to a game or quiz, compare tastes, etc. This gives users a chance to interact with each other and this is what really makes facebook applications viral (the holy grail of all web marketing people nowadays).
Speaking about viral aspect: it feeds on something called netowork effects. To exploit that, you need our application to become even more useful with more users adding it. This way the value of application for each user grows with the number of users who have also added it. Let users help to distribute your application. For example taking a movie quiz and putting results on your page could be interesting. But allowing user to challenge one of his friends to take a movie and compare results makes your application viral.
All of this might sound obvious, but as part of my consulting business, I have to explain these things regularly to customers coming to us for help facebook applications development.
Sep. 14th, 2006
01:36 am - PeopleAggregator, modeilling relationships in social networks
For last few months, I was closely following developments in the social network space. Partially because of curiosity, partially for professional reasons (the project I am involved in for a customer). So I have an account at MySpace, Xanga, Orkut, Friendster, Facebook, LinkedIn, OpenBC, and others I forgot the name of. After opening all these accounts it is hard to not to start thinking about meta social networks and social network interlinking. As in many cases LiveJournal was a pioneer in this area not only with providing social networking functionality but also adopting such thins like FOAF and inventing things like OpenID (big Kudos to LJ folks!).
So, when I have heard about Marc Canter's PeopleAggregator I was very glad to see somebody finally doing something in this area. I have attended the talk he was giving at BayCHI meeting another day and must gladly report that he seems to be on the track to success both technically and business wise.
Even though PeopleAggregator site needs more work to become something average internet non-geek user can comprehend and use, and some most exiting features like actually linking several existing accounts from several networks are yet to come, but I am sure we will see them soon.
However, I would like argue a bit on the model he has chosen. As we know well from RDF world it is all about triples:
(subject, predicate, object)
In social networking world the subject is you, the object is some other person and the predicate is relationship type: a relative, a friend, a colleague, a classmate, etc.
The fundamental problem which arises when you link various social networks is that semantic of the predicate varies from the network to the network. For example in Facebook world, the friend is very often a classmate. In LiveJournal, it is just somebody whose blog you read regularly via friend blogroll. In Flickr it could be either somebody whose photographs you like to watch (a ‘contact’ in their terms) or friend of family member to whom you would like to grant the access to some of your personal photographs not visible to general public. So if you try to connect your Flickr and Facebook accounts via some meta social networking site like PeopleAggregator the question arises: how to distinguish these relationship types in order to protect your and other people privacy.
How PeopleAggregator choose to solve this problem? Marc's answer is something he calls "Persona". He suggests that you create several virtual identities with different contact lists, not shared between them. This is a very familiar concept for seasoned Internet users like myself. After all I have two blogs, separating my professional and personal blogging. But, this separation was done mostly because of limitations of existing blogging platforms. I do not hide my identity and in both blogs I am, well, myself, just discussing different subjects with different groups of people.
Somebody may try to separate his virtual personalities further to hide some parts of his identity from different groups of his contacts. My answer to these people is that this is very unwise to expect to be able to protect their secret identities on the Internet. There are many ways to find out who is hiding behind your online alias, and generally you should always assume that your identity could be exposed at any moment.
Now let us consider hypothetical example: Mark plays poker with Peter. Mark is an engineer and looking for a job. Peter works for a software company as VP of Sales and knows Mark only socially, via poker. The relationship between them looks like:
Now, it is conceivable that Mark mentions that he is looking for a job and Peter has heard that his company is hiring engineers and offers to pass Marks resume to Lucy, his HR manager.
Let us project this situation into the social networking word. Mark and Peter are both belong to "PokerWizzards" group at Orkut. At the same time Peter and Lucy are using LinkedIn. Of course, usually Peter does not expose his poker buddies to his business contacts, so when importing all his social network contacts to a site like PeopleAggregator he created two “Persona”. Let us call them "PeterWork" and "PeterPlay". Mark is also usually do not keep a link to his resume on his Orkut profile and might have separate OpenBC profile for his business contacts. As we can see, our relationship graph gets little more complicated:
Both Mark, and Peter now has split personality, with their own contact lists. Mark could not easily send his resume to Peter via his social networking channels first because he might not have it attached to his "MarkPlay" account and because he probably only his "PeterPlay" Persona, which is his personal non-work account at Orkut.
Now let us assume they somehow managed to get Mark’s resume to Lucy and he somehow got hired by Peter’s company. Now they are colleagues and Poker partners at the same time:
Does that mean they would see two contacts for each other on their contact lists?
I think a multiple Persona approach is not good for average Internet user. It is just too confusing. Instead of allowing user, to create multiple Persona it is much simpler to allow him to specify types of his relationships. A user should not be limited by list of pre-defined relationship types - he should be able to add his own. No social network could pre-program all variety of possible human relationship types like "Our kids are going to the same school," "Kennel club members," etc. Additionally, multiple relationship between two members should be allowed (which could be represented to a user as single relationship with multiple labels). And finally, a user should be able to control access to his personal information based on relationship type. For example, a fellow kennel club member will see a name of his terrier. If he also happens to be his coworker, he would see also his business phone number. And the final relationship diagram would look like:
