Thursday, 4 October 2007

Groupware and Social Dynamics: Eight Challenges for Developers

The huge software markets created by standalone PC's used to be restricted to single-user applications. However, this changed as computers became interconnected through networks which opened the markets for group applications. The main problems arises from the fact that the biggest interest in groupware development is found among developers and users of commercial off-the-shelf products, who used to focus om single-user applications.

In general, an organization may adapt to a large computer system, but a small application program must adapt to the organization. Groupware is seen as a small application in comparison with MIS software. Due to the social and political factors at work in group settings, achieving groupware acceptance is much trickier than single-user product acceptance.

The eight challenges for groupware developers are:

  1. There exist a disparity in the work and benefit of different users - Electronic calendar example
  2. A critical mass for groupware is required and according to the prisoner's dilemma if everyone furthers his own goal the critical mass will not be reached.
  3. There is often a disruption of social processes that can lead to rejection of the groupware. It is extremely important for groupware developers to work with representative users whenever possible.
  4. Exception handling - Most systems requires ad hoc solutions and it is difficult to implement these features within the groupware.
  5. Unobtrusive accessibility - Infrequently used features must not obstruct more frequently used features. However, they must be known and accessible to users.
  6. Difficulty of evaluation - It is difficult to relaibly capture complex but important social, motivational, economic and politicial dynamics.
  7. Failure of intuition - Good intuition for multi-user applications is unlikely to be found anywhere in a product development environment. Experience is based on single-user applications.
  8. The adoption process - Consultation is not packaged with shrinkwrapped software and groupware adoption is a much more complex process than that of of-the-shelf wordprocessors.

The following methods may help in overcoming behavioural and social challenges.

  • Extend the use of single-user applications by adding groupware features
  • Find niches where existing groupware succeeds
  • Build on projects that have fared better in the past
  • Find ways to provide direct benefits for all group members
  • Educate managers and developers about groupware


Thursday, 27 September 2007

Belated Readings: Week 3

Computer-Supported Cooperative Work: History and Focus - Jonathan Grudin

What factors and developments led to the establishment of the area of CSCW?
Started with office automation where it was tried to extend word processors and spreadsheets to support groups. It was found that technology alone was not enough, and that it would be necessary to research group dynamics and how people work in groups in order to create successful groupware application. Initial developments consisted of desktop conferencing, videoconferencing and email. Typical related studies that supported the establishment of CSCW were CAD/CAM, CASE and MUDs.

What are the differences between US and EU research traditions in CSCW?
USEurope
Small-system/product developmentLarge-system/internal development
R&D sponsored by Computer industry, research labs and University; R&D more intertwinedMostly Government sponsored
Focus on Experimental, observational and sociological dataFocus on large-scale systems development
Others build technology and they look for ways to use itDriven by philosophy, social, economic, or political theory
Empirical:Experiments by social psychologists looking at group activity among teams of studentsContributions: Explicitly grounded in the writings of philosophers, social theorists and economists.

Collaborative Computing: The Next Millenium - Jay Nunamaker


What does Nunamaker tell about the role of anonymity in groupware systems?

Traditionally the requirements gathering process documented each person’s contribution every step of the way. This stifles both innovation and criticism, since no one wanted to get a reputation for rocking the boat. To prevent this stifling of ideas Nunamker suggested anonymity during the idea-gathering phase of meetings. The anonymity was obtained by allowing each person the use of a computer during the meeting to type their contributions to the meeting, which appeared, anonymously, on everyone else’s screen.

This allowed people who tended to remain silent in meetings, from shyness or intimidation, could now share their ideas freely. It also avoided constant bickering and shooting down of hostile participants ideas.
The net effect of these meetings was to generate more and better ideas faster .

Unfortunately, the very anonymity that allows freedom of expression can also be abused. To avoid this type of chaos, the anonymity should be conditional. There are times when you want participants to be anonymous and times when you don’t.

Friday, 21 September 2007

Belated Readings: Week 2

Distance Matters

What are the major differences between co-located and distant work? Why does "distance matter"?

When trying to bridge co-located and distance located workgroups, it is necessary to realize the key characteristics of co-located teams. These are:

1. Rapid Feedback
2. Multiple Channels
3. Personal information
4. Nuanced information
5. Shared local context
6. Informal “hall” time before and after
7. Co-reference
8. Individual control
9. Implicit cues
10. Spatiality of reference

Groupware in the market currently only supports characteristics 2, 3, 4 and 6 of the above list, and even then, it is supported poorly. Future groupware would at least be able to provide most of these characteristics; however the following factors will continue to provide resistance

1. Lack of common ground, context and trust
2. Different time zones
3. Culture differences


What do you think: will it be possible to make distributed teams as efficient as collocated ones in the future?

Within the global environment today, it is necessary to work across countries and time zones. Unfortunately, we are forced to accept the current solutions. In my opinion, distributed teams will never become as efficient as the co-located teams. It would rather be necessary to look at the added value provided by distributed teams, which will force the work environment to accept these collaborative solutions.

Thursday, 20 September 2007

Objective

This blog will mainly be used to post answers to the discussion of certain scientific papers made available through the CSCW class.