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