Collaborative Software: Design Issues
As with all user interface design, the method chosen for designing a collaborative software system will have a much greater impact on project success than any one specific design suggestion. This section thus begins with an introduction of the collaborative software design process, and then it goes on to address some of the most common issues that face collaborative software designers.
The Collaborative Software Design Process
It’s best to start by gaining a solid understanding of your prospective users, what their goals are, and how they go about their work. For broadly-targeted groupware applications, such as videophones or email, understanding users can boil down to understanding how human beings communicate in the first place. A design is also best informed by conducting user studies on system prototypes. In these cases, user testing is often significantly more difficult than with single-user systems for the following reasons:
- Organizing and scheduling for groups is more difficult than for individuals.
- Group interaction style is hard to select for beforehand, whereas individual characteristics are often possible to determine before a study is conducted.
- Pre-established groups vary in interaction style, and the length of time they’ve been a group affects their communication patterns.
- New groups change quickly during the group formation process.
- Groups are dynamic; roles change.
- Many studies need to be long-term, especially when studying asynchronous groupware.
- Modifying prototypes can be technically difficult because of the added complexity of groupware over single-user software.
- In software for large organizations, testing new prototypes can be difficult or impossible because of the disruption caused by introducing new versions into an organization.
When designing groupware, it is often best to begin with field studies. The goal is to understand a particular type of group or organization that will be using the groupware system. A number of different studies can be conducted: interviews, surveys, analysis of artifacts used in the work process, examination of processes and workflows, etc. In all cases, the object is to identify the users’ tasks and goals, understand how the group communicates, and determine the power structures and roles.
One key challenge is to appear non-threatening and objective to the users in order to obtain accurate information and to ensure that they will accept any design that results. Another challenge is translating the findings from one organization to others; this is especially a concern when the groupware is intended for organizations which are truly unique or too large to effectively study.
Adoption and Acceptance
Many groupware systems simply cannot be successful unless a critical mass of users chooses to use the system. Having a videophone is useless if you’re the only one who has it. Two of the most common reasons for failing to achieve critical mass are the lack of interoperability and the lack of appropriate individual benefit.
Interoperability
In the early 90s, AT&T and MCI both introduced videophones commercially, but their two systems couldn’t communicate with each other. This lack of interoperability/compatibility meant that anyone who wanted to buy a videophone had to make sure that everyone they wanted to talk to would buy the same system. Compatibility issues lead to general wariness among customers and may make those customers want to wait until a clear standard has emerged.
Perceived Benefit
Even when everyone in the group may benefit, if the choice is made by individuals, the system may not succeed. An example is with office calendar systems: if everyone enters all of their appointments, then everyone has the benefit of being able to safely schedule around other people’s appointments. However, if it’s not easy to enter your appointments, then it may be perceived by users as more beneficial to leave their own appointments off, while viewing other people’s appointments.
This disparity of individual and group benefit is discussed in game theory as the prisoner’s dilemma or the commons problem. To solve this problem, some groups can apply social pressure to enforce groupware use (as in having the boss insist that it’s used), but otherwise it’s a problem for the groupware designer who must find a way to make sure the application is perceived as useful for individuals even outside the context of full group adoption.
Avoiding Abuse
Most people are familiar with the problem of spamming with email. Some other common violations of social protocol include: taking inappropriate advantage of anonymity, sabotaging group work, or violating privacy.
The Commons Problem
If a village has a “commons” area for grazing cattle, then this area can be a strong benefit to the community as long as everyone uses it with restraint. However, individuals have the incentive to graze as many cattle as possible on the commons as opposed to their own private property. If too many people send too many cattle to the commons, the area will be destroyed, and the whole village is worse off as a result. There are a couple of straightforward solutions to the Commons Problem: an appropriate fee can be charged for each head of cattle or a limit can be imposed on the number of cattle any individual may bring. These solutions are an appropriate starting point for solving problems of abuse in groupware.
Socially vs. Technologically-Determined Structure
- Communication Structure
Communication between people is typically highly structured. When someone asks a question, they usually expect either an answer or a request for clarification. After a request, a typical response is to fulfill the request or specify a reason for not fulfilling the request. When someone fills out an official form, that form usually has a pre-determined route that it takes through an organization — possibly to a manager for a signature, then an administrator for processing and filing, then perhaps a duplicate is sent back to the original employee. The point is that most actions have a known range of responses and people to handle them — communication has structure. - Technological vs. Social
When the type of structure is known, systems can take advantage of the structure to speed up communications and minimize errors. When the system determines exactly how the conversation is structured, this is known as technologically-mediated communication structure. The alternative is socially-mediated communication; for instance, when someone wants to make a request, they send a plain email message to another person, and that person decides whether to respond, how to respond, and to whom to respond. - Socially-mediated Communication
This type of structure can be more time-consuming and prone to error, and thus it may be unacceptable for certain types of organizations, especially ones that allow no exceptions to protocol, such as the military or certain safety-critical organizations. On the other hand, exceptions to the expected structure of communication are extremely common. For this reason, technologically-mediated communication may actually be an obstruction to getting work done efficiently and may lead people to not use a groupware system or use it incorrectly, especially when the designer has not completely anticipated the range of communication possibilities. - Facilitation vs. Enforcement
A reasonable compromise between the two possibilities is to make a groupware system capable of facilitating common communication tasks without enforcing a rigid workflow or structure. For example, a discussion forum application might have a “quick reply” function with limited formatting capabilities, but also offer the full formatting options if the user decides they want to use them (which may involve an extra step). Thus, the communication is technologically-facilitated but not technologically-enforced.
Customization and Grounding
When groups are working together with the same information, they may individually desire customized views. The challenge of customized views is to support grounding, which is the establishment of a common ground or shared understanding of what information is known and shared between the different users.
Consider, for example, a healthcare setting. When a physician talks to a lab technician about a patient, they may both have access to the same patient record, but because of their different interests, each may want a view on their computer screen which selects and emphasizes different pieces of information. This may cause confusion when a given piece of information, and therefore an obvious inference about a patient’s condition, is readily available to one person and not the other. Another concern is if one user chooses to display exceptional values in red and another chooses to display exceptional values in blue, different users may be confused. When working together on the same screen, this inconsistency can result in dangerous miscommunication.
In communication situations, it’s important to make it very clear what information is private and what is shared, and, as much as possible, make it clear what information the other user is seeing; for instance, provide a miniature or summary view of the other person’s screen. In all cases, be sure to maintain consistency of the data. Users should never see spurious or irreconcilable differences.
Session Control
A session is a situation where a group of people are in a conversation together at a given time, such as a group of people together in a chat room or people talking together over the telephone. Metaphorically, session control is like a person standing at the door of a room checking IDs and deciding who gets to enter. Floor control, discussed below, involves what you get to do once you’re inside the room. The distinction between the two can be blurry when, for instance, you can look through a window into the room — in some sense you have access to the room and in some sense you don’t.
Session control issues include finding out what rooms are available, determining who can enter and exit the room, and when and how this can happen. Here are some suggested policies for session control:
- Decide what limits there are to who can join a session. Are there limits to the number of people or to who is qualified to enter?
- Allow people to join and leave at any time. Provide a “polite” protocol for doing so. Let people comfortably enter and leave conversations through continuous degrees of commitment and intrusion.
- Avoid intrusive situations where users are able to invade privacy or impose a session on others. A telephone call is an example of an intrusive session control mechanism; in the absence of an answering machine or caller ID, a person has no way of determining whether a call is desired or not.
- Provide a means for preventing interruptions.
- Facilitate people getting together. Provide mechanisms for identifying appropriate conversational partners.
- Provide a means for setting up side conferences.
Floor Control
Once people have joined a conversational session, it must be decided what kind of access each person has to shared artifacts, also known as conversational props. For instance, when using a shared whiteboard, can everyone draw on it at the same time (simultaneous access), can only one person access it at a time (by passing a token, or baton), is there a moderator who controls access, and is there a time limit for each person?
Simultaneous access by everyone to everything is often preferred for the most fluid conversation, but it can be vulnerable to just a single non-cooperative person. This risk is higher when a large number of people are part of the conversation. The advantages to providing some kind of mediated access include preventing mistakes, preventing unauthorized access, and avoiding people making conflicting changes.
Of course, some intermediate solutions are also possible. For instance, in the shared whiteboard example, there can be multiple whiteboards. Some may be personal and others shared. Personal whiteboards may be visible to other users but non-editable by other users. This allows everyone to work simultaneously without interfering with the work of others.
Privacy
- Privacy, Security, and Anonymity
Whenever using groupware, some information needs to be shared. This brings up concern that all other information remain private and that critical information be secure even against aggressive attempts to obtain the information. In many situations, users choose to be anonymous or use a consistent pseudonym. Anonymity can be crucial in encouraging fair participation in discussions and is useful for providing protection from harassment. - Sharing Information, Identification, and Accountability
On the other hand, there is continuing pressure to share more information. If more information is shared, common ground can be achieved more easily. Sharing information about yourself enables many systems to provide more useful customization and matching to your interests. Furthermore, while anonymity can protect an individual, there are also quite legitimate reasons for identifying people for accountability, especially when security and the risk of abusive behavior are involved. - Control and Reciprocity
To resolve these conflicting needs, it’s important to give users as much control as possible over what information gets shared and what remains private. Let users decide how much information to share, and use that to determine what kinds of information they can access. One example of privacy policy is the principle of reciprocity: if a user wants information about another user, then they must provide the equivalent information about themselves. Reciprocity isn’t always the right policy, but serves as a useful starting point.
Awareness
In addition to explicit communication, such as sending a message or speaking to someone, many group work situations benefit from implicit communication, such as indirect gestures, information about people’s environment (whether their office door is open or closed), or biographical information about people in a conversation (what their job position is and what they had for lunch). This information helps people to establish common ground, coordinate their activities, and helps avoid surprises.
Awareness information takes many forms. In videoconferencing, simply providing a wide-angle camera lens can provide a greater degree of environmental awareness. In email, simple information about the time and date of the message or the signature file of the sender (i.e. with contact info, company info, etc.) gives context for making sense of the message. Awareness tools can be designed for letting others know whether you’re in the office or not, letting them know what document you’re working on, or how you’re feeling at any given time.
Obviously, awareness can be at odds with privacy concerns, and as previously indicated, it’s important to give users control over how much information about themselves is made available to others. This is not entirely a technical design issue, but is an issue we must be aware of as a society — we will often want more and more information from others, and the social and economic pressure to share this information will increase over time. As a society, we are obligated to be sensitive to when we are asking for too much information and find other ways of achieving our common objectives without compromising individual privacy.