[comp.groupware] Audio & Video Needed for Group Support?

markabel@uswat.uswest.com (Mark Abel) (01/18/91)

This is a followup to a discussion between Nick Szabo, Mark Shepherd (& later
Alan Wexelblat).

Let me say first that I strongly support Mark Shepherd's position that
visual and auditory communication is a critical factor in interaction.
This is based on 6 years of research in Multi-media Groupware systems at
Xerox PARC and U S WEST Advanced Technologies. (Many other groups have
been exploring these issues as well - e.g., Bell Labs, Bellcore, NTT, NEC,
Olivetti, Xerox EuroPARC, etc., etc.).

Social scientists claim that two types of communication are taking place in
any interaction: 1. "information transfer," and 2. social or emotional
info.  For example, if two hackers are discussing the best way to code
something, they not only exchange information (e.g., details of how a
program works) but they also read each other and decide things like "Do
I believe this person?" "Do I trust their opinion?" "Do they like me and/or
believe me?" etc.  As Alan Wexelblat said, the visual channel carries most
of this socio-emotional information by allowing people to see gesture,
posture, facial expression, eye-contact info, etc.  Admittedly, some
socio-emotional information is carried via other channels (e.g., through tone
of voice, through "flames" in e-mail, etc.).  

Although one can coerce single channel interaction systems like e-mail into
providing socio-emotional information (e.g., smileys :) ), a richer
set of interaction media that includes two-way video, quality audio etc.
is almost certainly much better to convey this sort of information.  In
short, why limit ourselves, especially when full multi-media communications
solutions will be here in the 1990's?

	-Mark Abel
	 U S WEST Advanced Technologies

shackelf@tlab2.cs.unc.edu (Douglas Shackelford) (01/19/91)

In article <14533@uswat.UUCP> markabel@uswat.uswest.com (Mark Abel) writes:
Stuff deleted...

>
>Although one can coerce single channel interaction systems like e-mail into
>providing socio-emotional information (e.g., smileys :) ), a richer
>set of interaction media that includes two-way video, quality audio etc.
>is almost certainly much better to convey this sort of information.  In
>short, why limit ourselves, especially when full multi-media communications
>solutions will be here in the 1990's?
>

Something that has always been interesting to me is that the
smiley ( :) ) is in some sense a humor equalizer.  That is,
everyone does the smiley in about the same way.  It is hard to
misunderstand a smiley, whereas, more complicated facial and
speech behaviors can be easily misinterpreted.

In some ways this is related to compact disc technology.  By
digitizing the sound, we can eliminate the background noise.
I wonder if an advantage of the smiley is that it helps
to reduce the noise that is inherent in any human conversation.

--Doug Shackelford
shackelf@cs.unc.edu    "When I drink alone, I prefer to be by myself"

kevinc@cs.athabascau.ca (Kevin Crocker) (01/22/91)

szabo@crg5.UUCP (Nick Szabo) writes:

>In article <14533@uswat.UUCP> markabel@uswat.uswest.com (Mark Abel) writes:
>>This is a followup to a discussion between Nick Szabo, Mark Shepherd (& later
>>Alan Wexelblat).
>>Social scientists claim that two types of communication are taking place in
>>any interaction: 1. "information transfer," and 2. social or emotional
>>info. 

>This is a good distinction, and allows me to state my position 
>succinctly: category (2) is more harmful than helpful to technical 
>communications.  

>Allocating technical workgroup bandwidth for (2) will lead to a poorer 
>solution of that group's technical task.  The best evidence is scientific 
>journals, which can communicate so much technical information
>precisely because they are totally devoid of category (2) bandwidth.
>Similarly, source code control systems lack category (2) content and have 
>proved very useful in coordinating the work of software engineering teams.

