Authenticity in new media

XVII.5 September + October 2010
Page: 22
Digital Citation

The (anti) social net

Elizabeth Churchill

back to top 

It is time we stopped talking about social networks and started talking about people, groups, and relationships.

This is probably the fourth time this week I have said this: Social is more than the social network. It is perhaps the 500th time I have said it in the past two years. Maybe the 1,000th time if you count the past five years.

This is not news to anyone who takes a deep research interest in social networks. Rooted in insights from sociologists like Émile Durkheim, Ferdinand Tönnies, and Georg Simmel, the field as we know it emerged in the 1930s with the work of Jacob Moreno, who invented the "sociogram"—a connection diagram showing people's connections to each other. The term "social network" was coined in the 1950s by John Barnes, a British anthropologist, inspired by the work of Elizabeth Bott and her kinship studies.

These early social network researchers were primarily and fundamentally concerned with people and the social management of relationships and connections. Tacitly or explicitly there was concern for how methods could be triangulated with other data sources to foster an understanding of how people interact—these pioneers were not satisfied with the elegance of the model alone. They understood there was something to be said for looking at people as people, not simply as gates or nodes or conduits to other people. They fundamentally understood that a social network is more than a collection of nodes or dyads; and that each node has dimensions that may not be instantly or easily obvious or observable, but may be highly relevant for predicting their behavior in the network. For many early social network researchers, understanding that models of human social behavior are simplifications was an ethical as well as a scientific stance; they were interested in understanding people, and less invested in the belief they could engineer behavior. One gets the sense that some current network analysts believe their models to be more interesting and more accurate than the human activities and people on whom their abstractions are based.

While some of us intuitively know that being social as a human being involves more than what we do on a social network, once we put on our hats as designers, developers, and business entrepreneurs of social technologies, we often don't act as if we know this simple fact. This is the problem with believing your clean abstraction is the reality rather than a simplification of it. It is also a problem with our design mindset and our design processes.

Why do I say this? Let's invoke the high profile snafus in recent months with social networking technologies, in which the technically possible trumped the socially responsible—Google Buzz and Facebook's privacy settings. In both instances, the focus on what is possible (when you get enough computational power that can make connections) outstripped what was intelligent to do from a human-relations standpoint. Google opened people's profiles to reveal your contacts and whom you chat with to the rest of your network. All this proved, once again, that email contacts/=friends. In my contacts list are electricians, doctors, car mechanics, travel agents, florists, and restaurants. I have never had the urge to share my activities ("updates"), links, or personal photos with them. The labyrinthine privacy settings that Facebook implemented to enable people to retain some control over who can access them and their content was famously published by the New York Times [1]. Facebook's default response was everything is public. To retain your privacy you had to reset the permissions, but for many, the horse had already bolted the stable.

These are the kinds of mistakes that happen when you focus on the network and not the social in social networking—and when you go for what is technically easy not for what is socially appropriate. "Nodes" were upset, betrayed, embarrassed, left vulnerable when their actions and associations were rendered visible, and broadcast beyond their intended or imagined audiences. All because an easy flip of the switch made connections where technically possible, bridging the gaps that were perhaps socially desirable as gaps. Ironically, one of the downsides of an integrated technical network is the potential resultant instability of the social network itself. That is, human beings take a while to develop social norms that enable and preserve their social connections; having a sudden disruption issued from afar and rippled through the system in a flash can be seriously damaging and can take time to repair.

How could the snafus mentioned here have happened? Truly understanding this requires a post-structuralist approach, which basically states it is necessary to study both the object itself and the systems of knowledge that produced the object. Crudely, I would say the "systems of knowledge," that is, the way of thinking that led to these errors, were ones that privileged simplified ideas and simplistic business imperatives over any concern for or understanding of human social engagement. Developers are excited about the hard technical problems but also the relatively easy control a graph (again, once we have the computational power) can give. Entrepreneurs and media strategists are goggle-eyed for the potential audience "reach" and the bucks that can be made. I realize I sound cynical, but perhaps being cynical is also being realistic in this case. There is no judgment here just a perspective on the nature of the forces involved. I confess, though, I expect designers to know better. To be clear, there were plenty of people who argued against what happened in both these cases. But the prevailing logic was "let's go ahead."

