DEVELOPING ARGUMENT ASSISTANT SYSTEMS

FROM A USABILITY VIEWPOINT

Mar´ıa Paula Gonz´alez, Carlos Iv´an Ches˜nevar

CONICET / Department of Computer Scicence & Engineering, Universidad Nacional del Sur, Bah´ıa Blanca, Argentina

Niels Pinkwart

Department of Informatics, Clausthal University of Technology, Clausthal-Zellerfeld, Germany

Mauro J. G´omez Lucero

CONICET / Department of Computer Scicence & Engineering, Universidad Nacional del Sur, Bah´ıa Blanca, Argentina

Keywords:

Intelligent information systems, Tools for knowledge management, Argument assistant systems, Usability.

Abstract:

This paper discusses the role of usability as a quality key attribute for the deployment of Argument Assis-

tant Systems, which are software tools intended to provide effective knowledge management facilities when

solving problems in different contexts, helping to identify, create, represent and analyze the arguments in-

volved as well as their interrelationships. Based on a reverse engineering process, a set of usability-oriented

Design Guidelines were identiﬁed and instantiated for the Argument Assistant System domain. Besides, some

usability principles are proposed and linked to every suggested guideline to evaluate its quality in use.

1 INTRODUCTION

Argumentation is an important aspect of human de-

cision making. Argumentation systems (Rahwan and

Simari, 2009) have been increasingly considered for

applications in developing software tools, constitut-

ing an important component of multi-agent systems

for negotiation, problem solving, and for the fusion of

data and knowledge. Theoretical advances in the area

have consolidated different computational models of

argument, paving the way for the development of soft

implementations, specially Argument Assistance Sys-

tems (AAS) (Verheij, 2003). AAS are intended to pro-

vide effective knowledge management facilities when

solving problems in different contexts (legal reason-

ing (Verheij, 2007), organizational knowledge (Brena

et al., 2007), CSCW (Scheuer et al., 2010), etc.).

Several AAS have been developed in the last

years (e.g. Araucaria (Reed and Rowe, 2004),

ArguMed (Verheij, 2003), Compendium (Kirschner

et al., 2003), etc.). As pointed out in (Verheij, 2003),

AAS are to be distinguished from fully automated

reasoning systems; the latter can do complex reason-

ing tasks for the user, whereas AAS’s goal is not to

replace the user’s reasoning, but rather to assist him

as a knowledge management tool for reasoning.

A common element present in all AAS is the Ar-

gument Assistant user interface (AAI), which plays

a key role with respect to the user experience when

interacting with the system. The AAI user’s accep-

tance is directly proportional to its quality, since if

his experience when using the AAI is rewarding, it

will lead to higher productivity and applicability of

the tool. A qualiﬁed AAI is not only the result of an

appropriate surface design of the interaction. It relies

on the achievements of some critical characteristics.

In particular, one of these characteristics is usability,

formed by a set of attributes that bear on the effort

needed for use, and on the individual assessment of

such use, by a stated or implied set of users. Indeed,

some software implementations have explicitly con-

sidered usability features in the AAI design (e.g. the

Hermes system (Karacapilidis and Papadias, 2001),

ArguMED (Verheij, 2003), AVERs (Van den Braak

et al., 2007), among others). However, there are no

standard adopted criteria for assessing the usability of

AAI within the argumentation community.

This paper proposes a set of minimum design

157

Paula González M., Iván Chesñevar C., Pinkwart N. and J. Gómez Lucero M..

DEVELOPING ARGUMENT ASSISTANT SYSTEMS FROM A USABILITY VIEWPOINT.

DOI: 10.5220/0003066801570163

In Proceedings of the International Conference on Knowledge Management and Information Sharing (KMIS-2010), pages 157-163

ISBN: 978-989-8425-30-0

 2010 SCITEPRESS (Science and Technology Publications, Lda.)

guidelines towards usability (DG) instantiated to the

particular domain of AAI. First, key features included

