I have been a member of online communities of one type or another for over ten years. My first experiences were with online services like CompuServe. Then I moved on to Usenet and then to email groups and message boards on the web. For a time, I was even a moderator of a message board.
In all that time, I have never been afraid to share a piece of my mind with the people who ran the various services. I'm chronically opinionated, and having a background in programming and web development often allows me to see how things could be done better or at least differently. I can't count the number of times that I've looked at these services and cursed the "idiots in charge".
Reading Design for Community by Derek M. Powazek has given me a new perspective though. It seems that I'm the idiot! Believe it or not, folks, building and maintaining a thriving community is not as easy as it looks!
Design for Community is essential reading for anyone thinking about starting an online community or for those who are currently ripping their hair out over an existing online community. Even those who participate in online communities could benefit from reading it.
Design for Community covers all of the non-implementation issues regarding online communities, whether they are maintained through email lists, message boards, chat rooms or whatever. Each chapter addresses a topic related to online community development. Topics include such things as why to start an online community (hint: it's not to get free content), how to deal with abuse (does the phrase "kid gloves" mean anything to you?), and design issues related to community sites (if you don't want people to abuse a function, bury it!). It also includes chapters discussing specific types of online communities and particular issues unique to the distinct types. The final chapters discuss the future of online communities including new implementation techniques.
One common issue that is repeatedly addressed throughout Design for Community is the barrier of entry and how it can be used to control a community. Every community has some barrier for entry that determines who can and cannot participate. A developer can encourage growth in a new community by having a low barrier of entry or control the amount of abuse in a large community by raising the barrier. A simple thing like requiring an email address will make a site less prone to abuse. The more information that is required and displayed publicly, the more people will act as they would in their "real" neighborhoods. Allowing users to vote on good/bad, useful/not useful, positive/negative puts the power of controlling the tone of the community in the hands of the people. Further, a community can usually best be served by selecting a group of people who behave as you want all community members to act and then stepping away from the day-to-day control of the site a bit. In general, the idea is to reduce work of the owners of the site while empowering the participants. This also allows the owners to get a more impartial view of whether the mechanisms that are in place are working or not.
Design for Community does not offer much in the way of implementation details. One chapter gives a very high level introduction to graphic design issues. Another chapter provides a few suggestions for implementing communities with message boards and web logs. The book also discusses ways to use chat rooms, web cams, and role-playing games to build communities. In each of these areas, Powezek presents what it is, how it relates to communities, and issues related to the barrier of entry. But other than mentioning a few services by name and bashing Infopop's Ultimate Bulletin Board software on more than one occasion, he does not explore how one goes about actually configuring a community site. It also doesn't address the expense of online communities. A small one may be built for very little money. But a successful one might cost hundreds of dollars a month. This isn't given adequate attention, which might lead someone to start a community site that they will quickly not be able to afford. Thus, Design for Community is clearly targeting the decision-makers more than the development staff or bill-payers.
Powazek is uniquely qualified to write a book such as Design for Community. With over 15 years of experience in developing web communities, he has worked for companies such as HotWired.com, LotusNotes.com, and Netscape. He has also created community sites like kvetch.com and fray.com. He knows the business inside and out and has struggled through many of the pitfalls that other people are just beginning to experience.
Powazek writes with the easy style of one who is accustomed to communicating with people. He talks to people rather than down at them. Through his writing, he reveals a rather quirky sense of humor and confidence in what he believes. His recounting of one of his experiences, "The Great Cheese-Off", had me laughing out loud because it is so similar to things that I've seen time and time again throughout each of the communities in which I have participated.
Powazek is not satisfied to just relate his own experiences though. Each chapter concludes with a "close up" interview with one of the big guns in online community development. Each person shares the unique perspective found from developing, maintaining, and, in one case, killing off an online community. Matt Haughey from MetaFilter describes the day that he started speaking to his users and engaging them in conversation. The interaction and thoughtful responses really surprised him because the site suddenly started to develop a life of its own. Caleb Clark, who worked with Netscape's Professional Connection, shares his insights on flame wars and suggests ways to isolate combatants in order to protect the rest of the community. Ron Malda discusses the methodology that is used to keep garbage to a minimum on Slashdot, one of the most active communities on the Net.
I really enjoyed reading a community development book with contributions from such an experienced group of individuals. The reader is allowed to see many of the pitfalls in community development and ideas for how to avoid or overcome them. However, since I have been active in so many communities and am familiar with the work of some of these individuals, I also saw something else. No matter how hard you plan, no matter what you do, no matter how good your intentions, you only have so much control of an online community. There will always be users who are smart enough to circumvent all of the protections that you have built into the community to protect it from itself or who will attempt to use the mechanisms that are meant to protect the community to destroy it. Further, a community may just implode due to the sheer weight of it, regardless of how much work has been done to prevent that from happening. Finally, sometimes the odd combination of business and community features present issues with which no one has learned to deal effectively. It's rather like playing God with only a tiny fraction of His powers.
This was most obvious in the interview with Matt Williams, the Director of Community for Amazon.com. His interview concludes the chapter on commerce communities, or those communities that are developed for the specific purpose of selling something. Williams describes the community features built into Amazon.com and how those features serve to unite enthusiasts and allow them to share purchasing preferences. He explains how Amazon.com controls spam and undesirable content. Given the success of Amazon.com, his model would seem to be great for all commerce communities where participants contribute product reviews. However, an astute observer would know that his story is rather one-sided. Yes, his approach to community development has its good points. But a quick cruise around the community boards on Amazon.com shows that there are still problems in the Amazon.com community. Those who have written reviews are quibbling over topics such as who owns the reviews and whether Amazon.com should have the right limit their use elsewhere and placement of reviews. Obviously, even the pros don't even have all of the answers!
Design for Community also makes it clear that there is no such thing as a "one size fits all" community. A site that is open to the world will attract all sorts of people. When the user base becomes extremely large, the diverse personalities may find that they are totally unable to live with each other. Some people will deal with this by moving on to a community that is more appropriate to their interests and temperament. Others will deal with it by trying to bully everyone else into adopting their philosophies. When this happens, communities typically begin to fail, and some adjustment of the barrier of entry is required to direct the community to the goals for which the community was initially intended. Also, a community site that is wonderful for a smaller group of people may lose its intimacy as it grows. In an interview with Noah Grey on the topic of "Killing Your Community", Grey talks about the birth and death of a community that he developed for male sexual abuse survivors. When it was small, it filled a need for Grey. But as it got larger, he found himself less and less able to have the one-on-one communication that such an intimate issue required. Eventually, he killed off the community because the internal tensions in the site too frequently left him in turmoil.
Design for Community is well worth reading. As I was going through the book, I found myself scribbling notes with recommendations for some of my favorite online communities and for the people who run them. I also found myself thinking about my place in these communities and how the things that I do (or don't do) might affect it. As a web developer, it gives a good basis for discussing community issues with site owners. If nothing else, it has given me a whole new appreciation for the people who care enough to try to keep community sites going.
Author's Note:
I have intentionally avoided addressing how this book can be applied to specific Epinions-related issues. I did not want a review of a book that can be really useful for all community developers to be buried in topics that someone outside of the Epinions community might not understand. For an editorial that applies concepts in this book to Epinions, refer to:
http://www.epinions.com/content_2562367620
Recommended:
