Synchronous Collaboration and Awareness Systems

1. Synchronous Collaboration and Awareness Systems Bo Begole Ubiquitous Computing Area Manager Computer Science Lab UC Berkeley, Sep 25, 2006

2. Synchronous Collaboration and Awareness Systems • Degrees of Interdependence • Replicated Application Sharing: Flexible JAMM • Multi-user UNIX terminal: SharedShell • Awareness: • ConNexus • Awarenex • Presence and Availability Forecasting: • Rhythm Awareness • Lilsys

3. Why CSCW Research is Important • Inter-Personal Computing • Most of what we do with computers is communicated to others • Documents • Information Analysis • Even calculating Ballistic Missile trajectories are a form of communication (“I hate you”) • CSCW combines systems and social research

4. Grudin’s Time/Space Model

5. Task Criticality Time Spent Degrees of Interdependence Weakly Interdependent work Moderately Interdependent work Highly interactive Interdependent work Two Examples Research Funding: Technology Development: Proposal Module-level programming Reviews System design & prgrmng Negotiation System integration & debugging Paper Memos Communication Tools Full-duplex audio Usenet SMS IM Text chat email Web pages Push-to-talk audio Face-to-face meeting Blogs Asynch Semi,Peri,Psuedo-synch Synchronous Editors Shared File Systems Wikis Distributed Presentation Multiplayer Games Productivity Tools Shared Apps Browsers & other Viewers Decision Support Systems Meeting Support Systems

6. Collaboration Transparency • Sharing single-user legacy applications • Application source code is not modified • Runtime environment is modified • sharing mechanism is “transparent” to application. • Synchronous “Application sharing” for • Pair programming • Debugging/integration • Collaborative document editing • Examples: • NetMeeting, WebEx, GoToMyPC, SharedX, SharedApp, XTV, SunForum, Timbuktu, etc.

7. What You See Is What I See • Collaboration is grounded in shared view • Are there downsides to WYSIWIS? • Collaboration is grounded in shared view, but • prevents independent work

8. Maintaining Awareness: What You See Is What I Think You See

9. User A Host User B Host User Input User Input Display Display Network Traffic Conference Agent Merged Input Display Broadcaster Conference Agent Host Application Conventional Collaboration Transparency Architecture Does this model human collaboration? • Centralized architecture • One copy of application • Remote inputs merged • Graphics output sent to each remote participant • Used by all collaboration-transparent systems

10. Concurrency Control • Input events can interleave and conflict • Solution: take turns using “floor control” • How well does turn-taking model human collaboration? (a) intended result of two users drawing curves simultaneously (b) unintended result due to conflicting mouse movement events

11. Limitations of Collaboration-Transparency Systems • Strict What You See Is What I See • Slower application responsiveness • No concurrent work • Limited group awareness information • Higher network bandwidth requirement than collaboration-aware applications

12. Collaboration-Aware Applications • Applications designed for collaborative use • Examples: • Editors – SASSE, Calliope, SubEthaEdit, Writely • Whiteboards – innumerable • Chat – ICQ, AIM • Visualization – CAPI, Shastra, Sieve • Work flow – TeamRooms, Groove • Learning – LiNC, CoVis • Games – Diablo, Doom, WorldOfWarcraft, There • Toolkits – Habanero, Tango, GroupKit

13. Shared editors Collaboration-Aware Applications Shared whiteboards SubEthaEdit

14. Telepointers to represent remote mouse cursors “radar” views to indicate remote scroll positions Workspace Awareness • Information about participants: • identity • location • activity • access

15. User A Host User B Host Appli- cation Appli- cation User Input User Input Display Display Network Traffic Conference Agent Merged Input Event Broadcaster Conference Agent Host Replicated Architecture • Copy on each host • Remote inputs merged • Inputs distributed • Enables: • Lower network bandwidth • Independent views • Concurrent work

