Network Connections Home
Thesis Presentation Message Board Wiki


Introduction  |  More is Different: Why "Social Software," Why Now?  |  Social Network Analysis: The Big Deal About Small Worlds  |  The Big Picture: Friendster, Ryze and Meetup  |  Case Study Analysis: Friendster, Ryze and Meetup  |  Directed Searching: Working the Network  |  Conclusions  |  Sources  |  Printer-friendly Version
Conclusions

Friendster's stated goal is to enable people to build a virtual social network of friends of friends in order to facilitate real world dating and friendships. A good deal of trust is required to make that leap from virtual interaction to real life meeting for the purposes of forging a friendship. Friendster would seem to be well-suited for facilitating face to face meetings, as personal connections on Friendster are supposed to be made though referrals. A user testimonial posted on Friendster expresses this phenomenon as such:
"Christian, 32, single, from San Francisco, CA (member since May 2002) says: We all know that meeting people out in the wild is a risky proposition. With Friendster, you meet people through people that you already know and trust. So it's like having an infinite social network." -- Friendster user testimonial[72]

Friendster's trust mechanism, however, is deeply flawed. Maybe you meet people through people that you already know and trust on Friendster. Except we've seen that Friendster friend lists do not necessarily reflect real world friendships. We've seen that Friendster testimonials skew to paint the best possible picture of a user. We've seen that Friendster's "personal network" can encourage premature network contractions and friendship solicitation. So, the idea that "we're all friends (of friends) here" is really more of a gimmick than a statement of fact. If a Friendster friend that is your real-life friend volunteers to introduce you to another real-life Friendster friend, then the referral is likely to be sound. However, once you begin looking for people to meet on Friendster, all bets are off.

Even in a perfect Friendster world where everyone who said they were real life friends actually was, someone four degrees away from you is still not necessarily socially close. Valdis Krebs, developer of the social network analysis software InFlow, thinks four degrees is too big a number to even bother with:
"The six-degrees small world is a fallacy. The small world is two or three steps. I, for example, am supposedly six steps from Madonna. But if I want a backstage pass, it's not going to happen. On the other hand, if I know you, and you know Madonna's manager, there's a chance it will. The practical limit is about three hops. After that, information, for the most part, doesn't travel."[73]

The largest part of a Friendster user's personal network is the part that is the least accessible: the users that are four hops away. Friendster does not support network traversal, so middlemen ought to be important, and yet the majority of acquaintance chains are too long to support the transmission of information. Reaching specific users or transmitting information becomes so hard that explicit network paths become more of a novelty than an important feature of Friendster's functionality.

Even if one were to find another Friendster user by trawling the network or being introduced by a bonafied friend, the user interaction supported by Friendster does not make the incentive to meet face to face for the purpose of forging a friendship simple and clear. Because email-styled Private Messages are the primary means of communicating, conversation with another user is intense and direct. On a site like LiveJournal, conversation between users is the product of the creation of journal entries. It happens organically and evolves over time in response to the journal entries users create. Friendster Private Message communication, on the other hand, must sustain itself. This is actually quite hard with someone you don't really know. At a certain point, even if you've exchanged pleasant words and learned a few interesting things, you find yourself asking, "Okay, now what?" Friendster has a poor social memory in that users have no way of annotating or categorizing other users, so once the email exchange stops, the user is likely to drop off the radar. But exchanging emails indefinitely is also not a reasonable option because private one-on-one communication is time and energy consuming. If a clear incentive and easy means of planning a face to face meeting is not provided, the communication is likely to burn out before a friendship can evolve virtually or the interaction can shift to the real world.

Unfortunately, because Friendster user-to-user communication is for the most part private, there's no evidence that other users are meeting in real-life. As a result, there's no social momentum built into the system to encourage people to meet. "Everybody else is doing it" really is a powerful motivator, but it's also completely missing on Friendster. In addition, because there are no event-centric components to Friendster's functionality, the burden to arrange a meeting rests squarely on he shoulders of the user. So, not only is it unclear whether or not anyone else is arranging face-to-face meetings, but if you want to you're on your own. Either you must decide to meet one-on-one (which can be scary in real life), or you can try to convene a group of Friendster users by sending separate Private Messages (which is hard to coordinate) or you can post a message to the Friendster BBS. After all, that's what the BBS is for:
"Use the Bulletin Board to post messages (such as questions, party invites, event information, romance issues, etc.) to your entire personal network. You can only see bulletins that were posted by people in your network, and your postings will only be visible to people who are connected to you."
Great. So, if I were a particularly gregarious Friendster user ready to start making those face-to-face connections, I could throw a party and post the invitation to the Friendster BBS--where all 27,067 members of my personal network would see it. Better warn the neighbors.

