Social Software and the Politics of Groups
Social software, software that supports group communications, includes everything from the simple CC: line in email to vast 3D game worlds like EverQuest, and it can be as undirected as a chat room, or as task-oriented as a wiki (a collaborative workspace). Because there are so many patterns of group interaction, social software is a much larger category than things like groupware or online communities -- though it includes those things, not all group communication is business-focused or communal. One of the few commonalities in this big category is that social software is unique to the internet in a way that software for broadcast or personal communications are not.
Prior to the Web, we had hundreds of years of experience with broadcast media, from printing presses to radio and TV. Prior to email, we had hundreds of years experience with personal media -- the telegraph, the telephone. But outside the internet, we had almost nothing that supported conversation among many people at once. Conference calling was the best it got -- cumbersome, expensive, real-time only, and useless for large groups. The social tools of the internet, lightweight though most of them are, have a kind of fluidity and ease of use that the conference call never attained: compare the effortlessness of CC:ing half a dozen friend to decide on a movie, versus trying to set up a conference call to accomplish the same task.
The radical change was de-coupling groups in space and time. To get a conversation going around a conference table or campfire, you need to gather everyone in the same place at the same moment. By undoing those restrictions, the internet has ushered in a host of new social patterns, from the mailing list to the chat room to the weblog.
The thing that makes social software behave differently than other communications tools is that groups are entities in their own right. A group of people interacting with one another will exhibit behaviors that cannot be predicted by examining the individuals in isolation, peculiarly social effects like flaming and trolling or concerns about trust and reputation. This means that designing software for group-as-user is a problem that can't be attacked in the same way as designing a word processor or a graphics tool.
Our centuries of experience with printing presses and telegraphs have not prepared us for the design problems we face here. We have had real social software for less than forty years (dated from the Plato system), with less than a decade of general availability. We are still learning how to build and use the software-defined conference tables and campfires we're gathering around.
Old Systems, Old Assumptions
When the internet was strange and new, we concentrated on its strange new effects. Earlier generations of social software, from mailing lists to MUDs, were created when the network's population could be measured in the tens of thousands, not the hundreds of millions, and the users were mostly young, male, and technologically savvy. In those days, we convinced ourselves that immersive 3D environments and changing our personalities as often as we changed socks would be the norm.
That period, which ended with the rise of the Web in the early 1990s, was the last time the internet was a global village, and the software built for this environment typically made three assumptions about groups: they could be of any size; anyone should be able to join them; and the freedom of the individual is more important than the goals of the community.
The network is now a global metropolis, vast and heterogeneous, and in this environment groups need protection from too-rapid growth and from being hijacked by anything from off-topic conversations to spam. The communities that thrive in this metropolitan environment violate most or all of the earlier assumptions. Instead of unlimited growth, membership, and freedom, many of the communities that have done well have bounded size or strong limits to growth, non-trivial barriers to joining or becoming a member in good standing, and enforceable community norms that constrain individual freedoms. Forums that lack any mechanism for ejecting or controlling hostile users, especially those convened around contentious topics, have often broken down under the weight of user hostile to the conversation (viz usenet groups like soc.culture.african.american.)
Social Software Encodes Political Bargains
Social interaction creates a tension between the individual and the group. This is true of all social interaction, not just online. Consider, from your own life, that moment where you become bored with a dinner party or other gathering. You lose interest in the event, and then, having decided it is not for you, a remarkable thing happens: you don't leave. For whatever reason, usually having to do with not wanting to be rude, your dedication to group norms overrides your particular boredom or frustration. This kind of tension between personal goals and group norms arises at some point in most groups.
Any system that supports groups addresses this tension by enacting a simple constitution -- a set of rules governing the relationship between individuals and the group. These constitutions usually work by encouraging or requiring certain kinds of interaction, and discouraging or forbidding others. Even the most anarchic environments, where "Do as thou wilt" is the whole of the law, are making a constitutional statement. Social software is political science in executable form.
Different constitutions encode different bargains. Slashdot's core principle, for example, is "No censorship"; anyone should be able to comment in any way on any article. Slashdot's constitution (though it is not called that) specifies only three mechanisms for handling the tension between individual freedom to post irrelevant or offensive material, and the group's desire to be able to find the interesting comments. The first is moderation, a way of convening a jury pool of members in good standing, whose function is to rank those posts by quality. The second is meta-moderation, a way of checking those moderators for bias, as a solution to the "Who will watch the watchers?" problem. And the third is karma, a way of defining who is a member in good standing. These three political concepts, lightweight as they are, allow Slashdot to grow without becoming unusable.
The network abounds with different political strategies, like Kuro5hin's distributed editorial function, LiveJournal's invitation codes, MetaFilter's closing off of user signups during population surges, Joel Spolsky's design principles for the Joel on Software forum, or the historical reactions of earlier social spaces like LambdaMOO or Habitat to constitutional crises are all ways of responding to the fantastically complex behavior of groups. The variables include different effects at different scales (imagine the conversation at a dinner for 6, 60, and 600), the engagement of the users, and the degree to which participants feel themselves to be members of a group with formal goals.
Further complicating all of this are the feedback loops created when a group changes its behavior in response to changes in software. Because of these effects, designers of social software have more in common with economists or political scientists than they do with designers of single-user software, and operators of communal resources have more in common with politicians or landlords than with operators of ordinary web sites.
Testing Group Experience
Social software has progressed far less quickly than single-user software, in part because we have a much better idea of how to improve user experience than group experience, and a much better idea of how to design interfaces than constitutions. While word processors and graphics editors have gotten significantly better over the years, the features for mailing lists are not that different from the original LISTSERV program in 1985. In fact, most of the work on mailing list software has been around making it easier to set up and administer, rather than making it easier for the group using the software to accomplish anything.
We have lots of interesting examples of social software, from the original SF-LOVERS mailing list, which ifrst appeared in 1970s and outlived all the hardware of the network it launched on, to the Wikipedia, a giant community-created encyclopedia. Despite a wealth of examples, however, we don't have many principles derived from those examples other than "No matter how much the administrators say its 'for work', people will bend communications tools to social uses" or "It sure is weird that the Wikipedia works." We have historically overestimated the value of network access to computers, and underestimated the value of network access to other people, so we have spent much more time on the technical rather than social problems of software used by groups.
One fruitful question might be "How can we test good group experience?" Over the last several years, the importance of user experience, user testing, and user feedback have become obvious, but we have very little sense of group experience, group testing, or group feedback. If a group uses software that encourages constant forking of topics, so that conversations become endless and any given conversation peters out rather than being finished, each participant might enjoy the conversation, but the software may be harming the group goal by encouraging tangents rather than focus.
If a group has a goal, how can we understand the way the software supports that goal? This is a complicated question, not least because the conditions that foster good group work, such as clear decision- making process, may well upset some of the individual participants. Most of our methods for soliciting user feedback assume, usually implicitly, that the individual's reaction to the software is the critical factor. This tilts software and interface design towards single-user assumptions, even when the software's most important user is a group.
Barriers
Another critical question: "What kind of barriers work best?" Most groups have some sort of barrier to group membership, which can be thought of as a membrane separating the group from the rest of the world. Sometimes it is as simple as the energy required to join a mailing list. Sometimes it is as complicated as getting a sponsor within the group, or acquiring a password or key. Sometimes the membrane is binary and at the edge of the group -- you're on the mailing list or not. Sometimes its gradiated and internal, as with user identity and karma on Slashdot. Given the rich history we have with such social membranes, can we draw any general conclusions about their use by analyzing successes (or failures) in existing social software?
There are thousands of other questions. Can we produce diagrams of social networks in real time, so the participants in a large group can be aware of conversational clusters as they are forming? What kind of feedback loops will this create? Will software that lets groups form with a pre-set dissolution date ("This conversation good until 08/01/2003.") help groups focus? Can we do anything to improve the online environment for brainstorming? Negotiation? Decision making? Can Paypal be integrated into group software, so that groups can raise and disperse funds in order to pursue their goals? (Even Boy Scouts do this in the real world, but it's almost unheard of online.) And so on.
The last time there was this much foment around the idea of software to be used by groups was in the late 70s, when usenet, group chat, and MUDs were all invented in the space of 18 months. Now we've got blogs, wikis, RSS feeds, Trackback, XML-over-IM and all sorts of IM- and mail-bots. We've also got a network population that's large, heterogeneous, and still growing rapidly. The conversations we can have about social software can be advanced by asking ourselves the right questions about both the software and the political bargains between users and the group that software will encode or enforce.
Prior to the Web, we had hundreds of years of experience with broadcast media, from printing presses to radio and TV. Prior to email, we had hundreds of years experience with personal media -- the telegraph, the telephone. But outside the internet, we had almost nothing that supported conversation among many people at once. Conference calling was the best it got -- cumbersome, expensive, real-time only, and useless for large groups. The social tools of the internet, lightweight though most of them are, have a kind of fluidity and ease of use that the conference call never attained: compare the effortlessness of CC:ing half a dozen friend to decide on a movie, versus trying to set up a conference call to accomplish the same task.
The radical change was de-coupling groups in space and time. To get a conversation going around a conference table or campfire, you need to gather everyone in the same place at the same moment. By undoing those restrictions, the internet has ushered in a host of new social patterns, from the mailing list to the chat room to the weblog.
The thing that makes social software behave differently than other communications tools is that groups are entities in their own right. A group of people interacting with one another will exhibit behaviors that cannot be predicted by examining the individuals in isolation, peculiarly social effects like flaming and trolling or concerns about trust and reputation. This means that designing software for group-as-user is a problem that can't be attacked in the same way as designing a word processor or a graphics tool.
Our centuries of experience with printing presses and telegraphs have not prepared us for the design problems we face here. We have had real social software for less than forty years (dated from the Plato system), with less than a decade of general availability. We are still learning how to build and use the software-defined conference tables and campfires we're gathering around.
Old Systems, Old Assumptions
When the internet was strange and new, we concentrated on its strange new effects. Earlier generations of social software, from mailing lists to MUDs, were created when the network's population could be measured in the tens of thousands, not the hundreds of millions, and the users were mostly young, male, and technologically savvy. In those days, we convinced ourselves that immersive 3D environments and changing our personalities as often as we changed socks would be the norm.
That period, which ended with the rise of the Web in the early 1990s, was the last time the internet was a global village, and the software built for this environment typically made three assumptions about groups: they could be of any size; anyone should be able to join them; and the freedom of the individual is more important than the goals of the community.
The network is now a global metropolis, vast and heterogeneous, and in this environment groups need protection from too-rapid growth and from being hijacked by anything from off-topic conversations to spam. The communities that thrive in this metropolitan environment violate most or all of the earlier assumptions. Instead of unlimited growth, membership, and freedom, many of the communities that have done well have bounded size or strong limits to growth, non-trivial barriers to joining or becoming a member in good standing, and enforceable community norms that constrain individual freedoms. Forums that lack any mechanism for ejecting or controlling hostile users, especially those convened around contentious topics, have often broken down under the weight of user hostile to the conversation (viz usenet groups like soc.culture.african.american.)
Social Software Encodes Political Bargains
Social interaction creates a tension between the individual and the group. This is true of all social interaction, not just online. Consider, from your own life, that moment where you become bored with a dinner party or other gathering. You lose interest in the event, and then, having decided it is not for you, a remarkable thing happens: you don't leave. For whatever reason, usually having to do with not wanting to be rude, your dedication to group norms overrides your particular boredom or frustration. This kind of tension between personal goals and group norms arises at some point in most groups.
Any system that supports groups addresses this tension by enacting a simple constitution -- a set of rules governing the relationship between individuals and the group. These constitutions usually work by encouraging or requiring certain kinds of interaction, and discouraging or forbidding others. Even the most anarchic environments, where "Do as thou wilt" is the whole of the law, are making a constitutional statement. Social software is political science in executable form.
Different constitutions encode different bargains. Slashdot's core principle, for example, is "No censorship"; anyone should be able to comment in any way on any article. Slashdot's constitution (though it is not called that) specifies only three mechanisms for handling the tension between individual freedom to post irrelevant or offensive material, and the group's desire to be able to find the interesting comments. The first is moderation, a way of convening a jury pool of members in good standing, whose function is to rank those posts by quality. The second is meta-moderation, a way of checking those moderators for bias, as a solution to the "Who will watch the watchers?" problem. And the third is karma, a way of defining who is a member in good standing. These three political concepts, lightweight as they are, allow Slashdot to grow without becoming unusable.
The network abounds with different political strategies, like Kuro5hin's distributed editorial function, LiveJournal's invitation codes, MetaFilter's closing off of user signups during population surges, Joel Spolsky's design principles for the Joel on Software forum, or the historical reactions of earlier social spaces like LambdaMOO or Habitat to constitutional crises are all ways of responding to the fantastically complex behavior of groups. The variables include different effects at different scales (imagine the conversation at a dinner for 6, 60, and 600), the engagement of the users, and the degree to which participants feel themselves to be members of a group with formal goals.
Further complicating all of this are the feedback loops created when a group changes its behavior in response to changes in software. Because of these effects, designers of social software have more in common with economists or political scientists than they do with designers of single-user software, and operators of communal resources have more in common with politicians or landlords than with operators of ordinary web sites.
Testing Group Experience
Social software has progressed far less quickly than single-user software, in part because we have a much better idea of how to improve user experience than group experience, and a much better idea of how to design interfaces than constitutions. While word processors and graphics editors have gotten significantly better over the years, the features for mailing lists are not that different from the original LISTSERV program in 1985. In fact, most of the work on mailing list software has been around making it easier to set up and administer, rather than making it easier for the group using the software to accomplish anything.
We have lots of interesting examples of social software, from the original SF-LOVERS mailing list, which ifrst appeared in 1970s and outlived all the hardware of the network it launched on, to the Wikipedia, a giant community-created encyclopedia. Despite a wealth of examples, however, we don't have many principles derived from those examples other than "No matter how much the administrators say its 'for work', people will bend communications tools to social uses" or "It sure is weird that the Wikipedia works." We have historically overestimated the value of network access to computers, and underestimated the value of network access to other people, so we have spent much more time on the technical rather than social problems of software used by groups.
One fruitful question might be "How can we test good group experience?" Over the last several years, the importance of user experience, user testing, and user feedback have become obvious, but we have very little sense of group experience, group testing, or group feedback. If a group uses software that encourages constant forking of topics, so that conversations become endless and any given conversation peters out rather than being finished, each participant might enjoy the conversation, but the software may be harming the group goal by encouraging tangents rather than focus.
If a group has a goal, how can we understand the way the software supports that goal? This is a complicated question, not least because the conditions that foster good group work, such as clear decision- making process, may well upset some of the individual participants. Most of our methods for soliciting user feedback assume, usually implicitly, that the individual's reaction to the software is the critical factor. This tilts software and interface design towards single-user assumptions, even when the software's most important user is a group.
Barriers
Another critical question: "What kind of barriers work best?" Most groups have some sort of barrier to group membership, which can be thought of as a membrane separating the group from the rest of the world. Sometimes it is as simple as the energy required to join a mailing list. Sometimes it is as complicated as getting a sponsor within the group, or acquiring a password or key. Sometimes the membrane is binary and at the edge of the group -- you're on the mailing list or not. Sometimes its gradiated and internal, as with user identity and karma on Slashdot. Given the rich history we have with such social membranes, can we draw any general conclusions about their use by analyzing successes (or failures) in existing social software?
There are thousands of other questions. Can we produce diagrams of social networks in real time, so the participants in a large group can be aware of conversational clusters as they are forming? What kind of feedback loops will this create? Will software that lets groups form with a pre-set dissolution date ("This conversation good until 08/01/2003.") help groups focus? Can we do anything to improve the online environment for brainstorming? Negotiation? Decision making? Can Paypal be integrated into group software, so that groups can raise and disperse funds in order to pursue their goals? (Even Boy Scouts do this in the real world, but it's almost unheard of online.) And so on.
The last time there was this much foment around the idea of software to be used by groups was in the late 70s, when usenet, group chat, and MUDs were all invented in the space of 18 months. Now we've got blogs, wikis, RSS feeds, Trackback, XML-over-IM and all sorts of IM- and mail-bots. We've also got a network population that's large, heterogeneous, and still growing rapidly. The conversations we can have about social software can be advanced by asking ourselves the right questions about both the software and the political bargains between users and the group that software will encode or enforce.
posted by Arcadia at
6:46 AM
0 Comments:
Post a Comment
Subscribe to Post Comments [Atom]
<< Home