16. Can We Achieve Spontaneous Collaboration? • Co-workers “encounter” each other • Accessing shared content, docs, code, etc. • Within shared events, web sites, meetings, etc. • Applications morph into collaborative versions on-the-fly • Research prototypes • Flexible JAMM [Begole et al. 99] • Zipper [IBM] • Co-Word/Co-PowerPoint [Griffith U.]

17. Flexible JAMM: Replication + Object Replacement

18. (a) Original application (b) Shared application Applet Applet ScrollPane Panel Multi-user ScrollPane Panel Button Button Button Button object reference Button Button Radar View Single- to Multi-user Object Replacement

19. Replacement Process Initiating Host New-comer Host • Java Object Serialization • Table of replaceable classes and equivalents • JScrollPane => JRadarPane • PlainDocument => SharedDocument • also Image, FontMetrics, etc. • Multi-user replacement class must • be subclass of single-user original • have constructor that takes single-user object and initializes to same state Replacement Filter

20. “Thanks to your, ...” insert(7, “to ”) delete(10, 1) “Thanks you, ...” Concurrent Editing using Operational Transformation “Thanks your, ...” “Thanks to you, ...” “Thanks to ou, ...” 0 delete(10, 1) delete(13, 1) Goal: “Thanks to you, ...” insert(7, “to ”) 1 “Thanks your, ...” “Thanks to you, ...”

21. What About System Resources? • E.g., File, system time, network sockets? • “Externalities” cannot be replicated completely • Some services are unique per host: e.g., time, hostname, etc. • Different file systems, paths, etc. • Replicating files is partial solution, but • Paid network services may limit to one connection • Redundant output • Don’t want to send multiple email

22. Master Copy FIS Proxy Joiner Copy DIS Flexible JAMM’s Proxied System Resources Original Applet DIS FIS FIS Proxy FIS Server FIS DIS RMI Does this still qualify as a “replicated” architecture?

23. Does it Work? Could it Introduce Problems? • Flexible JAMM versus NetMeeting • Two tasks • Loosely-coupled collaboration - Text Entry • Two authors simultaneously enter text • Tightly-coupled collaboration - Copy Edit • “Editor” leads “author” to correct errors in existing text • 8 pairs, with 35 wpm typing proficiency

24. Performance Time • Text Entry: less time using JAMM than NetMeeting • 223.75 sec vs. 353.50 (p<.001) • Copy Edit: no difference • (p = 0.7905)

25. User Perceptions - Text Entry Q1: satisfaction with the software Q2: ability to work simultaneously Q3: ease of controlling the shared application Q4: ease of indicating text locations Q5: ease of simultaneous editing Q6: ability to have independent views Q7: ease of knowing partner's view

26. User Perceptions - Copy Edit Q1: satisfaction with the software Q2: ability to work simultaneously Q3: ease of controlling the shared application Q4: ease of indicating text locations Q5: ease of simultaneous editing Q6: ability to have independent views Q7: ease of knowing partner's view

27. Evaluation - other results • No difference in accuracy • JAMM preferred for Text Entry • Neither preferred for Copy Edit • JAMM preferred overall • NetMeeting floor control mechanism is difficult for people to use

28. Designed for Sun Customer Care Center Support Engineers “can’t see through the telephone” SE and Customer have knowledge to jointly solve the problem SE teaches customer how to solve the problem, reducing future support calls Sun SharedShell

29. SharedShell Video • Yankelovich, N., “Bo” Begole, J., and Tang, J. C. 2000. Sun SharedShell tool. In Proceedings of the 2000 ACM Conference on Computer Supported Cooperative Work (Philadelphia, Pennsylvania, United States). CSCW '00. ACM Press, New York, NY, 351. DOI= http://doi.acm.org/10.1145/358916.361981