in the most well known AAIs are identiﬁed. Taking

as starting point the most solid factors proposed by

the Usability Engineering approach (Mayhew, 1999),

general mechanisms are added to every feature, thus

providing a set of minimal DG for developing usable

AAS. Some questions are added to every DG in or-

der to clarify its intended meaning in this particular

domain. Furthermore, on the basis of the comparison

between the proposed recommendations and the most

classical usability related questions (e.g. those ques-

tions which help to concretize every general UPs),

traditional usability principles are linked to measure

quality in use of everyDG. Our ﬁnal goal is to help the

design, development and evaluation of usable AAS.

2 ARGUMENT ASSISTANT

SYSTEMS

Argument assistant systems (AAS) (Verheij, 2003;

Van den Braak et al., 2006) have evolved as software

tools which provide an aid for drafting and generat-

ing arguments, assisting the user in his reasoning pro-

cess. This assistance involves several aspects of the

argumentation process (e.g. keeping track of the is-

sues that havebeen raised, assumptions that have been

made, evaluating the justiﬁcation status of the state-

ments involved in the argumentation process, etc.).

More speciﬁcally (Verheij, 2003), AAS are aids to

drafting and generating arguments by a) administer-

ing and supervising the argument process, b) keep-

ing track of the issues that are raised and the assump-

tions that are made, c) keeping track of the reasons

that have been adduced for and against a conclusion,

d) evaluating the justiﬁcation status of the statements

made, and d) checking whether the users of the sys-

tem obey the pertaining rules of argument.

Most AAS provide different kinds of facilities to

support argument diagramming, resulting in “box and

arrow” diagrams and allowing to formulate premises

and conclusions as statements. These are represented

by nodes which can be connected by lines to display

inferences; arrows in such lines indicate the inference

direction. Some AAS provide facilities for displaying

a text ﬁle in natural language, from which arguments

are to be extracted and analyzed. Several AAS cur-

rently exist (Kirschner et al., 2003), among which we

can mention Araucaria (Reed and Rowe, 2004), Ar-

guMed (Verheij, 2003), Compendium (Okada et al.,

2008), and AVERs (Van den Braak et al., 2006).

In spite of their differences (e.g. the intended

application domain), some common features can

be observed in most AAS interfaces (AAI). First,

they convey the representation of some user men-

tal model (i.e., all the cultural and personal-biased

users’ perceptions and assumptions, as well as their

pre-conceptions about how the system is expected

to react), together with the interaction style (i.e., all

the ways the user can communicate or interact with

the software, including both physical and mental ac-

tions). Additionally, AAS offer feedback and sup-

port for the user (related to explicitate the current

system status, helping the user to prevent, recognize,

diagnose, and recover from errors and misuse, e.g.

by means of help and documentation, undo options,

etc.) as well as diverse interoperability facilities (such

as links to multimedia elements). In many cases,

there are also collaborative features associated with

AAS (such as different kinds of awareness, the syn-

chronization, the visualization of shared workspaces,

the communicationmechanisms, the representation of

self and other’s performance and proﬁles, the shared

knowledge , etc.). On the other hand, there are some

common features in AAS interfaces typically associ-

ated with the argumentation process itself. Two cen-

tral features are the visual argument representation

(including the recognition of different types of argu-

ments, their statuses, etc.) and the modeling of con-

ﬂict among arguments which allows the user to recog-

nize the argumentation situation under consideration,

Another feature is the preference criteria associated

with the possibility of visualizing or deducing how

the conﬂict among arguments are resolved.

3 USABILITY PRINCIPLES

Usability is formally deﬁned by ISO 9241-11 as “the

extent to which a product can be used by speciﬁed

users to achieve speciﬁed goals with effectiveness,

efﬁciency and satisfaction in a speciﬁed context of

use”.where the context of use is a description of the

actual conditions under which the interactive system

is being assessed, or will be used in a normal work-

ing situation. Usability Engineering is a systematic

