From the number of emails and calls I get on community each week, it's very clear to me that people have very different ideas when they talk about community. Some talk about blogs when they really mean a group discussion forum, others ask about forums, when they really mean a live chat system, and so on.
Even within a particular service type, such as a forum, there are many models of how teams make use of the service. For example, many teams think of a forum particularly as a product support area. Others thing of it as a way for community members to discuss ideas and new topics. Still others perceive forums as a social gathering/group blog-like atmosphere.
Take another example of a chat system: many have asked us for chats which are more like a presentation with a group of experts that others can submit questions to. Others ask for a free-form open chat room associated with a topic where anyone can ask any question. Still others, consider chats as a private meeting only for a specific group of people.
It's also not limited to a single service either. For example, some want a community service where it's mostly a free-form discussion forum, but occassionaly they can save some information to put into a FAQ. Others want a group document/wiki along with a chat room or forum to discuss some aspects of the document project they are working on. Still others want a blog where occassionally the blogger can have an open chat with people.
My point is that there are many use-cases of these services. Such community use-cases are often repeatable or reusable for different populations or teams. For our site, it's very handy to define such use-cases because the next time you use that model, you have a better understanding of what to expect. Also when people ask for features of the community they want to create, you have a list of use-cases that you may be able to pick from (or create a new one).
From a super-community (a community of communities) like our dW Community, it is even more helpful to have this because you can learn by experience what works and what does not. You can also record best practices on how to interact with the community if you are an outsider, or even within the community.
This kind of semi-formalized approach isn't always perfect or successful but like any kind of knowledge, applying some kind of structure can help in the long-term. This is especially good for the "wild wild west" for new innovative ideas like Web 2.0
Community and social computing
with Tags: use-cases X
I wanted to point out that "use cases" are different than technology implementations in Web 2.0. I've mentioned this before but I really think people need to see the difference between the two points.
An "online diary" is a use case. Lot's of people have them. Before the rise of blog implementations we called them personal home pages. The actual technology evolved over time. There are now videoblogs, photoblogs, etc. but whatever the technology, they are still online diaries.
On the work-level, a "documentation development tool" can be implemented in a great many ways. It could even be implemented in separate application tools (e.g., a forum + a wiki, a workflow app + email + content management system, etc.) There are also many variations of this documentation development tool depending upon the needs. But across all of them the use cases have some common basis.
The idea is to figure out the common/base use cases that are useful and that can be replicated on a common basis such that it can be reused by many. That's where the real challenge lies. Technology after all will always come and go.
For that same reason, I consider the Web 2.0 as a superset of all these use-cases that everyone is so interested in. It is also why "Web 2.0 != blogging", "Web 2.0 != wikis", or any one specific technology. It is the sum of all the ways we interact with the Web under the new common aspects/principles of Web 2.0 (see end of this post).
The rise of Web 2.0 brings a new level of collaboration into the mindsets of the audience. Ideas which were previously taboo, are now actually being considered.
For example, the value of a book is traditionally considered to be in having access to the content of the book itself. For book publishers, this model means: get one or more authors, work on a book, then print and publish the thing, and distribute to bookstores where customers can buy them.
Usually, the ability a person has to examine the contents of the book is usually limited in time (enough time to read some of the book in a store), in content (having access to some portion of the content they can review), or based on the opinion of others.
While not the first, Robert Scoble helped change views while working on his book as a blog, by giving people access to its content while it is being developed online.
This idea is close to my heart and went into the reasoning behind why we needed the developerWorks Books series, and why I helped to start that as part of IBM Press. Somewhere in the following I think is the future of how books can be developed in something that benefits most parties.
It's similar to, although not exactly the same, as "open sourcing" the book since the philosophy of open source does not preclude selling the product. However, if you have access to the contents of the book for free, why would you buy it.
This puts traditional print publishers in a dilemma. Their business is based on selling the product, not giving it away online and hope someone still buys a copy.
To me, both ways seem a little extreme.
Developing a book takes a lot of time and effort and in some topics, by the time you finish writing, a lot may have changed. My guess is that most authors want not only the noteriety but hopefully would also like to get paid from the knowledge they put down. Call me a capitalist, but giving away a year or two of my life to write a book that may become outdated deserves some reward beyond the satisfaction that you've tried to impart some wisdom to the world.
In the fast changing online world, it makes a lot of sense to do some grass-roots promotion of the book by talking about the subject or showing people some of what you have been working on. This is in hopes that later, when you are done writing and editing, people will want to buy the finished product.
Therefore, I think there's a use-case somewhere in between. I say a use-case because I think this is something people will want to do online.
E.g., provide a group of authors with a tool for them to put together a document (say a Wiki), that they can all edit. Develop the outline, and start fleshing out some of the chapters and sections. Then introduce processes between the authors and an editor where they can bring in the editorial process. Then give access to a select audience or even a wide audience to some of the content so you can get some feedback and peer review. Finally, give access to the content and some knowledge about what others think of the book in progress to the book marketing group so they know what it is about and how its doing.
Thus, this package is a specific use-case for book development that involves an online tool for document development, perhaps another tool for discussion, access control to select or public audiences to portions of the content that you choose, ways to measure opinions and traffic to the publicly available/reviewable sections, and then finally a way to transfer the developed content into a format suitable for publishing/printing/distribution.
It involves giving away part of the book for free so that you get a drumbeat going as well as some feedback on coverage. In exchange, you get a better understanding of how the market may receive the work before it is even complete.
The step beyond is where it gets real interesting.
There's no real end to the book, if people are really interested. You could continue working on developing the content, adding new material, and exposing new material to others. You continue to build on a book without having to build a huge business case for a new book or a new edition, unless there really needs to be one.
Paul Dreyfus from our team is helping to make the dW series of books become real and there should be some interesting news coming out this year.
This idea above is so far just my own brainstorming. I doubt it is unique and probably already in force somewhere. It requires the expertise, experience and cooperation of a book publisher, an online publisher, and authors daring enough to try it out. From a Web 2.0 perspective, I think it makes for an interesting approach to team and even community driven content, and brings remixing to a whole new level (between print and online media).
Whether formalized or ad-hoc, there are several common types of communities based on the goals of that group of people
Some of these types include:
The behavior of the groups, the tools they need, the processes they use, etc. are different. Some groups may start out as one type and change into another. It really helps the group to identify what they want to accomplish.
The failure of most groups to develop or encourage a healthy, growing community stems from not setting up that initial direction.
For example, a project-based community need tools help manage the project and the product they are developing. This can be software, but it can apply to any kind of product really. Having tools to monitor activity, define schedules, and record achievements are all hallmarks of a good project management system. However, not all projects need complex PM
tools; in fact they can be quite intimidating or cause bureaucratic overload, which just leads to frustration.
A community of practice needs means for the members to get together and collect their ideas and experiences. Very often, you see this happening in Wikis and other group editing tools.
A community of interest exists to gather more energy and followers to a topic but may not be focused as much on developing knowledge, just sharing experiences. Thus, regular communications through some form of discussion tool is quite healthy.
This is not to say that any of these require only one specific tool to achieve their goal. Quite the converse. You will find that many communities will use the same type of tool for different purposes and many will need multiple tools to interact.
This is one of the reasons why when developing a community, you cannot base it on a single tool like a forum or a wiki, and similar why a single tool does not signify the extent of the community. So far, I have not seen no one perfect solution for all communities.
If you're a community of many other communities like we are at developerWorks, then you will likely have each of these different subtypes within yourself, and then you really need to expand the tools that allow your community members to interact.
Davenport in his book Thinking for a Living points out that the are essentially four basic types of activities carried out by Knowledge Workers in a line starting from :
For example, developerWorks is involved primarily in the activities ofPackaging and Distribution. We rely on authors, contributors, bloggers,and other experts to create the knowledge. We then package thatknowledge in various forms: articles, tutorials, blogs, briefings etc.We then offer a distribution mechanism for these pacakged knowledgethrough our web sites, our live events, etc. This is made available toour readership so that they may try to apply it each to their own uses.
The packaging part is the difficult proposition now in the light of unstructured knowledge.The dW web sites has typically been a e-zine in the past with manyZones each reflecting a magazine along some topic that appeals to someaudience. The knowledge comes from many sources, both within andoutside IBM to attempt to get the best coverage on a topic we can.These are structured into the semblance of an article or a tutorial.
Unstructured or less-structured knowledge, however, is where dWCommunity comes in. It's less structured because it does necessarilyfollow some kind of content format that people are familiar with: thereisn't necessarily an order to how the information is formatted, wherethe answers lie, where to look for more resources, or sometimes evenwho wrote the information or what their reputation/skill level in thesubject is. There is also usually little formal or standardized editinginvolved.
On the other hand, unstructured knowledge is where there is a hugeamount of growth, everywhere on the Internet. Take our blogs forexample: every blogger has their unique style on how they post theirknowledge, or even what kind of info they provide; while it isstructured according to the goals of that person, every visitor has totry to figure out each post or each blogger in context of others. Thisis both good and bad; it invokes style and personality to a greaterlevel. However, not everyone is a born-writer or blogger. Lots ofpeople go to school and study journalism just to learn how to do it;others, I will daresay like myself, have a natural apptitude for it.
To become more useful to those Knowledge Appliers, it helps to know howto better package your knowledge. While blog systems provide a tool forpresenting the knowledge, they don't automatically make you a betterwriter or a better blogger. With unstructured knowledge like blogs, fordW for example, we now share the workload of knowledge packaging withour experts, in exchange for greater freedom for them to carry oncreating knowledge about their activities. We also carry out anotherpart of the Packaging aspect through the blog tool itself.
What we (dW) need to provide is guidance. We collect the ideas,information, practices and success stories on what makes for goodhabits, techniques and practices for more successful blogs. We sharethat information with our bloggers as much as we can. In addition, wecontinue to workon ways to better distribute this knowledge across the site and the net.
Take the example of our blogs and multiply it for each other type ofcommunity tool (wikis, forums, podcasts, etc.) and you can see the rolewe provide in this Knowledge activity line in terms of unstructuredknowledge. When you consider that much of this is still fairly new orbleeding edge, we sometimes have to do the bleeding in the process offinding out what works and doesn't to better support our unstructured knowledge creators.
Unless of course someone else wants to handle that function ;)
We talked about crowdsourcing as a particular community use-case. It definitely counts as a use-case because of the use of multiple community services, tools and need for potential CMs.
(I looked up Wikipedia but there's no entry right now, so perhaps I'll have to add one)
The concept itself is far from new but the delivery is. The core idea is that you pick a topic, invite a crowd to discuss or brainstorm on it, pick top ideas, let people vote on it. The way it's being applied in online communities is interesting. Take a look at a recent Businessweek story on this (and an earlier one from July).
The following is from our slide on this item that draws some from this:
There are plenty of other examples I'm sure that I left out.