db@witzend.East.Sun.COM (David Brownell) (10/21/90)
I'm curious why, with the good platform technology we have today, there's
so little software that could comfortably be called "groupware". Let me
define my terms a little, and give what seems to me to be a partial
answer ... I'll really like to know if my impressions are shared, and
what I'm missing!
First, what's groupware?
(I meant to post this one a long time ago. Ever since this group began
everone just _assumed_ there was a common definition! So here's one version
of a definition; I expect there are changes to come, I have my asbestos on!)
I pretty much agree with Esther Dyson's comments at CSCW'90 that the word
reflects more of an underlying commonality of approaches than specific tools.
In my mind, those approaches include:
- Directly supporting groups _as well as_ individuals within them.
- Being an environmental feature, not a primary application. (That
relates to the above point: individuals can use it to advantage,
then there's benefit when more of them use it.)
- Supporting a variety of group work styles and policies, rather than
being restricted to particular styles such as strong central control.
- Taking advantage of networked, or at least multi-user, environments
to provide knowledge of the other group members.
- Letting groups define themselves through shared history, storage,
messaging, and task definitions external to computer systems.
By this definition a lot of computer applications (as in, the problem the
software solves) are groupware: multiuser tools built with a database like
Sybase or Ingres, system and network administration done with a variety of
operating systems, USENET and EMAIL, the mission-critical apps built by many
businesses, and so on. These are rarely "neat" problems, or static ones.
The focus of "groupware" is applications, and on the sociological aspects of
people sharing computer usage. Groupware is systems that include many people
as well as at least one computer; it's not just whizzy GUI tools.
Second, why so little groupware?
On one hand, there's a lot of it ... mainframes run multiuser applications,
some of the provided by third parties that need to support a variety of
customer usage policies. That extends to departmental computers and so
on; what most of those don't have in common is running on the UNIX hosts
or networks that so many of us work with. MIS groups traditionally had to
find out a lot about how their organizations worked, and improve them by
using computer technology that only recently could have all those "open
systems" benefits.
So why doesn't the current technical community (no longer trained exclusively
in IBM shops) produce such applications? The best reason I have been able
to come up with is that building groupware requires collaboration between
(at least) two technical communities with very different goals:
* Software implementers understand the computer technology, and want
to push technological systems.
* Social scientists understand the dynamics of a variety of groups,
and want to study them further.
One disconnect here is that I rarely hear of applied social sciences (can
someone educate me?) that might use computer technology as a tool to affect
the operation of groups ... while I often hear studies about how technology
is used by groups, experiments on any scale are uncommon (or not presented
as such -- they're called "managerial mistakes" :-).
Another problem, with which I'm a little more familiar, is that implementors
of software don't want to deal with messy issues of group dynamics. There
are tendancies both to oversimplify (claiming all user groups will work like
the development/testing group does, so only one control policy is needed) and
to add complexity because it's technically simple.
Maybe the simplest explanation is that it just takes time for lots of group
applications to be made available, and it won't happen just because there
are all these likely looking platforms around.
- Davelanning@parc.xerox.com (Stan Lanning) (10/23/90)
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
p+t@awaken.UUCP (Peter+Trudy Johnson-Lenz) (10/23/90)
Like David, we believe the lack of groupware is due in large part to the
difficulty of collaboration between software and social scientists with
different methodologies and purposes. Ultimately, however, these differences
are a rich and vital source of creative, interdisciplinary potential. As
wearers of both software and social science hats, we finding working with
both most fruitful.
We were drawn to this medium over a decade ago by the potential for
supporting group dynamics that we saw in Murray Turoff's tailorable EIES
(Electronic Information Exchange System) at the New Jersey Institute of
Technology. Through our experience there we began to realize that tailoring
systems to fit group needs is a messy and labor-intensive process, much like
managing and facilitating a face-to-face group.
Like David's point that groupware is many people and at least one computer,
we increasingly understood Doug Engelbart's assertion that this was a
co-evolving human and tool system. Our original 1978 definition of
groupware included both -- "intentional group processes plus software to
support them."
During the past three years, using our own tailorable system, we've
experimented a great deal with the messiness, or what might also be called
the inherent "fuzziness" of group interaction via computer. In this
process, we discovered an array of six "groupware primitives" (context,
timing, rhythms, boundaries, containers, mechanisms) that satisfy
both our social science interest in group process and our computer science
interest in computable, orthogonal primitives. In doing so, we realized
these primitives bridge the polarity between two prevailing
approaches to groupware: 1) groupware as mechanism that *makes* groups work,
and 2) groupware as context that *allows* self-organization to emerge.
This array of six primitives gives us tools to dynamically tailor a variety of
changing forms appropriate to a group at each stage in its evolution towards
a self-organizing learning team. They are implemented through scripted
situated agents and a variety of arrangements of the "virtual furniture"
(communication structures). Our tools are still crude and rudimentary, but
they allow us to work with the messiness more effectively than ever before.
We detail this work in our Research Report #4, "Rhythms, Boundaries, and
Containers: Creative Dynamics of Asynchronous Group Life," available from
us for $10. An abridged version will be published in the forthcoming
INTERNATIONAL JOURNAL OF MAN MACHINE STUDIES special issue on CSCW/groupware
under the title "Post-Mechanistic Groupware Primitives."
We are beginning to explore ways of distributing these groupware primitives
to workstations/PCs. They are currently implemented on our server/host
system only in order to support a wide variety of PCs connecting over a
wide-area network using a variety of telecommunications software. We are
looking for a development environment that will run on Macintoshes, DOS, and
OS/2 that includes a uniform GUI and telecommunications tools. Smalltalk V
is the best we have found so far, but it is weak on telecommunications. Any
suggestions?
Alas, while we don't have any commercial groupware to sell, we are
encouraged by the baby steps we've taken into this interdisciplinary
frontier and welcome collegial dialogue.
We expect it will take us all (at least) a few more years before any of us
*really* get the hang of groupware anyway (grin).
--------------------------------------------------------------------------------
Peter+Trudy Johnson-Lenz, Awakening Technology, 695 Fifth, Lake Oswego, OR 97034
(503) 635-2615 (voice); uucp: tektronix!pdxgate!awaken!p+t
>>> creating groupware for a vital, sustainable culture in hyperspace <<<andyo@glasperl.masscomp (Andy Oram) (10/23/90)
Not to draw attention away from the good research in technical and ergnomic
areas, but...Don't forget that individuals and organizations RESIST sharing.
On rational grounds, too. I posted something on this a few months ago, and
will repost if there's interest.
-------------------------------------------------------------------------------
Andrew Oram Concurrent Computer Corporation
(I don't represent Concurrent; this message represents my own opinion)
Digital Communications Route: andyo@westford.ccur.com
{harvard,uunet,petsd}!masscomp!andyo
Analog Communications Route: (508) 392-2865
Automatic UN*X documentation utility:
cref | compress | crypt | man
-------------------------------------------------------------------------------p+t@awaken.UUCP (Peter+Trudy Johnson-Lenz) (10/24/90)
Stan> The biggest lesson I learned while working on the Colab project is: > > Building groupware is really hard. It's interesting that this generality applies regardless of the type of groupware. Ours is asynchronous narrow-band text, Stan's Colab is synchronous wide-band multi-media. The problems are often different, but the challenge of using the technology to support the complexities of human interaction is the same.
ittai@shemesh.GBA.NYU.EDU (Ittai Hershman) (10/24/90)
> > Building groupware is really hard. > > It's interesting that this generality applies regardless of the type of > groupware. Ours is asynchronous narrow-band text... Not to be flippant, but I think that the correct abstraction is: Building good software (which takes the end-user into account) is really hard. The parentheses are there because that clause is really one of the primary components of "good", but not everyone agrees. I think that we are more sensitive to interface issues, when the software is a communications medium between/among other people. When a computational program is run, interface is relative to other programs which do similiar things -- we tend to curse while climbing the learning curve, and then we grow used to using the tool. When the software become a medium for human communications (we'll leave collaboration out for now), we compare it to the media with which we are familiar. We are less tolerant of the tool getting in the way. But it's not because it is inherently more difficult, it's because our expectations are higher. -Ittai
mfidelma@bbn.com (Miles R. Fidelman) (10/24/90)
There is also the question of what we consider to be groupware. To my mind, airline reservation systems, order entry systems, and the like are groupware. Since these beasts typically have awful user interfaces, but are used widely, I'm not sure the user interface problems are really the issue. Rather, a major issue is whether the cost of the learning curve is worth the organizational benefits of a groupware system. Miles Fidelman