Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!helios!bcm!dimacs.rutgers.edu!seismo!uunet!zaphod.mps.ohio-state.edu!unix.cis.pitt.edu!dsinc!bagate!cbmvax!atha!aupair.cs.athabascau.ca!kevinc
From: kevinc@cs.athabascau.ca (Kevin Crocker)
Newsgroups: comp.groupware
Subject: Re: Audio & Video Needed for Group Support?
Message-ID: <641@aupair.cs.athabascau.ca>
Date: 31 Jan 91 17:49:18 GMT
References: <14533@uswat.UUCP> <20965@crg5.UUCP> <616@aupair.cs.athabascau.ca> <20995@crg5.UUCP> <632@aupair.cs.athabascau.ca> <21041@crg5.UUCP>
Organization: Athabasca University
Lines: 81

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