approach to improving the usability of user interfaces

by applying a set of proven methods throughout the

system development lifecycle.

Usability is such a complex concept that has been

divided in a series of measurable principles (also de-

noted usability attributes) in order to be understood in

a better way. Alternative sets of UPs have been pro-

posed, each of them emphasizing different features

present in usability deﬁnition. Also diverse classiﬁca-

tions are proposed when linking them with the formal

deﬁnition. In spite of this situation, nowadays some

KMIS 2010 - International Conference on Knowledge Management and Information Sharing

158

common UPs have been agreed within the major part

of the Usability Engineering community (Constan-

tine and Lockwood, 1999; Dumas and Redish, 2000;

Mayhew, 1999). Consequently, we also have con-

sidered these UPs and this classiﬁcation as the most

relevant for the AAI scope. The most accepted of

those UPs principles are listed below, including some

general questions that have been abstractly deﬁned to

clarify and determine the scope of each one of them:

Effectiveness. How do users deﬁne success? Is suc-

cess the same for all stakeholders? What are

the goals; what are the tasks? Are there hidden

goals?. Can be decomposed in Completeness and

Accuracy.

Efﬁciency. In how many ways the user and system

exchange information?. How long do users ex-

pect a task to take? Is the task completed in a sin-

gle session? What styles of interaction do users

prefer? What would make the interface feel efﬁ-

cient?. Can be decomposed in Flexibility, Speed

and Effort.

Engaging. What kind of work (or play) is this? What

are the expectations for style and tone? How of-

ten? How long? When, where, how and why?.

Can be decomposed in Pleasant and Satisfaction.

Error Tolerance. How familiar is the domain? The

terminology? What will users ﬁnd difﬁcult? What

kinds of errors are likely? How serious are their

consequence? Will the users understand the prob-

lem, or they will need an explanation?. Can be

decomposed in Error Prevention and Recovery.

Easy to Learn. Will users expect to have to learn to

use it? Are they learning something new? How

complex is the task? How often will it be used?

How important is it to get it right?. Can be de-

composed in Predictability, Consistency and Af-

fordance.

4 THE PROPOSAL

As stated before, this paper proposes a set of mini-

mum design guidelines (DG) that should be taken into

account when deploying high qualiﬁed AAI from a

Usability Engineering viewpoint. The main contribu-

tions are summarized in the tables included in Fig. 1

and Fig. 2. First, the key features included at AAIs

were identiﬁed (see Section 2). Following the lessons

learned form Usability Engineering, a minimal set of

DG that should be taken into account when designing

usable AAI were linked to every of the above spe-

ciﬁc key features (see third column in Figs. 1 and 2).

Besides, to minimize the bias and interpretation of a

particular AAS development team, DG related sug-

gestions and recommendations were included, help-

ing to instantiate the proposal to the speciﬁc domain

of AAI (4th column in Figs. 1 and 2). For clarity rea-

sons, some of those recommendations were expressed

as questions, aiming to facilitate their applicability in

future real scenarios. Finally, the information of the

2nd column in Figs. 1 and 2 was contrasted against

the UPs corresponding speciﬁc questions. As a result,

each DG was associated with a set of UPs that should

be considered when evaluating a AAI (either a ﬁnal

version or a prototype). To improve this selection, in

the case of the less novel features (e.g. user mental

model, collaborative features, feedback and support)

UPs presented in practical examples in (Carroll, 2000;

Dumas and Redish, 2000; Gonz´alez et al., 2008a; Sut-

cliffe, 2002) were considered, since these were used

before to test interface features that materialized sim-

ilar DGs as those shown in Figs. 1 and 2. Note that,

even when an alternative development process model

is chosen to cope with the AAI creation, the above

DGs and their corresponding UPs are still to be con-

sidered, being the unique restriction related to its ap-

plicability the inclusion of usability as a key factor

during the AAI life cycle.

5 DISCUSSION

The AAI Design Guidelines presented in the previous