30. athena% zlocate username athena% zwrite username # isthere <userid> # campon <userid> # talk <userid> Zephyr, ‘87 UNIX, ‘80s Portholes, ‘92 Peepholes, ‘96 Montage, ‘94 Awarenex, ‘01 [Saddler & Hill, Apple, ‘97] AIM, ‘97 ICQ, ‘96 Intellisync, ‘05 Hubbub, ‘02 WatchMe, ‘03 Awareness through the ages More to come?

31. Awarenex • Awareness • Finding a good time to make contact • Non-disruptive approach and leave-taking mechanisms • Integrated communication • Making contact easy • Ubiquity • Multiple clients • Shows location Awarenessnexus

32. Presence & Awarenss Service Collect, aggregate and propagate data “Presence” = can be reached • No info when recipient is not present • Presence ≠ Availability

33. Buddy list is nearly useless when someone is not Present • Inactive duration • Longer implies more likely not present, but • Could be reading, talking, etc. • Don’t really care how long inactive, what I want to know is when/where/how can I reach them in the future?

34. Rhythms in Group Coordination • Temporal patterns of behavior: Rhythms • Start/end of day, commutes, lunch, regular breaks, recurring events, typical durations, … • Zerubavel [1981] found that workers in a medical operations can infer the time of day from surrounding activities • Rhythms used to plan communications • “How long will Jane be away?” • “Where might she be next?” • “When will she be in her office for 15 minutes?” • “What time does she leave for the day?” • “When will she read my email?” • “When should I worry if there’s no response?” • Difficult for distributed groups to form E. Zerubavel, Hidden Rhythms: Schedules and Calendars in Social Life, Chicago: The University of ChicagoPress, 1981.

35. Time of Day Date Computer Activity Computer Activity over 6 weeks

37. Day of Week Key Factors Affecting Rhythms Location Home Office Home Office

38. Predictability varies between individuals Mean and std dev of minutes active in 15 min window programmer manager

39. 80% 60% 40% 20% 0% Human-observable patterns in Presence History Probability of computer activity in office during Mondays Mondays – Office Start of day Lower presence probability Lower presence probability End of day Lunch

40. Modeling Approaches Decision Tree Bayesian Network [Horvitz, et al. 2002] Difficult for end-users (and developers!) to interpret Temporal periodicity and patterns are not apparent to users

41. Goal: Descriptive model of temporal patterns to augment user’s mental model of rhythms • Identify and describe “Transitions” • Significant changes in probability of presence • Start, end of day, commute, recurring inactive periods • When, how long, how frequent • Types of transition • Recurring transitions between locations • Start- and end-of-day transitions • Recurring mid-day transitions • EM approach to find mid-day transitions 1. Estimate possible transitions 2. Expectation Maximization 2.a Cluster instances using transition estimates 2.b Refine estimates and iterate until converge

42. Step 1: Estimate Transition Periods • Determine threshold levels • Upper and lower thresholds to filter noise • Threshold crossing: potential transition • Initial estimate of transition properties Initial upper and lower thresholds determined heuristically Mondays – Office Transition Transition Transition

43. Step 2: Cluster observed inactivity periods by distance from estimated periods • Euclidean distance • An observed inactive period is a member of cluster when distance < 3 • An inactive period may differ by 2 stddev in two properties, but not all three Estimated Transition time end start Observed Inactive Periods Not in the transition’s cluster

44. Mondays – Office Mgr Example Rhythm Model Transition frequency and probability distributions of start, duration and end times

45. Example with Location Transition Starts work from home very early Monday mornings, then commutes to office Mondays – All Locations Commute time: 45 – 80 mins

46. A. B. C. D. E. End-user Visualizations – Which are Easier to Interpret?

47. Integrating Rhythms and IM

48. John office (10m) Lunch (66%) Probability that Inactivity is a Transition Suppose:

49. John office (20m) Lunch (80%) Probability that Inactivity is a Transition Suppose:

50. Outline • Presence and Non-Presence • Rhythm Awareness • Modeling • Applications • Availability and Unavailability • Lilsys • Technical details • User reactions • Future Directions