Content-type: text/html Downes.ca ~ Stephen's Web ~ On-Line Conferencing

Stephen Downes

Knowledge, Learning, Community

May 06, 1996

This Proceedings Article published as On-Line Conferencing in Distance education & technology: Future visions, Second annual professional development workshop Online May 06, 1996. University of Maryland University College [Link] [Info] [List all Publications]

Introductions

My purpose in this presentation and in the discussion to follow for 
the next week is to explore the topic of on-line conferencing. 

Much of this conference thus far - not surprisingly - has focussed on 
the world wide web and HTML. To me, this is a very small - and in the 
end, less effective - part of the internet.

The real power of the internet is not global publishing, it's global 
communication. And it is here that on-line conferencing shines.

First, however, some background information and reading.

As the introduction to this session mentioned, I am co-founder and 
administrator of an on-line conferencing facility called the Painted 
Porch MAUD (Multi Academic User Domain). The home page for the 
Painted Porch may be found at:

   
   http://www.assiniboinec.mb.ca/www/isiit/maud.htm

One use of the Painted Porch is to conduct on-line discussions. 
Recently Jeff Mclaughlin (Cariboo College), Terry Anderson 
(University of Alberta) and I conducted an on-line seminar for the 
Canadian Association for Distance Education.

This seminar was supported by a list-serv, much like this one, and a 
set of web pages. The web pages included links to background 
discussion about MAUDs, MUDs and MOOs. For those of you who have 
world wide web access, the address is:

   
   http://www.assiniboinec.mb.ca/www/isiit/cade.htm

For those of you who do not have world wide web access, your plight 
is one of the topics I hope to address this week.

While I'm dishing out web addresses, the issue of critical thinking 
came up quite a bit in the first week of this conference. One web 
resource I maintain (and have received a lot of feedback on) is a 
series of pages called "Stephen's Guide to the Logical Fallacies". It 
may be found at:

   
   http://www.assiniboinec.mb.ca/user/downes/fallacy/

And finally, my home pages may be found at:

   
   http://www.assiniboinec.mb.ca/user/downes/

--------------------------------------------------------

Why On-Line Conferencing?

In my mind the need for on-line conferencing is obvious, however, in 
my experience a need for on-line conferencing needs to be shown 
before it will be adopted.

This is partly due to history. On-line conferencing has its origins 
not only in email (the application most of you are familiar with) but 
also in role-playing games such as Adventure.

For those of you not familiar with Adventure, it is a piece of 
software which spread through mainframes in the late seventies and 
eighties. The user was given a description of a situation and asked 
to enter commands describing chosen actions. Depending on the 
commands entered, different situations would be presented and, if the 
user was at all successful, he or she (usually he) would be led 
through a series of "rooms" deeper and deeper into a dungeon. In this 
dungeon, said user would seek to aquire objects, fight monsters, and 
in the end conquer the dungeon.

Needless to say, this game was frowned upon by system administrators 
(or their managers, as many of the games were installed by system 
administrators).

Adventure was the inspiration for what is now a phenomenon on the 
internet, the Multi-User Dungeon, or MUD. Indeed, as the name 
implies, a typical MUD is nothing more than Adventure with the 
element of multi users added. Originally run over a single network, 
they were soon designed to run over the internet. People from around 
the world could log into a MUD and participate with others in the 
same adventure.

Needless to say, system administrators really didn't like this, and 
many placed restrictions on MUDs and MUDding. 

OK, why this story? The point is, many people consider on-line 
conferencing to be frivolous and wasteful of system resources. This 
has had in my mind profound consequences in the nature and shape of 
on-line conferencing today, beginning with the fact that its use must 
be justified over and over.

So, why on-line conferencing?

I argue for on-line conferencing by analogy. With the advent of the 
book it became possible to store all necessary information about a 
particular subject in an easily accessible highly portable format. 
The invention of the book made it possible to learn everything that 
needed to be learned without the use of oral communication. 

