Research and Advances
Computing Applications

Argumentation Support: From Technologies to Tools

A plethora of technologies exist that are not necessarily tools. For technologies to become a tool, we contend, argumentation routines and design must coevolve.
  1. Introduction
  2. Argumentation Technology in the Community: A Socio-Technical System
  3. Technology Becoming a Tool: Coevolution of Argumentation Routines and Design
  4. An Analysis of the Evolving Socio-Technical System
  5. Toward a Diagnostic Method
  6. Conclusion
  7. References
  8. Authors
  9. Footnotes
  10. Figures
  11. Tables

Argumentation is a crucial communicative activity in society. Many technologies exist that support argumentation, such as mailing lists, group decision-support systems, co-authoring, and negotiation support systems. However, many of these technologies do not work very well in practice; they often support discussions that do not sufficiently contribute to the purposes of their users. An important question therefore is: How to select or design information technologies that better support the argumentative practices of their community of use? In other words, how do technologies that support argumentation become real argumentation tools?

Two research areas that have an interest in argumentation support are Computer Supported Cooperative Work (CSCW) and argumentation theory. CSCW has mainly focused on designing, building, and experimenting with ICT systems, such as group decision-support systems or issue-based information systems (IBIS). Often, the underlying communicative interaction models are rather simple. Argumentation theory, on the other hand, has mostly concentrated on designing human procedures and methods. Although this field has developed subtle models for the design of argumentative interactions, the rigorous implementation and testing of these models in real systems is often lacking. To productively bring together the insights of these two domains of theory and practice, we draw upon the Language-Action Perspective (LAP).

LAP takes the fundamental position that language is not only used for exchanging information as in reports or statements, but also to perform actions, for example, promises, orders, and declarations [12]. The conventional perspective on information systems stresses the contents of messages rather than the way they are exchanged and the effects they have. In contrast, LAP emphasizes what people do by communicating, how language is used to create a common basis for communication partners, and how their activities are coordinated through language. As such, LAP reveals practical ways to improve coordination and effective action, using three types of conversations for accomplishing goals: conversations for action, focusing on the commitments made between participants, conversations for possibilities that create a context for action, and conversations for disclosure, which reveal the concerns and world views that help achieve better alignment between participants [5]. Each of these conversations involves argument.

LAP suggests that arguments are not just messages carrying content with truth claims but that argument is an interaction, a form of activity, to be coordinated through language use. The argumentative aspect of conversations for accomplishing goals presents one of the deep challenges to CSCW—that is, how to enable people to cooperate at conflict. Argumentation theorists have dealt directly with this issue in a variety of ways [11]. One common starting point in argumentation theory corresponding to LAP is the distinction between making arguments and having arguments [9]. Making arguments involves using reasoning, evidence, and claims to put forward a case. Having arguments involves the interactive pursuit of disagreement and controversy. Having an argument does not necessarily involve the making of arguments. Indeed, an ideal form of argument activity is the making-of-arguments in the process of having-an-argument so that people resolve their differences on the merits. This kind of argument, which is called critical discussion, has been extensively modeled in argumentation theory [10].

Critical discussion is an activity to be achieved that calls for support. While argumentation theorists have identified rules and strategies, less is known about how communities of people develop practices and tools that enable them to carry out critical discussions as a means for handling their differences of opinion and managing their conflicts. Here, we address this issue common to the theoretical and practical interests of the CSCW and argumentation fields. We focus on describing how technologies that support argumentation become tools that members of a community use to handle their differences and manage their conflicts. In so doing, we put forward the prospects for a theory of the coevolution of social and technical dimensions of communities from a LAP perspective. Such a theory has implications for diagnosing the argumentation support a community needs and the argumentation support a technology affords. Effective and efficient argumentation, embedded in the collaborative practices of a community, is essential to its success. Having a diagnostic instrument to tailor argumentation support to communal needs is a necessary condition: diagnosis is crucial to select—from the bewildering variety of partially overlapping communication technologies available—those functionalities that are most useful to a community. Without such socio-technical diagnosis, complex and evolving communal argumentation requirements will often be only partially satisfied.

Back to Top

Argumentation Technology in the Community: A Socio-Technical System

Each community has customary—often unarticulated—argumentation routines: the expected argumentative practices that define who is allowed to speak, who may listen in, what types of arguments are admissible, how to resolve conflicts, and so on. On the other hand, a technology used by a community has a set of well-defined functionalities that enable its users to conduct some interactions, while constraining or preventing other behavior. A town hall meeting is a very good way of assessing the emotions and sincerity of various stakeholders, but provides a poorly structured record of the precise arguments made. Decision exploration software is highly capable of recording, organizing, and providing access to the arguments advocating or refuting a particular issue, but makes it very difficult for participants to evaluate the personal motivations of participants. So, selecting the right argumentation technology that, through its functionalities, maximizes its contributions to communal argumentation goals, while minimizing the undesired limitations it puts on the argumentation process, is essential, but not trivial.