When it comes to arranging face to face meetings, Friendster has a Goldilocks problem. Some user clusters are too big (your personal network). Some user clusters are too small (Private Messages). No user clusters are just right, because even the users on your friend list must be contacted via one-on-one private messages. Providing ways for users to cluster and communicate around topics of interest or affiliations would be a more organic way to facilitate face-to-face meetings. If the purpose is to foster real-world friendships, convening a group to meet in real life is paradoxically easier (provided that no one particular member must be present) than arranging a one-on-one meeting. Groups provide safety in numbers, as well as a meta-agenda that takes the social pressure off any two given individuals. While Friendster will no doubt birth some friendship success stories (serendipity is like that), its functionality seems far better suited to a dating service than to a friend service.

Ryze, in contrast, circumvents many of the obstacles that litter the path to offline meetings. Ryze's stated goal is to enable people to make connections and grow networks that will enable users to make business contacts. As a result, an inherent advantage Ryze enjoys is that the incentive to meet for the purpose of business networking, as opposed to making a new friend, is clear and simple. First, "business contact" is a relationship that requires far less maintenance than "friend." It's easier to get into; it's easier to get out of. It's also easier to describe and look for the perfect job than the "perfect friend." Furthermore, the fact that network traversal is possible on Ryze, due to the emphasis placed on user affiliations, means that the search itself will be easier as well. Easy is good; it's what keeps the transaction costs of using the software acceptably low.

While the trust mechanism on Ryze initially appears to be the weakest of the three case studies because it's merely declarative in nature, a combination of factors serves to boost the trust factor considerably. Believing someone is who they say they are and knows who they say they know simply because they say it is a bigger leap of faith than accepting the referral of a friend or meeting a person face to face. However, as John Seely Brown notes: "In general, people look beyond information to triangulate reliability. People look past what others say, for example, to gauge trustworthiness. Some clues might be formal and institutional...Others are informal."[74] So, who and what a Ryzer says they know are only part of the picture. Are they members of Networks? Which ones? Do they interact there? What do other Network members seem to think of this person? Do they attend events? Which ones? Is their user profile detailed? Consistent? Are their friendships reciprocal? There are so many ways to be a member of a group and to interact on Ryze that users leave footprints and clues all over the system. A great deal of metadata about users can be collected and mined on Ryze.

If that sounds suspiciously like a little too much work, a user can forgo the detective work all together and rely on Ryze's event-coordination tools to meet the person face to face at a Ryze event. The event-centric elements on Ryze further serve to enhance trust. If you're one of those that prefers eye contact and a handshake to a user profile, Ryzers are meeting in real life and those meetings are both easy to see and easy to join. Circumspect users can attend Ryze events, organized and run by Ryze administrators. Bolder users can attend user or Network listed events. On Ryze, everybody's doing it and it's obvious (you can even get a souvenir print in a convenient wallet size).

Finally, Ryze provides a good combination of public and private means of communicating. Ryzers can communicate with entire groups, on Network BBSs and through Event pages, or with specific individuals, through Private Messages or Guestbook entries. More importantly, however, Ryze also provides users with the tools to manage and remember the virtual and real social interactions they've had and the users they've met. The ability to annotate users in the Contact list means that Ryze can be a powerful transactive memory for users. Gladwell says of memory:
"When we talk about memory, we aren't just talking about ideas and impressions and facts stored inside our heads. An awful lot of what we remember is actually stored outside our brains. Most of us deliberately don't memorize most of the phone numbers we need. But we do memorize where to find them -- in a phone book, or in our personal Rolodex. Or we memorize the number 411, so we can call directory assistance. Nor do most of us know, say, the capital of Paraguay or some other obscure country. Why bother? It's an awful lot easier to buy an atlas and store that kind of information there."[75]

Since there is a human limit to the number of social connections most people can reasonably manage and maintain, Ryze's relationship management functionality essentially serves as a social complexity cruncher. Ryze may bump its head against the scale ceiling a bit, particularly during real life Events, but Ryze's functionality certainly seems to be successfully bridging the gap between virtual and real worlds. The same can be said for Meetup.

Meetup's stated goal is to locally connect people around topics of interest. The most lightweight of the three applications, Meetup achieves this end by employing a radically different design strategy than either Friendster or Ryze: Little to no onsite user-to-user interaction or user identity. Part of the reason meetups happen successfully, despite the almost complete lack of user-to-user interaction, is that the incentive to meet is simple and clear. When you go to a meetup, it's to meet people to talk about a specific topic. No fuss, no muss. In addition, evidence that meetups occur can be seen all over the site. Photographs, user testimonials, news articles, and attendance lists posted to the site all demonstrate that meetups happen. The visibility of meetups and the ease within the system create social momentum.