And indeed, oral communication is wasteful. People read a lot faster 
than they can talk. And a lot of talk is spent in trivia - it's 
common to start a speech with a joke, but much less so a book. And 
books are much more efficient. They do not wander all over the place 
or stray off-topic. They can't be interrupted. They don't need to be 
remembered; the same information, word for word, is still there the 
next day.

But as it turns out, the book did not replace oral communication in 
learning. It turns out that learning is not merely a cognitive 
phenomenon, it is a social phenomenon as well. People need much more 
than information; they need to know why they are getting this 
information, how it can be used, how other people use it, how other 
people understand it. They need support, encouragement, and 
relevance. None of this is provided by a book, and, in the end, none 
of this is provided by the world wide web.

So too while we could say that on-line conferencing has all of the 
disadvantages of oral learning, we can say that in the same way, and 
for the same reasons, it is essential.

-----------------------------------------------------

Real Time Conferencing

These definitions may be old hat for many readers but they bear 
repeating here: the distinction between synchronous and asynchronous 
communication.

In synchronous communication, dialogue is conducted in real time. 
That is, one person makes a statement and another person hears that 
statement at approximately the same time the statement is made, and 
may offer a response to that statement within a few seconds. The 
classic example of synchronous communication is a face-to-face 
conversation.

In asynchronous communication, there is a time-delay between 
statement and response. The statement is stored in some device - a 
letter, perhaps, or a book, or computer memory - and is accessed at a 
later time by the receiver, who may then respond in the same format. 
The classic example of asynchronous communication is email.

Approaches to on-line conferencing may be split down this divide. 
Let's look at the classics:

Asynchronous Communication:
   - email - I assume everybody knows what this is (otherwise this 
conference would be impossible to conduct).
   - usenet - most readers are probably familiar with usenet as well. 

Synchronous Communication:
   - MUD - as discussed above, the MUD is originally an on-line 
multi-user game. Participants interact with each other using speech 
commands. For example, I may "tell taylor" that it's time to get a 
new torch.
   - IRC - stands for "Inter Relay Chat" and is probably familiar to 
most readers. Participants log on to a server and join various chat 
groups. Chat groups are usually defined by topic. Once logged on, 
anything a person types (with the exception of commands) is seen by 
any other person logged onto that chat group.

The advantages and disadvantages of each mode of communication stem 
from the time factor. MUDs and IRCs allow for immediate responses and 
quick question-and-answer sessions. Because responses are immediate, 
they are more revealing of a person's character, temprament, and 
knowledge (hence they have certain advantages for testing).

Like any conversation, however, on-line chats have their limitations. 
It would not be possible, for example, to conduct this seminar 
through a MUD. Even were the system able to accomodate so many 
people, a room full of 700 people having a conversation at once would 
be chaotic (though this chaos does illustrate one of the appeals of 
MUDs as recreation, in the same way that a nightclub is so suited to 
recreation). 

Further, except in rare cases where a conversation is logged, there 
is no record of what has been said. If a person is right there and 
paying attention, they understand what was said. Otherwise, they 
miss it. Like a lecture or a forum, late arrivals cannot catch up on 
what they have missed. 

Also, like verbal conversation, synchronous communication is more 
liable to distractions and interruptions (more so, even, because the 
computer places a certain distance between individuals which makes 
them less aware of the consequences of their actions).

-----------------------------------------------------------

The Primacy of Text

All of the on-line conferencing systems discussed above have one 
feature in common: they are text-based. This makes them fundamentally 
different from the world wide web and from contemporary information 
media such as television, radio, casettes, and CD-ROM. And it 
explains why, until very recently, the internet was dominated by 
well-educated (and therefore upper-income) users.

This has been discussed at some length in the previous posts in this 
conference and so I would like to linger on it for a moment. For 
there is a widespread concern that access to the internet is limited 
to the rich and well-educated.

But let me contrast the internet to another well-known communications 
medium: television.