Nick, I agree that for discussions of technical information the
reductions of side band noise, in this case emotion, is beneficial.
However, not all groupware discussions are technical in nature.  At
this university we use groupware on a very primitive level but little
of it is used for technical discussions.  My job is to design and
develop courseware in my chosen field (Financial Management) for
consumption by students.  I work closely with an editor, an
Istructional designer and a visual designer.  Our discussions generally
have little to do with the technical aspects of either the content (my
area), the instructional paradigm (the ID's area), or the visual
presentation (the Visual Designer's area).  We assume, perhaps in
error, that each of us are proficient in our field of study.  What we
use groupware for is to communicate ideas in a brainstorming session to
determine new ways to apply already known concepts in an attempt to
provide a learning experience that is more applicable to the learner.
In this sense, we attempt to provide learning materials in a format
that is suitable to the learners dominant learning mode with the
addition of some standard presentation formats.  In our courses we use
print, graphics, video, audio, TV, radio, computers and any other media
that we think would benefit the learner.  Not that we use every media
for every course but many of our courses are multimedia.  In order to
develop this type of material I need access to developmental resources
to make this available.  Therefore, having groupware capabilitites that
permit multimedia communication is very important to me and our group.
At the moment we are attempting to develop a multimedia workstation for
a proposed M.B.A. degree.

Kevin
-- 
Kevin "auric" Crocker Athabasca University 
UUCP: ...!{alberta,ncc}!atha!kevinc
Inet: kevinc@cs.AthabascaU.CA

szabo@crg5.UUCP (Nick Szabo) (01/22/91)

In article <616@aupair.cs.athabascau.ca> kevinc@cs.athabascau.ca (Kevin Crocker) writes:
[wants to try multimedia groupware to develop multimedia course]

Good example!  Given that the product contains sound or video, 
groupware that manipulates these media might be useful for the
product developers.

This is quite distinct from using sound and video to communicate emotions
between workgroup participants.  Where the product involves emotions
(eg advertisements), groupware that communicates emotions might be useful.

Where the end product does not contain either emotions or sound/video
-- the large majority of technical work -- groupware that communicates
emotions, and for the most part sound/video capability, is not useful.


-- 
Nick Szabo			szabo@sequent.com
Embrace Change...  Keep the Values...  Hold Dear the Laughter...

pease@amarna.gsfc.nasa.gov (Pease) (01/23/91)

I recall attending a short course at UCLA in the 60's and one of the presenters
had long hair and a beard.  At that time the long hair & beard hippie look had
not reached the east coast or the media.  Guess what, I didn't absorb much or
anything of what he had to say, all I could do was look at his weirdness.

At that same gathering I had my first view of mini-skirts by some "daring" UCLA
coeds, and do you think that helped in being able to study the material from the
course?  Wow, I'll never forget the experience.

Anyway, in some cases the emotional content of such scenes certainly do distract
from the purpose at hand.  But maybe the emotional content was just as important
as all that technical stuff, 8^).

I would also like to make the point that there are some people whose preferred
method of absorbing information are by sight and others by ear.  That is some
prefer to hear someone talk and others prefer to read the paper.  Those who
prefer to read take lots of notes when listening to a speaker compared to those
who prefer to hear what is said.  So, I think that for those that are "sound"
people they would not find this type of written stuff very satisfactory, while
those of us who are "sight" people can't see that audio is needed at all.

Now to change the subject -

About 10 years ago I took a graduate class in Small Group Processes (in the
Psychology department).  My theme paper was the use of computers in group 
processes.  At that time networking was just beginning, and some researchers
were investigating computer conferencing.  Thus I indicated that computers
would be used for recording individual's ideas, organizing them into inter-
related subjects, and then accessing the combined organized thought of the
group.  I also indicated that some statistical techniques could be used for
arriving at decisions based on an analysis of group members opinions (i.e.,
the "Delphi method").  I reported studies that showed that the Delphi method
produced better decisions than was obtained by having one "person in charge"
making the decision even after hearing or reading the same opinions that were
given by the group members.

In my paper I took a set of monographs entitled "Looking into Leadership" by
Dr. Warren H. Schmidt of UCLA Busisness School in which he identified 13
principles of group behavior.  I will present these principles below, but
omit my analysis of how the use of computers/networking would relate to them.
I will leave it to you to reflect on this.

1. Successful group productivity depends on the ability of the members to
exchange ideas freely and clearly and to feel involved in the decisions and the
processes of the group.

2. No group can be fully productive until its members are willing to assume
responsibility to the group.

3. An effective group has a clear understanding of its purposes and goals.

4. An effective group is flexible in selecting its procedures as it works
toward its goals.

5. An effective group has achieved a high degree of communication and 
understanding among its members.

6. An effective group is able to initiate and carry out effective decision
making, carefully considering minority viewpoints, and securing the committment
of all the members to important decisions.

7. An effective group achieves an appropriate balance between group productivity
and the satisfaction of individual needs.

8. An effective group provides a sharing of leadership responsibilities by group
members - so that all members are concerned about contributing ideas, 
elaborating and clarifying the ideas of others, giving opinions, testing the
feasibility of potential decisions, and in other ways helping the group to work
on its task and maintain itself as an effective working group.

9. An effective group has a high degree of cohesiveness (attractiveness to its
members) but not to the point of stifleing individual freedom.

10. An effective group makes intelligent use of the differing abilities and
interests of its members.

11. An effective group is not dominated by its leader or by any of its members.

12. An effective group can be objective about reviewing its own processes; it
can face its problems and adjust to needed modifications in its operation.

13. An effective group maintains balance between emotional and rational 
behavior, channeling emotionality into productive group effort.

In my conclusion, I noted that Managers tend to overlook the human aspect of
the group process all to often and superficially.  They focus mainly on
productivity, efficiency, costs, meeting deadlines, and quality of results; and
that for these reasons computers will be used in group process for the benefits
they will bring to these areas. 

The human aspects of group interaction will be diminished in the computerized
system.  However, there are some aspect which us humans would find desirable,
such as greater self direction, ease of contributing to the group product, more
flexibility in the times one works on the group tasks, and less travel or time
constraint in getting everyone together to interact;  but, for many of us there
is a joy which comes from the human interaction of sharing ideas over coffee
which would be sadly missed if all work were done over a computer network. 

Phil Pease 
My witty disclaimer - everything I perceive, through either sensory or
extrasensory means, has been filtered to such an extent that you had better not
attempt to attribute anything I say to anyone else.

lippin@oreo.berkeley.edu (The Apathist) (01/23/91)

Recently szabo@crg5.UUCP (Nick Szabo) wrote:

>Where the end product does not contain either emotions or sound/video
>-- the large majority of technical work -- groupware that communicates
>emotions, and for the most part sound/video capability, is not useful.

I design software which contains little emotion, sound, or video.
Nevertheless, when I'm considering new features or new ways of doing
things, I talk to people face-to-face, rather than by email.  I want
their emotional reaction to the changes, so that I can design a
product that will please people.

Wearing another hat, I'm a mathematician.  In this role, I attempt to
produce theorems and proofs.  I'm interested in my colleagues'
emotional reactions to these as well.  Why?  Because a good theorem
isn't just true -- there are scads of true theorems just lying about
-- it also has to be either interesting or useful.  Or both, for a
really good theorem.  If it's neither interesting nor useful, there's
no way it'll get published.

This brings me to a secondary product: communication.  I want the
papers and courses I put together to be clear and easy to follow.
Emotional feedback is essential in getting the presentation right.  I
greatly prefer one-on-one tutoring to classroom lecturing for this
reason.  Similarly, it's generally accepted that small classes are
more effective than large lectures.  And getting the reactions of a
test reader is a very good way to find the confusing spots in a paper.
(And a sense of confusion is *very* difficult to gauge through email.)

When considering needs like these for emotional communication in
technical fields, I'm hard pressed to find technical fields that
wouldn't benefit from working it better into their groupware.

					--Tom Lippincott
					  lippin@math.berkeley.edu

 "I enjoy working with humans, and have stimulating relationships with them."
					--HAL

kenn@intrbas.uucp (Kenneth G. Goutal) (01/24/91)

Heh heh...  You *think* smileys are hard to misinterpret!  But is this true?
I had unquestioningly assumed so until you brought it up.
Now I am not so sure.  It seems easy to believe that, 
by reducing the number of 'facial expressions' to a very small number, 
the writer will be able to 'assume an expression' that will be universally
understood.  I see at least two problems with this:
(1) What if there is no icon that accurately represents how I feel?
If this happens, then no matter which one I pick, it will be intrinsically
in error by some amount, right at the outset, no matter who interprets it.
(2) There really is no basis for believing that the emoticons are universally
understood.  Take the smiley -- ":-)".  (Ignore for the moment that I use the
"nasal dialect"!)  Suppose I say:
	This will cause the end of civilization!  :-)
