Path: utzoo!attcan!uunet!zaphod.mps.ohio-state.edu!uwm.edu!bionet!arisia!roo!lanning From: lanning@parc.xerox.com (Stan Lanning) Newsgroups: comp.groupware Subject: Re: why so little groupware? Message-ID: Date: 22 Oct 90 17:39:53 GMT References: <2997@jaytee.East.Sun.COM> Sender: news@parc.xerox.com Organization: Xerox PARC, Palo Alto, CA Lines: 63 In-reply-to: db@witzend.East.Sun.COM's message of 20 Oct 90 20:55:30 GMT The biggest lesson I learned while working on the Colab project is: Building groupware is really hard. Why? Here's an unordered grab-bag of for-instances: -- Face to face group dynamics is full of subtle interactions. Facial gestures, coughs, eye movements, interruptions, tone of voice, ... This is a _lot_ of bandwidth, and capturing & communicating this information via computer isn't something we know how to do. I think this is why there is such a growing focus on video -- give up trying to interpret actions, just capture them and make them available to the other participants. We can't compute fast enough to do anything else. -- A shared editor had better be really fast. Over a network. While providing lots of contextual cues. And dealing intelligently with conflicting requests. And multiple views. And multiple versions. These are just not things that we know how to do (yet). -- An occasional half second delay propagating a change through a shared editor may be enough to disrupt the communication flow in a meeting. -- Office automation tasks have, so far, focused on rather passive data structures that the user manipulates via explicit requests. There are few (if any -- of the top of my head I can't think of one) applications that deal with dynamic data. The "problem" is that users base their actions on their mental model of the data, not what the computer is telling them. That's OK when there is only one person manipulating the data, but it fails big when there are multiple entities changing the data. Even if the system is doing a great job at providing the user with all sorts of information, it doesn't help if the user isn't paying attention. After all, (s)he may be thinking about the issues being discussed instead. David> [...] building groupware requires collaboration between David> (at least) two technical communities with very different goals: David> * Software implementers understand the computer technology, and want David> to push technological systems. David> * Social scientists understand the dynamics of a variety of groups, David> and want to study them further. Here at PARC, "social scientists" and "software implementors" work side-by-side. We actually have the same goals: wanting to make the workplace better (more productive, healthier, happier, less stressful, more flexible, ...). Perhaps more importantly, we understand that we need each other. David> Another problem, with which I'm a little more familiar, is that implementors David> of software don't want to deal with messy issues of group dynamics. Personally, I enjoy the messy issues. And I'm an implementor. DISCLAIMER: The above is not necessarily the opinion of the author, or of anybody else. -- -- smL