TV is, as we all know, almost universal. In western countries 
especially almost every home has a television set. The number of 
hours spent by children and adults in front of the "boob tube" is 
legendary. Television is pervasive, it is influential, and there is 
no widespread concern about lack of access.

But discussed less is the cost of television. It's not cheap, or more 
accurately, it's not a lot cheaper than internet access. A cheap 
television, like a cheap computer, may be had for one or two hundred 
dollars, while more expensive models may cost in the thousands. And 
while watching transmissions costs nothing more than the 
inconvenience of commercials, many people choose cable even though 
this may mean a monthly expense of thirty to sixty dollars. While 
it's true that television is a little cheaper than the internet, it 
is not cheaper by any order of magnitude.

Cost alone does not explain why only three percent of Americans (to 
cite a figure from a previous post) use the internet. The newness of 
the technology does, to a large extent, but in what does this newness 
consist? I suggest that it is the fact that the internet has been - 
and still is - perceived by many people as hard, in exactly the same 
way they see reading as hard. 

The recent surge of the internet parallels exactly the development of 
the world wide web. And what is significant about the world wide web 
is that it is not merely text-based. It incorporates images, sounds, 
and video. It is thus a lot easier for people to understand than the 
internet of old.

Because the old forms of conferencing are text-based, they have been 
largely left behind by the world wide web (and I point to the 
majority of discussion in this conference as evidence). But the world 
wide web is not a conferencing tool. It is more similar to a book (a 
picture book, perhaps, but still a book) than a conversation.

-------------------------------------------------------

Web Based Conferencing

Although the world wide web is not suited to conferencing, this fact 
has not prevented people from trying. Some efforts of note:

Hypermail: this is a program which takes email archives and displays 
them as web pages. Input to hypermail is typically submitted from a 
web page using a form. Messages can be sorted by author, by date, or 
by topic (groups of messages about the same topic are known as 
"threads"). For an example of hypermail, go to http://www.thespot.com and 
look for the Spotboard.

Web Chat: this program is very similar to hypermail except that 
messages are displayed on the same page. For an example of Web Chat, 
go to http://www.parkland.assiniboinec.mb.ca/chat.html

It is also worth noting that Netscape has incorporated both email and 
usenet into its web browser. This allows a person to go from a world 
wide web page to a newsgroup, or from an email message to a web page, 
simply by clicking on a link.

In my mind, none of these is successful, and for two reasons:

First, despite their attachment to the world wide web, they remain 
text-based. Hence, they are no improvement upon - and considerably 
slower than - email, usenet or MUDs.

Second, they are asynchronous. Even though they are designed to 
emulate real time chat, it requires input from the user to update a 
web page. There is always a time lag because users do not want to 
update their web page every second or two (and speed makes this 
impossible in any case).

I am not familiar with any web-based chat programs which avoid these 
two obstacles. Input would be welcome here if in fact I am in error.

--------------------------------------------------------------------

Graphical MUDs

Another approach to graphical on-line communication is the graphical 
MUD.  two major approaches are currently in use:

First, the model developed (and heavily marketed) by The Palace 
depicts users as icons and surroundings as background images. 
Conversation is typed by the user and appears as text-bubbles over 
the appropriate icon.

In order to use the palace, users must download a dedicated client 
program and install it on their computer. This program then makes a 
connection over the internet with a palace server.

In my opinion, the Palace model is not the way to go. Even with a 56k 
connection it still takes several minutes for background images to 
load. Additionally, the amount of text which can fit into a text 
bubble is limited. With the exception of character icons flitting 
about, the displays are static and predictable. None of the richness 
of a MUD is present in the Palace. Check for yourself at 
http://www.thepalace.com

Another approach - and in my mind a more promising approach - is the 
use of virtual reality in a mud environment.  Several such systems 
exist; a client-server assembly called "Other Realms" is an example. 
Because of the use of virtual reality, windows NT or 95 is required 
to run the client (windows 3.1 users need to install a 32 bit 
emulator). My own experience with this software is that it is 
unstable, but future versions should reduce this problem.

