synchronous collaboration and awareness systems n.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
Synchronous Collaboration and Awareness Systems PowerPoint Presentation
Download Presentation
Synchronous Collaboration and Awareness Systems

Loading in 2 Seconds...

play fullscreen
1 / 63

Synchronous Collaboration and Awareness Systems - PowerPoint PPT Presentation


  • 102 Views
  • Uploaded on

Synchronous Collaboration and Awareness Systems. Bo Begole Ubiquitous Computing Area Manager Computer Science Lab. UC Berkeley, Sep 25, 2006. Synchronous Collaboration and Awareness Systems. Degrees of Interdependence Replicated Application Sharing: Flexible JAMM

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Synchronous Collaboration and Awareness Systems' - yetty


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
synchronous collaboration and awareness systems

Synchronous Collaboration and Awareness Systems

Bo Begole

Ubiquitous Computing Area Manager

Computer Science Lab

UC Berkeley, Sep 25, 2006

synchronous collaboration and awareness systems1
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
why cscw research is important
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
degrees of interdependence

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

collaboration transparency
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.
what you see is what i see
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
conventional collaboration transparency architecture

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
concurrency control
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

limitations of collaboration transparency systems
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
collaboration aware applications
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
workspace awareness

Telepointers to represent remote mouse cursors

“radar” views to indicate remote scroll positions

Workspace Awareness
  • Information about participants:
    • identity
    • location
    • activity
    • access
replicated architecture

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
can we achieve spontaneous collaboration
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.]
single to multi user object replacement

(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
replacement process
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

concurrent editing using operational transformation

“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, ...”

what about system resources
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
flexible jamm s proxied system resources

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?

does it work could it introduce problems
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
performance time
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)
user perceptions text entry
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

user perceptions copy edit
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

evaluation other results
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
sun sharedshell
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
sharedshell video
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
awareness through the ages

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?

awarenex
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

presence can be reached

Presence & Awarenss Service

Collect, aggregate and

propagate data

“Presence” = can be reached
  • No info when recipient is not present
  • Presence ≠ Availability
buddy list is nearly useless when someone is not present
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?
rhythms in group coordination
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.

slide35

Time of Day

Date

Computer

Activity

Computer Activity over 6 weeks

key factors affecting rhythms

Day of Week

Key Factors Affecting Rhythms

Location

Home

Office

Home

Office

predictability varies between individuals
Predictability varies between individuals

Mean and std dev of minutes active in 15 min window

programmer

manager

human observable patterns in presence history

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

modeling approaches
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

goal descriptive model of temporal patterns to augment user s mental model of rhythms
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

step 1 estimate transition periods
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

step 2 cluster observed inactivity periods by distance from estimated periods
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

example rhythm model

Mondays – Office

Mgr

Example Rhythm Model

Transition frequency and probability distributions of start, duration and end times

example with location transition
Example with Location Transition

Starts work from home very early Monday mornings, then commutes to office

Mondays – All Locations

Commute time: 45 – 80 mins

outline
Outline
  • Presence and Non-Presence
  • Rhythm Awareness
    • Modeling
    • Applications
  • Availability and Unavailability
  • Lilsys
    • Technical details
    • User reactions
  • Future Directions
presence availability
Presence ≠ Availability
  • Interruptions are necessary
    • and welcome when related to current task [Sproull ’84, J. Hudson, et al. ’02]
  • But carry costs
    • 15-20% of time spent on interrupts [Solingen ‘98, Czerwinski ‘04, Gonzalez & Mark ‘04]
    • £139bn annual loss in UK (14.6% GDP) [Brother Industries Ltd. 2005]
      • roughly $1.75tn US
  • Willingness to be interrupted depends on
    • Situation, activity, task, relation, topic, time, etc.
  • Inferencing based on situation can approach human accuracy [Fogarty 2004]
two philosophies on infering availability
Two philosophies on infering availability
  • Human interpretation

Awarenex

[Saddler & Hill, 97]

  • Machine interpretation
salient factors in detecting unavailability in an office
Salient Factors in Detecting Unavailability in an Office
  • Predicting human interruptibility with sensors: a Wizard of Oz feasibility study
  • Social engagement was the most salient factor
  • Top 3 factors
      • Speaking
      • Telephone on/off-hook
      • Keyboard/mouse activity
  • Minor factors: sitting/standing, eye gaze on monitor, drinking water, etc.
  • Door was not a factor

