WhatCommunicationSoftwareToUse

“software for collaboration … the world’s future depends on it” – “A Manifesto for Collaborative Tools” by Eugene Eric Kim[1][2]

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.

types of social software

TheMedium:

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.

group size

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 Also


CategoryCommunication

Discussion

See http://twelve71.com/cgi-bin/wiki.cgi?WikiVersusEgroupVersusBlog broken link

Why are many free software projects using a MailingList and not a ScoopEngine?

  1. Mailing list is easy to create and maintain.
  2. There are gateways from mailing-lists to news servers [3]
  3. This means that some active developers interested in long-term discussions can use their favorite mail-client or news-reader to read threads.
  4. Since mail and news has been around longer, and since these clients are dedicated to dealing with threaded messages, some of these clients are extremely well suited to the task.
  5. Scoop relies on the generic web-browser; the user-interface generally sucks, compared to the favorite mail-client or news-reader of experts.
  6. The one benefit Scoop has over mailing lists – the documents – has turned out to be irrelevant, because existing articles on existing sites are rarely referenced. In that they rather resemble blogs.

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.

Think of something like- coordinating KDE development. A ScoopEngine would be better than a MailingList, a collection of mailing lists, or a wiki, or a combination of the above.

Would you agree with that?

LionKimbro

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.

BayleShanks

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.

BulletSummaryBlock:

  • Can wiki support a large community?
  • My guess: 50 people - ScratchWiki
  • Imagine if C2 had x2 people? x10 people?
    • Can people follow conversations?
    • Can people rework?
  • Scoop sites: I can imagine x10 people.
    • We have tree diagrams,
    • We have “Who replied?” features.
  • Counts: C2 - 35. K5: 200 at a moment.
  • Wikipedia: Supports many, because:
    • Different topics are separable. Each person only follows a small subset of the entire wiki.
    • People have a mission.
    • FilteredRecentChanges

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.

BayleShanks

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.

Videoconferencing:

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.

DistributedEditing, DistributingWiki:

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”.

DavidCary

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

  • pointing out other completely different media that don’t have those flaws. (Instead, they have an entirely different set of flaws :-) ).
  • pointing out different versions of that kind of media that have fixed at least some of those flaws. (Wiki, in particular, seems to have mutated into dozens of WikiEngines, each one fixing one little percieved flaw or another).
  • trying to fix those flaws (perhaps via the SoftwareBazaar). or the ever-popular
  • trying to convince these people that they aren’t really flaws, they’re actually features :-).

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? )

This may be yet another answer to the question “is there any way for social network sites to make money?” – BayleShanks on FOAF.

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?

Independently:

“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.

Ok, what do you think about http://pastebin.com/ ? It seems to be something like an independent SideSystem that makes IRC / IM slightly more wiki-like.

The use case seems to be something like:

  • Bob (in IRC) types that he wants some help with some code.
  • Bob (at pastebin) pastes in the code, and gets a unique URL that refers to that version of the code.
  • Bob (in IRC) pastes in that URL.
  • Alice (in IRC) clicks on the URL, (and now at pastebin) spots the obvious problem, and fixes it. pastebin saves the new version with a new URL.
  • Alice (in IRC) types that she knows what the problem is, and pastes in the new URL.
  • Bob clicks on the URL, then clicks the “diff” button to see exactly what Alice changed. …
  • pastebin deletes versions that are more than a month old. (much like WikiFeatures:IdeasToPlace #66: SelfDestructingPages? ).

Good systems consist of a pastebin website + bot combo, eg. http://paste.lisp.org/.

Thus:

  • Bob (in IRC) types that he wants some help with some code. (Because tradition demands it.)
  • Bob (at the website) pastes in the code, the question, his nick, and his channel
  • The bot (in IRC) posts a unique URL that refers to that version of the code in the appropriate channel, plus nick and question.
  • Alice (in IRC) clicks on the URL, (and now at the website) spots the obvious problem, and fixes it, giving her nick, too.
  • The bot (in IRC) posts a unique URL that refers to that new version of the code in the appropriate channel, plus new nick.
  • Bob (in IRC) clicks on the URL to see exactly what Alice changed.

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.

JonathanRoes wrote an UliBot?, it was really easy to send messages to any service, and then get back a response from it.

Limitations:

  1. Services received ONLY those messages that were directed to them. We didn’t like the idea of sending everything, automatically, each time something was spoken.
  2. Services could not ring the bot. Communication was one-way.

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 :-).

I recently saw this email-vs-wiki diagram showing the difference between email (while attaching proprietary document) and wiki collaboration. Useful to show the efficiency of wiki for document collaboration especially in corporate environment.

Define external redirect: FadingText SelfDestructingPages UliBot BuiltinThreading

EditNearLinks: ScoopEngine AppropriateMedia WikiEngines SlashDot DocumentMode WardsWiki KuroShin RecentChangesJunkies MeatballWiki WikiMindWipe ThreadMess UseNet MailingList

Languages: