1. Groupware Groupware C.A. Ellis, S.J. Gibbs, G.L. Rein Chapter 13
Michael Rounding

2. CSCW Defined
“…[CSCW] is about groups of users – how to design systems to support their work as a group and how to understand the effect of technology on their work patterns…”
Both the old and the new definitions roughly work out to be the same, just different in wording.
Michael Rounding

3. Face-to-face conversation
Time/Space Matrix
Same place
Different place
Same time
Face-to-face conversation
Telephone
Different time
Post-it note
Letter
Time space taxonomy of groupware, covered in both papers with some cool jargon. Here’s the basic breakdown of where these things can possibly fit in, plus simple examples of each.

4. Face-to-face conversation
Time/Space Matrix
Co-located
Remote
Face-to-face conversation
Synchronous
Telephone
Asynchronous
Post-it note
Letter
Here’s the terminology as it will appear in most CSCW literature. This classification/taxonomy is limiting, get to that a bit later.

5. Cooperative Work Framework
understanding
direct communication P P
participants
control and feedback
The entities and the artifacts on which they work make up groupware.
There are two or more participants
They are engaged in some common task
To do so, they interact with various tools
Some are shared, some are not
Participants communicate to teach other while they work, with the goal of establishing an understanding of the task at hand
Participants issue control over the artifacts which yield feedback to the participants A
artifacts of work

6. Cooperative Work Framework
Computer mediated communication
Meeting and decision support systems
Shared applications and artifacts
For the presentation, will classify stuff in terms of their operation in that framework (although some may use multiple classes):
Cmc supports direct communication between the participants
Mdss supports capturing common understanding between users
Saa supports the participants’ interaction with shared work objects – the artifacts of work

7. Computer-mediated Communication
and bulletin boards
Structured message systems
Video conferences & communication
Virtual collaborative environments
Systems that support direct communication – computer mediated communication.
systems, although one of the simplest, it is one of the most successful cscw apps out there. In the old paper, they call these “message systems.” is asynchronous, but more synchronous example in the same category can be chat apps like unix talk and IRC chat stuff.
Problems with these types of systems, can get overwhelming … too much mail (personal observation, makes it easier for more people to churn out more junk to give to you more frequently with no consequences to themselves). That’s why filters are useful.
Newsgroups and such can get huge. Just look at the subscription lists for newsgroups and imagine the number of messages posted in total. But, subscription idea is structured and is a simple filtering mechanism to let users see only postings (supposedly) in an area of interest.
Video weird to be in CSCW, most don’t use computers.
Idea of videophones been around for years. Realtime communication idea too (p12, old paper dated remark)
Video stuff is an idea coming of age, data transfer getting close to fast enough to support it along with compression.
Problem: field of view of camera, lack of eye contact (although people can get used to that). Good for scheduled meetings, not so good for random hallway meetings (although video-walls aimed to help there)
Virtual reality, virtual representation of a physical space with several people occupying it. Mostly research.  Simpler systems exist, such as MUD (multi-user-domain). More physical metaphor idea, your icon can run into other people’s icons and you can interact with them.

8. Meeting and Decision Support Systems
Argumentation Tools
Meeting Rooms
Shared Drawing Surfaces
Generation and recording of ideas and decisions.
AT record arguments used to arrive at a decision and support principally asynchronous-co-located design teams
MR support face-to-face groups (synchronous co-located) in brainstorming and management meetings.
SDS can be used for synchronous remote design meetings.

9. Argumentation Tools Often hypertext-like structure Concurrency control
Often hypertextlike structure. One person at a time in simplest terms, sorta like doing revision control in word and reposting document.
Others allow multiple dev at the same time. Stop work of one from interfering with work of another: concurrency control. Can do simple locking.

10. Meeting Rooms Specially constructed rooms WYSIWIS
Floor control policies
Social and software protocols
Support for deictic references
The cool rooms are expensive!
Specially constructed rooms designed to support face-to-face meetings. Face-to-face is successful to start, so the design of the rooms has to take that into consideration.
Sometimes have a monitor per person, with a groupware app going. All participants see the same thing, what you see is what I see. The shared display can become a community whiteboard … imagine having like 4 more machines wired to the smartboard.
Ana: problems if several participants decide to go at once. Floor control policies: locking, one person gets the floor and other people have to get it from them when they relinquish it. Simpler solution: just let everyone go at once!
Different forms of locking: social vs. software protocol.
If you have one public pointer, then people can do the pointing “that” and “there” and “this thing” easier. That’s deictic reference and groupware needs to take this social phenomenon into account.
Less expensive solutions exist, but I won’t talk about any of it.

11. Shared Work Surfaces
Take meeting rooms, make them run between multiple locations!
Notification Collage, kinda…