------------------------------------------------------

Conferencing Systems

Another approach to on-line conferencing is on-line conferencing 
systems. Two major examples spring to mind: Lotus Notes, and First 
Class.

Each of these requires a server and a client. Users use the client 
software to log onto the server and enter a conference. Conferencing 
systems have the advantage of allowing for threaded discussions, 
private and public mail, retrievable documents, and participation 
from a distance.

However, conferencing systems are for the most part asynchronous. 
This means that they have no clear advantage over the much more 
popular and widely used world wide web. The installation of 
additional software and the lack of easy access to other internet 
resources - such as web pages - also speaks against them. Finally, 
they are - like the traditional internet - text-based. This means 
that while they are useful for business applications, they will not 
capture the imagination - and the minds - of a large number of users.

--------------------------------------------------------------

Technical Issues

Let me now turn from this survey of the different approaches to 
on-line conferencing to some of the technical issues which will be faced by 
people who wish to start a service of this sort.

First, in all cases, a server is required. A server is a computer 
connected to the internet which is running software which can accept 
logons and interact with remote users. As a general rule, the better 
the computer, the faster the server. At a minimum, however, nothing 
less than a 486 should be contemplated. Because many users are 
involved, as well, memory requirements are often high. 32 megabytes 
of RAM is my minimum recommended configuration for any on-line 
service.