Does this mean that I am happy that civilization will end?
Does it mean that I am happy that "This" will be cause thereof?
Does it mean I'm happy about some side effect (e.g. no more styrofoam cups)?
Does it mean that I'm just in a good mood, and perhaps I'm joking, but
I'm not a winking sort of person?
I'm afraid that this is not a very imaginitive example, 
and does not do justice to the sort of different slants
that readers can impose on emoticons depending on their own background,
their own mood, etc.

This is not to say that emoticons are not an improvement over natural
facial expressions and body language -- perhaps they are.
But I think that there is ample room for miscommunication in them,
and we should not fall into the trap of believing that the use thereof
will cause emotional miscommunication to disappear.

-- Kenn Goutal
...!linus!intrbas!kenn
...!uunet!intrbas!kenn

stewarte@sco.COM (Dr. Luther's Assistant) (01/25/91)

Even net.pundits were baffled when shackelf@tlab2.cs.unc.edu (Douglas Shackelford) wrote:

>Something that has always been interesting to me is that the
>smiley ( :) ) is in some sense a humor equalizer.  That is,
>everyone does the smiley in about the same way.  It is hard to
>misunderstand a smiley, whereas, more complicated facial and
>speech behaviors can be easily misinterpreted.

Yes, but this is precisely because the smiley contains less information --
and as a result of that, people have to shoehorn a variety of meanings
into that one symbol.  The distinctions between good-natured leg-pulling,
sarcasm, and poking fun at someone can't be made at all with the smiley,
wheras with those more complicated behaviors there is some hope that 
they will be correctly interpreted.  