Each technology has a technical functionality design, which consists of all functions that operate on the information objects that the technology can process. The technical functionality design is made explicit in the manuals and tutorials associated with the technology. For instance, an IBIS allows its users to create issues, take positions on these issues, and make arguments pro and contra positions. One well-known IBIS grounded in this paradigm, QuestMap, translates these concepts (which it calls questions, ideas, and arguments, respectively) into such technical functions as “create root question,” “respond with idea to question,” “specialize idea,” and “add argument pro/con idea” [3]. Such a functionality design theoretically supports a wide range of argumentation behaviors. However, the actual quality of the support a technology provides is determined by more than just the technical support for selecting a file, adding a comment, and asking or replying to a question. In argumentation terms, it is not sufficient to look at the technical functions that enable particular low-level argumentation moves.

Implicit in the technology is also an argumentation design that comprises— often subtly—the interrelated functionalities, procedures, checks and balances, and connotations that shape the practical range of argumentation behavior [1]. However, the argumentation design often remains implicit. This can lead to breakdowns when the technology is applied in a real-world situation, as unexpected behaviors emerge during use, requiring a conversation for possibility in LAP terms.

To give a much simplified example: The functionality design of the well-known GroupSystems electronic meeting room software includes many components, such as Brainstorming for eliciting ideas from all participants, Categorizer for classifying these loose ideas, Topic Commenter that can be used to add further remarks to, for instance, brainstormed ideas, and Vote to assess positions of participants [6]. This is powerful functionality, but which component should be used in a particular situation? GroupSystems is well suited for meetings of peers, who often remain anonymous. Many situations, however, assign particular argumentation privileges to specific community roles. If GroupSystems were to be used for electronic journal review, the Topic Commenter could be used as a way of gathering various reviewers’ comments on an article. However, its argumentation design would not fit well with the subtle argumentation routines prevailing in an open, distributed scholarly review process.

Argumentation theory would suggest that in a review process, different functionalities may be needed to support the different stages of a critical discussion within a broader review process: Confrontation, Opening, Argumentation, and Conclusion [10]. For the initial Confrontation stage, in which various standpoints, doubts, and objections are first surfaced, Topic Commenter could be fine. For the Conclusion stage, in which the final decision is to be made, it could provide too many degrees of freedom, however. In that case, Vote could be a more appropriate functionality, as Topic Commenter basically supports divergent discussion and Vote convergent discussion into a final decision (see Figure 1).

One solution to deal with the difference between the implicit argumentation design of a technology and the argumentation routines it is to support is to stress the role of the human facilitator, capable of dealing with such contingencies [4]. Our approach, however, is to clearly diagnose the socio-technical gap between the argumentation routines prevailing in the community and the argumentation design emerging from the functionality design of a specific argumentation technology. Understanding this gap between what must be supported socially and what can be supported technically has become a central challenge in the field of CSCW [2], to which argumentation theory can provide at least a partial answer. This is not to say that human facilitation is unnecessary. Rather, our approach is to diagnose the socio-technical gap in order to design technologies and practices that reduce the gap. The aim is to provide more systematic ways to match preferred argumentation routines with available technological designs. Thus, the need for human facilitation may be reduced and its effectiveness increased, while opportunities for better technological designs may be more easily recognized.

Back to Top

Technology Becoming a Tool: Coevolution of Argumentation Routines and Design

We have defined what it means that a technology is a tool for argumentation. We now shift our attention to the process in which a technology becomes such a tool. Understanding this coevolutionary process is crucial if proper support is to be provided for the continuous sensemaking process of both communal argumentation requirements and specifications of the supporting technological functionality.

The BCFOR Case. In 1993, at the height of a conflict about a government decision to allow for clearcut logging in the Clayoquot Sound watershed, the mailing list-mediated British Columbia Forests and Forestry Group (BCFOR) was formed to discuss issues related to forests and forestry in the Canadian province of British Columbia. To dissolve the conflict, the government appointed a Scientific Panel to write a series of reports defining new land-use policies.

The group, however, was dissatisfied with the published reports, as they did not reveal important differences of opinion that might contribute to further policy deliberation and decision-making about land-use policy. The group therefore decided to write its own group reports to accurately identify the points where consensus existed, but also the points where differences prevailed. Their choice to create a different kind of policy report entailed foreseen and unforeseen choices about transforming their interaction with each other into an argumentation process that would produce the desired report. There were many conflicting interests and points of view among the members of BFCOR. The group therefore required that the argumentation central to their collaborative report authoring be neutral and transparent, in the sense that all opinions would be represented in the final report and that all authoring processes leading up to the final report elements would be completely visible. In essence, what was required was functionality to produce dialogic texts, in which multiple authorial voices could be recognized [7].

