🚀 go-pugleaf

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"

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

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

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.

In article <20995@crg5.UUCP> szabo@crg5.UUCP (Nick Szabo) writes:

> 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 think this captures the essence of why I disagree with Nick about the
role of "emotions" in the workplace.  Clearly, he's not worked in an
environment that's anything like those I've been in .  It's only a rare
minority of allegedly technical situations that don't have some person
who's got some personal/emotional stake in an outcome.

Those situations may not be pleasant, and it may piss the hell out of
me to need to deal with someone's fear of new ideas or their irrational
attachment to something that blocks progress in a direction I want to
move in ... but it's a lot better to know about those things and be able
to work with them than to not know about them and hence be unable to get
an acceptible outcome.  If our communication's been restricted to exclude
those important nuances, that might increase technical content, but
will (guaranteed!) reduce its overall effectiveness thereby.

I'd like to dedicate this new thread to discussions like how just because
people have chosen technical specialties says nothing about how truly
logical and rational they are ... or maybe about how it's critical to
design so-called "groupware" systems to facilitate real flesh-and-blood
people who are irrational and emotional and aren't about to change just
to make some bloody programmer happy!  (:-)

- Dave
One of the Million monkeys ... see, here's my keyboard!

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

In article <4015@eastapps.East.Sun.COM> db@east.sun.com (David Brownell) writes:

>... I disagree with Nick about the
>role of "emotions" in the workplace.  Clearly, he's not worked in an
>environment that's anything like those I've been in .  It's only a rare
>minority of allegedly technical situations that don't have some person
>who's got some personal/emotional stake in an outcome.

I don't think I have ever worked in a situation where people did *not*
have personal and emotional stakes in the outcome.  It simply does not
follow, however, that communicating those emotions will increase the
quality of the technical outcome.  Furthermore, if one did need to
communicate emotions, the bandwidth of computer and even video 
communications is several orders of magnitude below face-to-face contact 
and spoken language, and personal contact will be much preferable to 
emotional groupware in nearly all instances.


>Those situations may not be pleasant, and it may piss the hell out of
>me to need to deal with someone's fear of new ideas or their irrational
>attachment to something that blocks progress in a direction I want to
>move in ... but it's a lot better to know about those things and be able
>to work with them than to not know about them and hence be unable to get
>an acceptible outcome. 

This assumes two things:

* That your definition of "progress" is in fact the correct one and
  that all you need to do is emotionally convince your fellows that
  you are right.
* That people with the correct technical solution are more emotionally
  convincing than those with the incorrect solution.

I see no relation, unless it is negative, between the ability to 
emotionally persuade and the correctness of one's technical solutions.
If the communication sticks to the technical task, instead of spending
brain and communications bandwidth on emotional persuasion, the technical
outcome will likely be superior.


>If our communication's been restricted to exclude
>those important nuances, that might increase technical content, but
>will (guaranteed!) reduce its overall effectiveness thereby.

I reach quite the opposite conclusion.  The "nuances" soak up bandwidth.
They do not contribute to the communication of the technical information
or resolution of the technical problems.  If emotional nuances and 
deciphering of the nuances are excluded, the technical solution will
be superior.  


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

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  */

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

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

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