In addition, meetups look safe. While Meetup administrators do not supervise meetups, all meetups take place in public venues and meetups with fewer than 5 confirmed attendees are cancelled. Of course, there's always the potential that confirmed attendees who RSVP'd in the affirmative might not show up. Arriving at a meetup to find yourself the only user there would be a nuisance, but it wouldn't be dangerous. Meetup truancy, however, could pose a problem for Meetup. Finding yourself the only attendee at a meetup could discourage you from trying Meetup again, particularly if you had to travel to get there. Unfortunately, because there is no consistent pseudonymity on Meetup, there's no way to rely on social norms for regulating RSVP behavior. So, Meetup has to resort to forbidding what it can't prevent. Meetup's only other Achilles' heel is the exact opposite problem: meetups that get too big. Although, splitting or subdividing popular meetups could resolve this issue if site popularity continues to grow.

Perhaps the most interesting facet of Meetup, however, is the fact that half of the top 10 most popular meetup topics are pre-existing social software communities such as LiveJournal, Slashdot, Weblogger, and Fark.[76] Each of these communities is a robust form of social software, conversational in nature and with trust mechanisms and reputation systems of their own. These outside community members will often import their pseudonyms into Meetup. The success of Meetup as an add-on tool for other forms of social software would seem to imply that social software attempting to parlay online communication into offline interactions is best served by the extremes of user-to-user interaction. Either the site should implement a reputation system and support robust user-to-user interaction, or the site should pare onsite user-to-user interaction to a bare minimum. It's the middle ground occupied by Friendster--a present but deeply flawed trust mechanism and middling support for user-to-user interaction--that causes the most trouble.

So, without further ado, an informal collection of Guidelines for the design of social software intended to turn online interactions into offline friend and colleague relationships as gleaned from Friendster, Ryze and Meetup:

Guidelines

1. Make the incentive to meet simple and clear. Real life meetings require an investment of time and energy. If it's not clear what users stand to gain by making that investment, they won't. "Make a business contact" is clear and simple. "Meet another person who also likes to talk about knitting" is clear and simple. "Make a friend" is not clear or simple. Seems like it should be, but it's not.

2. Build event-centric components into the software. If you want users to meet face to face, make it easy for them to do so. Build functionality into the system designed expressly for that purpose. Keep in mind that planning to convene a group is paradoxically easier (provided the participation of any given group member is not required) than attempting to arrange a meeting between two individuals.

3. Don't forbid what you can't prevent. Unfortunately, the honor system is not a valid design parameter. Rely on it at your peril. See: Friendster's invitation policy, Meetup's RSVP policy.

4. Create a transactive social memory. If your software is designed to create an online social network, providing the means to generate an explosion of weak acquaintance ties is not enough. Users should be able to annotate, contextualize and categorize their friends within the system to help make sense of them. The software should remember social interactions and relationships on our behalf. If it doesn't, network ties become too costly to forge and maintain.

5. Make successful meetings visible within the system. Success breeds success. If your software is facilitating offline relationships, make them obvious within the system. Let users post pictures of the event or talk about what happened when they met. Give users an example to follow. Make meeting look like a good idea.

6. Facilitate network traversal and trawling. If your software is designed to create an online social network, provide users with the means to evaluate each other's social affiliations, not just their affinities. Our social affiliations are how we gauge social distance. If users are left affiliation-blind, it becomes impossible to execute directed searches within the system.

7. Beware the Goldilocks problem. Some user clusters are too big. Some are too small. Strive for just right. Just right will depend on what the group in question is trying to achieve. Enabling users to form different groups of different sizes for different reasons will go a long way towards resolving the Goldilocks problem.

8. Expect the system to evolve. Let it. The functionality of Friendster and Ryze evolved even over the course of the last few months. This is not surprising. Social networks are dynamic, and users use social software in unexpected ways. The best thing is just to build something you think will work. Then be ready to change it.

Sources >>>


[72] "Friendster Testimonials," (http://www.friendster.com/info/testimonials.jsp) (31 March 2003).

[73] Jon Udell, "Seeing and Tuning Social Networks," O'Reilly Network, 4 June 2002, (http://www.oreillynet.com/1pt/a/2385) (3 March, 2003).

[74] Brown and Duguid, The Social Life of Information,187.

[75] Gladwell, The Tipping Point: How Little Things Can Make a Big Difference,187-188.

[76] Amber Cartwright and Melora Heavey, "Meetup Findings," (http://stage.itp.tsoa.nyu.edu/%7Eac931/meetUp_findings.html) (29 April 2003).


Introduction  |  More is Different: Why "Social Software," Why Now?  |  Social Network Analysis: The Big Deal About Small Worlds  |  The Big Picture: Friendster, Ryze and Meetup  |  Case Study Analysis: Friendster, Ryze and Meetup  |  Directed Searching: Working the Network  |  Conclusions  |  Sources  |  Printer-friendly Version


Thesis  |  Presentation  |  Message Board  |  Wiki  | Home

Contact: Alicia L. Cervini
Interactive Telecommunications Program, 2003