Entailed in matters of developing effective and appropriate argumentation were issues about the technological support required to enable such argumentation among the participants. After initial experiments with the mailing list and the Web-based threaded discussion technology HyperNews, the customized Group Report Authoring Support System (GRASS) tool was designed. At the time of the conflict, the required Web technology was not available yet. The current implementation, however, allows for different stakeholders in a societal debate to get involved in a process of collaborative report authoring.1 Using GRASS, positions and arguments on focused research questions can be developed, and consensus of participants on issues more easily assessed than in traditional forms of Internet-mediated discussion, such as mailing lists [8].

Back to Top

An Analysis of the Evolving Socio-Technical System

The challenge faced by both the Scientific Panel and the BCFOR group, like by many groups, organizations, and communities, lies in making critical discussion a viable part of the conversations for action, possibilities, and disclosure that produce desired outcomes (for example, plans, agreements, contracts, and reports). Increasingly, (Internet-based) information and communication technologies are used to support these interactions. However, the mere presence of a technology does not mean it will prove to be a viable tool for people to craft conversations that include critical discussion.

In BCFOR, the coevolution of the social and the technical system was an achievement of incorporating critical discussion into its conversation. The argumentation requirements of the group emerged and changed as they made choices about how to interact and what technology to use in support of their argumentation. The incorporation and rejection of these technologies involved the group in recognizing aspects of argumentation they valued, such as assessing consensus while simultaneously having maximum opportunities for the expression of disagreement, and incorporating means to articulate those aspects over other possible aspects of interaction among the participants.

In making these choices, the group was not merely adopting or appropriating technology into preconceived ideas about argumentation but was also recreating and refining its capacity for argumentative communication and collaborative interaction. In other words, a clear coevolution of argumentation routines and argumentation design took place. This evolutionary struggle is summarized in the four stages outlined in Table 1. Each stage was initiated by a particular intervention, such as a change in routine or design. As a consequence, the socio-technical gap fluctuated considerably, but ultimately became smaller.

In the first, informal stage of the BCFOR group, free discussion was the norm. The argumentation design implicit in the mailing list used quite closely matched the informal discussion routines. As a result, the socio-technical gap was very small, and the socio-technical system was close to optimal. However, in Stage 2, the community decided to become productive by writing joint reports. Thus, the argumentation routines became much more complex, and no longer matched the existing mailing list design. In Stage 3, a Web-based threaded discussion tool, HyperNews, was used to better match the focused discussion needs of the community. However, although the socio-technical gap was reduced in this respect, it was enlarged in the sense that valuable functionality—the informal communication allowed by the mailing list—was lost. In Stage 4, the gap finally narrowed by building the customized GRASS tool, with its sensitivity to the particular argumentation needs of this type of community.2

Back to Top

Toward a Diagnostic Method

We’ve shown that argumentation technologies have an explicit functional design, resulting in an implicit argumentation design, in terms of support for both argumentation moves and the design or crafting of the process in which these moves are embedded. We also described how in the BCFOR case the socio-technical gap between this argumentation design and the routines adopted by the community of use coevolved in a way that the argumentation technology became a tool for producing a dialogic text and managing the social conflict around the differences of opinion in the group. The analysis of the coevolution of argumentation routines and design in the BCFOR case was informal. We are working on a diagnostic method in order to more systematically perform such analyses. Here, we summarize this method.

One subfield of argumentation theory, Pragma-Dialectics, provides the advanced argumentation designs required to reconstruct discourse by capturing the subtleties of the pragmatics of argumentative interaction [10, 11]. In our method, the theory-grounded argumentation designs act as reference models used to classify both argumentation routines and designs identified in actual communities. We refer to these reference designs as argumentation models. The diagnostic method consists of five main steps shown in Figure 2: create a knowledge base of argumentation models; define the implicit argumentation routines of the community; define the implicit argumentation designs of the technologies available to the community; match both now explicit models to identify the socio-technical gap; and make recommendations to reduce the socio-technical gap. Such recommendations may include changing the argumentation routines, the technologies used, or the roles these technologies play in the community.

Argumentation models are classified using three argumentation design dimensions: purpose, means of orchestration, and the systemic rationality designed into the procedures enabled by technology [1]. The purpose refers to the aim of the procedure, which is to transform a given mode of social interaction into a preferred one (for example, from dispute to negotiation). Orchestration refers to what affordances a procedure’s design provides for this transformation. Systemic rationality refers to how the orchestration warrants the process and outcome of the interaction. Using these concepts, Table 2 describes three argumentation models identified in pragma-dialectics: issue networking, funneling, and reputation argumentation [1]. Figure 3 shows an example of how the diagnostic method can be used in analyzing the support provided to a BCFOR-type community by the current (Stage 4) prototype of GRASS. The gap mainly concerns the limited activation of participants; lack of technical support for argumentation resolution; and the limited support for publication of (parts of) written reports. To address these issues, recommendations include defining more explicit norms (what may/must/may not participants in their various roles do at specific stages of the authoring process) and notification of report authoring actions (funneling); discovering dependencies between positions and arguments (issue networking), to be used in activation; and publishing parts of report findings on blogs related to that topic (reputation). Future versions of GRASS will incorporate these recommendations.