section are a ﬁrst attempt to systematically describe

the factors that constitute usability in the ﬁeld of ar-

gument assistant systems. While the 8 categories and

31 guidelines are, thus, rooted in the relevant research

both in the ﬁeld of usability engineering and in the

AAS ﬁeld, the DGs are still a ﬁrst attempt and will

need further reﬁnement and research. In particular,

the following directions are important.

5.1 Operationalization

While all the DGs we propose are concrete and can

be used to inform system design, some of the aspects

will need a further operationalization in order to sim-

plify the decision if (or to what degree) a guideline

was met. In that respect, note that our proposal com-

bines both qualitative and quantitative approaches to

asses usability. Consequently, some DGs can be oper-

atized by developing usability metrics where a numer-

ical value (or range) is obtained as a ﬁnal result. Part

of this work has been already done, and some of the

DGs in our proposal do contain speciﬁc, measurable

criteria (e.g., VR2, CA2, IO1, and more). However,

DEVELOPING ARGUMENT ASSISTANT SYSTEMS FROM A USABILITY VIEWPOINT

159

Feature DG

Design Guideline (DG) Recommendations Usability Principle

User Mental

Model

UM1 Provide a tool that match both un-

derlying theory and real world

Are the fundamental elements of the underlying theory rep-

resented? How easy and natural is for the user to recognize

each type of element?

Affordance

Easy to Learn

Predictability

UM2 Apply a cross-cultural viewpoint Consider cultural-biased issues when choosing design

patters (cultural-biased metaphors, genre considerations,

iconography, etc.)

Easy to Learn

Engaging

Accuracy

Affordance

UM3 Explicit the domain How domain-oriented is the interface? Does the grade of

generality helping the user to argue? Do the main elements

follow domain-oriented metaphors?

Engaging

Satisfaction

Effectiveness

Interaction Style

IS1 Interaction design should be cho-

sen according to the underlying

theory

Is there coherence between the underlying theory and the

interaction design? In what ways can the user argue? Are

those ways reﬂecting the underlying theory?

Flexibility

Accuracy

IS2 Enhance user control How active should the user be to complete the task? Are the

main User-Centered Design principles followed?

Engaging

Satisfaction

IS3 Look for aesthetic and minimalis-

tic design

Is there irrelevant information included in the dialogues? Are

there unnecessary elements or options cluttering the inter-

face? In what measure is the interface concise and user-

focused?

Predictability

Satisfaction

Affordance

IS4 Minimize technical considera-

tions. Provide high-level actions

and user-oriented language

Are technical restrictions and related issues subordinated to

the user experiences? Is the vocabulary domain-oriented or

plain in all possible situations (labels, menus, alerts, error

screens, help, etc)?

Easy to Learn

Engaging

Efﬁciency

IS5 Do not include unnecessary inter-

action styles

Does the tool impose adequate limits on the ways in which

users can argue? How many styles are supported? Are

those styles necessary?

Engaging

Satisfaction

Error Prevention

Easy to Learn

IS6 Information architecture and in-

teraction design should empha-

size general tool purposes (spe-

cially if the tool is web-oriented)

How is the layout of the tool’s elements in the interface? Are

they grouped following some criterion? Are the conceptual

structures of the tool coherent and efﬁcient? Is the ﬁndabil-

ity

of the tool achieved?

Engaging

Effectiveness

Error Prevention

IS7 Balance conﬁgurable and ﬁxed is-

sues

How conﬁgurable is the interface? Do alternative conﬁgura-

tions help to understand what was happening? How many

different elements can be included in a single view?

Flexibility

Error Prevention

Consistency

Accuracy

Visual Argument

Representation

VR1 Arguments must be clearly repre-

sented

How are arguments visualized? Are there common design

patterns for argument visualization?

Effort

Consistency

Affordance

VR2 Arguments should be easy distin-

guished by the user

Is it easy to recognize different types of arguments (e.g. war-

ranted vs. non-warranted, the user’s arguments from other

arguments, etc.)?

