🚀 go-pugleaf

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