Intertwining Perspectives and Negotiation
Gerry Stahl
Center for LifeLong Learning and Design
University of Colorado
Boulder, CO, USA
Thomas Herrmann
Collaborative work typically involves both individual and group activities. Computer support for perspectives allows people to view and work on a central information repository in personal contexts. By intertwining perspective and negotiation mechanisms, individual results can be systematically merged into a group product while work continues. Personal perspectives on shared information are thereby intertwined and merged into a shared group understanding.
WebGuide is a prototype system that integrates perspective and negotiation mechanisms; its user interface has been mocked up in detail to work out the many issues involved. The application domain of WebGuide is web research by teams of middle school students.
Perspective, negotiation, CSCL, web research, K-12 classroom practice.
Support for Individual and Group Perspectives
The World Wide Web (the web) provides an obvious medium for collaborative work. However, it provides no support for the interplay of individual and group understanding that drives collaboration. First, we need ways to find and work with information that matches our needs, interests, and capabilities. Then we need means for bringing our individual knowledge together to build a shared understanding and collaborative products. The web must be enhanced with perspective and negotiation mechanisms to accomplish this.
The term perspective means that a particular, restricted segment of an information source is being considered, stored, categorized, and annotated. In the realm of collaborative work, it is important to intertwine personal perspectives with each other. An individual can do this by taking into account the perspectives of others or by adopting part of another person’s perspective within one’s own. It is also possible to merge several perspectives into one common one. In this paper, we explore the possibility of providing computer support for intertwining perspectives in collaborative work.
Our approach combines previous research we conducted individually on computer support for perspectives [27] and for negotiation [14, 15]. Computer support for perspectives allows people in a group to interact with a shared information source; everyone views and maintains their own perspective on the information without interfering with content displayed in the perspectives of other group members. The problem is that perspectives of group members tend to diverge instead of converging as work proceeds. Computer support for negotiation can help by allowing members of a group to communicate about what information to include as mutually acceptable. The problem with negotiation is that it delays work on information while potentially lengthy negotiations are underway. Here, perspectives provide a solution, allowing work to continue within personal perspectives while the contents of shared perspectives are being negotiated.
We believe that perspectives and negotiation are each important CSCW concepts in their own right, but that when combined they can offset each other’s major weaknesses and provide powerful support for shared information sources. We propose an approach to intertwining the mechanisms of perspectives and negotiation to help collaborative groups intertwine the personal perspectives of their members into an effective shared network of perspectives on task-relevant information.
This paper describes the application of intertwined perspectives and negotiation to a collaborative research project in a middle school classroom.
 | The next section characterizes perspective and negotiation mechanisms that the authors developed independently in the past. |
