Transcript CSCW: Computer Supported Collaborative Work

[CSCW]
Computer Supported
Cooperative Work
CS376 Reading Summary
Bjoern Hartmann (bjoern@cs)
10/5/2004
Readings
• Beyond Being There
Jim Hollan and Scott Stornetta
CHI 1992: ACM Conference on Human Factors in Computing
Systems, pp. 119-25
• Groupware and social dynamics: Eight challenges
for developers
Jonathan Grudin
Communications of the ACM, January 1994, pp. 93-105
• Social, Individual & Technological Issues for
Groupware Calendar Systems
Leysia Palen
CHI 1999: ACM Conference on Human Factors in Computing
Systems, pp. 17-24
10/5/2004
Hollan, Stornetta: Beyond Being There
• Upshot: most of telecommunication research is headed
along a dead end street. Hollan & Stornetta present an
alternate route.
• The telecommunication problem: afford the richness and
variety of physically proximate interaction during distant
interaction. (focus on tele part)
• Ever since Strand [1898],
the standard goal has been to
transmit synchronous audio+video
of realtime conversation.
10/5/2004
[gdc.com]
Hollan, Stornetta: BBT 2
• Problem: imitation can never get “close enough.” Any
discrepancy is decisive.
Social Presence-O-Meter
Written
Audio Audio+Video
…???…
Face2Face
• Solution: Let’s forget about “being there” as the natural
and perfect state. Instead, let’s develop communication
tools that people prefer to use even if they could interact
face-to-face. (focus on the communication part)
10/5/2004
Hollan, Stornetta: BBT 3
• Conceptual framework:
– Communication needs are medium-independent.
– Media mediate. (duh)
– Mechanisms are medium-specific enablers of communication
needs.
• Physical proximity is just one medium, not the entire
model. New technologies should satisfy basic needs, not
re-implement mechanisms.
• Significant features of computer-mediated
communication not present in face-to-face interaction:
– Asynchronicity, anonymity, automatic archiving
10/5/2004
Hollan, Stornetta: BBT 4
•
Examples – Email and its derivatives:
– Email:
• Also used in physically proximate situations
• Asynchronous
• Archival
[www.tc.gc.ca]
– Ephemeral interest groups
• Informal, disposable, asynchronous discussion linked to (virtual)
seed objects.
• Sought to increase people’s sense of presence in a community.
• Today: Slashdot et al. – definitely informal, but not ephemeral
– Meeting Others
• Personal homepage + activity indicator
• Computing personals: automatic matchmaking
• Today: social networking sites - Friendster, Orkut, etc.
10/5/2004
Hollan, Stornetta: BBT 5
• Email derivatives cont’d:
– Anonymity
• Allows for discussion of issues associated with social stigma
• Today: Group hug , FreeNet
– Semisynchronous discussion
• Discussion threads that are batch-updated in regular intervals
• Avoids thread-hijacking, allows for greater range of opinions
• Today: daily digest mailing lists?
– Beyond face-to-face
• Ideas for rapid, synchronous feedback BUT with higher info
richness:
– Clarity/disambiguation
– Feedback beyond the head nod
– Easy archiving
10/5/2004
Hollan, Stornetta: BBT 6
– Anticipated criticism:
• Imitation is good – people are used to face-to-face
interaction.
H&S: Yes, but then we can never exceed what is
possible in the familiar situation. No progress.
• You are ignoring the cultural context of media use.
H&S: Culture is dynamic, will adapt.
• Only face-to-face has intersubjectivity (I know that
you know that I know what you are talking about).
H&S: Intersubjectivity is possible in any medium in
principle. Managing it may be advantageous.
10/5/2004
Grudin: Groupware and Social
Dynamics – Eight Challenges
• Upshot: Groupware is situated in between applications
aimed at individual users and mainframe systems
targeting entire organizations. Because of its peculiar
spot, groupware boasts an impressively high failure rate.
Eight design and evaluation challenges are discussed.
10/5/2004
Grudin: Eight Challenges
• What is groupware?
– Defining feature: software designed/used to support
groups -> social factors become an issue.
– Around since mid-1980s when standalone personal
computers connected to network architectures
became pervasive.
– Examples: desktop and video conferencing, bulletin
boards, coauthoring, calendar scheduling, email.
– Market mostly driven by shrink-wrapped sales –
isolated development typical of off-the-shelf products
is behind many of the challenges encountered. In
contrast, IS software is designed and deployed
individually with management support.
10/5/2004
Grudin: Challenge #1
• Work vs. Benefit disparity:
– Problem: Costs and benefits from using groupware
are often distributed unevenly. Principal beneficiaries
are often the purchase decision makers/management;
but others have to carry out bulk of work without clear
motivation.
– Examples: meeting scheduling, voice annotation.
– Solution: create benefits for all group members during
design stage.
10/5/2004
Demotivated schedule maintainer
[communicateinstitute.com]
Grudin: Challenge #2
• Critical Mass / Prisoner’s Dilemma
– Problem: Groupware is only useful if most
[sundsvall.se]
group member utilize it – more stringent
requirement than for individual software. If
individuals prefer lurking/freeloading,
groupware the app will ultimately fail.
– Solution: Build in use incentives, emphasize
individual/group benefites (vague).
10/5/2004
Grudin: Challenge #3
• Disruption of social processes:
– Problem: Groupware has to fit into implicit
framework of social group interaction. Not all
processes can be represented explicitly
without violating taboos.
– Example: meeting scheduling
– Solution: Don’t assume a completely rational
work environment. Understand the subtleties
of the target environment. Work with
representative users.
10/5/2004
Grudin: Challenge #4
• Exception handling:
– Problem: Groupware has to adapt to/enable
ad hoc problem solving and improvisation;
post hoc rule-based systems are too rigid and
brittle. In Reality, decoupling of rules and
actual work patterns is pervasive - allows for
flexibility and localized judgment
– Examples: the chocolate factory
– Solution: Learn how work is really done.
10/5/2004
[spiralandcircle.com]
Grudin: Challenge #5
• Infrequently used features
– Problem: “To a hammer, everything looks like
a nail”: group communication may be
infrequent.
– Solution:
• Integrate group features w/ individual activity
• Design should be unobtrusive yet accessible
• Add groupware features to already existing
applications (e.g., MS Office)
10/5/2004
Grudin: Challenge #6
• Difficulty of evaluation:
– Problem: Group context introduces social,
motivational, economic, political dynamics
that are hard to measure. Lab situations and
prototypes are ineffective. Because of a lack
of definitive studies, the same mistakes are
repeated over and over again.
– Solution: Grudin doesn’t know.
10/5/2004
Grudin: Challenge #7
• Breakdown of intuitive decision making
– Problem: Developers cannot rely on their own
individual informed intuition when group
processes are concerned. Nor can any other
resource inside the development environment
help out. Too many applications target
managers, neglecting to accommodate other
users – resistance results.
– Solution: Involve real users early on in the
design process.
10/5/2004
Grudin: Challenge #8
• Managing acceptance
– Problem: Most CSCW software is shrinkwrapped – developers are removed from
system acceptance issues – needs to be
overcome.
– Solution: Learn form IS; cooperate with
marketers; package software w/ consulting
services (Lotus Notes)
10/5/2004
Grudin: Wrap-up
• Evaluation of email w.r.t. 8 challenges is left as an
exercise to the reader.
• Take home messages from the paper:
Groupware should :
– Directly benefit all users.
– Augment existing applications if possible.
• Developers must:
– Truly understand the working environment where the software
will be used.
– Interact directly with the users in an iterative process.
– Question their own decision making processes during the design
stage.
• Dear Mr. Grudin: Concision is a virtue.
10/5/2004
Palen: Issues for Groupware Calendar
Systems
• Upshot: A synthesis of three design and evaluation
perspectives is needed for groupware (in this case GCS)
to be successful: technological, individual, and social.
• Ethnographic study of GCS use at Sun Microsystems
(software “CM”)
– Interviews, in-office observation, video recording, photographs of
work environments, printouts of calendars, survey
• Remember critique from last paper: meeting scheduling
is the “least useful groupware app”
10/5/2004
Palen: GCS 2
• How single-perspective design and
deployment fails:
– Exclusively technology-centric development is
cheap but often ignores reality.
– ‘Traditional’ HCI takes software into account,
but focuses only on the individual.
– CSCW looks at work practice and social
structures, but needs the previous two levels
to build upon.
10/5/2004
Palen: GCS 3
10/5/2004
Palen: GCS 4
• Single User Calendar Demands (arrow 1)
– Software has to support all of the flexible uses of a
physical calendar – otherwise competition with other
calendars will result.
•
•
•
•
•
•
Temporal orientation
Scheduling
Tracking (contacts, expense reports)
Reminding
Note recording/archiving
Retrieval & recall
– For successful adoption, calendar maintenance has
to be simple and attractive (cf. Grudin’s challenge #1).
10/5/2004
Palen: GCS 5
• Interpersonal Communication (arrow 2)
– Personal and social use may conflict.
– Managing privacy / protection from peer judgment is
mainly left to user through adopting usage strategies
like cryptic entry, omission, defensive scheduling
(cf. Grudin’s challenge #3 – disruption of social
processes)
– Peer pressure results in homogenous usage patterns
within groups
– Open calendars enable more than meeting
scheduling: locating people, mtg. room info for nonparticipants, organizational memory, non-meeting
synchronization
10/5/2004
Palen: GCS 6
• Socio-technical evolution (arrow 3)
– Reciprocal interaction between organizational
structures and technology – possible at Sun
since development was internal. What about
off-the-shelf products?
– Default settings are rarely changed: passivity
and institutionalization
10/5/2004
Palen: GCS 7
• Interaction between the three levels:
– Final section describes how in Sun’s specific
case technological features, personal usage
patterns, peer pressure and institutionalization
intermesh to shape how CM is used.
– Particular setting matters; we can generalize
that these interactions happen, but not what
they will be in any particular case.
10/5/2004