260 likes | 381 Views
[ CSCW ] Computer Supported Cooperative Work. CS376 Reading Summary Bjoern Hartmann (bjoern@cs). Readings. Beyond Being There Jim Hollan and Scott Stornetta CHI 1992: ACM Conference on Human Factors in Computing Systems, pp. 119-25
E N D
[CSCW]Computer Supported Cooperative Work CS376 Reading Summary Bjoern Hartmann (bjoern@cs)
Readings • Beyond Being ThereJim Hollan and Scott StornettaCHI 1992: ACM Conference on Human Factors in Computing Systems, pp. 119-25 • Groupware and social dynamics: Eight challenges for developersJonathan GrudinCommunications of the ACM, January 1994, pp. 93-105 • Social, Individual & Technological Issues for Groupware Calendar SystemsLeysia PalenCHI 1999: ACM Conference on Human Factors in Computing Systems, pp. 17-24
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 totransmit synchronous audio+videoof realtime conversation. [gdc.com]
Hollan, Stornetta: BBT 2 • Problem: imitation can never get “close enough.” Any discrepancy is decisive. • 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) Social Presence-O-Meter …???… Written Audio Audio+Video Face2Face
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
Hollan, Stornetta: BBT 4 • Examples – Email and its derivatives: • Email: • Also used in physically proximate situations • Asynchronous • Archival • 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. [www.tc.gc.ca]
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
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.
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.
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.
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. Demotivated schedule maintainer [communicateinstitute.com]
Grudin: Challenge #2 • Critical Mass / Prisoner’s Dilemma • Problem: Groupware is only useful if most 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). [sundsvall.se]
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.
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. [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)
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.
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.
Grudin: Challenge #8 • Managing acceptance • Problem: Most CSCW software is shrink-wrapped – 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)
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.
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”
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.
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).
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 non-participants, organizational memory, non-meeting synchronization
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
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.