12. Shared Applications & Artifacts
Sharing work domain
Shared PCs & Shared Window Systems
Shared Editors
Co-authoring systems
Shared Diaries
Communication through the artifact
In this category, the focus of sharing in the group setting is the work domain itself (This is more accurate for describing NC)
SHPCSHWS allow ordinary apps to be the focus of cooperative work. (like imagine multiple people with the same entry point in an instance of word)
Design problems: interleaving of mouse and keyboard movements are annoying and disruptive. Locking is possible to alleviate the problem, and social protocols (mentioned previously) can be developed.
Good area for this: Technical support … can log onto a troubled user’s machine and guide them visually or help them to get to the right place. (VNC it here!)
Shared editor: editor that is collaboration aware. Provides several insertion points or locking protocols more tuned to the editor’s behavior.
Design issues: single or multiple insertion points? Views? WYSIWIS problems: scroll wars.
Funny stuff: users like to have the most natural sense of engagement possible. The more natural it gets, the more they revert to natural stuff like pointing to a spot on _their_ screen. 
Co-authoring systems are largely asynchronous. Most are built on a hypertext model. Must have some sort of concurrency control for when synchronous editing is going on (although the idea is that this is generally rare).
A calendar system that will look for a common available slot for a group of people wanting a meeting.
In the end, it’s up to the users to cooperate.
Design issues: how much info to give out about a schedule? Do we let others enter stuff in our schedule?
All the other systems are artifacts being manipulated by the users. Basically this is just cooperative work with single docs. IE, someone enters something in a database that is used by another, document passing, statistic passing, etc…

13. A Redefined Matrix co-located remote concurrent synchronized
video conferences, video wall, etc.
meeting rooms
shared work surfaces and editors, shared PCs and windows
mixed
co-authoring systems, shared calendars
Concurrent access: when users are active at the same time
Mixed means that you may have people going all at once or it could be asynchronous
Serial means that people are forced to use the tools in a turn-based fashion.
Unsynchronized is when people aren’t using the tools at the same time, or at least that isn’t the intention.
serial
argumentation tools
and structured messages, electronic conferences
unsynchronized

14. design: Granularity chunk size update large
network file systems with locking
co-authoring systems
meeting system with floor holder
shared editors
Some systems operate at a fine grain, such as systems that let you update a character or a word at a time, others have a grain size and updates occur with larger changes/amounts of data (like locking down a complete paragraph until it’s completely updated).
small
frequent
infrequent
update

15. design: Sharing Shared databases WYSIWIS Race conditions
Rare in explicit groupware, but no less prevalent in shared databases – sharing the view but not the presentation: the example of looking at a tabular set of data versus a pie chart or graph of that particular set of data.
Problems with WYSIWIS: reiterate the scroll war, imagine one person scrolls while another person is typing at their insertion point, as soon as the insertion point scrolls of the screen, it starts to move with the scroll, planting characters sorta all over the place.
Race conditions: two people submit edits to the same object at the same time. Who goes first?

16. Integrating Communication & Work
understanding
direct communication P P
participants
deixis
Talked about the gray arcs:
direct communication supported by , electronic conferences and video connections
Common understanding supported by argumentation tools meeting rooms and shared work surfaces
Control and feedback from shared artifacts supported by shared pcs and windows shared editors coauthoring systems and shared diaries
New arc: deixis, people need to point to stuff in direct communication. “In general, direct communication about a task will refer to the artifacts used as part of that task”
New arc: feedthrough, one participant’s manipulation of a shared object can be observed by other participants. Communication through the artifact thing
feedthrough
control and feedback A
artifacts of work

17. Design Time! Feedback and network delays
Architecture: centralized & replicated
Architecture: shared window
General problems, blah blah blah…
network delays: can produce breakdowns in feedback, ie if it takes 30 seconds for a character you insert to appear, it’s probably not so cool.
Architectures for groupware, discussed previous class but mention basic outlines here, centralized and replicated
Shared window architecture, where several workstations are sharing instances of the same window managed by the window manager (example, easily supported in X with several users talking to an application stub through X)
Failures in network, server crashing, errors in programming, failure to scale up as the number of users increases!

18. Design Perspectives Distributed Systems Communications
Human Computer Interaction
Artificial Intelligence
Social Theory
These points came from the earlier paper and I though it was a cool perspective on groupware design, my fave part of that paper.
Many multi-user systems are naturally thought of as distributed systems. Their perspective focuses on the decentralization of data and control.
Focus on the exchange of information between remote agents. Concerns: increase connectivity and bandwidth (reduce problems and increase the amount of info available) protocols for exchanging different types of info: text, graphics, audio, video. How to make groupware interaction as effective and natural as face-to-face interaction?
Importance of the user interface is put in the forefront. Is multidisciplinary in the first place: graphics, ID, cognitive science. Human Computer interaction from the perspective of a group is a cool problem.
I didn’t get this perspective.  technology transform machines from passive agents to agents with a more active role in groupware mediation?? Is this a dated idea?
Social Theory perspective: emphasize the social element of groupware design. Systems looking from this perspective are designed from observing real behavior and trying to support that through systems.

19. The End *whew!*