The operating system is also important. While MUD software exists 
even for DOS-based machines, the fact that many users are involved 
means that the server must be able to perform many tasks at once. DOS 
is not suited to this; nor is Windows 95. Most MUDs and IRCs run on 
Unix or Linux software. Windows NT is also a popular choice. I can't 
speak for Apple computers because I don't know anything about them 
(nor do I care to, but that's a different story ;) ).

Line speed is also a major factor. It is important to consider line 
speed not only from the server end, but also at the user end. Many 
people will connect to the internet using a modem, and this may mean 
speeds as low as 2400 baud (though 14400 is better considered to be 
an average). As a rule, the lower the line speed, the less fancy you 
can be (and by "less fancy" I mean more text, fewer graphics).

MUDs and IRC shine in conditions of low line speed. Because they are 
text-based, and because typically only a few lines of text are sent 
at a time, MUDs are accessible even by people running an old IBM PC 
or an Atari ST with 2400 baud. They are therefore much more 
accessible to people in rural or remote regions. Their disadvantage - 
as has been noted - is that they are text-based and therefore not as 
easy to use as the world wide web.

On the server side, anything less than 56K is probably too slow (I 
have run MUDs on 28800, but I haven't liked it). Even at 56K 
performance may be sluggish is there are many users (one advantage of 
asynchronous communications is that the users are not all logged on 
at the same time. This means that linespeeds may appear faster). 
Obviously, better linespeeds mean better performance (though over T1, 
text-based systems simply top out because there isn't any more data 
to send).

----------------------------------------------------------------

Time

One factor which is seldom discussed in the area of on-line 
communication is time. Simply put: it takes a LOT of time to put 
together a quality on-line conferencing facility. 

The amount of time varies with the complexity of the software. One 
advantage of packages such as Lotus Notes or FirstClass is that they 
require little configuration (compared to, say, MUDs). This 
advantage, however, comes at a cost: there is much less flexibility 
for the user at the other end.

MUDs, by contrast, can be configured in a wide variety of ways. This 
is possible because service providers can define a virtual 
environment using a pseudo coding language (usually a variation of 
C). Hence, a person logging onto a MUD may greet an object which 
talks, read some mail, look at a bulletin board, participate in a 
discussion, act out a scenario - in short, any form of interaction 
which may be imagined. However, a small mud may take 200 hours to 
design.

My experience also is that all on-line conferencing systems require 
maintenance. There is no such thing as a computer program which 
doesn't crash, or which doesn't have bugs which need to be worked 
out. The amount of time required for maintenance varies depending on 
the complexity of the software. 

------------------------------------------------------------------

User Issues

One of the major factors to be faced when implementing an on-line 
conferencing system is the user's inability to use the system to its 
full potential.

In text-based systems, designers are faced with the fact that users 
will not read all the text. This is a weakness in many MUDs and MOOs 
(designers, are you listening?). At the Painted Porch, we determined 
that a user will read six to eight lines of text at a time. This had 
a major impact on our design. Room descriptions are kept very short. 
Help files are kept short.

(As an aside, this knowledge has had an impact on my other electronic 
conferencing. Readers of this post - although very long - should have 
had an easier time because the paragraphs are short. I would be 
interested in hearing perceptions).

Another factor is user training. Standard applications, such as 
email, usenet or the world wide web, have a significant advantage 
here because the user is likely to already know how the system works. 
This is one major advantage of a list-server conference such as this.

But even the slightest deviation from the expected may cause havoc 
with users. A list service called e-conf (to which many readers here 
probably subscribe) required that its server commands be placed in 
the subject field of an email, rather than in the body as is usual 
for a list-server. This resulted in a deluge of messages sent in 
error and a great deal of hand-wringing on the part of the list 
owners.

Conferencing programs which require custom clients - and this list 
includes The Palace, Other Realms, Lotus Notes, FirstClass, and more 
- also require training. While much of the training may be 
accomplished by the software itself, nonetheless service providers 
will have to budget time to help people with installation and to find 
the help files. 

In the case of MUDs and IRC the training issue is even more 
significant. At the Painted Porch we designed a training session 
which we require all users to follow before they are allowed to log 
on to the MAUD as a whole. This is because while the set of commands 
required to effectively use the MAUD is relatively small and 
intuitive, people need practise and instruction before they are 
comfortable in this environment.

One of the significant weaknesses of MOOs, in my mind, is the 
obscurity of the command set. many commands in a MOO require the use 
of the @ character. This is not something people remember easily when 
they are working in an unfamiliar environment. IRC presents similar 
difficulties because commands need to be preceeded with a / character 
(more recent IRC clients allow users to use buttons instead, however, 
the training issue remains even with buttons).

-----------------------------------------------------------------------

Concluding Remarks

In my original presentation to the committee managing this seminar I 
stated that I would like to discuss two major areas:
   a) Options for on-line conferencing
   b) On-line conferencing system requirements
I hope I've accomplished these in the discussion above, though of 
course I must wait for your feedback and responses before I know. :)

I also stated that an objective of mine is to produce a conferencing 
FAQ which could be posted periodically to DEOS-L and e-conf. Here is 
where I need your help.

While I have listed a number of options above, my list is not 
exhaustive. So if you are familiar with software which I have not 
mentioned, please send me the name of the software and the URL where 
I can obtain relevant information. Any comments you may have about 
the software would also be appreciated.

In the FAQ, I intend to arrange the material much in the manner 
presented in this paper. It would be useful to know whether you think 
this is a good arrangement, or whether you feel some other form of 
categorization would be helpful.

Finally: I have not discussed some of the more advanced software (for 
example, the internet phone). I have limited my discussion to 
software which uses text and graphics only. Should these applications 
also be considered to be within the domain of on-line conferencing? 
If so, should interactive television be considered as well. Where, in 
other words, do we draw the line? Or should we at all.

Thank you for your time and patience in reading this. I look forward 
to your comments. This page is stored on the world wide web at
http://www.assiniboinec.mb.ca/user/downes/iuc96.htm and will be 
updated through the week according to the imput I receive from 
participants.

- Stephen



Stephen Downes Stephen Downes, Casselman, Canada
stephen@downes.ca

Copyright 2024
Last Updated: Oct 05, 2024 3:46 p.m.

Canadian Flag Creative Commons License.

Force:yes