In short, I think they're less likely to be misinterpreted because they
don't lend themselves to much interpretation at all.

-- Stewart
-- 
"The old stereotypes must be lost
 that peace and knowledge and love are soft."
			-- Blastmaster KRS-ONE
/*  uunet!sco!stewarte  -or-  stewarte@sco.COM  -or-  Stewart Evans  */

kevinc@cs.athabascau.ca (Kevin Crocker) (01/25/91)

szabo@crg5.UUCP (Nick Szabo) writes:

>In article <616@aupair.cs.athabascau.ca> kevinc@cs.athabascau.ca (Kevin Crocker) writes:
>[wants to try multimedia groupware to develop multimedia course]

>Good example!  Given that the product contains sound or video, 
>groupware that manipulates these media might be useful for the
>product developers.

>This is quite distinct from using sound and video to communicate emotions
>between workgroup participants.  Where the product involves emotions
>(eg advertisements), groupware that communicates emotions might be useful.
>Where the end product does not contain either emotions or sound/video
>-- the large majority of technical work -- groupware that communicates
>emotions, and for the most part sound/video capability, is not useful.

Sometimes it is difficult to separate the media from the message.
Especially in  this day and age of media management (sic!) that is
exercised by a wide variety of sources but most specially the media
experts like advertisers.  How much of TV advertising is devoted to a
single clear message and how much of it is devoted to manipulating the
emotive aspects of perception?  In attempting to develop materials in a
multimedia environment there are cues and informational content in all
aspects of both the message and the media container or channel(s).
Whether the information that exists within the message and channel is
relevant and useful is of course debateable -- what is not debateable,
at least to me, is the rather arbitrary decision to exise part of the
message or informational content.  As the receiver (decoder), I would 
prefer to exercise control (and perhaps build or develo filters) of the
informational content that I receive.  As a sender (encoder), I should
be cognizant of what I compose, how I compose it, and how I provide for
the enrichment of the receiver, as well as providing the capability for
receivers to filter the message as they see fit.

Now, when it comes to groupware, much communication takes place in side
bands whether it was intended or not.  For communication of pure
technical information where the focus is on encoding and decoding a
pure signal with 100% accuracy other side bands of communication will
introduce signal loss and dropout.  For other types of communication,
side band information may or may not be beneficial.

Kevin

-- 
Kevin "auric" Crocker Athabasca University 
UUCP: ...!{alberta,ncc}!atha!kevinc
Inet: kevinc@cs.AthabascaU.CA

kevinc@cs.athabascau.ca (Kevin Crocker) (01/25/91)

lippin@oreo.berkeley.edu (The Apathist) writes:

>more effective than large lectures.  And getting the reactions of a
>test reader is a very good way to find the confusing spots in a paper.
>(And a sense of confusion is *very* difficult to gauge through email.)

One way that I encourage the groupware concept is when I ask several
people to test or proof material that I have developed.  The way that
this is accomplished is to get these people together and get them to go
through the material while I am present.  This is not using computers
as a facilitator of the groupware process.  The
interactions that take place are both numerous and complex.  One thing
that I would like computer groupware to capture is this richness of
interaction and information.  At the present time I feel that the
computer environment needs to start at providing a method of
transmitting the various signal sources such as audio and video.  