Predictability

Consistency

Easy to Learn

VR3 Argument relevance should be

suggested

Is the relevance of different arguments visualized? (screen

position, visual design, emphasis by size, by colors, etc.)

Predictability

Consistency

Easy to Learn

Conﬂict among

Arguments

CA1 Provide simple mechanisms to

express conﬂict between argu-

ments

What strategies are used to model conﬂict analysis among

arguments? If grade of generality allows more than one do-

main, how transferable are those strategies across the dif-

ferent domains?

Consistency

Easy to Learn

Predictability

CA2 Provide alternative modeling of

the arguing situation currently un-

der consideration

Are different views provided? (e.g. graph view, matrix view,

etc.)

Consistency

Affordance

CA3 Provide different views to allow

bird’s-eye perspective and focal-

ization

Are there mechanisms to zoom in and out? Is it possible to

focalize in a particular part of the view? When zooming in or

out, is the represented situation still understandable for the

user?

Flexibility

Consistency

Easy to Learn

Affordance

Figure 1: Features, design guidelines and related usability principles for developing AAIs.

others do not contain such criteria yet, and in order

to assess the value of the catalogue beyond theoreti-

cal considerations, they will be required (cf. subsec-

tions below). Others DGs will require a more quali-

tative viewpoint to be operatized. In these cases, our

proposalcan rely on datamining-basedmethodologies

like those described in (Gonz´alez et al., 2008b). For

instance, DG UM3 states that an interface should ex-

plicit the domain - but the precise way of measuring

this needs to be deﬁned in order to assess if a speciﬁc

tool adheres with the guideline. As before, further

experimentation will be required (cf. subsections be-

low).

5.2 Empirical Validation of Categories

Another aspect worth discussing are the guidelines

themselves. Backed up by literature in usability re-

search and argumentation, and supported by a reverse

engineering process carried out, it is reasonable to as-

sume that all the DGs in our list are, in fact, support-

ive to AAI usability, and that a tool that adheres to

KMIS 2010 - International Conference on Knowledge Management and Information Sharing

160

Feature DG

Design Guideline (DG) Recommendations Usability Principle

Preference Crite-

ria

PC1 Preference criteria should be

clear enough

Can non-expert users state the preference criteria after us-

ing the tool?

Accuracy

PC2 Allow user changes in preference

criteria

If it is possible to redeﬁne the preference criteria dynami-

cally, how is this visualized? The current view changes radi-

cally when doing this? When changing the preference crite-

ria dynamically, how many single actions are necessaries to

re-calculate the conﬂict between arguments?

Predictability

Efﬁciency

Interoperability

IO1 Interoperability with other AAS

should be supported

Are there import mechanisms? Can arguments from oth-

ers frameworks be captured? Does the tool support cus-

tomized plug-ins for different argumentation domains, tech-

niques, etc.?

Efﬁciency

Predictability

IO2 Multimedia elements should be

supported

Is it possible to link multimedia elements to arguments? (as

evidence / explanation / follow-ups, etc)

Error Prevention

Effectiveness

Satisfaction

Feedback and

support

FS1 Provide feedback regarding con-

ﬂict among arguments

In which form is the user aware about conﬂict between argu-

ments?

Consistency

Easy to Learn

Predictability

FS2 Allow easy reversal of actions Are backward and forward mechanisms provided? How difﬁ-

cult is to do/undo actions? How many single actions (mouse

clicks, opening task bars, etc) are necessaries?

Error prevention

Correctness

Accuracy

FS3 Include help and documentation Are help and documentation easy to search and focused on

the user’s task? Do they list concrete steps to be carried

out?

Error Prevention

Easy to Learn

FS4 Support user minor errors Is the system supporting minor user’s errors and reporting

status when major errors occur?

Error tolerance

Error Prevention

Predictability

Accuracy

FS5 Inform the current status Is the system keeping users informed about what is going

