There are many types of SocialSoftware. The question is: What technology, or combination of technologies, should your group use?
In an ideal world, you would rank which MediumAttributes are the most important, and use some combination of software that has all those attributes.
Instant Messaging - Instant Messaging is good for one-to-one on-demand communications. Group meetings by IM can be pre-arranged. Some people don’t like IM, because they don’t want to be interrupted. This tends to be more of an individual’s technology, rather than a group’s.
IRC Chat - IRC chat doesn’t interrupt people like IM does, and tends to be subject focused. It is not used on an on-demand basis. Groups use IRC channels to leave short messages to each other that aren’t quite worthy of being on a Mailing List. They also use them to “hang out,” and know each other personally.
Personal E-Mail - Personal messages sent by email can be used to conveniently carry messages of all sizes. They can be stored for delayed response, demanding no immediate attention. Sometimes, people ignore their e-mail.
Mailing List (E-Mail) - Mailing lists are easy to follow. However, they have very little organization, mostly being a long chain of messages. Joining and leaving mailing lists is a nuisance, at best. People frequently don’t join mailing lists, because the nuisance is too involving. Mailing lists have only one channel, limiting the breathing room for discussion, and, ultimately, limiting discussion size. However, they are excellent for small, focused, groups and group forming (see MailingListThenWiki.)
Wiki - Wiki are collaborative hypertext documentation systems. Of all the systems here, only WikiIsDocumentBased. Depending on the DegreesOfEditorialControl, they can focus document writing between small groups, or facilitate document sharing amongst mid-sized groups. Use Wiki when you want to develop linked documents that will last for some time, or have your messages eventually turn into documents.
Scoop - Scoop is a multi-channel communications system. Use it if you want to foster discussion and shared awareness by very large numbers of people on some open subject. Because members vote on published stories, output documents tend to be good. Documents are categorized. However, they are not reworked, nor cross-referenced, as in wiki. If you want to connect very large numbers of people, Scoop is a great way to go. Scoop doesn’t work well for small groups, which may be better served with a wiki or mailing list.
Bulletin Boards - Bulleting boards generally have a collection of subject-related topics, that are then divided even further into individual threads. Threads open with a message or short document, and then are followed by linear discourse. Use Bulletin Boards when you want a relatively laid back community that can support very large numbers of people.
Blogs - Blogs are a journaling system for individuals, and sometimes groups. Blogs focus on customization, uniqueness, self-ownership, the individual. Use blogs when you want to keep interested parties abreadst of you or your groups activities and work, without necessarily involving them in a community. Blogs are not so good at coordinating activities of large groups of cooperating people, because they feature no SharedAwarenessSystem. (Because there is no SharedAwarenessSystem, we find massive redundancy amongst peer bloggers. Massive redundancy of expression is un-coordinated expression.)
2 way videoconferencing – much science fiction assumes that this will be ubiquitous.
1 way videoconferencing – practically identical to television. Many colleges are exploring transmitting class lectures through the air (television) or through the internet (1 way videoconferencing).
custom application – sometimes someone wants to enable some specific kind of interaction (SocialAffordance) that doesn’t seem to be supported by available systems. So new software is written to support it. For example, StrategicDialogSupportSoftware looks like it might require at least some custom software.
The maximum number of people that these technologies can comfortably support seems to be:
Tiny groups: IM, Personal E-mail, 2-way videoconferencing
Medium-sized groups: IRC chat, Wiki, Mailing Lists
Large groups: Bulletin Boards, UseNet, Scoop, 1 way videoconferencing
Tiny groups are roughly 1-5 people. Medium-sized groups are roughly 5-15 people. Very large groups are roughly 15-300 people.
These figures are very rough.
See http://twelve71.com/cgi-bin/wiki.cgi?WikiVersusEgroupVersusBlog broken link
I think you misunderstand. I’m not suggesting that a Free Software project should use a MailingList.
I’m saying that if you have 100 Free Software projects, and you want to coordinate development amongst them, then a ScoopEngine is best.
Would you agree with that?
I don’t know. I’ve never been part of such a meta-project. The only experience I’ve had is with SlashDot and KuroShin. Both have a frustrating user interface, and I stopped reading either, even though I usually like the kuro5hin stories.
Neat page! Thanks, Lion and Alex. – BayleShanks
Btw, some stuff in my notes from last summer's CMU conference on online deliberation are tangentially related. They’re not very directly related to this page, but I bet you folks would find many of the notes interesting. I’ll put in some more links as I see places that they’d fit.
By the way, I wrote most of that wiki, except for pages where it’s clear I didn’t (i.e. pages with someone else’s name on them). Feel free to incorporate any of it into CommunityWiki if you find anything useful.
I’m not sure that the classification by the size of the community is totally relevant. I do agree that mailling lists are better than personal e-mail when the community grows, mailing lists have been created because of the personal e-mail exchange limitation when lots of people are involved. Again I think that the same may be applied to blog vs scoop system, IM vs irc. Having said that I don’t think this applies to Scoop vs Wiki. While Scoop system are used by large community they offer news services, after an article havs made the headlines it’s more difficult to get back to this article. For a knowledge repository Wikis are far better, and I don’t see why wikis could not be use by a large or tiny community especially as other tools can’t be easily use to provide the kind of services a wiki offers. Also, if the set-up cost of a mailing list is not too high, I don’t see any drawback using mailing lists vs using personal e-mail for a tiny community, only benefits. Finally I don’t see so much difference between newsgroup, BBS and mailing lists.
That’s fair. Let me see if I can answer some of what you said.
:For a knowledge repository Wikis are far better, and I don’t see why wikis could not be use by a large or tiny community especially as other tools can’t be easily use to provide the kind of services a wiki offers.
We agree that, for being a knowledge repository, Wiki are better.
Our difference is: Can wiki support a large community?
I think wiki could support, say, 50 active people, if it was being used as a ScratchWiki. (I need to make the “community size” numbers higher in the DocumentMode text; I’ve gone counting, and in all cases, need higher numbers.) I think ThreadMess becomes a limiting factor. I could be totally wrong, but I think without a stronger messaging infrastructure, it becomes unmanagable.
For a thought experiment: Imagine if C2 had twice as many people. Would it be harder to follow a conversation? What it if had ten times as many people. Would it be harder to follow a conversation? I think it’d be a lot harder.
And reworking- imagine reworking, to please 10 times as many people. (IdentityAndIntegration issues.)
Now, on a Scoop site, imagine that there are ten times as many people. Is it harder to follow a conversation? No, not really, because- You’ve got tree diagrams for your ThreadMode conversations (BuiltinThreading?), and you’ve got the ability to ask “Who’s replied to things I’ve said?” with counts.
On C2, I counted about 35 different unique numbers in RecentChanges. When I looked at Kuro5hin, it said, “there are 200 unique people here, right now.”
I think if you put BuiltinThreading? into Wiki, you could maybe tripple or quadruple the number of people the wiki supported. (The exact multiplier isn’t important- what is important is a sense of “not quite 10 times as many people.”) But then, maybe you hit the “reworking barrier,” where you can’t humanly rework text. However, if you don’t care about reworking, you can probably go even further, until you hit the “WikiMindWipe barrier,” where people are destroying each others comments on accident, or something like that. I don’t know. I just can’t imagine that it’s as smooth and usable as Scoop, and hense has as much traction.
And, we’re talking about Scratch Wiki. CommunalWiki are even more constrained. You want document integration, you want LessRedundancy, you want all types of things when you’re a CommunalWiki, rather than a ScratchWiki. Scaling falls way down, I think.
As for WikiPedia: WikiPedia supports vast numbers of people. But, I think that’s because people pick just one tiny little area to work in, and because there’s a very clear goal: NPOV articles. A small fragment of WikiPedia becomes a “complete wiki” for the person who’s commited to that territory. And I would guess that we could model this fragment as a Communal wiki.
Now, I don’t know know if any of my argument is true. It’s probably full of holes. I’m just describing my intuition here.
Funny that you say
:Now, on a Scoop site, imagine that there are ten times as many people. Is it harder to follow a conversation? No, not really, because- You’ve got tree diagrams for your ThreadMode conversations (BuiltinThreading?), and you’ve got the ability to ask “Who’s replied to things I’ve said?” with counts
because I think that one of the main attractions of wiki is that it is ultimately EASIER to read conversations – I much prefer to read a page on C2 than a SlashDot discussion; since wikis support ConsolidateInformation, excess and redundant information is eliminated and the total discussion on any one page is kept to a readable length.
So, yes, I think that if a site like Scoop grows by 10x, the discussion becomes harder to follow (or rather, is just as easy to follow, but takes too much time).
However, as you know, I agree with your larger concern (we need to incorporate other medias’ discussion management technologies, like threading!). And, I certainly think that the lack of the ability to ask “Who’s replied to things I’ve said?” is a crucial limiting factor in wiki size (one of the top two or three, maybe even #1).
The desire to read replies to your posts is one of the reasons that wiki users become RecentChangesJunkies; if one could monitor specific threads (and sub-threads) for new posts, then one could focus more effectively.
Well, it may be the case that if you get 10 times as many people on WardsWiki, that means that there would be 10 times as much reworking. My intuition tells me that the increase in arguments would counter the increase in reworking. But, I have no real knowledge about this.
Yes; BuiltinThreading? would be nice. It has to be different, though; You need little check boxes next to comments, for deleting. Or maybe FadingText?, or something like that. I don’t know. (FadingText? might motivate some working into DocumentMode..!)
I’m feeling it’s about time to rework the page, incorporating our comments and discussion.
Mattis ‘ back on his Italian 24/7 line, yeah. In Berlin I haven’t but a 56 k modem taximeter line, that’s every second costs (corrupt €) money. Wikiwork on a modemline payed by time is (almost) impossible. I can’t realy relax, I can’t disconnect either. The local policies for short distance telephone connections differ a lot from country to country. For useful work in wiki a cheap or even free 24/7 connection is essential. Another thing is video. Two persons talking and seeing each other, or video conferencing with even more participants. I have tried on videoconferencing programms a bit, without success. Which programms work? On Linux, Mac and maybe even on Win? Is there anything non-commercial, open software based? Is there anybody who would like to try out on a video chat? (Lion, that would be cheaper - and therefor easier to repeate - and it woul carry even more paralingual information than the outstanding phone conversation I still have in mind). An open telephone company should be created. A commercial idea for an open society (earlier or later running its own virtual money, ea. eTerra) to earn some money. In a way everybody on earth should have the possibility to communicate with everybody on earth in whatever way possible. That would be the optimum for the hive-mind to develop. Assuming everybody has access (there’s a bit of a common efford to be made left) we already have it for written conversation - wiki and the thread mode based tools. We have not: worldwide free telephone communication, and - thinking technically forwards a tiny little bit - worldwide free video communication. No reason why videocommunication with someone two blocks away cost more, better be just as free as videocommunicating with someone at the other side of the world. I dream about this little programm you download. You run it and it gives you access to real common, decentralized wiki. Secure wiki, as nobody can switch off the sever anymore. It includes the possibility to phone and videcommunication to whoever participating, which can not be for free right in the beginning, but as more people join in will get cheaper and cheaper. The hive-mind will prove superior, you bet. … Sorry for the babble - is there any new page to be made? -, but it’s just great to be connected to you again. Have a nice day evr’body.
I bought my computer in 1997, and I run Linux, which makes things tricky as far as video conferencing goes. I may be able to rig my girlfriend’s computer to do video conferencing, but it would have to be planned. I’ll ask her about the software to do it. I believe that video on Linux is still difficult, but I may be wrong.
I was thinking earlier about a wiki that posts it’s page database on bit torrent. I don’t think it’d help us a lot right now- I think it’d just make things a lot more complicated. But for something like WikiPedia, where bandwidth costs are real, I could see it being useful.
Perhaps we should extend the list to include pre-computer communication techniques ?
“Electronic-discourse (E-discourse): Spoken, written or a new hybrid?” by Alageswary V A Muniandy 2002 – Faculty of Language Studies, Universiti Kebangsaan Malaysia http://www.nceltr.mq.edu.au/prospect/17/pros17_3avam.asp
I was astonished that Muniandy lumps all computer-mediated communication into one category. But Muniandy also lumps “one-on-one private talk” together with “public speech in front of huge audiences”.
Does Drupal fit into this?
Perhaps we should also collect things people find annoying about particular bits of software – such as "10 Reasons Why Blogs Are an Awkward Conversation Tool". (Or does this go on MediumAttributes ?) Then we help those people by
Does Plaxo count as a “communication media” ?
If so, Plaxo is only the second the second documentation-centered communication media I’ve seen. It’s certainly document-centered, if you consider a business card to be a document. Plaxo appears to be ConsolidateInformation applied to email addresses: a single “white pages” telephone book of email addresses.
I never heard of Plaxo until one of my friends sent me an email this week saying “I’m updating my address book. Please … update me …” with a link that started https://plaxo.com/ and a long, random-looking string. Apparently that string is a password that allows me permission to edit “my” email address information in “her” email address rolodex/database. People are allowed to directly edit “their own” email address once, for all their friends, saving tons of time compared to every person trying to keep every address in every address list up-to-date. (Reminiscent of WhyWikiWorks).
Rather than simply publishing an email address like the “white pages”, there’s a couple of barriers intendended to keep out spammers. According to their forums ( http://forum.plaxo.com/ ), lots of people trust it enough to post their contact information there … but many of those people hesitate to upload their complete contact list full of “other people”’s contact information. ( Would Wikipedia:Talk:Plaxo be a better place for discussion? )
I think it’s a communications media, but I don’t think it’s revolutionary, or “the second document centered media.” I mean, if we’re going to include Plaxo, why not all the website maintenance programs? Surely those have come before, no?
Or is there something I’m missing about Plaxo?
“You may not use the Plaxo Web APIs for or in conjunction with any products competitive with the Plaxo Service. If you offer a product or service which is integrated with the Plaxo Network through the Plaxo Web APIs (an “Integrated Product”), you may not sell or otherwise receive any cash or other compensation for that Integrated Product.” - TOS
As far as I can tell, this means that if you make a program that uses the Plaxo API, it is bound to Plaxo. You can’t make a competing Plaxo server, and they basically ownz0rs you.
I wouldn’t touch it with a ten foot pole.
There are a ton of ways for social network sites to make money. Lots of people are persuing the ways that endanger people, which is sad. Part of our job is to find the people who are doing it that does not endanger them, promote them, and make use of them.
By “endanger,” I mean: Become a drain on people, by unnecessarily tying up the rights and freedoms of their group.
A lot of groups don’t understand it, they just see ease of use.
“why not all the website maintenance programs?”
Because Plaxo (like wiki) is intended for one person to post the initial rough draft, and then someone else – the person most familiar with a particular piece of data – to immediately update it herself, rather than sending a memo to the webmaster ( WhyWikiWorks ).
When I first heard of it it seemed like such a nifty idea. It’s too bad the TOS (once LionKimbro pointed it out) scared me away.
The use case seems to be something like:
Good systems consist of a pastebin website + bot combo, eg. http://paste.lisp.org/.
This system is more comfortable than the one David describes, but it requires the presence of a bot associated with the pastebin website. Usually this means an administrative bottleneck, since you have to beg the bot owner.
I don’t know of a system where channel ops can summon appropriate bots to their channels. That would be cool. We should get lisppaste (the bot for paste.lisp.org) on to #oddmuse.
“Web Services for Robots.” TheBot.
We also talked about using simple telnet: hook a bot up to telnet, forward everything to telnet, speak back whatever responses are returned.
So you write the services for telnet, and then implement telnet on the bots.
All I know about this “Celtx” is what I read on the website: “Celtx … collaboration. It replaces old fashioned ‘paper, pen & binder’ media creation with a digital approach to writing and organizing that’s more complete, simpler to work with, and easier to share.”
Sounds like wiki to me .