[Hudson, Fogarty et al. 2003]

lilsys
Lilsys

Online/Offline Toggle

Motion Detector

Override Timer

Indicator Lights

Sound Detector

client interface
Client Interface

Probably

Unavailable

Sensor-

enabled

Possibly

Unavailable

usage observations
Usage Observations
  • “Online/offline” switch not used
    • but its presence was reassuring to some
  • “Override: Not Available” not used
  • Individuals weigh indicators differently
    • Users desire more control over inference
  • Observers reverse-infer unavailability
    • Users guess reasons why remote party is considered unavailable
    • Diminishes value of hiding sensor data
did it work
Did it work?
  • Can there ever be a good time to interrupt?
    • Users perceive same amount of interruption
      • Also found in MyVine by Fogarty, Lai, Christensen 2004
    • But the interrupter “approached” more politely
  • Interruptions in face-to-face
    • Approach is shaped by availability assessment
    • Both parties aware of degree of intrusion
    • Recipient gives feedback on appropriateness by being gracious or annoyed
  • You can’t hold a caller accountable if they can’t be expected to know your interruptibility
  • Availability inference helps contact negotiation
what s next

[Reality Mining, MIT ’05]

What’s next?
  • The genie is out of the bottle
    • Scott McNealy: 'You already have zero privacy anyway, get over it.'

[IMWatching.net, 2005]

impression management
Impression Management
  • Awareness complicates Impression Management [Goffman]
    • Harder to “give” intended impressions
    • Harder to know what is “given off” (i.e., others see)
    • Harder to repair undesired impressions
  • Support impression management
    • Show what others can and have seen
    • Give user control of inference rules
    • Modify personal data
    • Give users “reverse Digital Rights Mgmt”
      • E.g., if rhythm model shows Janet takes long lunches
      • Show that
        • Janet attends meetings during lunch
        • Janet reads email from home in evenings
        • Janet had the most sales last quarter, etc.

How?

rhythm and unavailability inferencing

Rhythm Inferencing

Dagwood office {ETA < 3m}

Dagwood office {Lunch, ETA < 12:47}

Dagwood office {5:30 < ETD}

Rhythm and Unavailability Inferencing

Unavailability Inferencing

Dagwood office

Dagwood office

Dagwood office {ETA ~9:10 am}

synchronous collaboration and awareness systems2

Synchronous Collaboration and Awareness Systems

Bo Begole

Ubiquitous Computing Area Manager

Computer Science Lab

references
References
  • "Incorporating Human and Machine Interpretation of Unavailability and Rhythm Awareness into the Design of Collaborative Applications", James "Bo" Begole and John C. Tang, to appear in HCI Journal.
  • “If Not Now, When?:The Effects of Interruption at Different Moments in Task Execution”, P.Adamczyk & B. Bailey, CHI 2004
  • "Beyond Instant Messaging", J. Tang & J. Begole, ACM Queue, (1)8, Nov 2003, pp. 28-37
  • “Lilsys: Sensing Unavialability”, J. Begole, N. Matsakis and J. Tang, Technical Note in CSCW 2004, to appear
  • “Rhythm Modeling, Visualizations and Applications”, J. Begole, J. Tang, and R. Hill, UIST 2003
  • “Work Rhythms: Analyzing Visualizations of Awareness Histories”, Begole, Tang, Smith & Yankelovich, CSCW 2002
  • “Coordinate: Probabilistic Forecasting of Presence and Availability”, E. Horvitz, P. Koch, C. Kadie, A. Jacobs, UAI 2002
  • “'I’d Be Overwhelmed, But It’s Just One More Thing to Do:' Availability and Interruption in Research Management”, J. Hudson, J. Christensen, W. Kellogg, and T. Erickson, CHI 2002
  • “Predicting Human Interruptibility with Sensors”, S. Hudson, J. Fogarty, C.Atkeson, J.Forlizzi, S.Kiesler, J.Lee, J.Yang, CHI 2003
  • “The time famine: Toward a sociology of work time”, L. Perlow, Administrative Science Quarterly, 44, (1999), 57-81.
  • “When Can I Expect an Email Response? A Study of Rhythms in Email Usage”, J. Tyler and J. Tang, ECSCW 2003
  • Hidden Rhythms: Schedules and Calendars in Social Life, E. Zerubavel, 1981