Skip to main content

Home/ Post Etmooc Blog/ Group items tagged education

Rss Feed Group items tagged

Vanessa Vaile

Shirky: A Group Is Its Own Worst Enemy - 0 views

  • a pattern I've seen over and over again in social software that supports large and long-lived groups. And that pattern is the pattern described in the title of this talk: "A Group Is Its Own Worst Enemy."
  • one of the core challenges for designing large-scale social software
  • definition of social software
  • ...70 more annotations...
  • It's software that supports group interaction.
  • although that's a fairly simple definition, how radical that pattern is. The Internet supports lots of communications patterns, principally point-to-point and two-way, one-to-many outbound, and many-to-many two-way
  • Prior to the Internet, we had lots of patterns that supported point-to-point two-way
  • patterns that supported one-way outbound
  • So although the Internet does good things for those patterns, they're patterns we knew from before.
  • Prior to the Internet, the last technology that had any real effect on the way people sat down and talked together was the table. There was no technological mediation for group conversations. The closest we got was the conference call, which never really worked right
  • ridiculously easy group forming is really news
  • software that supports group interaction is a fundamentally unsatisfying definition in many ways, because it doesn't point to a specific class of technology. If you look at email, it obviously supports social patterns, but it can also support a broadcast pattern
  • If I'm mailing you, and you're mailing me back, we're having point-to-point and two-way conversation, but not one that creates group dynamics
  • email doesn't necessarily support social patterns, group patterns, although it can. Ditto a weblog
  • weblogs are not necessarily social, although they can support social patterns.
  • Nevertheless, I think that definition is the right one, because it recognizes the fundamentally social nature of the problem. Groups are a run-time effect. You cannot specify in advance what the group will do, and so you can't substantiate in software everything you expect to have happen.
  • The best explanation I have found for the kinds of things that happen when groups of humans interact is psychological research that predates the Internet, so the first part is going to be about W.R. Bion's research
  • that I believe explains how and why a group is its own worst enemy.
  • The second part is: Why now? What's going on now that makes this worth thinking about? I think we're seeing a revolution in social software in the current environment that's really interesting.
  • And third, I want to identify some things, about half a dozen things, in fact, that I think are core to any software that supports larger, long-lived groups.
  • Part One: How is a group its own worst enemy?
  • Part Two: Why now?
  • The web turned us all into size queens for six or eight years there. It was loosely coupled, it was stateless, it scaled like crazy, and everything became about How big can you get? "How many users
  • But it could only be really a lot if you didn't require
  • answering those readers, and you didn't require those readers to be talking to one another.
  • The downside of going for size and scale above all else is that the dense, interconnected pattern that drives group conversation and collaboration isn't supportable at any large scale. Less is different -- small groups of people can engage in kinds of interaction that large groups can't.
  • We've had things like mailing lists and BBSes for a long time, and more recently we've had IM
  • We've gotten weblogs and wikis, and I think, even more importantly, we're getting platform stuff. We're getting RSS. We're getting shared Flash objects. We're getting ways to quickly build on top of some infrastructure we can take for granted, that lets us try new things very rapidly
  • It's not that you couldn't have built a similar application a couple of years ago, but the cost would have been much higher. And when you lower costs, interesting new kinds of things happen.
  • Why did we get Geocities and not weblogs? We didn't know what we were doing.
  • It took a long time to figure out that people talking to one another, instead of simply uploading badly-scanned photos of their cats, would be a useful pattern
  • So, first of all, this is a revolution in part because it is a revolution. We've internalized the ideas and people are now working with them. Second, the things that people are now building are web-native.
  • Third, in David Weinberger's felicitous phrase, we can now start to have a Small Pieces Loosely Joined pattern
  • So, suddenly you've got this meeting, which is going on in three separate modes at the same time, two in real-time and one annotated.
  • But something different is happening now. In many situations, all people have access to the network. And "all" is a different kind of amount than "most." "All" lets you start taking things for granted.
  • for some groups of people -- students, people in high-tech offices, knowledge workers -- everyone they work with is online. Everyone they're friends with is online. Everyone in their family is online.
  • this pattern of ubiquity lets you start taking this for granted.
  • a different kind of thing than the old pattern of "online community."
  • a second kind of ubiquity, which is the kind we're enjoying here thanks to Wifi.
  • These kinds of ubiquity, both everyone is online, and everyone who's in a room can be online together at the same time, can lead to new patterns.
  • Part Three: What can we take for granted?
  • If these assumptions are right, one that a group is its own worst enemy, and two, we're seeing this explosion of social software, what should we do? Is there anything we can say with any certainty about building social software, at least for large and long-lived groups?
  • "What is required to make a large, long-lived online group successful?"
  • But I can at least say some of the things it depends on.
  • The normal experience of social software is failure
  • failure is inevitably more than 50%
  • Three Things to Accept
  • 1.) Of the things you have to accept, the first is that you cannot completely separate technical and social issues.
  • 2.) The second thing you have to accept: Members are different than users.
  • core group, Art Kleiner's phrase for "the group within the group that matters most."
  • n all successful online communities that I've looked at, a core group arises that cares about and gardens effectively. Gardens the environment, to keep it growing, to keep it healthy.
  • the software does not always allow the core group to express itself,
  • if the software doesn't allow the core group to express itself, it will invent new ways of doing so.
  • mailing list was for meta-discussion
  • So they created this three-tier system, not dissimilar to the tiers of anonymous cowards, logged-in users, and people with high karma on Slashdot.
  • 3.) The third thing you need to accept: The core group has rights that trump individual rights in some situations.
  • So the core group needs ways to defend itself
  • leveraging the core group is a really powerful system
  • you have to accept them. Because if you don't accept them upfront, they'll happen to you anyway
  • All groups of any integrity have a constitution. The constitution is always partly formal and partly informal.
  • there will always be an informal part
  • Four Things to Design For
  • 1.) If you were going to build a piece of social software to support large and long-lived groups, what would you design for? The first thing you would design for is handles the user can invest in.
  • anonymity doesn't work well in group settings, because "who said what when" is the minimum requirement for having a conversation. What's less well understood is that weak pseudonymity doesn't work well, either
  • best reputation management system is right here, in the brain
  • in the back, in the emotional part of the brain
  • If you want a good reputation system, just let me remember who you are
  • Users have to be able to identify themselves and there has to be a penalty for switching handles.
  • 2.) Second, you have to design a way for there to be members in good standing
  • 3.) Three, you need barriers to participation.
  • Ease of use is the wrong way to look at the situation, because you've got the Necker cube flipped in the wrong direction. The user of social software is the group, not the individual.
  • 4.) And, finally, you have to find a way to spare the group from scale. Scale alone kills conversations, because conversations require dense two-way conversations
  • the density of conversation falls off very fast as the system scales even a little bit.
  • soft forking
1 - 3 of 3
Showing 20 items per page