Community Builder Anatomy – Part 3 – The Contact Manager

My flickr friends ( well some of them ... )

Contact manager enables community members to mange their list of friends, or foes (those who have been blocked). A contact manager could be as simple as a sorted list of user profiles, or it could get very sophisticated similar to the ones used on flickr or facebook. Friends can view content and activity logs of each other that aren’t otherwise publicly available. In contrast foes have no access to a user’s private or sometimes even public profile.


One of my favourite features in some contact managers is the integration of a geo-map service such as Google Maps. Such an integration enables users to look for other members within a certain geographical area, or within a certain distance from their own location. Ohloh is a network that connects open source developers via the projects they are working on. If you view an open source project profile on ohloh, you can also see the location of all the other developers related to the same project, represented on the map as tiny bubbles. Clicking on each bubble takes you to a developer’s profile. This way a developer can also locate other team members on the map, just in case they wanted to join up for a beer.

Contact manager is the cement that holds a community together. A solid contact manager is also a valuable tool for people who create online virtual teams and collaborate on different types of projects.

Naturally the more people bookmark a user’s profile, the more popular she becomes. A more popular profile means a higher social status within an online community and that kind of social status cannot be achieved over night. In fact, the social status is what keeps many members within a community, because content could be migrated from one community to another, but once a user migrates to a new community, she often has to regrow that social status all over again.

On some applications ( such as facebook ), both user A and B have to agree to be on each other’s friends lists, that is because facebook’s primary focus is helping people stay in touch with each other. However, this isn’t always the case, for example on Flickr photo management application, user A could add user B to her list of friends, yet user B may decide not to reciprocate. In that case A is not really a friend, but more of an audience of user B.

System Design

I think both flickr and facebook contact/friend managers are pretty good examples of UI design, so have a look at those, and make your implementation even better!


The tricky part is perhaps the data model. The list of contacts is basically a mapping table that links users to other users, so there is a many-to-many relationship among users. Have a look at the following table:

Table Contacts
id: unique identifier ( optional )
my_id: integer user id
contact_id: integer contact user id
contactType: enum ( contact, friend, family, colleague, ... )
blocked: boolean ( if blocked == 1 this contact is blocked )
created: datetime
description: text ( optional )

The “id” filed is really optional since this is a mapping or relational table, but some frameworks do use a unique id even for the mapping tables.

“my_id” and “contact_id” are user ids. For a flickr style friendship that parties do not have to reciprocate ( A adds B as friend, B doesn’t have to A as friend ) 2 rows need to be added ( one representing the relationship from A to B, and visa versa ).
For a facebook style friendship that both parties can either be friends, foes, or none, then only one row is enough. In this scenario it would make sense to use “userA” and “userB”, instead of “my_id” and “contact_id” since the direction of friendship is nolonger relevant.
If the “blocked” field is 1 then that means one party has blocked the other party. The logic of how a dysfunctional relationship should be treated is handled by the application.

[tags]rmdstudio cb anatomy, contact manager, social networking, rastin mehr[/tags]