So, how could this have been prevented? First, there needs to be a deeper culture of social that is understood within these organizations—and that means more than social as node connections, but rather a "social" steeped in a deeper understanding of what the technology is and how it fits into people's everyday lives. Second, there needs to be a concomitant shift in the way in which design decisions are elaborated and business decisions are made. The evaluation methods used when testing ideas are clearly flawed. The media reported trials and lab tests occurred prior to changes to Facebook and the launch of Google Buzz. Testing in a lab on a small scale and/or testing on oneself (known as "eating your own dogfood") can yield results that are often limited and sometimes fallacious. On the first point, it has been argued we are witnessing a fundamental shift in human sociality because social networking technologies operate on a scale heretofore unseen and unimagined. But the argument can sometimes change: Prior understandings of human social relations from work on social technologies can't offer insights because of this shift in scale. But then, these technologies are tested in lab studies? What happened to "scale makes it all different?" The counter argument to this is "bucket" tests, in which a random sample of users are presented a new experience and the results of that limited release are evaluated, sometimes in a side-by-side comparison with other "buckets" (for those with an experimental training, think of buckets as experimental conditions). This way, testing on the Web itself can generate thousands, millions, and tens of millions of results from which one can arguably generalize and predict more effectively. Can you tell the effect on a social network with a "bucket test"? No, because a bucket is bounded and a social network is not.

Now let's address the "eat your own dog food" model. Geeks, computer scientists, and mathematicians who love networks are not good people to assess your social-networking products. And I include in this people who may not be formally trained in these disciplines but who are immersed (like fish in water) in cultures where these disciplines dominate every day— that is, people who work with geeks, computer scientists, and mathematicians (which would be me). Why? Because we operate simultaneously in user and evaluator mode, John Dewey, in his "Critique of Abstraction: The Intellectual Life as a Tool," makes the distinction between primary and secondary experience. Primary experience is a subjective relationship to external objects that are sensory—emotive, psychological, physical—but not reflected upon. They are experienced. Most of life is conducted in this mode. Secondary experience is a rational process in every sense possible. But it should not be thought that we are even conscious of the distinction between primary and secondary experience. The transition from primary to secondary is simply a matter of coming to be conscious of, and comprehending the experience at hand. This secondary mode of existence is really just our everyday sense of what it means to think about something. People who study social networks from within—the believers of human sociality as network sociality—sometimes can't see what is really going on because they are invested in seeing things as a network. Knowing how someone socializes in your network application is knowing only how they socialize in your network. It is not knowing them as a social being. The view of technical designers, developers, geeks, computer scientists, and graph theorists differs from that of users. Users are primarily primary, and the technorati are primarily secondary.

The idea that we need to critically interrogate and shift the way we think about social technologies in development or emergence is not new. In 1994 Jonathan Grudin wrote a paper entitled "Groupware and Social Dynamics," published in Communications of the ACM [2]. It begins with, "Computer support has focused on organizations and individuals. Groups are different." Grudin goes on to say "repeated extensive groupware failures result from not meeting the challenges in design and evaluation that arise from these differences."

Here is a paraphrase of Grudin's opening lines as I think about social networking sites: Social networking sites have focused on networks and individuals. When it comes to interacting and having relationships, people don't think in terms of the sum total of connections and inter-connections they have, they think of the individuals they know and the groups they belong to. People and groups are different from nodes and networks.

Groups do not necessarily imply work-teams, despite the use of the term "groupware" to denote primarily enterprise team management software. Groups can also be ad hoc constellations of people who congregate around events and content, or who are affiliated by an ongoing interest. Sara Bly and I Iooked at these ad hoc gatherings in virtual environments, and it was Bly and Tony Salvador who coined the term "constellation" for a number of people coming together with some more or less shared interest or focus for short or long periods. Constellations form for short and long term and gather in social online spaces.