| This is followed by a section on related work, to differentiate our mechanisms from others. |
| Then the student research project is described and requirements for computer support of this kind of collaborative work are discussed. |
| The structure of perspectives in our prototype is presented and tied in to corresponding classroom practices. |
| Next, procedures and mechanisms are discussed for students to make proposals for negotiation. |
| The paper concludes with future work,
introducing our software into the classroom and evaluating its use.
|
Previous Work on Perspectives and Negotiation
This paper integrates two previous approaches: collaboration using perspectives and negotiation of shared information.
The most important characteristics of Stahl’s [27] perspective mechanism are:
This model of perspectives has the important advantage of letting team members inherit the content of their team’s perspective and other information sources without having to generate it from scratch. They can then experiment with this content on their own without worrying about affecting what others see. This is advantageous as long as one only wants to use someone else’s information to develop one’s own perspective. It has frequently been noted in computer science literature [5, 10] that different stakeholders engaged in the development and use of a system (e.g., designers, testers, marketing, management, end-users) always think about and judge issues from different perspectives and that these differences must be taken into account.
However, if one wants to influence the content of team members’ perspectives, then this approach is limited because one cannot change someone else’s content directly. It is of course important for supporting collaborative work that the perspectives maintain at least a partial overlap of their contents in order to reach successful mutual understanding and coordination. The underlying subjective opinions must be intertwined to establish intersubjective understanding [29,13].
The concept of computer-mediated negotiation addresses the problem of making changes to a system design or an information source when the changes may conflict with the interests of others. Such a change must first be proposed by someone. The same software that is used to prepare and propose the change should also inform the people affected and help them to respond to the proposal. According to Herrmann [14], the following options for voting and discussion should be offered:
This concept of negotiation was originally developed for situations in which two users of a computer system discuss whether a system feature should be implemented or not. This approach was intended to support "controllability" and "suitability for individualization" (cf. ISO 9234, Part 10) for groupware. Such negotiation can take place in multiple cycles of the proposer and the responder reacting to each other. Negotiation rules must be established to define how many negotiation cycles can take place, how much time is allowed to pass before a decision must be reached, what happens when a time limit is reached, etc. The goal of this negotiation mechanism is to get through routine cases of agreement, abstention, or simple modifications of proposals as quickly as possible and to determine as efficiently as possible which proposals require a more intensive communication process. This provides a common starting point from which cooperation can proceed.
A disadvantage of this negotiation mechanism is that it was designed for just two people. If applied to several participants, the time period for arriving at a common starting point stretches out too much. The original negotiation concept assumed that a modified item would not be worked on further until the negotiation process was complete. This might make sense in the case of a change of software system functionality, but it seems unduly restrictive for modifications of information and analysis. By contrast, the approach of intertwining multiple perspectives into a common one has the advantage that participants can continue to work in their own perspective while awaiting the results of negotiations. This allows the negotiation mechanism to be extended to small groups.
Our work builds on ideas from a variety of CSCW approaches.
Hypertext and hypermedia structures provide an important mechanism for supporting collaborative work with shared materials. To some extent, this is provided by the web itself, although many hypertext mechanisms have been explored that go beyond the web’s simple model [2]. The original perspectives mechanism of Stahl [27] is a hypermedia implementation, based on a node and link structure; relationships among contents in different perspectives are defined by links. Internal manipulation of nodes and links allows multiple perspectives to share large information sources without unnecessary duplication. The use of "virtual copying" or "delta storage" is well-known in system software [9], but was not previously used in CSCW hypermedia systems.
The importance of perspectives in collaborative work has been recognized at a theoretical level by Boland [5, 6] and others, primarily based on the hermeneutic tradition in philosophy: Heidegger and Gadamer [see 27]. The application of virtual copying to perspectives on data was explored at Xerox PARC [4], but abandoned as too complicated for users at that time. A related mechanism of transclusion was proposed by Nelson [20] for hypertext. McCall applied a similar approach for organizing hypertext information by domain and version in Phidias [19]. Stahl extended McCall’s approach in Hermes [27], implementing a hypertext version of virtual copying in a productivity tool for professional design teams. He subsequently adapted this mechanism in CIE, a collaborative information environment for supporting peer group management of ISO 9000 documentation [26].
Computer Supported Collaborative Learning
A number of software systems have been developed to support collaboration of research teams in schools; CSCL [17] has become an important new research direction within CSCW. CSILE [23], for instance, is a threaded discussion system customized to scaffold classroom research. Systems like CoVis [21] and CaMILLE [25] also provide a shared workspace or notebook area for collecting research results. Rather than supporting negotiation through the system, they rely on face-to-face interactions to make choices about what materials get entered into the team repository. When such systems talk about "perspectives", they mean different representations of the same information, rather than views of information related to different individuals or groups. The WebGuide system detailed below is in the CSCL tradition, but brings a new concept of perspectives as well as support for negotiation.
By organizational memories we mean an approach to building a structured digital library of various forms of information that can be shared by community members through computer supported collaboration and communication mechanisms [1,18]. Intertwined perspectives can help to structure an organizational memory. For instance, when a group of community members undertakes a new project they can create a new perspective on the memory and negotiate which items from existing perspectives should be included for use in the new project.
GroupLens [22] is typical of approaches that try to automate the construction of perspectives. It displays available information in accordance with individual or team preferences. Statistical analyses are used to automatically determine which members of a group are interested in similar topics. Items of information that are of interest to one member are then sent to other group members with similar interests. In our approach, information is automatically assigned to perspectives only in the sense that a perspective can inherit entire other perspectives and that when one makes a virtual copy of an individual item one can inherit the subnetwork of items related to that item. Rather than relying entirely on automated mechanisms, WebGuide allows active selection or modification of information by users.
The above approaches lack any computer supported negotiation mechanisms. Wulf [32] adopted Herrmann’s approach to support of negotiation and developed it for conflict management in groupware. Wulf distinguishes various ways in which a groupware user can avoid or reduce the effects of another user’s actions. However, we believe that it should always be possible for users to react to each other, at least by commenting. Ideally, these reactions back and forth should take place with support from the same system that presents the content under discussion.
The clearest parallel to computer-supported negotiation is decision support and meeting support systems [11]. In these systems, one can respond to proposals from others by extending them with one’s own proposals or amendments. One can also annotate the proposals. In more elaborate systems, such as those derived from Argnoter, [28] one can classify one’s annotations as pro or con the argument. Several systems count votes for or against a proposal [8]. Sen, et al. [24] describe an application of this for meeting scheduling. Our negotiation mechanism shares many features with these decision support systems, but does so within a systematic context of individual and group perspectives.
Supporting Collaborative Student Research
In summer 1997 we decided to apply our vision of intertwining perspectives and negotiation to a situation in middle school (6th grade, 12 year olds) classrooms we work with. The immediate presenting problem was that students could not keep track of web site URLs they found during their web research. The larger issue was how to support team projects. The more we discussed computer support for collaborative student web research, the more complicated and detailed the issues became. To facilitate our own collaboration we adopted two representations: (1) formal modeling of the software procedures, data elements, and social context; (2) design of a detailed user interface using HTML. You will see both representations in the remainder of this paper.
The result of our collaboration is an interface design for WebGuide [31], a web-based prototype that integrates perspective and negotiation mechanisms to support collaborative learning. To make our design concrete, we focused on a project-based curriculum [3] on ancient civilizations of Latin America used at the school. The example of this student research project is well suited to illustrating the power of intertwining perspectives and negotiation: it shows the level of complexity that our approach can handle.
Sixth grade provides an exciting and challenging venue for this kind of software because the students are just starting to acquire adult cognitive skills and they are open to new experiences. The WebGuide system is designed to make explicit and scaffold for students the structure of web research, team collaboration, personal perspectives, and group negotiation that they may be experiencing for the first time in their lives.
WebGuide is a glorified web bookmark manager [16] and electronic notebook application [30], enhanced with perspective and negotiation mechanisms as described below. Students can conduct web searches, collect, annotate, categorize, and organize bookmarks for sites they like. They can summarize or excerpt the web page contents (there is no need to copy the full contents because it is already available through the active bookmarks). Students are encouraged to use the facilities of WebGuide to make the results of their research more self-explanatory for themselves and their team mates by defining a hierarchy of headings or categories, arranging bookmarks under these, and adding concise summaries of the content or importance of the bookmarked sites.
Figure 1 shows a view of a student’s personal perspective in WebGuide. There are three topics visible in this view. Within each topic are short subheadings or comments, as well as web bookmarks and search queries. At the bottom is access to search engines.
Figure 1. Part of Kay's personal perspective in WebGuide.
In compiling a list of requirements for WebGuide, we focused on how computer support can help structure the merging of individual results. Such support should begin early and continue throughout the research process. It should scaffold and facilitate the decision-making process so that students can learn how to build a consensus. WebGuide combines displays of individual work with the emerging group view. Note that the topic on Aztec Religion in Figure 1 has been proposed by other students to be part of the team perspective. The other two topics are ideas that Kay is preparing to work on herself. Within her electronic workspace she views information from the team perspective along with her own work.
Each student should be able to view the work of other team members as they work on it, not just when it is submitted to the team. Students should be able to adopt individual items from the work of other students into their own perspective, in order to start the collaboration and integration process. From early on, they should be able to make proposals for moving specific items from their personal perspective (or from the perspective of another) into the team perspective, which will eventually represent their team product, the integration of all their work. The next section discusses how this is supported in WebGuide.
The requirement that items of information can be copied, modified, and rearranged presupposes that information can be collected and presented in small pieces. This is also necessary for negotiating which pieces should be accepted, modified, or deleted. Figure 2 presents a schematic model of the information elements that are relevant for WebGuide and that may appear on a page. The web pages of a student’s personal perspective should not only contain clickable bookmarks and search queries, but also categories, comments, and summaries authored by the student.
Figure 2. Data structure for a basic WebGuide page.
As indicated in Figure 2, a bookmark can have a title as well as the link to a URL. A note icon can optionally be attached as well (the hexagonal symbol indicates an option). This icon represents a link to another web page that might contain an extract, summary, or commentary to the bookmarked site, authored by the student and possibly incorporating information from readings or discussions. In addition to bookmarks, the WebGuide page can contain web search queries for finding current sites on a given topic. WebGuide is designed to help students learn to do web research, and the sharing of successful query formulations is important for that.
WebGuide pages are structured by topic headings or categories for organizing the bookmarks and queries. These categories can initially be created without any bookmarks or queries as preparation for looking for relevant information, as Kay has done for the topics of Mexico City and Live Sacrifice (in Figure 1) that she intends to research. The categories can be structured hierarchically to create an information outline, as indicated by the recursive embedding of information item in the model (Figure 2).
Comments can optionally be attached to any information item. Every item is tagged with the name of the person who created or last modified it. Items are also labeled with perspective information. Furthermore, there is a set of functions which can be used to edit the information items.
Because of the hierarchical nature of items, something that appears as a unit of information that can be proposed for negotiation may actually consist of many parts, some of which appear differently in different students’ perspectives. The possibility of information items having a complex but hidden internal structure is required for the intertwining of perspectives and negotiation. The internal complexity is handled by the perspective and negotiation mechanisms behind the scenes of the WebGuide interface.
While fairly complicated manipulations may be going on behind the scenes, the interface attempts to present a relatively clean metaphor of perspectives and negotiation. Figure 3 shows a view of the WebGuide table of contents, which is always visible as a frame on the left. The table of contents lists communication media and information retrieval tools that are bundled into WebGuide. As part of this list of tools, the six perspectives that let students compile their individual and joint research are also listed:
Figure 3. The WebGuide table of contents (left) and part of the team perspective.
Figure 4. Automativc inheritance relations among the different perspectives in WebGuide.
The power of the perspectives mechanism comes from the inheritance relations among these six different kinds of perspectives. Figure 4 shows these relations for the Aztec team and three of its members:
| The team perspective is pivotal. It includes accepted and proposed items. It gradually collects the products of the whole process. |
| Each student’s personal perspective inherits a view of everything in the team perspective. The students can each modify (add, edit, delete) their virtual copies of team items in their personal perspectives. They can also create completely new material there. |
| The comparison perspective inherits from the personal, team, and class perspectives. Students can go here to get ideas and copy items into their own personal perspective or propose items for the team perspective. |
| The negotiation perspective inherits proposed items from the team perspective. When they are approved or rejected at the end of negotiation, then their status in the team perspective changes. |
| The history perspective inherits from the comparison perspective, that contains information from all the other perspectives. |
Of course, there is not really such a multiplicity of information in the central database. The perspectives mechanism merely displays the information differently in the different perspectival web pages, in accordance with the relations of inheritance.
To design software for collaborative learning means to design curriculum and classroom process as well. Computer support has to be matched with appropriate content on the web and with a constructivist pedagogy [7, 12, 23]. The design of the WebGuide interface and the perspective and negotiation mechanisms is accompanied by the design of informative web pages and of a use scenario.
Figure 5 shows a model of the process involving the teacher (represented by "T"), the students ("S") and WebGuide. It shows the relation of individual to cooperative work and the mediating roles of the perspective and negotiation mechanisms.
Figure 5. Model of the task performance and perspectives.
Figure 5 shows the process flow. Students research using sources available to them: the web, books, encyclopedia, CD-ROM, discussions, or other sources. Students can review the contents of the class perspective, their team perspective, and the personal perspectives of their team mates. All of these contents are collected in the comparison perspective, where they are color-coded and labeled by their perspective of origin. Students extract from the research those items which are of interest to them. Then they organize and develop the data they have collected by categorizing, summarizing, labeling, or annotating. The three stages of investigating, collecting, and editing can be repeated as many times as necessary.
To support these steps of the work, WebGuide provides a menu of functionality for each information item. The following menu options are included:
| show/hide detail applies to most items within any perspective. It means that all items below the given item in the information hierarchy should be displayed/hidden. |
| Add a new item brings up a dialog displaying the context within which the item is to be added. The student can select what type of item to add, specify a title, and type the new text. Such dialogs are intended to scaffold the student’s work, providing a structure of small tasks to perform in accomplishing a larger goal. |
| Move this item, Edit this item’s text, and Delete item allow students to configure web page representations of the knowledge they are constructing. Each of these options involves a dialog box that accepts further specifications. |
| Copy to my perspective offers the choice of copying a single item, such as a category, or copying all the items under that category as a group to one’s personal perspective. |
| Propose to team and Negotiate this item are discussed in the following section. |
The class project ends with each team producing an organized web site about one of the civilizations. These web sites can be used by members of the other teams to learn about the civilizations that they did not personally research. The sites can also provide a basis for additional class projects, like narrative reports and physical displays. Finally, this year’s research products can be used to create next year’s class perspective starting point, so new researchers can pick up where the previous generation left off–within a web information space that will have evolved substantially in the meantime.
A student can make proposals for the team perspective from the Propose to team option within his or her personal perspective. This is how new items get introduced into the team perspective. A student can also propose an item from someone else’s perspective by locating it in the comparison perspective. If she wishes to modify it, she can first copy it into her own perspective. If someone wishes to modify an item that is already in the team perspective, she must copy it into her own perspective, make the modifications there, and then propose the modified item.
It should be possible when proposing–just as with copying–to treat a set of related items in one step. It is important to be able to treat a set of proposed changes together even if they are not related. For example, if a student deletes a bookmark at one spot in order to replace it with a better, richer bookmark elsewhere, then the deletion and the replacement should both be proposed and negotiated together. Of course, students should be discouraged from grouping too many items together.
When a student selects the Propose to team menu option for an item, a dialog box opens (see Figure 6). The student can decide whether the new proposal item should be combined with a previous or future proposal.
Figure 6. A dialog for proposing an item for negotiation.
The proposer also sees a list of all the other students who will be involved in the negotiation of the item. The determination of who should be involved is a matter for installation settings that define a local negotiation policy. These settings are system parameters of WebGuide, so they can be easily varied by teachers or other user communities. For example, one might want to establish a rule that all new items must be negotiated by all team members–or alternatively that they do not require negotiation at all–while modified items require just those people to participate who either originally created the item or subsequently modified it. Another plausible rule would be to accept all annotations without negotiation.
As soon as an item is proposed, it appears in the negotiation perspective. Through perspective inheritance, it also appears in the team perspective and in the personal perspective of all team members, labeled as Proposed by name-of-proposer. A student can select the Negotiate this item menu option for the item to switch to the negotiation perspective for that item.
No editing of the proposal is allowed in the negotiation perspective. Rather, there are three windows (see Figure 7). The top window includes buttons corresponding to the negotiation options: Accept, Reject, Abstain, and Let’s talk. The second window displays the proposed item or items within the context they would have in the team perspective once accepted. The bottom window contains the results of negotiation decisions already made about the proposal and the commentary of team members concerning these decisions
Figure 7. The Negotiation Perspective.
Several negotiation responses to the proposal are possible at this point. A negotiator can indicate that she abstains, that she does not care to participate in the negotiation. Alternatively, she could indicate with Let’s talk that she would like to discuss the proposal face-to-face in the team. In the later case, the label on the proposed item changes to Proposed by name-of-proposer, Let’s talk. In addition, an automatically maintained agenda of points for group discussion is extended to include this proposal.
Of course, the primary options are to Accept or Reject the proposal. It should be noted that a proposal can have been modified by other group members so that there may be several versions of the same proposal. If Accept is selected for one alternative, then all the others are assigned Reject and the negotiation is over for that student. If Reject is selected, then the next version of the proposal is displayed. When several versions are available, a student can either accept precisely one or reject them all.
After making a negotiation decision, a student should comment on the reasoning behind her response. All students who view the negotiation perspective after that can see her response with her comment. Although it may not be sensible in a negotiation situation involving several participants to allow cycles of responses to responses because the negotiation process would quickly become too confusing, WebGuide does allow students (and teachers) to comment on all actions, including comments on comments. Even after a student has completed her voting on a proposal she can comment on other people’s choices or change her vote.
The procedure for amending a proposal is a bit involved. Once a student has rejected all the existing versions of a proposal, she can modify the proposal in her personal perspective and propose her amended version. Then the new version will be automatically integrated into the negotiation process of the original proposal. The label of the proposed item will be altered to read, Proposed by name-of-first-proposer amended by name-of-second-proposer. Students who have already voted will see this new label and can decide if they want to return to the negotiation perspective and reconsider their vote on this proposal. It might also make sense to have a more intrusive mechanism to alert people to newly proposed versions by event mechanisms. The design decision to restrict modifications this way in the negotiation process results in a simplification of the process. It is only possible to edit the original proposal, not proposals that already have the label amended. Otherwise, things would become too confusing. While a proposal can be rejected by its original proposer when she prefers an alternative version, it cannot be recalled because that would create an asymmetry between the proposer and other participants.
The negotiation process for a proposal cannot exceed a time limit, determined by the negotiation policy parameters. At the end of the time period, the system determines whether the proposal or a modified version is accepted or rejected. Again, installation parameters determine what kind of majority is required: 2/3 of those voting, majority of those eligible, simple majority, etc. If the results are indecisive, the proposal will be labeled proposed for talk and added to the discussion agenda. Then students will have to get together in the classroom and decide what to do about the proposal. When matters are decided in group meetings, someone with a special password can enter changes directly in the team perspective, short-cutting the computer-supported negotiation process.
We now have an interface design mock-up that shows several typical perspective views [31]. Although the menu functionality for the perspectives and negotiation is not implemented, the dialogs showing planned options can be seen in Kay’s personal perspective and in the Aztec negotiation perspective. One can see how illustrative contents show up under different perspectives and observe certain stages of negotiation.
WebGuide will be further implemented in 1998/99. Now that we have an initial demo of our concept, we will engage in participatory design with teachers over the summer to refine the approach. Initial evaluation of some of its concepts will be conducted during the term in middle school classrooms in Boulder, Colorado. We will investigate how different features are used in practice. For instance: Do students move fluidly and effectively among the different perspectives? To what extent do students group related proposals together? How much do students comment on their negotiation decisions or on those of others? Can students handle the process of modifying proposals? We will also explore different negotiation policy parameters: What happens to proposals that just one or two students slate for group discussion? What time limits, voting methods, negotiation participation rules are meaningful and effective?
Certainly, the full concept of negotiation has to be drastically simplified if middle school students are to succeed with it. The textual description of intertwining perspectives and negotiation in this paper is complex indeed, even for adult computer scientists to think about. We assume that the ideas can be made more intuitive in a CSCW system with a carefully designed interface.
While we want the structure of perspectival views and negotiation options to be made explicit to students as they begin to develop critical thinking skills, we hope that much of the mechanism for implementing them can be hidden from view behind intuitive interface metaphors. We will have to introduce the functionality of WebGuide into the classroom gradually, working closely with teachers and students, and creating a curriculum and classroom process to complement it. This process will reveal opportunities for simplifying the system and making it more useful and usable.
If we are successful in creating an effective WebGuide system for twelve year olds, we will have learned much that is relevant to developing usable mechanisms for intertwining perspectives and negotiation in other domains of collaborative work and collaborative learning.
The WebGuide prototype and this paper resulted from the intertwining of two rather different perspectives on software development: a German theoretical inclination toward abstract modeling and an American pragmatic preference for mock-up. Through delicate negotiation, the authors arrived at a mutual understanding of the complex of design issues that confronted our collaborative research. The research reported here was undertaken during a six month visit by Herrmann to Boulder. Stahl’s work was supported in part by grants from ARPA (N66001-94-C-6038), NSF (IRI-9711951) and the McDonnell Foundation.