on, through appropriate feedback within reasonable time?

Error Prevention

Efﬁcacy

Correctness

Collaborative Is-

sues (if the AAS

is collaborative)

CI1 Enhance communication mecha-

nisms

In how many ways can users exchange information? Is it

possible to keep the view of the interface (the current dis-

cussion/ the arguments under consideration) when commu-

nicating with others? How easy is to distinguish sent and

received information?

Accuracy

Engaging

Efﬁcacy

CI2 Include alerts regarding collabo-

ration

Is there any mechanism helping me to detect that others are

waiting for my contribution? Can the user distinguish logged

in / logged out users? Can the user send an alert to others?

Completeness

Prevention

Consistency

CI3 Provide an explicit sensor of the

user’s and others’ collaboration

performance

Can the user identify the ownership of other arguments on

the current screen?

Effort

Consistency

Predictability

Affordance

CI4 Distinguish user proﬁles (spe-

cially if the proﬁle deﬁnes part of

the preference criteria, e.g. argu-

ments weighed by user’s exper-

tise)

Are other users’ proﬁles available? Are there any elements

in the current view helping the user to be aware of other’s

expertise? How can the user establish his proﬁle? Can he

change it dynamically?

Accuracy

Consistency

Predictability

CI5 Implement mechanisms to restart

actual state of the task (asyn-

chronous tools)

How difﬁcult is to restart the system’s last state after turning

off it? How many steps are necessaries to do it?

Effort

Consistency

Predictability

CI6 Provide human-oriented aware-

ness

Are there explicit mechanisms to cope with group aware-

ness, social awareness, task-speciﬁc awareness, situation

awareness, objective self awareness and shared knowledge

awareness? How visible and explicit are those mecha-

nisms?

Effort

Effectiveness

Engaging

Satisfaction

Figure 2: Features, design guidelines and related usability principles for developing AAIs (cont.).

all these criteria will achieve high scores in usability

tests. Yet, empirical backup for this argument is re-

quired. It might well be that some of the guidelines

are theoretically valid, but just not important enough

to make a real difference (and thus should be removed

from the list). Or, other factors not contained in the

list may come up in actual system usage in the ﬁeld

(and thus the list needs to be extended). Finally, due

to the complexity and diversity of the AAS domain,

without empirical data we cannot be sure if all DGs

hold for all AAS (e.g., is the guideline IS2 really help-

ful for all possible usage scenarios and domains, or do

some application scenarios beneﬁt from a more pas-

sive user role?). As such, studies which measure the

usability of AAIs and relate this information to each

single item in our list will be required.

5.3 Grounding in Existing Systems

A systematic comparison of existing AAS with re-

spect to the 31 DGs will be highly interesting: do the

tools that are available today fulﬁl the guidelines (and

DEVELOPING ARGUMENT ASSISTANT SYSTEMS FROM A USABILITY VIEWPOINT

161

to which extent)? A prerequisite for this systematic

comparison is the availability of measurable success

and/or fulﬁlment criteria for each single DG. Our hy-

pothesis is that many of the existing tools meet some

of our DGs (e.g., VR1 through VR3 are met by most

systems), but that no currently available tool meets

them all. For some of the DGs, there are actually

quite few tools that fulﬁl them (e.g., CA2). In com-

bination with the empirical backup for the validity of

the guidelines, a systematic comparison of the degree

of DG fulﬁlment for each category will enable us to

ground the DG list in practice and assess the usability

of existing single AAS.

6 RELATED WORK

In the last decade some AAS like Araucaria (Reed

and Rowe, 2004), Compendium (Okada et al., 2008),

AVERS (Van den Braak et al., 2007), Hermes (Kara-

capilidis and Papadias, 2001) or the LASAD Proto-

type (Scheuer et al., 2010) were designed having us-

ability into account. However, they constitute particu-

lar approaches, rather than a systematic reverse engi-

neering process as the one which supports the conclu-

sions reported here. Indeed, to the best of our knowl-