Grudin lays out "eight challenges for groupware developers" based on the insight that we need to think about groups not individuals and institutions. I wonder: Would it behoove us to move beyond individuals (user-centered design) and networks? Can a group way of thinking help us move beyond a network way of thinking? So here is my initial list entitled "Challenges for the Social Network Developers." (Grudin's full list is available in the sidebar).

  1. Understand that your intuitions are likely wrong. Remember that you, as a designer/developer, are operating in secondary mode, even if only some of the time. Most people are operating in primary mode most of the time. Given that your intuitions are likely wrong we need to conduct well-grounded evaluation and have an experimental mindset. Which brings me to my next point.
  2. Broaden your ideas about evaluation. This is more than a numbers game. You don't understand social by only looking at your social network, try to understand what else your users are using. Research papers usually report data sets from one social site. Only comparative studies and studies that look at behavior across sites can give a picture of people's actual social patterns. Grand "implications" about human sociality based on data from one social site are overblown and should be taken with a pinch of salt. Start with the assumption that you are being biased and myopic, and from there drill into the data to see what you might be missing. And then go and collect more data from elsewhere.
  3. Understand your constituencies. People operate in groups and communities. I find the word "community" to be almost as nebulous as the word "network." But, that being said, at least we have some idea of what draws people together in a community—that is, why they may be there. We talk about communities of circumstance, communities of interest, and communities of practice; all of these describe different factors that may draw people to one another and different needs that are perhaps being met. Thus, we can think about how these constituencies may have different needs and design features that may only be used by a few but have high value in that they deepen possibilities for collaborative engagement. So, following Grudin's point, don't only support features that are most trafficked. Give some thought to seldom used but highly valued.
  4. Manage change; don't thrust it on people. Social technologies require careful introduction, and changes to social features must be carefully managed in their introduction as well as in their design. This directly relates to Grudin's point about the disruption of social processes. Social technologies sometimes (more often that you'd think) lead to activities that violate social taboos, threaten existing political structures, or otherwise demotivate the very users who are crucial to their success. Social technologies always disrupt social processes, but there are better and worse ways to handle these disruptions. So...
  5. Communicate with people who use your site, and understand what they want to communicate to others and to you. Transparency is essential for conferring a sense of agency on the users of a social service. Further, make sure to understand the crucial distinction between information and data that should be surfaced for general consumption and that which should not be—think about what should be seen (or not) by whom and when and how. Your recommendations will likely differ depending on the group or community you are serving.
  6. Develop a clear ethical stance. As you consider the possibilities for potential disruption of social processes you may end up with predictions that prove false. But the process of thinking through potential issues will ensure you are at least thinking of possible social (not just technical or business) slipups. Think beyond just what is legal to what is ethical. Moving from what is possible or good for business to what is ethical; and that may mean your design process needs to include evaluations and assessments that have a focus broader than Wall Street and your technological advantage.

The takeaway: people operate as individuals and in more or less formally organized groups, they seldom operate intentionally in their prescribed role as "nodes in a network." Sociologist Barry Wellman has been articulately pointing out for years, there is a lot more to social than the "networked individualism" of an elegant graph. There is much we can learn from looking at how people operate in groups, as the group level sits between the focus on a single person, the user, and an abstract entity that is too far from human experience—the network.

back to top  References

1. Gates, G. "Facebook Privacy: A Bewildering Tangle of Options." The New York Times, 12 May 2010.

2. Grudin, J. "Groupware and Social Dynamics: Eight Challenges for Developers." Communications of the ACM 37, 1 (1994): 92–105.

back to top  Author

Elizabeth Churchill is a principal research scientist at Yahoo! Research leading research in social media. Originally a psychologist by training, for the past 15 years she has studied and designed technologies for effective social connection. At Yahoo, her work focuses on how Internet applications and services are woven into everyday lives. Obsessed with memory and sentiment, in her spare time Churchill researches how people manage their digital and physical archives. She rates herself a packrat, her greatest joy is an attic stuffed with memorabilia.

back to top  Footnotes


back to top  Figures

UF1Figure. A social network graph of tweet replies from October 14th to December 11th, 2009. The more lines you have, the more replies you sent to different users.

back to top  Sidebar: Jonathan Grudin's Eight Challenges

  1. Disparity in work and benefit. Groupware applications often require additional work from individuals who do not perceive a direct benefit from the use of the application.
  2. Critical mass and the Prisoner's dilemma problems. Groupware may not enlist the "critical" mass of users required to be useful, or can fail because it is never to anyone individual's advantage to use it.
  3. Disruption of social processes. Groupware can lead to activity that violates social taboos, threatens existing political structures, or otherwise demotivates users crucial to its success.
  4. Exception handling. Groupware may not accommodate the wide range of exception handling and improvisation that characterizes much group activity.
  5. Unobtrusive accessibility. Features that support group processes are used relatively infrequently, requiring unobtrusive accessibility and integration with more heavily used features.
  6. Difficulty of evaluation. The almost insurmountable obstacles to meaningful, generalizable analysis and evaluation of groupware prevents us from learning from experience.
  7. Failure of intuition. Intuitions in product development environments are especially poor multi-user applications resulting in bad management decisions and error-prone design process.
  8. The adoption process. Groupware requires more careful implementation (introduction) into the workplace than product developers have confronted.

back to top 

©2010 ACM  1072-5220/10/0900  $10.00

Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee.

The Digital Library is published by the Association for Computing Machinery. Copyright © 2010 ACM, Inc.

Post Comment

No Comments Found