Back to Top


Traditional IS modeling approaches no longer suffice to design the sophisticated tools satisfying contemporary communication needs. LAP provides a better way of matching communication needs with technological designs, as it is concerned with the way language can be used to coordinate and accomplish evolving (inter)actions. We outlined a diagnostic method grounded in LAP that elaborates traditional CSCW designs with argumentation theory. It may contribute to more successful collaboration by systematically tailoring technological argumentation designs to communal argumentation routines. The proposed approach gives a fuller account of argumentation support than provided by many traditional CSCW perspectives that mainly look at the direct support of conversational moves. The approach may also contribute to the evolution of argumentation theory, as it allows for sophisticated argumentation models to be better tested in actual technologies, thus closing the theoretical-empirical cycle.

In sum, we need a paradigm shift away from building static information systems to designing rapidly evolving communication systems, in which change is the rule, not the exception. Here, we have only scratched the surface of a rich and exciting field of inquiry governed by a perspective that can help redefine the models, methods, and systems urgently needed by an ever more complex and dynamic global society. By adding a language-action perspective to current systems development models and techniques, the vast potential of information technology could become much better realized in practice.

Back to Top

Back to Top

Back to Top

Back to Top


F1 Figure 1. A simplified socio-technical analysis of GroupSystems for joint review.

F2 Figure 2. A method for argumentation support diagnosis in communities.

F3 Figure 3. Applying the diagnostic method to Stage 4 of the BCFOR case.

Back to Top


T1 Table 1. Coevolution of argumentation routines and designs in the BCFOR case.

T2 Table 2. Pragma-dialectical analysis identifying argumentation designs.

Back to top

    1. Aakhus, M. Modeling reconstruction in groupware technology. Advances in Pragma-Dialectics. F.H. van Eemeren, Ed. Sic Sat, Amsterdam, 2002.

    2. Ackerman, M.S. The intellectual challenge of CSCW: The gap between social requirements and technical feasibility. Human-Computer Interaction 15, 2 (2000), 179–203.

    3. Conklin, J. The IBIS Manual: A Short Course in IBIS Methodology. Touchstone, 2003.

    4. Conklin, J., Selvin, A., Buckingham Shum, S., and Sierhuis, M. Facilitated hypertext for collective sensemaking: 15 Years on from gIBIS. In Proceedings of the 8th International Working Conference on the Language/Action Perspective on Communication Modeling. (Tilburg, the Netherlands, July 1–2, 2003).

    5. Denning, P.J. Accomplishment. Commun. ACM 46, 7 (July 2003), 19–23.

    6. GroupSystems; shtml (accessed Nov. 12, 2005).

    7. Harrison, T.M. and Stephen, T. On-line disciplines: Computer-mediated scholarship in the humanities and social sciences. Computers and the Humanities. 26 (1992), 181–-193.

    8. Heng, M. and de Moor, A. From Habermas's communicative theory to practice on the Internet. IS Journal 13, 4 (2003), 331–352.

    9. O'Keefe, D. Two concepts of argument. J. American Forensic Association 13 (1977), 121–128.

    10. van Eemeren, F.H. and Grootendorst, R. Speech Acts in Argumentative Discussion. Foris Publications, Dordrecht, the Netherlands, 1984.

    11. van Eemeren, F.H., Grootendorst, R., and Henkemans, F. Fundamentals of Argumentation Theory: A Handbook of Historical Backgrounds and Contemporary Developments. Lawrence Erlbaum, Mahwah, NJ, 1996.

    12. Winograd, T. and Flores, F. Understanding Computers and Cognition: A New Foundation for Design. Ablex, Norwood, NJ, 1986.

    1We commend Jaap Wagenvoort for his continuing efforts on its current implementation;

    2The BCFOR community is no longer operational. However, the analysis is similar for contemporary communities.

Join the Discussion (0)

Become a Member or Sign In to Post a Comment

The Latest from CACM

Shape the Future of Computing

ACM encourages its members to take a direct hand in shaping the future of the association. There are more ways than ever to get involved.

Get Involved

Communications of the ACM (CACM) is now a fully Open Access publication.

By opening CACM to the world, we hope to increase engagement among the broader computer science community and encourage non-members to discover the rich resources ACM has to offer.

Learn More