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

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

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.

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.

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

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

Computer-mediated Communication Email and bulletin boards Structured message systems Video conferences & communication Virtual collaborative environments Systems that support direct communication – computer mediated communication. Email 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.” email 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.

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.

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.

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.

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

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…

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 email and structured messages, electronic conferences unsynchronized

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

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?

Integrating Communication & Work understanding direct communication P P participants deixis Talked about the gray arcs: direct communication supported by email, 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

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!

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.

The End *whew!*