Just some more $.25 worth.

Kevin
-- 
Kevin "auric" Crocker Athabasca University 
UUCP: ...!{alberta,ncc}!atha!kevinc
Inet: kevinc@cs.AthabascaU.CA

szabo@crg5.UUCP (Nick Szabo) (01/29/91)

In article <632@aupair.cs.athabascau.ca> kevinc@cs.athabascau.ca (Kevin Crocker) writes:
>
>...there are cues and informational content in all
>aspects of both the message and the media container or channel(s).
>Whether the information that exists within the message and channel is
>relevant and useful is of course debateable -- what is not debateable,
>at least to me, is the rather arbitrary decision to exise part of the
>message or informational content.

We are explicitly designing groupware.  We _must_ make decisions to
include or leave out certain media, and to use those media in certain
ways (whether by software constraint or usage convention).  Hopefully
these decisions are not "arbitrary", but they must be made.


>As the receiver (decoder), I would 
>prefer to exercise control (and perhaps build or develo filters) of the
>informational content that I receive.

That's a good idea.  Any groupware that allows the senders to force-feed
the receivers will not be something I want to receive.  The receiver wants
to be able to change channels, grep for favorite subjects, clip 'n save 
the good stuff, filter out noise, and do it at his/her convenience not
the sender's or other receivers'.


>As a sender (encoder), I should
>be cognizant of what I compose, how I compose it, and how I provide for
>the enrichment of the receiver, as well as providing the capability for
>receivers to filter the message as they see fit.

Hah!  Senders do not not want receivers to be able to filter anything.
They want the reciever to see everything, as originally intended: they 
don't want to be colorized, edited, quoted out of context, skipped over 
or worst of all put in "kill files".  

Sender vs. receiver is a major source of conflict in groupware.

>....


-- 
Nick Szabo			szabo@sequent.com
Embrace Change...  Keep the Values...  Hold Dear the Laughter...

kevinc@cs.athabascau.ca (Kevin Crocker) (02/01/91)

szabo@crg5.UUCP (Nick Szabo) writes:

Kevin>In article <632@aupair.cs.athabascau.ca> kevinc@cs.athabascau.ca (Kevin Crocker) writes:
Kevin>at least to me, is the rather arbitrary decision to exise part of the
Kevin>message or informational content.

Nick>We are explicitly designing groupware.  We _must_ make decisions to
Nick>include or leave out certain media, and to use those media in certain
Nick>ways (whether by software constraint or usage convention).  Hopefully
Nick>these decisions are not "arbitrary", but they must be made.

Nick, I wasn't trying to imply that these decisions were being made
without regard to the eventual users for that is what this discussion
is all about.  I agree that the design of systems and software require
the application of constraints.  What we need to remember is that often
important information is contained in channels that are not traditional
(reading and contextual mapping).  Sound does contain significant
information but even more information can be conveyed through the use
of visual representations (pictures/graphics/motion etc).  The old
truism that a picture is worth a thousand words is one that governs the
communication process for many people.  I will azlso admit that good
writing can convey a richness and depth that can never be conveyed
through a visual representation, just as an operetta can convey
information that can never be captured by a picture or description of
what happened.

When we design groupware I feel that we must not limit the ability of
the sender and receiver -- especially in this day and age where the
bandwidth that is becoming available is growing at an ever increasing
rate.  Groupware is about "groups" of ""people"" communicating.  We
should provide for as many different channels of communication as
possible.  we don't have to implement everything that is designed into
the system but it is much harder to retrofit a totally new channel of
information into something that it was not designed to handle than to
design for as much as possible and not implement until it is needed --
even given that what we designed will be hopelessly out of date by the
time we implement.

I'm going to step out on a limb here:  CAVEAT -- I am not a Microsoft
fanatic by any means, I use it because I have to!

DOS was not designed to handle graphics and sound etc.  It has taken
Microsoft almost 10 years to incorporate a primitive level of graphic
support into it.  Loading GRAFTBLE.EXE to be able to get on screen the
high order characters is incredibly poor.  DO WE WANT TO DESIGN
SOMETHING NOW THAT WILL TAKE TEN YEARS BEFORE IT CAN INCORPORATE EVEN
WHAT WE ALREADY KNOW ABOUT vis-a-vis communication????