edge, this paper is the ﬁrst to propose usability guide-

lines for designing AAS in a general setting.

Several separate efforts have been made towards

enhancing and assessing usability in AAS. In (Sid-

lar and Rinner, 2007), the authors offer an usability

analysis of Argumaps (Argumentation Maps) to sup-

port participants in geographically referenced debates

as they occurs. Argumaps are based on the combi-

nation of an online discussion forum and an online

geographic information system (GIS) component. In

contrast with our approach, the usability analysis is

focused on this particular tool, not being extensible

to AAI in general. Another example where usability

features f an AAS have been explicitly studied is the

the AVERs system which combines visualizing argu-

mentation and anchored narrative theories. As part

of AVERs development, some features related with

usability were analyzed (Van den Braak et al., 2006;

Van den Braak et al., 2007). Differentindependentex-

periments were reported and critically examined giv-

ing as well methodological recommendations for fu-

ture experiments. The authors stress the importance

of testing “the usability and user-friendliness of the

visualization tool”. However, (Van den Braak et al.,

2006; Van den Braak et al., 2007) are not focused

on generalizing usability but rather on describing the

effects of AAS tools use on an user’s argumentation

skills. In (Mu˜noz et al., 2009), the authors propose the

materialization of a complete argumentation system

ready to be built in conventional agent software plat-

forms. In contrast with our work, the focus here is on

making theoretical argumentation usable for software

engineers, not being involved with the development

and assessment of AAI.

7 CONCLUSIONS AND FUTURE

WORK

Argument Assistant Systems (AAS) are one of the

most promising software products emerging from the

maturity of argumentation technologies. Their suc-

cess relies partly upon the possibility of offering

a way of solving sense-making problems in terms

which are natural and easy to understand for human

beings as end users (arguments, conﬂicts among ar-

guments, etc.). In this paper we have presented a ﬁrst

approach towards standardization of usability for the

development of AAS. After identifying relevant fea-

tures common to the AAS interfaces, we have pro-

posed a minimum set of design guidelines that should

be taken into account when designing and testing such

interfaces from an Usability Engineering viewpoint.

By means of a series of questions and recommenda-

tions, the guidelines were instanciated to focus on the

particular domain of AAS. Different usability princi-

ples were identiﬁed and associated with every sug-

gested guideline to evaluate its quality in actual AAS

interfaces, ranging form early prototypes to fully im-

plemented ﬁnal versions.

The consolidation of argumentation technologies

has recently led to the deﬁnition of standards for ar-

gument exchange (notably the Argumentation Inter-

change Format AIF (Ches˜nevar et al., 2006)). We

think that in the near future similar standards will

be required concerning usability of AAS, establish-

ing uniform criteria for its assessment and evaluation.

Future work includes the performance of alternative

full usability evaluation that will help to validate

and improve the set of minimal DG currently iden-

tiﬁed, as well as the corresponding UPs. In particu-

lar, recently a novel usability evaluation methodology

called QUTC

KDD

has been characterized (Gonz´alez

et al., 2008b), providing a datamining-based tech-

nique for detecting common usability problems of

particular contexts of use. The application of such

kind of approaches to characterize most relevant us-

ability problems of the speciﬁc domain of AAS is cur-

rently under consideration.

KMIS 2010 - International Conference on Knowledge Management and Information Sharing

162

ACKNOWLEDGEMENTS

This paper was partially funded by CONICET (Ar-

gentina) and Projects PIP-CONICET 112-200801-

02798 (Argentina), CICYT TIN2008-06596-C02-01

(Spain), and LASAD Project (DFG and TU Clausthal,

Germany).

REFERENCES

Brena, R., Aguirre, J., Ches˜nevar, C., Ram´ırez, E., and Gar-

rido, L. (2007). Knowledge and information distribu-

tion leveraged by intelligent agents. Knowl. Inf. Syst.,

12(2):203–227.

Carroll, J. (2000). Making Use:Scenario-Based Design of

