This experiment was relatively small and short, having been applied to one group over two days. It would be interesting to know what the effect would be for groups meeting for longer periods. On the first day, we averaged not quite three and a half posts a minute, occasionally spiking to nine or 10. On the second day, the average rose to just over four posts a minute, but the spikes didn't change, suggesting that users were becoming more accustomed to a steady pace of posting.
During the half-hour of chat only/no talking out loud, the average nearly tripled, to over 11 posts a minute, and occasionally spiking to 18, suggesting that during the normal sessions, users were paying what Linda Stone calls "continuous partial attention" to both the chat room and the real room, and with the structures of the real room artificially suppressed, the chat room exploded. (The question of whether the change in posting rate was uniform among all users is difficult to answer with the small sample data.)
Several additional experiments suggest themselves:
For conferences whose sessions average no more than 30 users, having each room assigned its own chat channel could let users listening to the same talk find one another with little effort. Likewise, finding ways of forking large groups into multiple chats might be worthwhile, whether using specific characteristics (UI designers in one, information architects in another, and so on) or arbitrary ones (even or odd date of birth) to keep the population of any one channel in the 12-25 range. (The lack of plasma screen as a public mediating factor might be an issue.)
ARSC translates URLs into clickable links. This suggests other regular expressions that could be added. "A:" plus an author name or "T:" plus a title could be turned into Amazon lookups. A QuoteBot might be very useful, as several times during the two days someone asked "Who said 'Let the wild rumpus start'?" A social network analysis bot might be interesting, logging things like most and least frequent posters, and social clustering, and reflecting those back to the group. (Cameron Marlow of blogdex wrote a simple program during the meeting to display the number of chat posts per user.)
The social network angle, of course, is hampered by the lack of threading in chat. This is obviously a hard problem, but several people wondered whether there might be a lightweight way to indicate who you are responding to, to create rudimentary threading. This may be a problem best fixed socially. If we had asked people to adopt the general IRC convention of posting with the name of the recipient first ("greg: interesting idea, but almost certainly illegal"), we might have gotten much better implicit threading. This in turn would have been greatly helped by tab-completion of nicknames in ARSC.
\whisperfunction is secret, rather than private. In a real meeting, seeing who is having a side conversation can allow the group as a whole to feel the overall dynamic, so a private
\whisperfunction might be an interesting addition, entering lines into the chat like "Clay whispers to Cameron," but providing no information about the content of those conversations.
Likewise, it might be useful to flag interesting or relevant posts for later review. If someone says something particularly cogent, other users could click a link next to the post labeled "Archive me," and in addition to appearing in the general log, such posts would go to a second "flagged comments only" log.
Greg provided a polling function, but you had to click off the chat page to get there, and it was only used once, as a test. Given this failure, polling and voting functions may need to appear directly in the chat room to be useful. Bots are an obvious interface to do this as well. A PollingBot could ask questions in the chat room and accept answers by
Given that meetings generally involve people looking at similar issues from different backgrounds, DCC-like user-to-user file transfer might be a valuable tool for sharing background materials among the participants, by letting them send local files as well as URLs over the chat interface.
We got close to the edge of IRC-style chaos, where the chat scrolls by too fast to read it. A buffering chat channel might solve this problem, by having some maximum rate set on the order of 120-150 words a minute, and then simply delaying posts that go over that limit into the next minute, and so on. This congestion queuing would let everyone say what they want to say without dampening the ability of other participants to take it all in before reaction.
Finally, ARSC is server-based. With Zeroconf networking, it might be possible to set up ad hoc, peer-to-peer networks of laptops without needing to coordinate anything in advance. Likewise, while DCC-ish file transfer might be valuable for person-to-person file sharing, the ability to post "I have a draft of my article on my hard drive at such and such a local address" and have that material be as accessible as if it were on the Web would make public sharing of background materials much easier.
Real world groups are accustomed to having tools to help them get their work done -- flipcharts, white boards, projectors, and so on. These tools are typically used by only one person at a time. This experiment demonstrated the possibility of social tools, tools that likewise aid a real-world group, but that are equally accessible to all members at the same time. There are a number of other experiments one can imagine, from using the chat to accept input from remote locations to integrating additional I/O devices such as cameras or projectors. The core observation, though, is that under certain conditions, groups can find value in participating in two simultaneous conversation spaces, one real and one virtual.
Return to the OpenP2P.com.
- Trackback from http://radio.weblogs.com/0110772/2003/01/06.html#a693
Profs vs. the Web
2005-07-18 13:14:32 [View]
- Trackback from http://mtl3p.ilesansfil.org/blog/archives/2004/10/31/more_on_the_backchannel.html
More on the Backchannel
2004-10-31 21:16:16 [View]
- Trackback from http://www.corante.com/many/archives/2004/06/01/the_backchannel_and_conference_design.php
The backchannel and conference design
2004-06-01 15:25:46 [View]
- Trackback from http://www.corante.com/many/archives/2004/04/12/orcmid_on_the_backchannel.php
Orcmid on the Back-channel
2004-04-12 12:44:27 [View]
- Trackback from http://jmcgeexp/research/2003/01/20.html#a2902
2004-02-04 09:11:57 [View]
- Trackback from http://mtl3p.ilesansfil.org/blog/archives/2004/01/20/ive_been_wanting_to_do_this_for_a_while_now.html
I've been wanting to do this for a while now.
2004-01-20 19:04:27 [View]
2003-07-24 06:23:51 anonymous2 [View]
Reinventing Group Support Systems
2003-05-13 18:30:21 anonymous2 [View]
2003-02-03 05:52:03 anonymous2 [View]
is it too techy?
2003-02-02 08:01:41 anonymous2 [View]