Kevin>As a sender (encoder), I should
Kevin>be cognizant of what I compose, how I compose it, and how I provide for
Kevin>the enrichment of the receiver, as well as providing the capability for
Kevin>receivers to filter the message as they see fit.

Nick>Hah!  Senders do not not want receivers to be able to filter anything.
Nick>They want the reciever to see everything, as originally intended: they 
Nick>don't want to be colorized, edited, quoted out of context, skipped over 
Nick>or worst of all put in "kill files".  

Nick, I'm appalled at this type of attitude.  You're talking like a
technician that has never communicated with anything except a machine.
Communication occurs in many ways beyond electronic transfer of bit
streams.  We're not just talking about news/notes/conferences/etc, we
are talking about interaction in at least one-to-one, one-to-many, and
many-to-one relationships.  The mere fact that you indicated "kill"
files supports the ability of the receiver to filter messages as they
see fit.  The question remains -- should we build this kind of
capability into the groupware or not?

The ability to communicate intelligently connotes many things but at
the most basic level it connotes that we understand and are aware of
the level and degree of control we have over both the message and the
channel.  The intent of communication is twofold -- to provide for the
transfer of information and to allow both the sender and receiver the
ability to filter the information.

Kevin

-- 
Kevin "auric" Crocker Athabasca University 
UUCP: ...!{alberta,ncc}!atha!kevinc
Inet: kevinc@cs.AthabascaU.CA

drd@siia.mv.com (David Dick) (02/02/91)

In <633@aupair.cs.athabascau.ca> kevinc@cs.athabascau.ca (Kevin Crocker) writes:

..description of groupware "in person" elided..

> One thing
>that I would like computer groupware to capture is this richness of
>interaction and information.  At the present time I feel that the
>computer environment needs to start at providing a method of
>transmitting the various signal sources such as audio and video.  

I think the management of the interaction is more important, IMHO.

As humans in the real world we are +--------------------------------------
continuously bombarded by sensory  | As to the complexity of the world:
input--the world is a complicated  | I recently attended a conference
place.                             | on virtual reality and cyberspace,
                                   | and one of the speakers noted that,
Our great skill in navigating it   | in his experience, he appreciated
is that our perceptual systems do  | reality much more after spending
considerable filtering below the   | time in a virtual world.  It's 
level of consciousness.            | consistent, doesn't have video 
                                   | glitches, and there's always something
Analogously, I think groupware     | behind every door!
needs to give us a way to manage   +---------------------------------------
the complexity.  Why go to all
the expense and trouble just to
recreate the chaos and inefficiency
of most meetings?

David Dick
Software Innovations, Inc. [the Software Moving Company (sm)]

kevinc@cs.athabascau.ca (Kevin Crocker) (02/05/91)

kenn@intrbas.uucp (Kenneth G. Goutal) writes:

>I think (though I could be wrong) that what you benefit from in one-to-one
>face-to-face interaction vs e-mail is not *emotional* feedback, or even
>the presence of feedback, but *immediacy* of feedback.  In a typical

A very interesting and vital observation.  Here at Athabasca University
(we are almost entirely a distance education institution)
we have extensive experience with non-immediate communication with
groups and to date the groupware metaphor has largely been conducted
with paper/mail transfers.  What we have found is that there is a
significant amount of evidence (in our scenario) that indicates that
the most critical factor in the success (don't ask how we define this
one) of students is the immediacy of feedback.  Thus we have instituted
a hot-line telephone system, electronic mail access that guarantees
responses within 24 hours to supplement our regular telephone system.

We are now investigating the application of the groupware concept to
the instructional design as opposed to the instructional delivery of
university level education.  In this light we are experimenting with
computer aided communication through e-mail, file sharing, computer
conferencing, file transfer, etc.  Most of these experiments have
become defacto operations systems rather than experimental pilot
projects.  However, we would like to go much further into audio and
video transmission on the development side.  Thus the reason for my
interest in this dicussion. 

 We have just received a major project ($1.5 Million) to develop 
a Instructional design system.  WE are also about to invest heavily 
in a system wide document management system, although the emphasis 
will definately be broader than "document".

Groupware is a vital part of what we do here and we need to get a
handle on the technological alternatives.

Kevin
-- 
Kevin "auric" Crocker Athabasca University 
UUCP: ...!{alberta,ncc}!atha!kevinc
Inet: kevinc@cs.AthabascaU.CA