Human-Computer Interactions. MIT Press.

Ches˜nevar, C., McGinnis, J., Modgil, S., Rahwan, I., Reed,

C., Simari, G. R., South, M., Vreeswijk, G., and Will-

mott, S. (2006). Towards an argument interchange for-

mat. Knowledge Eng. Review, 21(4):293–316.

Constantine, L. and Lockwood, L. (1999). Software for

Use. A practical Guide to the Models and Methods

of Usage-Centered Design. Addison-Wesley.

Dumas, J. and Redish, J. (2000). A Practical Guide to Us-

ability Testing. Intl. Specialized Book Service Inc.

Gonz´alez, M., Granollers, T., Pascual, A., and Lores, J.

(2008a). Testing website usability in spanish-speaking

academia through heuristic evaluation and cognitive

walkthroughs. Int. Journal of Universal Computer

Studies, 14(9):1513–1529.

Gonz´alez, M., Lor´es, J., and Granollers, T. (2008b). En-

hancing usability testing through datamining tech-

niques: A novel approach to detecting usability prob-

lem patterns for a context of use. Information & Soft-

ware Technology, 50(6):547–568.

Karacapilidis, N. and Papadias, D. (2001). Computer sup-

ported argumentation and collaborative decision mak-

ing: the hermes system. Inf. Syst., 26(4):259–277.

Kirschner, P., Shum, S. B., and (Eds), C. C. (2003). Visu-

alizing Argumentation: Software Tools for Collabora-

tive and Educational Sense-Making. Springer-Verlag.

Mayhew, D. J. (1999). The Usability Engineering Lifecicle.

A practioner’s handbook for user interface desing. M.

Kaufmann.

Mu˜noz, A., Sanchez, A., and Botia, J. A. (2009). A

software architecture for an argumentation-oriented

multi-agent system. Advances in Intelligent Soft Com-

puting, 55:197– 206.

Okada, A., Shum, S. B., and (Eds.), T. S. (2008). Knowl-

edge Cartography: Software Tools and Mapping

Techniques. Springer: Advanced Information and

Knowledge Processing Series.

Rahwan, I. and Simari, G. (2009). Argumentation in Artiﬁ-

cial Intelligence. Springer-Verlag.

Reed, C. and Rowe, G. (2004). Araucaria: Software for

argument analysis, diagramming and representation.

Int. Journal on AI Tools, 13(4):983–.

Scheuer, O., Loll, F., Pinkwart, N., and McLaren, N. (to

appear 2010). Computer-supported argumentation: A

review of the state-of-the-art. Int. Journal CSCL, 5(1).

Sidlar, C. and Rinner, C. (2007). Analyzing the usability of

an argumentation map as a participatory spatial deci-

sion support tool. The Urban and Regional Informa-

tion Systems Association Journal, pages 47–55.

Sutcliffe, A. (2002). User-Centred Requirements Engineer-

ing. Theory and Practice. Springer–Verlag.

Van den Braak, S., van Oostendorp, H., Prakken, H., and

Vreeswijk, G. (2006). A critical review of argument

visualization tools: Do users become betterreasoners?

In Grasso, F., Kibble, R., and Reed, C., editors, Work-

shop on Computational Models of Natural Argument.

ECAI 06, page 6775, Riva del Garda, Italy.

Van den Braak, S., Vreeswijk, G., and Prakken, H. (2007).

AVERs: an argument visualization tool for represent-

ing stories about evidence. In Proc. of the 11th ICAIL

Conf., pages 11–15.

Verheij, B. (2003). Artiﬁcial argument assistants for defea-

sible argumentation. Artif. Intell., 150(1-2):291–324.

Verheij, B. (2007). Argumentation support software:

Boxes-and-arrows and beyond. Law, Probability &

Risk, 6:187–208.

DEVELOPING ARGUMENT ASSISTANT SYSTEMS FROM A USABILITY VIEWPOINT

163