Proceedings V Simpósio sobre Fatores Humano em Sistemas Computacionais Fortaleza, 7-10 de outubro de 2002

Transcrição

1 Proceedings V Simpósio sobre Fatores Humano em Sistemas Computacionais Fortaleza, 7-10 de outubro de 2002 "Usabilidade, um direito" Chairs (Coordenadores) Elizabeth Furtado, UNIFOR - Universidade de Fortaleza Jair C. Leite, UFRN - Universidade Federal do Rio Grande do Norte

2

3 Proceedings V Symposium on Virtual Reality October Fortaleza, Ceará, Brazil Edited by Creto Augusto Vidal Cláudio Kirner Sponsored by Brazilian Computer Society (SBC) Brazilian National Council for Reserarch (CNPq) Brazilian Commission for Higher Education (CAPES) Printed by BNB Fortaleza, Ceará, Brazil

4 Copyright 2002 by the Brazilian Computer Society All rights reserved SBC Brazilian Computer Society Symposium on Virtual Reality (5.:2002:Fortaleza, CE, Brazil) [Proceedings] / 5 th Symposium on Virtual Reality; edited by Creto Augusto Vidal, Cláudio Kirner. Fortaleza: SBC, xxxp. ISBN xx-xxxxx-xx-x 1.Virtual Reality. I Vidal, Creto Augusto. II. Kirner, Cláudio. III. SVR (5.:2002).

5

6 Table of Contents (SUMÁRIO) Preface (APRESENTAÇÃO)...IX Comittees (COMITÊS)...X Reviewers (REVISORES)...XI Brazilian Computer Society (SOCIEDADE BRASILEIRA DE COMPUTAÇÃO)...XII PAPERS (ARTIGOS COMPLETOS) Participation and Signification: Towards Cooperative System Design Cecilia Baranauskas, Rodrigo Bonacin, Kecheng Liu...03 Using the Underlying Discourse Unveiling Method to Understand Organizations of Social Volunteers Clarissa M. de A. Barbosa, Raquel Prates, Clarisse Sieckenius de Souza, Ana Maria Nicolaci-da-Costa...15 Modelo de Interação como Ponte entre o Modelo de Tarefas e a Especificação da Interface Simone Barbosa, Clarisse Sieckenius de Souza, Maíra Greco de Paula, Milene Selbach Silveira...27 Evaluating Usability of Information Visualization Techniques Carla M.D.S. Freitas, Paulo R.G. Luzzardi, Ricardo A. Cava, Marco Winckler, Marcelo S. Pimenta, Luciana Nedel...40 Considering Human Factors in Workflow Development Lucinéia Thom, Cirano Iochpe, Ida Gus...52 The Bifocal Tree: a Technique for the Visualization of Hierarchical Information Structures Ricardo A. Cava, Paulo R. G. Luzzardi, Carla M. D. S. Freitas...61 The Definition of an End-User Programming Language for Extensible Applications Sérgio Roberto Pereira da Silva, Clarisse Sieckenius de Souza...72 An Environment to Support Developers in Elaborating a Participatory and Evolutionary Help on Style Guide Elizabeth Sucupira Furtado, Kênia Sousa e César Colera...84 Uma extensão da LEMD e sua integração com a WAE/UML no Design de Sistemas Web Multimídia Antonio Almeida, Jair C. Leite...93 Sistemas de Reputação: Arquitetura, Propriedades e Desafios Bruno Dias Abrahão, Fernando Caixeta Sanches, Wagner Meira Jr Design de Sistemas de Ajuda Online baseado em Modelos Milene Silveira, Clarisse Sieckenius de Souza, Simone Diniz Junqueira Barbosa Analysing Influences of Context in a Game-mediated Collaboration Marcos Augusto Francisco Borges, M. Cecília C. Baranauskas Implementação de Técnicas de Interação no Presenta - Um software para edição de apresentações na Web Lirisnei Sousa, Elton Santana, Jair C. Leite...141

7 Scalable Vector Graphics como Ferramenta para Construção de Interfaces Baseadas em Zoom Contínuo Carlos Carneiro, Gabrielle D'Annunzio Cavalcanti, José Bezerra da Silva Filho, Pedro Porfírio M. Farias Uma Interface Visual para a Elaboração de Consultas em uma Ferramenta baseada no Modelo ERC+ Clodis Boscarioli, Laura Sánchez García, Marcos S. Sunye Um Modelo para Criação de Ferramentas de Apoio a Testes de Usabilidade de Interfaces Marcelo Oliveira, Ana Cristina Bicharra Garcia Metodologia de Aprendizagem a Distância de Recomendações Ergonômicas Contextualizadas em Casos de Uso Flávio Vieira, Elizabeth Furtado Desenvolvimento de Material Instrucional de Qualidade para EAD Segundo Princípios Cognitivos Rafael Orbolato, Vânia P. de Almeida, Júnia C. A. Silva Desenvolvimento da Interface de um Software Educacional com base em Interfaces de Jogos André Luiz Battaiola, Nassim Chamel Elias, Rodrigo de Godoy Domingues, Rodrigo Assaf, Geber Lisboa Ramalho Aprendizagem Online: ferramentas de comunicação para colaboração Janne Oeiras, Heloísa Vieira da Rocha Uso de agentes de interface para adequação de bate-papos ao contexto de educação a distância José Vahl Júnior, Janne Yukiko Yoshikawa Oeiras Heloísa Vieira da Rocha Uso de Agentes de Interface no Suporte à Análise de Sessões de Bate-Papo Ricardo Luís Lachi, Joice Lee Otsuka, Heloisa Vieira da Rocha Software Educacional e Diálogo Entre Usuários: Um Modelo de Avaliação Flavia Peres, Luciano Meira Construindo Significados para o Espaço Infantil na Internet: a Criança como Parceira Maria Cecília Calani Baranauskas, Amanda Meincke Melo Investigando a Interação de Crianças no Estágio Piagetiano Operatório-Concreto com Sites Infantis Juliano de Vargas Bittencourt, Marcelo Soares Pimenta Uma outra história da leitura Cristina Gislene Leiria ARFDIU - Um método para integrar análise de requisitos funcionais com o design de interfaces de usuários Tatiana Tavares, Jair C Leite Web accessibility guidelines and policies Claudia Gislene Dias A (in)acessibilidade de sites governamentais Marcelo S. Pimenta, Tito Lívio Castro, Daniel M. Viero, Lauro Nakayama, Andrea P. Cavalheiro, Michele Frighetto, Evandro M. Miletto, Roberto Cabral M. Borges...336

8 SHORT PAPERS (ARTIGOS RESUMIDOS) O Desafio de Prover Ambientes para EUP e Realidade Virtual com Usabilidade Fernando Cesar Balbino, Junia Coutinho A. Silva, Rosângela A. D. Penteado CollabSS - Sistema para apoio on-line à colaboração Marcos Borges, M. Cecilia C. Baranauskas Redação técnica e produção de software: uma relação interdisciplinar Cláudia Macedo, Evanir Brunelli Editor para Língua de Sinais Escritos em SignWriting Rafael Torchelsen, Antônio Carlos R. Costa, Graçaliz P. Dimuro Uma Camada de Interface Adicional para Mecanismos de Busca Luiz Gheller, Marcelo Soares Pimenta Rumo a uma Abordagem Teleológica para Construção de Cenários e Casos de Uso Roberto Vedoato, Marcelo Soares Pimenta itaos: A Graphical Tool to Support User's Task Description in UI Design Context Francisco Medeiros, Bernardo Lula Júnior, Pedro Barbosa Cordeiro Mapeamento de Interfaces WIMP para Interfaces Web Claudio Martins, Marcelo Soares Pimenta, Ana Maria Alencar Price POSTERS Natural Language communication via AIML Plus Chatterbots Flavia Barros, André M.M. Neves, Isabelle Diniz Eu falo português. E daí? Rachel Aires, Sandra Maria Aluísio Avaliando um sistema de operação de rede externa Marcos Borges, Sonia Mayumi Kutiishi, Anderson Delcio Parreira, Júlio Cesar Burjato Uma Ferramenta para Avaliação de Usabilidade de Aplicações para Web Fernando Itakura, Silvia Regina Vergilio Squeak Alice em Português: identificando nomes para movimentos de rotação em 3D Antonio Barros...390

9 Preface (APRESENTAÇÃO) Bem-vindos ao IHC V Simpósio sobre Fatores Humanos em Sistemas Computacionais. É com imensa satisfação que apresentamos os Anais desta quinta edição do IHC, realizado em Fortaleza, de 07 a 10 de outubro de O IHC 2002 é um dos eventos integrantes do IMIGRA 2002 que inclui o SIBGRAPI 2002, o SBMIDIA 2002 e o SVR O IHC - Simpósio sobre Fatores Humanos em Sistemas Computacionais é um evento anual promovido pela Sociedade Brasileira de Computação, através da sua Comissão Especial em Interação Humano-Computador, que visa promover o encontro de professores pesquisadores, estudantes e demais profissionais para divulgar e discutir estudos, projetos de pesquisa e experiências acadêmicas e profissionais na área de Interação Humano-Computador. O IHC 2002 mantém a sua característica multidisciplinar envolvendo participantes da ciência da computação, da psicologia, da ergonomia e várias outras disciplinas no estudo, no desenvolvimento e na avaliação de sistemas computacionais interativos que satisfaçam as necessidades dos seus usuários. Estes anais contêm 42 trabalhos submetidos pela comunidade de IHC do Brasil e do exterior, selecionados após rigoroso processo. Os artigos completos, com até 12 páginas, trazem contribuições técnico-científicas para a área de IHC. Os artigos resumidos, com no máximo 4 páginas, relatam pesquisas em andamento, relatórios de experiências práticas, demonstrações de produtos ou ferramentas, entre outros. Foram submetidos 106 trabalhos, sendo que 62 foram submetidos para a categoria artigos completos e 44 para a categoria artigos resumidos. Os processos de submissão e avaliação ocorreram em duas etapas. Na primeira etapa, os 62 artigos completos submetidos foram avaliados por pelo menos 3 revisores de um total de 34 revisores. Após a analise dos resultados dos revisores, o Comitê de Programa decidiu pela seleção de 29 artigos completos. Todos os autores receberam os comentários dos revisores e tiveram um prazo para atender as suas exigências. Na segunda etapa, iniciada após a conclusão da primeira, os 44 artigos resumidos foram submetidos após um rigoroso trabalho de revisão no qual cada artigo foi avaliado também por 3 revisores. Foram selecionados 8 artigos para publicação na íntegra nestes anais. Outros 5 artigos foram selecionados para apresentação como Poster e têm seus resumos apresentados nestes anais. O IHC 2002 traz para Fortaleza dois pesquisadores de renome internacional. O Professor Jean Vanderdonckt com a palestra "Uma ferramenta para geração de interfaces de usuário para múltiplas plataformas" e o Professor Phillipe Palanque com a palestra "Processo de desenvolvimento de interfaces de usuário a partir de especificações formais". Além das palestras convidadas, o evento conta com dois tutoriais. O tutorial avançado, "Elementos Aplicados da Teoria da Cor", apresentado pela Profa. Luciana Marta Silveira é destinado a professores, pesquisadores e estudantes de pós-graduação. O tutorial introdutório "Por que estudar IHC? Introdução aos fundamentos, aplicações, metodologias e desafios", apresentado pela Profa. Heloísa Vieira da Rocha é destinado a estudantes de graduação e ao público do IMIGRV. Na sua curta história de 5 anos, o IHC tem atingido seus objetivos de atrair pesquisadores, professores, estudantes e profissionais da área para discutir e apresentar resultados de trabalhos técnicocientíficos. A partir deste ano, o IHC, anteriormente chamado de Workshop, passou a ser denominado de Simpósio. Esta denominação reflete de maneira mais precisa os rigores utilizados na sua organização, no processo de revisão e seleção dos trabalhos submetidos e na escolha das palestras e convidados, que são equivalentes aos de outros simpósios promovidos pela Sociedade Brasileira de Computação. O nosso principal desafio é manter a tendência de crescimento e o nível de qualidade que o IHC vem conquistando nestes cinco anos. Gostaríamos de agradecer ao Comitê de Programa pelo excelente trabalho de revisão de todos os artigos submetidos e na elaboração da programação do IHC2002. Agradecemos também o apoio da Sociedade Brasileira de Computação na promoção deste evento. Um agradecimento especial todos os que trabalharam na organização deste evento e o apoio financeiro da Universidade de Fortaleza, do Instituo Atlântico, da CAPES e do CNPq. Jair C. Leite Coordenador do Comitê de Programa Elizabeth Furtado Coordenadora de Organização

10 Comittees (COMITÊS) Organization Comittee (COMITÊ ORGANIZADOR) Elizabeth Furtado (UNIFOR) - Organization Chair Programa Comittee (COMITÊ DE PROGRAMA) Jair C. Leite (UFRN) - Program Chair Afonso Orth (PUCRS) Ana Maria Nicolaci (PUC-Rio) Antonio Carlos dos Santos (UFSCar) Bernardo Lula (UFPB) Clarisse Sieckenius de Souza (PUC-Rio) Elizabeth Furtado (UNIFOR) Fatima Vieira (UFPB) Heloisa Vieira da Rocha (UNICAMP) Leland McCleary (USP) Marcelo Soares Pimenta (UFRGS) Maria Cecilia Calani Baranauskas (UNICAMP) Raquel Oliveira Prates (UERJ) Renata Vieira (UNISINOS) Sergio Silva (UEM) Simone Diniz Junqueira Barbosa (PUC-Rio) Suely Fragoso (UNISINOS) Walter Cybis (UFSC)

11 Jair C Leite Afonso Orth Ana Maria Nicolaci Antonio Carlos dos Santos Bernardo Lula Clarisse Sieckenius de Souza Elizabeth Furtado Fatima Vieira Heloisa Vieira da Rocha Junia A C Silva Leland McCleary Luciano Gamez Marcelo Morandini Marcelo Soares Pimenta Marco Winckler Maria Cecilia Calani Baranauskas Maria Cristina Ferreira de Oliveira Maria da Graca Pimentel Maria das Graças Volpe Nunes Mauro Madeira Raquel Oliveira Prates Regina Borges de Araujo Renata Fortes Renata Vieira Richard Faust Sandra Aluísio Sergio Crespo Sergio Silva Simone Diniz Junqueira Barbosa Suely Fragoso Soraia Musse Tatiana Tavares Viviane Todt Diverio Walter Cybis Reviewers (REVISORES)

12 Brazilian Computer Society (SOCIEDADE BRASILEIRA DE COMPUTAÇÃO) DIRETORIA Presidente Flávio Rech Wagner (UFRGS) Vice-Presidente Luiz Fernando Gomes Soares (PUC-Rio) Administrativa e Finanças Taisy Silva Weber (UFRGS) taisy@inf.ufrgs.br Eventos e Comissões Especiais Ana Teresa de Castro Martins (UFC) ana@lia.ufc.br Educação Marcos José Santana (USP - São Carlos) mjs@icmc.sc.usp.br Publicações Claudia Maria Bauzer Medeiros (UNICAMP) cmbm@ic.unicamp.br Planejamento e Programas Especiais Robert Carlisle Burnett (PUC-PR) robert@ppgia.pucpr.br Secretarias Regionais Aleardo Manacero Jr. (UNESP - São José do Rio Preto) aleardo@dcce.ibilce.unesp.br Divulgação e Marketing Sérgio Cavalcante (UFPE) svc@cin.ufpe.br Regulamentação da Profissão Roberto da Silva Bigonha (UFMG) bigonha@dcc.ufmg.br Eventos Especiais Ricardo de Oliveira Anido (UNICAMP) ranido@ic.unicamp.br

13 CONSELHO Mandato Ana Carolina Salgado (UFPE) Paulo Cesar Masiero (USP/São Carlos) Rosa Maria Vicari (UFRGS) Sergio de Mello Schneider (UFU) Tomasz Kowaltowski (UNICAMP) Mandato Daltro José Nunes (UFRGS) Silvio Romero de Lemos Meira (UFPE) José Carlos Maldonado (USP/São Carlos) Therezinha Souza Costa (PUC-Rio) André Carlos P. de Leon F. de Carvalho (USP/São Carlos) Suplentes - Mandato Itana Maria de Souza Gimenez (UEM) itana@din.uem.br Jaime Simão Sichman (USP) jaime@pcs.usp.br Miguel Jonathan (UFRJ) jonathan@nce.ufrj.br Raul Sidnei Wazlawick (UFSC) raul@inf.ufsc.br

14 COMISSÃO ESPECIAL DE INTERAÇÃO HUMANO-COMPUTADOR Jair C Leite (UFRN) - Coordenador Elizabeth Furtado - Coordenador Adjunto SECRETARIAS REGIONAIS Nordeste 1 Riverson Rios (UFC) Nordeste 2 Jair C Leite (UFRN)

15 PAPERS (ARTIGOS COMPLETOS)

16

17 Participation and Signification: Towards Cooperative System Design M. Cecilia C. Baranauskas 1,3, Rodrigo Bonacin 1, Kecheng Liu 2 1 Institute of Computing, State University of Campinas Caixa Postal Campinas, SP - Brazil 2 Department of Computer Science, University of Reading, Whiteknights, 3 Visiting Fellow at the Department of Computer Science, University of Reading. Reading RG6 6AY, UK {cecilia,ra000470}@ic.unicamp.br, K.Liu@reading.ac.uk Abstract. Although participatory techniques are useful instruments to capture the social context of the workers by their active participation, in traditional approaches to system design, it is ultimately the designers interpretation of these practices that are usually expressed in representations that lead to the final system. In this paper we propose to combine techniques from Participatory Design with methods from Organizational Semiotics as a way of enabling mutual learning among users and designers of the system. We illustrate the symbiosis between participation and signification with some aspects of the design of Pokayoke: a system proposed to support problem solving and decision making in the context of a manufacturing organization. Keywords. Participatory Design, Organizational Semiotics, Domain-Oriented Application 1. Introduction The design of computer applications that enhance not only the quality of products, but mainly the quality of work practices has been one of the main focuses of the Participatory Design (PD) approach. Active cooperation between users and designers has long been advocated by the PD practitioners, and many research has been conducted in establishing meaningful and productive interactions among those directly in charge of technology design and use [Schuler and Namioka, 1993]. Work has fundamentally a social nature, and critical aspects of it are often poorly addressed in traditional system development [Kyng 1991]. Therefore, we start with the view that to design a computer system that is part of human working environment, we must understand the social context of the organization in which the work is carried out. Meaning is constructed as a result of cooperation between designers and workers (prospective users of the technology). Organizational Semiotics (OS), a branch of Semiotics which understands the whole organization as a semiotic system, aims to study organizations using concepts and methods from Semiotics [OSW 1995]. OS understands that each organized

18 behavior is affected by the communication and interpretation of signs by people, individually or in groups. As a doctrine of signs, Semiotics encompasses several disciplines, facilitating our understanding about the ways people use signs for every type of purposes. Organizational Semiotics considers the internal work of the organization, including its information systems and its interactions with the environment, aiming at finding new ways of analyzing, describing and explaining the structure and behavior of the organization. The studies in OS are not restricted to information expressed in written or graphical discourse, but take into account the semiotic aspects of the human working behavior in the organization. Concerning the design and development of computer systems to be used in organizations, we argue that PD and OS could benefit of each other. From the perspective of PD, methods and formalisms of OS could be useful in the transition from what is learned from studies of work practices to the design of the IT system. From the perspective of OS, PD techniques can be useful in promoting direct and continued interaction between professional designers and those who use the technology in their work, ultimately the arbiters of system adequacy. In this paper we will present some of the methods and formalisms of OS that are useful to support mutual learning during the domain modeling process. This presentation will be illustrated with results of participatory practices conducted in the development of Pokayoke: a system aimed at supporting discussion and decisionmaking in the context of a lean production manufacturing organization. The paper is organized as follows: we begin by presenting the work context addressed. Next we present the main concepts and methods of OS and the ontology chart as a tool for cooperative construction of meaning, illustrating it in the addressed context. Finally we discuss some findings and point out the next derived steps in designing the system 2. Designing for the Context of a Production Organization The traditional approaches to IT development present a strict separation between design, implementation and use of the system. These approaches assume that there exists a common conceptual model of the domain, shared by all practitioners and the problem is to identify this model and codify it. However, several authors acknowledge the fact that shared domain models do not de facto exist but instead are socially constructed over time by communities of practice [Fischer et al. 1995, Kyng 1991, Lave and Wenger 1990]. Khun (1996) examines the ways in which designers and users can reshape the design and implementation of advanced manufacturing technology. He proposes human-centered design which puts human, social and organizational considerations on equal footing with technical considerations in the design process, seeing end users (operators, engineers, administrators) as central to an effective manufacturing system. According to this approach, well-designed technology should make use of human strengths such as skill, experience, judgment, capacity for learning, to create a robust and flexible production system, rather than seek to minimize and control human intervention. Kyng [1991] adopts the term mutual learning to stress the fact that both domain practitioners and system developers must engage in a process of communication to construct an initial model of the domain rooted in the practice, and to evolve it as each part learn more. Mutual learning implies that designers learn about the application

19 domain and practitioners learn about the new possibilities brought by the technology. We claim that the interaction between the participants could be understood in terms of semiotic relations established among them, as they develop and share a common sign system. In this paper we propose to extend this paradigm of design for the workplace, aiming to show how the design of information systems can be approached cooperatively by professional designers and personnel of the workplace. It recognizes and presupposes the necessity of mutual learning between the parts involved. By focusing on PD and OS, we hope to contribute with ideas on what design for cooperation in the workplace could be and what roles it could play within the organization. Participatory Design, an approach developed initially in the northern Europe, uses a variety of techniques to carry design with the user, rather than for the user. In Participatory Design, the users have direct interaction with designers in the overall cycle of development, having a degree of control over design decisions. The recognized value in this active participation of the worker is totally in line with the role the employees play in lean production organizations. The former predominant values of product quality and work productivity are enhanced by broadened participation and skill development, under the premises that these values are closely related. The approach to design we present here is inline with the practice of lean production methodologies, as it aims at facilitating and stimulating collaboration among different categories of workers in the organization (engineers, operators, administrators), in problem-solving and decision-making. The context of discussion in this paper is a project we are conducting [Nied 1997,2000], involving a multinational company that manufactures components of automotive systems. This organization applies the lean production philosophy to manufacturing. Differently from the mass production, the main characteristics of the lean production include the distribution of decision-power among the personnel, the incentive to teamwork and a more dynamic role for the shop floor workers. Together, these ideas propose that people from different organizational levels including shop floor workers should discuss and create solutions to problems in the factory routine in a collaborative way. This project establishes a cooperative relationship between a research group at the University and workers in the Factory, towards the design of technological artifacts to support collaborative discussion and problem solving. The project allows the group to experience the mutual learning and to put into practice theoretical and conceptual ideas about design and IT development in a real context. In this perspective, we understand design as being situated in the praxis of the community in which mutual learning takes place, and cooperative design is the outcome of this process. In this paper a new approach rooted in participatory practices and semiotic basis is proposed as a way of supporting users and designers in applying their knowledge and experience to design the system.

20 3. Organizational Semiotics: Principles and Practices Complementary to PD techniques we need a formal methodology, which is inline with the social understanding of an organization, to model it. For this we are drawing on Organizational Semiotics, which is defined as the study of organization using the concepts and methods of semiotics [OSW 1995]. The central concept of Semiotics is semiosis, which the Peircean School of Semiotics [Peirce ] defines as the action of the sign, i.e. the process in which the sign has a cognitive effect on its interpreter. A sign, or representamen, is something that stands to somebody for something (its object) in some respect or capacity. The equivalent sign created in the mind of the interpreter is called the interpretant of the first sign. Since a sign creates an interpretant, which in turn is the representamen of a second sign, semiosis results in a series of successive interpretants called unlimited semiosis. By signification we mean the final interpretant, i.e. the effect produced by the sign on the interpreter; it is the interpretative result an interpreter achieves if the sign is considered. Figure 1 illustrates the basic concepts involved in a semiosis. Figure 1. Semiosis as a process of signification There are four characteristics for describing semiosis. Firstly, it is universal. It is applicable to any type of sign-processing activity. Secondly, semiosis is a process capable of identifying anything present according to a specific criterion or a norm. Thirdly the process of representation can be recursive: a sign can be seen as an object in another sign-process, just as an interpretant or an object can be a sign. This will lead to its fourth characteristic, which is the subject-dependency. It is closely related to the interpreter who can be an individual, a group or a social community with certain knowledge and obeying certain norms. A semiosis process is always partial in representation of the object and subjective in interpretation, depending on the viewpoint of the interpreter, and the knowledge and ability s/he possesses. Literature has shown different paradigms underlying methodologies for system design and development. The philosophical instance underlying OS is the radical subjectivism [Liu 2000]. In this paradigm reality is seen as a social construction based on the behavior of agents participating on it. In this context, people share a pattern of

21 behavior governed by a system of norms. As people are constantly communicating and discussing, the world is in constant change. The two basic axioms upon which the OS methodologies are founded can be expressed as: there is not knowledge without a knower, and there is not comprehension without action. 3.1 Some Methods of Organizational Semiotics: Semantic and Norm Analyses Semantic Analysis (SA) focuses on the agents and their pattern of behaviors to describe the organization. Some basic concepts of SA adopted in this paper based in Liu (2000): The world is socially constructed by the actions of agents, on the basis of what is offered by the physical world itself; Affordance, the concept introduced by Gibson (1979) can be used to express the behavior of an organism made available by some combined structure of the organism and its environment; Agent can be defined as something that has responsible behaviour. An agent can be an individual person, a cultural group, a language community, a society, etc. (an employee, a department, an organization, etc.); An ontological dependency is formed when an affordance is possible only if certain other affordances are available. Semantic Analysis comprehends four major phases: the first phase is the problem definition, where a description of the problem is written and the problem is studied. In the second phase designers analyze the material of the first phase to identify affordances, possible agents and other relationships. At the third phase designers group the concepts and categorized them and connect them in small groups (small ontology charts), to represent the dependency between the concepts. At the last phase the ontology chart, a graphical representation of the semantic analysis is constructed. A norm analysis is usually carried out on the basis of the result of the semantic analysis [Liu 2000]. The semantic model delineates the area of concern of an organization and identifies the basic patterns of behavior (affordances). The norms describe how an agent can judge the situation and take actions. Through Norm Analysis we can represent the agents behavior in the pragmatic and social levels of the semiotic framework. The pragmatic level is concerned with the relationships between an intentional use of signs and the resulting behavior of responsible agents in a social context. The social level includes beliefs, expectations, commitments, contract, law, culture, as well as business. Norms corresponds at the social level to the idea of an affordance at the individual level [Liu et al. 1997]. They can be seen as collective affordances of complex agents (e.g. organizations, governments, departments, cultural groups, etc.) at the social level. The norm analysis can be performed in four steps. The first step refers to the responsibility analysis, carrying out detailed descriptions of the responsibility, authority and the respective actions of agents. The second step is the proto-norm analysis where the circumstances that an action may, must or must not be performed by the agents are specified. The third step is the trigger analysis where the relation between the time and the actions is modeled to construct a schedule for the actions. The fourth step is the

22 detailed norm specification where the norms are fully specified in both natural and formal language Using Participatory Techniques to Inform Semantic Analysis Participatory techniques can contribute during the four phases of the semantic analysis in different ways. We have investigated how some of these techniques can complementarily support the tasks in the phases of the semantic analysis. Below we describe briefly some PD techniques [Muller 1997] showing how they can inform the semantic analysis in modeling the organization. Starting Conference. It is a meeting of participants of multiple levels and roles in the organization, in which they analyze the current work methods and discuss possibilities for improvement. Results of this activity inform mainly the first phase of the semantic analysis (problem identification) generating a description that contains the basic agents, affordances and the ontology dependencies that feed the next phases. It also contributes to a preliminary description of the objectives of the system. This technique can be used for a first stage of modeling, capturing concepts of the technical, formal and informal layers of the organization. HOOTD (Hierarchical Object-Oriented Task Decomposition). In this technique, the workers decompose their task into objects and action, and assign groups for these objects. All participants write objects and action in cards in a parallel way, and after that, the entire group manipulates them. This technique is usually carried out with the aim of designing interface windows, but this method is also useful to understand the dependency relations between agents and affordances and their grouping, contributing to the candidate grouping and ontology charting phases. Using this technique the designer can analyze formal and informal dependencies and hierarchical grouping of agents and affordances. Icon Design Game. One of the participants (member of the workgroup) makes drawings to represent concepts and shows to the group who has to identify and discuss the representation. This technique concerns the identification of better representations for work related concepts. It addresses the design of interface icons, but this method can also be used to identify the meanings the workgroup assigns to the signs used in the semantic analysis and to identify the adequate text representation for the concepts in the ontology chart. This technique contributes especially to the generation of candidate affordances and to the first part of the candidate grouping. Using this technique the designer can construct a better understanding of the meaning of signs for the workgroup. 3.3 Using Participatory Techniques to Inform Norm Analysis The norms are results of the behavior of agents in a social level; therefore, to model norms we should capture aspects of the agents behavior in their social context. PD techniques can be useful for capturing the behavior and the social context of an organization, through activities the workers can share their knowledge and provide feedback about the designers understanding of the work place. Some participatory techniques inform the norm analysis in different ways, as illustrated below: Starting Conference. This technique can contribute to identifying the main norms, to discuss specific norms and to eliminate doubts about how to model specific

23 aspects of them. Using the starting conference the designers can identify the different understandings about a same norm in different levels of the organization. The starting conference can also be used to discuss the possibilities of improvement of the work practice using the system and the impact of using it in the current social norms. Ethnographic practices. Many techniques of ethnography [Rose et al. 1995] have been widely used in PD with the aim of designing information systems. These techniques include video recording, immersion and other mechanisms for observing users in their real-life contexts. Techniques of ethnography can contribute to norm analysis by making explicit the knowledge about the social context, through a close observation of the workers in the real workplace. Using these techniques the designers can model the informal norms, grasping the true behavior of the agents faced to the formal norms, establishing the relationship between the formal and informal levels of the organization. Artifact walkthrough. This technique can be used in the modeling of the formal behaviors, by studying the formal artifacts that contain the description of roles, laws and patterns of behavior. In an organization usually there are many documents that specify how the work activities should be conducted, the objectives in the operational, tactic and strategic plans, and the structure of the work. Using this technique the designer can identify how the norms described in these artifacts influence the work context and relate to the informal practices conducted in the organization. 4. Participation and Signification in the Design of Pokayoke In this section we address the design of a system that resulted from the mentioned participatory practices and OS methods. We show how the ontology chart was used as an artifact for discussion with the workers. Pokayoke is a system prototype constructed with the aim of exploring the symbiosis between participation and signification aspects in cooperative design. It was designed to support problem solving and decision making in the context of a manufacturing organization that adopts the lean production paradigm. It also includes the major problem solving tools that were used previously by the department of quality in a paper-based format. During application of the Starting Conference and Future Workshop practices, the practitioners stressed the importance of using these tools in a cooperative way at the problem solving process in all departments and levels of the organization. The use of these tools in a paper-based format was previously restricted to the department of quality personnel and some people from the engineering department. There are three main reasons emphasized by the workers to widen the use of the tools through the system: The paper-based format of the tools makes difficult the communication among the workers. Many times the workers need to leave their workplace to engage in activities such as to record the problem, to contact the team that will work on the problem and to obtain permissions to execute corrective actions. A long meeting is necessary in order to use some paper-based tools, but the workers (mainly the floor workers) have difficulty to leave their workplaces for long periods of time to participate in the meetings.

24 Training is necessary to enable the workers to use the tools according to the organization guidelines. Pokayoke is based on a procedure conducted in the factory to analyze and implement corrective, preventive, security, and health actions, known as five steps. The objective of the five-step procedure is to define a systematic method for dealing with problems in the routine of production. Every time when an unconformity is identified, an action must be taken to correct it and to make difficult a new occurrence of it. Also, every time when a situation of potential unconformity is indicated, an error proofing (Poka Yoke) action should be carried out. The Pokayoke system includes the five steps tool, which divides problem solving process into five steps: (1) the description of the unconformity found; (2) the immediate action to be taken; (3) the determination of the source cause for the problem; (4) the corrective/preventive/security plan established, and (5) the analysis of the implantation and effectiveness of the action. Other tools to support the problem solving are used in different moments of problem solving, for example: Ishikawa Diagrams are used at the step tree, brainstorming at the step two and tree, and 5-why at the step tree. These tools are embedded in the system and combined with asynchronous communication artifacts to facilitate communication among the workers and to minimize the necessity of long synchronous meetings, which were emphasized as two of the three main problems with the paper-based tools. 4.1 Using the Ontology Chart as a Participatory Tool The Pokayoke system is seen by the practitioners and designers as an artifact to improve the problem solving process in the organization; as so it should be understood and represented as part of a more complex social context. This mutual understanding of the organizational domain was constructed cooperatively in a participatory way. During the design of Pokayoke, a semiotic model was used as an artifact in the analysis of the current work scenario, and in the discussion about moving from the current situation to the intended organizational context using the prospective system. Figure 3 shows the ontology chart that was constructed to discuss the step two (immediate actions to be assigned in a problem situation) as part of the five steps tool. It is used in this paper to illustrate the use of ontology charts in participatory design activities and to show some implications of this diagram to the design of the Pokayoke system.

25 Figure 3: Ontology Chart for the Step Two The diagram of the figure 3 presents some concepts of the semantic analysis in a graphical representation. The agents that are related with the step two are represented in the ellipses, for example: multifunctional team, action team, person, etc.. Employee is a role-name of the agent person, and the person in charge of actions, the person in charge of Step II are role-names of employee. The affordances of the agents are represented in rectangles. The ontological dependencies are represented linked by lines and are relative to their position: the right is ontologically dependent on the left element, for example the affordance correct is ontologically dependent on problem (if the problem does not exist, there is not correction). This diagram was first modeled utilizing results of some participatory design techniques (Ethnographic Practices, Artifact Walkthrough, HOOTD, and Prototyping); furthermore it was itself used as an artifact (or an object to think with) in the meetings of the Starting Conference. After an initial presentation of the semantic diagrams conducted by the facilitators, the participants discussed specific points in it. The main points discussed in these Starting Conferences are associated to the concepts represented in the elements present in the semantic chart and the norms associated to them. By sharing the same model to represent different aspects of the organization and to discuss the software tool, the practitioners could discuss the impact of the design options and their implications in the work practice in a smooth way. The model has also supported the coordination between members of the organizational staff and the system

26 design team in their joint effort to improve the organization. Social changes and work practices changes are captured in the same model to be reflected in the system. To illustrate this activity, we can analyze some questions that were derived from an affordance represented in figure 3. This figure shows that the agent responsible for the step II has (or should have) the affordance of controlling the agent responsible for the actions. Some subjects discussed some reasons for maintaining this affordance and respective norms, as for example: The relation between the position at the hierarchy in the organization and the position of the responsible for the step and for the action. In discussing this question some points were raised: the new formal norms established when these tools would be effectively in use in the whole company and their implications. What could be done in the case of problems occurring in the action execution? To answer this question some points that were discussed include: automatic information for the person directly in charge in case of problems with deadline, alternative mechanisms for control and the follow-up of the exact problem in the action execution, with software support These issues had direct influence in the Pokayoke prototype design and in the activities at the organization. Figure 4 is a snapshot of the interface of the Pokayoke prototype for the Step II derived from the diagram of figure 3. The interface objects signaled in figure 4 are links to computational tools, related to some affordances present in the diagram of figure 3. These software tools (marked with ellipses in figure 4) are associated to the brainstorm, the define (Action), the define (responsible for actions), verify, and the control affordances. The ontological dependencies of the objects is represented by the conditions of enabling or disabling functions in the software system; for example, it is necessary to define (describe) an action in the Pokayoke to have the function to define the action group enabled. Figure 4: Pokayoke step II screen Snapshot

27 4.2 Discussion Although the participatory techniques are useful instruments to capture the social context of the workers, by their active participation, in traditional approaches to system design, it is ultimately the designers interpretation of these practices that usually are expressed in representations that lead to the final system. In this work we have shown that participatory techniques are useful to inform Semantic Analysis and Norm Analysis. But, more important, we have shown that the formalism created by designers to represent the information captured can be used back with the workers, as designers need also a feedback of their understanding of the context being modeled. This two way route characterizes a conversation between designers and users that are necessary to the mutual learning of both and to achieve a system more tied to this mutual understanding of work practice mediated by technology. Methodologies for systems design and development have been traditionally drawn upon the objectivist paradigm, which considers an objective reality to be discovered, modeled and represented in the software. On the contrary to this assumption, the subjectivist paradigm understands reality as a social construct based on the behavior of agents participating on it. Within this paradigm, participatory techniques seem to be the natural instrument to understand how these agents make sense of their natural surrounding in constructing reality of their work. We have shown that participatory techniques allied with organizational semiotics methods are a useful instrument to design software systems within the underlying subjectivist paradigm. 5. Conclusion Cooperative system design can be defined as the outcome of research on the design of computer applications that enhance the quality of work and products as a consequence [Kyng, 1991]. In this paper we proposed two building blocks for cooperative design: participation and signification. We have shown how techniques from Participatory Design can be combined with some methods from Organizational Semiotics as a way of enabling mutual learning among users and designers of the system. While results from participatory techniques are useful to inform semantic analysis and norm analysis, on the other hand, discussing back with the users the ontology chart is a valuable activity as it represents a way of evaluating the designers interpretation of the work context. We illustrated our approach with some aspects of Pokayoke: a prototype designed cooperatively as a result of participation and signification processes taken place during design. Next steps in conducting this work involves a systematic analysis of the system in use as it was designed for problem solving and decision making in the context of a lean manufacturing organization. Acknowledgments This work was partially supported by grants from Brazilian Research Council (CNPq /84-3 and FAPESP 2000/ ). The authors also thank Delphi Automotive Systems in Jaguariúna, Brazil, and Nied Unicamp for collaboration and partnership in the Pokayoke project. The first author also wishes to thank Andy Salter for the OntChart tool and the University of Reading for the support during a sabbatical study at the Department of Computer Science.

28 References Fischer, G., Lindstaedt, S., Ostwald, J., Stolze, M., Sumner, T., Zimmermann, B. (1995) From Domain Modeling to Collaborative Domain Construction. In ACM Proceedings of DIS 95 Symposium on Designing Interactive Systems: Processes, Practices, Methods & Techniques, Gibson, J.J. (1979) The Ecological Approach to Visual Perception. Houghton, Mifflin Company. Boston, Kyng, M.(1991) Designing for Cooperatin: Cooperating in Design. Commun. ACM 34,12, Kuhn, S. (1996) Design for People at Work. In T.A. Winograd (ed) Bringing Design to Software. Addison Wesley. Lave, J. Wenger, E. (1990) Situated Learning: Legitimate Peripheral Participation. IRL report , Palo Alto, Calif.: Institute for Research on Learning. Liu K. Semiotics in information systems engineering, Cambridge University Press, Liu, K., Stamper R. K., and Huang, K. (1997) A morphology for re-engineering competitive business. Legacy to client/server, A. Booth (ed.), Unicom Press. Muller, M. J., Haslwanter, J. H., and Dayton, T. (1997) Participatory Practices in the Software Lifecycle. In Handbook of Human-Computer Interaction, M. Helander, T. K. Landauer, P. Prabhu (eds.), Elsevier Science, 2 ed., Nied, Revitalizing Training and Learning in Industries in Brazil, Nied Núcleo de Informática Aplicada à Educação, Unicamp, internal document, Nied, O Uso da Internet na Formação Colaborativa e Descentralizada de Funcionários de Fábricas Enxutas, Nied Núcleo de Informática Aplicada à Educação, Unicamp, internal document, OSW. The circulation document in the Organizational Semiotic Workshop, Enschede, Peirce, C.S. Collected Papers, Cambridge, Mass: Harvard University Press, ( ). Rose, A., Shneiderman, B., and Plaisant, C. (1995) An applied ethnographic method for redesigning user interfaces. In ACM Proceedings of DIS 95 Symposium on Designing Interactive Systems: Processes, Practices, Methods & Techniques, Schuler, D., Namioka, A. Participatory design: Principles and Practices. Lawrence Erlbaum Associates, Inc., Publishers, New Jersey, USA, 1993.

29 Using the Underlying Discourse Unveiling Method to Understand Organizations of Social Volunteers Clarissa M. de Almeida Barbosa 1, Clarisse S. de Souza 1, Ana Maria Nicolaci-da- Costa 1, Raquel O. Prates 2 1 Pontifícia Universidade Católica do Rio de Janeiro (PUC-Rio) R. Marquês de São Vicente, Rio de Janeiro RJ Brazil 2 Universidade do Estado do Rio de Janeiro (UERJ) R. São Francisco Xavier, 524, 6o. andar, Bloco B, Rio de Janeiro RJ Brazil {cbarbosa,clarisse}@inf.puc-rio.br, anicol@psi.puc-rio.br, raquel@ime.uerj.br Abstract. In this paper we describe how the use of a particular method of investigation the Underlying Discourse Unveiling Method (UDUM) during the requirements elicitation phase of system development has made us aware of the need for fundamental changes in our design premises. UDUM, whose origins lie in clinical psychology research, has helped us identify some unique characteristics of social volunteer organizations, as well as the impact these characteristics may have upon software design and development. The method has also helped us define which new direction to take. We suggest that more popular methods, such as those based on ethnographic research, wouldn t have helped us as much as UDUM because they tacitly assume that the organizational environment where the technology will be introduced operates in a more process-oriented way than the one we are working for. Resumo. Neste artigo descrevemos como o uso de um determinado método de investigação o Método de Explicitação do Discurso Subjacente (MEDS) durante a fase de elicitação de requisitos de desenvolvimento de sistema tornou clara a necessidade de mudanças fundamentais nas nossas premissas de design. MEDS, que é originário da área de pesquisa em psicologia clínica, nos ajudou a identificar algumas características singulares de organizações de voluntários, bem como o impacto que essas características podem ter sobre o design e desenvolvimento de software. O método também nos ajudou a definir a nova direção a seguir. Sugerimos que métodos mais populares, como os baseados em pesquisa etnográfica, não teriam nos ajudado tanto quanto o MEDS porque tacitamente supõem que o ambiente organizacional no qual a tecnologia será introduzida opera de uma forma mais orientada para o processo do que aquele para o qual estamos trabalhando.

30 1. Introduction Today computers and the Internet are part of the daily activities of millions of people around the world. They have been increasingly used by groups of people to collaborate and communicate over a wide range of activities, varying from working together to meeting new people and forming online communities [Preece, 2002]. The variety of software available to support these kinds of activities has also increased and made it easier for people to be connected to each other. In this paper we describe how the use of the Underlying Discourse Unveiling Method (UDUM) has affected our strategies for developing software to support the activities of social volunteers who work for non-governmental organizations (NGOs). Having successfully developed groupware and workflow applications for large Brazilian companies, we assumed that NGOs would benefit from this kind of technology, although we knew that major adaptations compared to what we had done before would be certainly required to accommodate the peculiarities of volunteer organizations. Thus, we put a lot of effort into the initial phase of the project, in an attempt to better understand the specific needs of this community before we started to tailor existing group applications to provide it with more adequate technological support. One of our expectations was that volunteers would benefit from software that would help them coordinate their activities, since most of them do not work for the organization on a daily basis. We suspected that handing their work over to other volunteers and following a plan would be centrally important for the success of the organization as a whole. To confirm these premises, we used UDUM, which, having been developed for clinical psychology research, makes it possible to uncover underlying meanings, motivations, conflicts, desires, etc. This method revealed to us that our initial premises were wrong. Among other things, we found out that, even though many of the NGO workers share the same overall goal, the tasks they carry out are highly independent from each other. This does not mean that people do not need or want to interact. Workers often share experiences, but most of this sharing is done through informal and opportunistic meetings, not as a result of an organizational process. Furthermore, UDUM pointed out to us that one of our main concerns should be how to introduce technology into this environment. If technology is felt to conflict with personal drives and cherished values associated to volunteer work, the system being now developed will never be used and other systems may become harder to be accepted. This aspect is particularly important for HCI research in that most of the popular methods used during this phase of software development are based on Ethnography, a discipline that purports the primacy of observation over deepest inquiries of subjective desires and fears (precisely the point of clinical psychology investigation). We suggest that UDUM has given access to insights about our users that ethnography-based methods would probably have not. In the next section, we describe the Oré Project and our initial premises and plans regarding what we expected to deliver to our targeted organization of social volunteers (OSV). In section 3, we describe UDUM, explain how we applied it to elicit technological requirements and present what we learned about the OSV. In section 4, we discuss the

31 particularities of OSVs we have been able to identify, their implications to software design and their impact on our own project. Finally, we discuss UDUM s role in our change of perspective and the contributions of this paper to other designers. 2. Oré Project The Oré Project [Oré 2001] is part of our response to the Brazilian federal government initiative to disseminate and promote the use of the Internet throughout the country. Two of the main goals of the Information Society [MCT2000] initiative are to leverage the participation of Brazilian professionals and companies in the globalized Information Technology (IT) world market, and to use IT as a means to bridge existing social and economic divides that prevent Brazilian citizens from having full access to their civil rights. In this context, the project s aim is to design and develop IT products that will help communities of social volunteers involved in supporting families of hospitalized children. Community activities range from providing medical and sanitary care to the children, their parents, siblings and other relatives, to promoting recreational sessions while the children are at the hospital and providing skill training for their parents and other relatives. Saúde-Criança Renascer Association (Saúde-Criança Renascer), a NGO located in Rio de Janeiro, is our partner in the project. We chose this specific organization due to its history of success and credibility. Besides, Saúde-Criança Renascer is physically located near PUC, where the project would be conducted. By the time we performed this research, we were informed that this community was formed by 35 employees and 124 social volunteers. Its goal is to support families who are very poor (and often miserable) for a period of time and help these families raise their living standards. The families are chosen from a number of families whose children have been admitted to a specific public hospital. At the hospital, Saúde-Criança Renascer runs a recreation room for the children, where they play with volunteers and other children while receiving treatment. Saúde-Criança Renascer provides the child and his/her relatives who share the same dwellings with aid in food, medicines, clothes, home appliances and, if necessary, construction material. It also offers training courses, family planning courses, psychological and social service support, as well as legal counseling to family members. The goal is to improve family members lives, make them (re)gain confidence and pride, as well as learn ways to increase their income and be able to keep up the new standards on their own. Our ground assumption was that OSVs could benefit extensively from introducing IT in their environment. We believed that OSVs could be more efficient if they used Internetbased groupware applications tailored to their needs, especially considering this could make it easier for the many volunteers to coordinate their activities. Our experience in developing successful computer supported collaborative work (CSCW) and workflow applications for large companies led us to assume that our task would be essentially one of adapting the knowledge we have to the activities of OSVs. We certainly expected OSVs to be different from commercial, industrial and academic organizations in that they depend more fundamentally on the accidental or incidental availability of resources (like volunteers, for example) and thus have to deal with a much more flexible notion of planning and execution. In particular, we believed that opportunistic problem solving would be a more widespread

32 practice in OSVs than in other organizations, where rules and regulations tend to favor more structured goal-oriented work practices. Therefore, the initial proposal of the project was to develop groupware technology with such technological components and features as: , discussion lists, chat rooms, message boards, sites and portals, planning & execution management, information storage & retrieval, annotation facilities, documentation support, and the like. Figure 1 depicts the main components and agents involved in our original technological scenario. We also believed that the backflow from our experience with OSVs would benefit the other organizations we had worked for. Clearly, globalized markets and complex dynamics in rapidly changing economic and political scenarios have been forcing companies to find more flexible ways to operate, without jeopardizing their institutional identity or losing track of their mission. PRIVATE ENVIRONMENT PUBLIC ENVIRONMENT planning e-messaging e-meetings group Agenda tracking opportunities documentation & information Record of activities Narratives Documents Bulletin Boards publication REPORTS NARRATIVES DOCUMENTS ANNOUNCEMENTS community of volunteers contribution & participation general public subgroup 1 subgroup n supporting families of hospitalized children families Figure 1 - Overview of components and agents in the original scenario 3. Learning about the Volunteer Organization As already mentioned, we wanted to find out how to support task performance. To accomplish this goal, our first step was to learn what the employees' and volunteers' needs, difficulties and priorities were. The Underlying Discourse Unveiling Method (UDUM), specially developed for similar purposes within clinical psychology 1, was therefore used to select subjects, collect and analyze data. Its use seemed particularly appropriate because it 1 For a more detailed discussion of techniques, see Nicolaci-da-Costa, 1989, 1994; Nicolaci-da-Costa, Leitão and Romão-Dias, 2001.

33 uses open-ended interviews that are sensitive to what people have to say freely and has the capacity to grasp and analyze beneath the surface meanings, thus being able to reveal hidden fears, desires, motivations, aspirations, conflicts, etc. Although the design team believed tasks and goals would be central for the technology, we hoped UDUM could provide a wide range of contextual information independently of early design assumptions. Results could be then compared with and mapped to early design assumptions so as to confirm them or point at inconsistencies. The main characteristics of UDUM will be presented next, as we explain how we applied this method to elicit technological requirements Participants Our main criterion for selecting participants was that they used computers to perform their tasks at Saúde-Criança Renascer, and thus represented the population of potential users of the system being designed. Out of the 30 volunteers and 30 employees that satisfied this requirement, 5 volunteers and 5 employees were interviewed. Their ages varied from the late 30's to the early 60's (five were in their 50's and 60's). Nine of them were women. All but one a woman with a technical degree in administration had college education. Their professions or occupations varied (social worker, engineer, first-grade teacher, executive secretary, lawyer, housewife, chemist) and did not necessarily bear strict relation to what they do at Saúde-Criança Renascer. There they act as social workers, managerial and administrative assistants, and recreation or social event coordinators. They also support the elaboration of documents, presentations and reports. At the time of our study, they had been working at Saúde-Criança Renascer for a minimum of four years and a maximum of ten. The main difference between volunteers and employees was the fact that, while employees work at Saúde-Criança Renascer every day, volunteers usually go there once a week Data collection Face-to-face interviews were used for data collection. These interviews were jointly conducted by two members of the Oré Project (one of whom was herself a volunteer at Saúde-Criança Renascer) either at participants offices or in a meeting room at Saúde-Criança Renascer premises. The interviews had an average duration of 50 minutes. All were recorded for later transcription. Questions asked by the interviewers followed a guide script with open-ended questions. This script was structured around four major topics (each containing as many questions as necessary): a) The interviewees profile in as much detail as possible (whether they were volunteers or employees; how they came to Saúde-Criança Renascer; what was their previous professional experience; what they did at Saúde-Criança Renascer; how long they had been working there).

34 b) The interviewees experience with computers (whether they used computers, how often and what for; what kinds of software they used; whether they were familiar with the Internet; how often they logged on to it; what they did on the Internet). c) Activities carried out at Saúde-Criança Renascer (what activities the interviewees were responsible for; how they carried them out; whether these activities were optional or mandatory; whether they performed them collectively or individually and why; how they went about their activities when these were carried out collectively; how often they used computers for carrying out their work at Saúde-Criança Renascer, for what tasks; what kinds of software they used; what they did when in doubt about software use; whether they used computers spontaneously or because they were forced to do so; what the interviewees thought about computers in general; what they believed were the advantages and disadvantages of computer use for working purposes). d) The interviewees dreams for Saúde-Criança Renascer in an ideal situation with no practical technological obstacles (what would be the role of computers in this dream; what would be the advantages or disadvantages of their use; etc.). Interviewers should follow interviewees leads to explore their aspirations and desires in as much detail as possible Data analysis Qualitative analysis of participants discourse was performed on the collected data. Such an analysis comprised two basic complementary stages that could be repeated as often as deemed necessary (see in Figure 2). Participants replies Inter-participant analysis Intra-participant analysis Recurrences and Contradictions Figure 2. Stages of qualitative analysis of discourse (adapted from da Silva, de Souza & Nicolaci-da-Costa, 2002) In the first stage of analysis the inter-participant one the replies given by all interviewees to each question within each topic of the interview script were closely examined in search of recurring categories, metaphors, positions, behaviors, feelings, beliefs, etc. that would allow access to group (or, in this case, institutional) culture. These recurrences were assigned different priorities in the ensuing analysis on the basis of the frequency of their occurrence (the higher the frequency, the higher the priority).

35 Internal consistency of each participant s responses to all the topics in the script was checked in the second stage, the intra-participant one. In this stage, one tries to detect occasional contradictions and inconsistencies in participants statements. Such contradictions and/or inconsistencies can be a good pathway to invisible aspects that underlie human behavior, such as desires, motivations and/or fears 2. In this particular case, an attempt was made to identify possible contradictory statements that could indicate the existence of inner conflicts regarding the use of technology at Saúde-Criança Renascer and in volunteer work in general. 4. Findings Most of the volunteers offered to work for Saúde-Criança Renascer in order to fill up their idle time (mainly as a consequence of having retired from their jobs). One of them, a widow in her 50 s, states this clearly when she says: My husband died and left a hole in my life. She started working at Saúde-Criança Renascer soon after her husband s death in order to fill this hole. Another woman volunteer, in her 60 s, makes a similar statement: I started working here because I was adrift. Other volunteers are more discrete but the same motivation can be detected in their interviews. Volunteers and employees are very proud to be members of Saúde-Criança Renascer. A woman in her late 30 s, a former volunteer, now an employee, emphasizes how proud she is to be at Saúde-Criança Renascer since its inception. She says, making a pun with the word renascer (to be born again) which is similar to Renascimento (Renaissance) in Portuguese: I date back to the Renaissance. What is really interesting is that they are also proud of the way they perform their activities. As an example, some take pride in having created their own databases, which in theory can be used by others, but in fact are difficult to share. This becomes an important source of prestige and power for their creators. Others are extremely proud of their writing skills or of their managerial capacities. They enjoy being free to act in the way they want to and what usually happens is that they apply their background experience and knowledge to their current activities at Saúde-Criança Renascer. By doing so, they feel even more deeply involved, since they are contributing to the achievement of Saúde- Criança Renascer s goal. Volunteers tasks are mainly independent, and there is no high-level coordination to tie them together. For instance, a different volunteer is responsible for coordinating family assistance activities on different days of the week. Each one does his/her work in his/her own way. No attempts are made to set common procedures or to have a systematic higher-level coordination. One of these coordinators, a female volunteer in her 50 s, says that difficult cases are discussed in coordinators meetings. These meetings, however, happen only once every two weeks (which in some cases may be too long to wait for a decision) and may not be attended by all due to the fact that they go to Saúde-Criança Renascer on different days and times. Informal face-to-face meetings, such as having a cup of coffee at the end of the day, are used for opportunistic collaboration. 2 An example of what can be made visible by contradictions and inconsistencies can be found in Nicolacida-Costa, 2002.

36 Closer inspection, however, reveals that there is a covert form of coordinating different activities and allowing the sharing of relevant information among people performing different tasks regarding the families. This is done by means of the family file, which most interviewees allude to or describe in detail. The family file can be seen as an invisible binding that ties things together. Briefly, when a hospitalized child s mother or other relative is seen for the first time, a file is opened bearing the child s name. From that moment on, the family s history at Saúde-Criança Renascer is registered there (what donations they have received, what professional courses family members have enrolled in, what the social worker had to say about the family s dwellings, etc.). This is done by different employees and volunteers in charge of different forms of assistance. The file is passed from one to the other. Nevertheless, given that the file is physical, it cannot leave the headquarters of Saúde-Criança Renascer. Therefore, those who work at other premises of the NGO do not have access to it. Another interesting finding has to do with the above-mentioned fact that the volunteers go there on different days and perform independent tasks in their own ways (not having to be in touch with others to maintain common standards). As a consequence, they do not know many of their fellow volunteers personally. In addition, it is very difficult for them to have a general meeting because they have other engagements on the days they don t work at Saúde- Criança Renascer. Surprisingly as it may seem, however, they do not appear to resent this and do not spontaneously try to resort to other forms of communication. In fact, one of the volunteers, a female in her early 50 s, says that she doesn t interact with volunteers or employees with whom she doesn t work closely and emphasizes: I like it this way. This is an explicit personal statement but other volunteers also don t seem to mind their relative isolation. Finally, the open-ended interviews associated with the analysis of underlying meanings provided us with broader understanding of the challenges to be faced when introducing information technology. Most employees and volunteers appear to be very reluctant towards computers, even though they may sometimes say it would be great to have access to databases or to specialized sites on the Web. Some interview excerpts can help the reader understand how volunteers feel about technology. (The reader should be warned that the following excerpts were not made as a criticism, but rather in an attempt to explain this feeling.) A female volunteer, in her late 40 s, admits she uses computers but dislikes them profoundly, so much so that her sister sends s to her husband, who prints them for her to read. Two of her statements are particularly relevant to reveal how she deals with computers: These electronic things do not obey me and My husband always says that I use the computer like a typewriter.. (As a matter of fact, most of the employees and volunteers who use computers at Saúde-Criança Renascer tend to use them as typewriters.) A former executive secretary of a technological company, a female in her 60 s who is fond of computers and knows Saúde-Criança Renascer very well, tries to explain what happens to her fellow volunteers: Some don t want to know about computers because they are afraid. They are people who don t accept computers. They want to do everything manually.

37 Many of the employees share this aversion to computers. However, a female employee, in her late 50 s, gives a different and complementary interpretation for the aversion to computer use so common at Saúde-Criança Renascer. She says: Most people don t like computers. Some are retired people, from older times, who may even have dealt with computers because they were forced to learn, but they don t like them. Others like paper, they like to organize physical files I myself love paper, I love to organize files. There is also some awareness among the interviewees that the limited physical space of the premises and the lack of technical support are major obstacles for large-scale computer use. A female employee, in her late 30 s, says: If there were computers for every one, it would be chaotic. Another female volunteer, in her early 60 s, also points out that: We lack people with specific skills. People who could train others in the use of computer programs.. 5. Taking differences into account UDUM has proven to be an insightful resource for our work since it has allowed us to understand the differences between commercial, industrial and academic organizations, on the one hand, and social volunteer organizations on the other. The former have clearly defined processes to achieve their ultimate goals. People to work in each process or to perform each task are selected on the basis of required skills and are often told how they are expected to perform their duties. The latter, on their turn, tend to have only a more general view of the direction in which they want to proceed and frequently a group of volunteers willing to work to make it happen. These volunteers are assigned to activities based on their interests and availability and usually can decide how they want to perform their activities. These differences have some important implications to systems being designed to support the distinct organizations. As our findings reveal, a system to be used in an OSV has to be freely adopted by employees and volunteers. Whereas in any company this is also desirable [Grudin, 1994], system use may be encouraged by offering training courses or rewards for productivity, or even enforced by penalizing those that do not use it. In OSVs, volunteers work because they have chosen to, and people do so for many different, mainly personal, reasons. Furthermore, most of the volunteers are not at the organization every day, but only on few days a week. This may cause a task that has to be carried out every day to be performed by different people each day. Also, it is frequently the case that people that perform the same tasks do not know each other, or tell each other how they perform these tasks. Volunteers tend to have a rather local perspective of their work (mostly they don t see the big picture), and often don t see why this should be otherwise. They are proud of what they do and of the way they do it. To be appealing for each one of these volunteers, the system must support all of the different practices used in accomplishing each one of the tasks. Ruling out some ways of performing activities, may lead to frustration and cause some volunteers to feel unmotivated and quit, which would be a loss of valuable resources to the OSV. To be able to work as a volunteer, a person must have free time to donate to an OSV. Thus, oftentimes many of the volunteers are retired people. As observed in Saúde-Criança Renascer, these volunteers are generally not excited about technological enhancements and may be even afraid or turned off by them. Getting these volunteers involved and interested in the system is a challenge per se.

38 Also, in an organization such as Saúde-Criança Renascer, planning is deemphasized in view of a constant need to react appropriately and immediately to the emergence of favorable and unpredicted opportunities. Planning, in this case, is a much shorter-term and looser activity, when present at all. Thus a system to support their activities must be able to handle exceptions that may not have been foreseen at design time. Furthermore, the frequent changes of resources and situations OSVs deal with, may cause some changes in their initial direction and main activities. Hence the system must be able to adapt to new scenarios as they come along. In short, adaptability and extensibility, in the form of customization and simple userdefined modifications to the system, seem to be essential features for systems supporting OSVs. The realization of these fundamental differences made it clear to us that our initial assumptions about which IT products would best support this community were mistaken. We now see that it is not the case that we should only adapt CSCW and workflow applications we have successfully developed in the past for Brazilian companies to the special needs of an OSV. Instead, we concluded that the best initial step is a carefully situated (re)introduction to information technology. Our design choice has then been reoriented towards providing situated communicative tools that will give workers at Saúde-Criança Renascer a chance to know more about the organization and about volunteers in general and that will also foster informal communication as well as experience sharing. The idea is that this light-weight technology, made available for spontaneous use (not as a mandatory novel technological process) will give this community a chance to get acquainted with IT and to eventually tell us in which direction to go next. 6. Conclusion In this paper we described how we have used a method developed for research in clinical psychology, UDUM, to elicit requirements for groupware applications dedicated to OSVs. As it turned out, this method played a key role in defining a new direction for the project. UDUM s open-endedness allowed us to have access to some important distinctions between OSVs and other types of organizations. These fundamental differences caused us to review our original assumptions about which IT products would best support our targeted OSV. UDUM also provided us with information on potential problems we had not foreseen that helped us decide on our new approach to developing the Oré Project. An extensive assessment of the benefits of having used UDUM instead of other methods can be obtained if we ask different design teams, using distinct design methods, to elicit requirements for Oré, and then compare the results. Of course we should minimize or at least account for the impact of the design teams personalities (i.e. the interaction of different subjective traits) on the use of each specific method. However, this is a costly process that we cannot afford at this point. Nonetheless, we can raise interesting and relevant issues to be considered when choosing user study methods for different types of organizations. Most of the methods currently proposed to support user studies in the initial phases of design are based on Ethnography. Having its roots in Anthropology, Ethnography is devoted to understanding culture and the nature of social activities carried out by smaller and larger groups of people (including, of course, ethnic groups but work groups as well). The peculiarity

39 of ethnographic methods as far as HCI is concerned is that they all purport (or take for granted) the primacy of observation over all other sources of data collection. Interviews with observed subjects do take place in ethnographic research, but they typically center around activities, not around feelings. This is true for example of Contextual Inquiry, a part of the Contextual Design approach [Beyer and Holtzblatt, 1998], where the designer works as an apprentice to the user [Preece, Rogers and Sharp, 2002]. It is also true of approaches that are not ethnographic but psycho-social in nature, like Activity Theory (AT) [Nardi, 1996]. AT radically explores consciousness in relation to action and takes "object-orientedness" as one of its fundamental tenets [Kaptelinin, Nardi and Macaulay, 1999], an explicit recognition of the primacy of objective activity over subjective attitudes and predispositions. UDUM, in this context, seems to be particularly fit for the task of characterizing organizations of social volunteers because, as the etymology of the word reveals, volunteers are people who are doing something because they wish to, it is their desire to participate in an activity that they are not obliged to be involved with in other words, volunteerism is rooted in subjective volitional aspects. Thus, methods that deemphasize such aspects are likely to leave implicit (if not omitted) some of the most important factors determining the spontaneous adhesion of volunteers to the social causes embraced by OSVs. Technology developers can unknowingly ruin the fabric that keeps them together if they are not made aware of such psychological subtleties. UDUM also revealed some anxiety and fear that some volunteers have with respect to computer technology (see section 4). This finding seems to suggest that other alternative methods inspired in Participatory Design such as PICTIVE [Muller, 1991], for example, would also be highly risky in this context. Users who do not understand IT in general are likely to have increased difficulty to make the appropriate decisions as part of a design team. This is why we have redirected our original development plans towards designing pieces of technology that will gently and usefully increase computer literacy first, and only then design groupware that will directly support organizational activities. As part of our future work we are preparing other user studies. Some may be carried out with ethnographic methods. They can reveal how the users activities will have been affected by the availability of optional technological support for their work (such as the a Bulletin Board that users can explore if and however they wish). Later on in the project, quantitative methods can also help us explore some of the psychologically grounded categories revealed by UDUM. The peculiarities of volunteer organizations and the demands they impose for software design have a direct contribution to anyone developing software to support both work groups and online communities. The issues explored in this paper may be also helpful for those developing software for processes-oriented companies, since they bring to light some of the tension involving productivity and creativity. A system that strictly defines work processes, without taking into account the inner motivation, talent, creativity and inclinations of individuals can prevent opportunistic action and sacrifice people s satisfaction with their work and even possibly jeopardize a company s competitiveness in the market.

40 References Beyer, H.; Holtzblatt, K. (1998) Contextual Design: Defining Customer-Centered Systems. San Francisco, CA: Morgan Kaufmann Publishers, Inc. da Silva, E.; de Souza, C. S.; Nicolaci-da-Costa, A. M. (2002) Visões e idealizações de usuários potenciais a respeito de aplicações de groupware. Rio de Janeiro: PUC-Rio / Departamento de Informática Technical Report MCC XX/02. To be published. Grudin, J. (1994) Groupware and Social Dynamics: Eight Challenges for Developers. Communications of the ACM, v.37, n.1, p Kaptelinin, V., Nardi, B. and Macaulay, C. (1999) The activity checklist: A tool for representing the space of context. Interactions, p , jul./aug. MCT (2000) Site do Programa Sociedade da Informação. Disponível em: < Acesso em: nov Muller, M. (1991) PICTIVE An exploration in participatory design. Proceedings of CHI 91. New York: ACM Press. p Nardi, B. (1996) Context and Consciousness: Activity theory and human-computer interaction. Cambridge, Mass: MIT Press. Nicolaci-da-Costa, A. M. (1989) Análise de discurso e pesquisa qualitativa. In: Sociedade de Psicologia de Ribeirão Preto (Org). Anais da 18ª Reunião Anual de Psicologia, pp Nicolaci-da-Costa, A. M. (1994) A análise de discurso em questão. Psicologia: Teoria e Pesquisa, v.10, n.2, pp Nicolaci-da-Costa, A. M., Leitão, C. F. and Romão-Dias, D. (2001) Gerando conhecimento sobre os homens, mulheres e crianças que usam computadores: algumas contribuições da psicologia clínica. Anais do IV Workshop de Fatores Humanos em Sistemas de Computação. Florianópolis, pp Nicolaci-da-Costa, A. M. (2002) Quem disse que é proibido ter prazer online? Identificando o positivo no quadro de mundanças atual. Psicologia: Ciência e Profissão, 22(2), pp Oré (2001) Site do Projeto Oré. Disponível em: < Preece, J. (2002) Special Issue: Supporting community and building social capital. Communications of the ACM, v.45, n.4, p Preece, J., Rogers, Y. and Sharp, H. (2002) Interaction design. London: John Wiley.

41 Modelo de Interação como Ponte entre o Modelo de Tarefas e a Especificação da Interface Simone Diniz Junqueira Barbosa 1, Clarisse Sieckenius de Souza 1, Maíra Greco de Paula 1, Milene Selbach Silveira 1,2 1 Departamento de Informática Pontifícia Universidade Católica do Rio de Janeiro (PUC-Rio) Rua Marquês de São Vicente, o andar RDC Rio de Janeiro RJ Brasil Faculdade de Informática Pontifícia Universidade Católica do Rio Grande do Sul (PUCRS) Avenida Ipiranga, 6681 Prédio 30 Porto Alegre RS Brasil {simone, clarisse, mgreco, milene}@inf.puc-rio.br Abstract. This work deals with representation issues of HCI design. It proposes a conversation-based interaction model that fosters the designers reflections about solution strategies and their consequences. The proposed model is user-centered and supports the reuse and traceability of representations. Resumo. Este artigo aborda questões de representação de design de IHC. Propõe um modelo de interação baseado em conversação que favorece a reflexão dos projetistas sobre estratégias de solução de design e suas conseqüências. O modelo proposto é focado no usuário, facilita o re-uso das representações e mantém a rastreabilidade com outros modelos de IHC. 1 Introdução A abordagem de design de sistemas centrado no usuário foi proposta por Norman há quase duas décadas [Norman 1986]. Entretanto, os modelos e técnicas empregados em IHC não têm sido utilizados amplamente, se comparados com os modelos da Engenharia de Software. O tipo de modelo mais utilizado em IHC é o modelo de tarefa. Este tem por objetivo facilitar a compreensão de um domínio de aplicação, registrar os resultados de discussões interdisciplinares, projetar novas aplicações de forma consistente com o modelo conceitual dos usuários e analisar e avaliar a usabilidade de sistemas interativos [Paternò 2000]. Alguns modelos de tarefas privilegiam a compreensão do domínio, tais como GOMS [Card et al. 1983], TKS [Johnson et al. 1988], MAD [Scapin e Pierret- Golbreich 1989] e GTA [van der Veer et al. 1996], enquanto outros se concentram no projeto e especificação de aplicações, tais como TAG [Payne e Green 1989], CLG [Moran 1981], UAN [Hix e Hartson 1993] e ConcurTaskTrees [Paternò 2000]. Este artigo apóia o uso de modelos de IHC que permitam representar soluções de interação de forma a apoiar a reflexão e a tomada de decisões sobre o design, durante este processo [Schön 1983]. A questão levantada é que tipo de modelo deve ser utilizado em que momento do processo de design. Em vez de se utilizar modelos de

42 tarefa complexos para tentar cobrir todo o processo, propõe-se utilizar modelos de tarefas simples em conjunto com um modelo de interação baseado em conversação, e a partir deste especificar a interface propriamente dita. Estes modelos devem, cada um em um determinado nível de abstração, manter o foco no usuário, permitir a representação da estrutura das tarefas e da interação, apoiar o re-uso e garantir a rastreabilidade entre os modelos. Neste artigo, é proposto um modelo de interação que satisfaz estes requisitos e permite seguir uma abordagem de projeto baseada em modelos e centrada no usuário. O modelo de tarefas aqui utilizado é uma adaptação simples de modelos hierárquicos de análise de tarefas de uso comum em IHC [Preece et al. 1994]. Já o modelo de interação proposto inspirou-se na metáfora de interação como uma conversa [Brennan 1990], representada como cenas compostas de diálogos, estes constituídos de falas que representam as ações interativas propriamente ditas. A abordagem aqui apresentada foi utilizada no reprojeto de dois sistemas interativos, um no ambiente Windows e outro no ambiente Web, e no projeto de um sistema interativo para a Web. Estes projetos foram fundamentais para o refinamento do modelo de interação, em particular de sua notação. 2 O processo de design de IHC O processo de design de IHC em que os modelos propostos se encaixam é essencialmente iterativo, dele constando os seguintes passos: análise, construção de cenários, modelagem de tarefas, modelagem de interação, construção de storyboards e prototipação rápida. A etapa de análise se concentra na compreensão do domínio do problema e contexto do usuário. É realizada principalmente através de questionários, entrevistas e estudos etnográficos [Preece et al 1994, Beyer e Holtzblatt 1998]. Com base na análise realizada, são construídos cenários de uso, em forma narrativa, ricos em detalhes contextuais [Carroll 1995]. Um dos principais objetivos deste passo é ratificar ou retificar, junto aos usuários, o entendimento dos projetistas sobre as tarefas a serem apoiadas. É importante ressaltar que, apesar de detalhados, os cenários não devem conter detalhes da interface propriamente dita, como textos e rótulos, seleção de widgets, etc., para não haver um comprometimento precoce dos designers com a solução de interface a ser adotada, o que dificultaria a exploração de soluções alternativas. A partir dos cenários aprovados pelos usuários, constroem-se representações da estrutura das tarefas reveladas pelos cenários. Em seguida, começa-se a dar forma à solução computacional, através de um modelo de interação. De posse dos modelos de tarefas e de interação, os projetistas de IHC já têm elementos suficientes para especificar a interface e construir os storyboards e, conseqüentemente, dar início à prototipação. Tendo em vista os passos descritos do processo de design de IHC, este artigo apresenta uma proposta para a construção dos modelos, em particular do modelo de interação.

43 3 Requisitos dos Modelos de Apoio ao Design de IHC Na concepção do modelo proposto, foram considerados os seguintes requisitos: foco no usuário: Deve-se manter o foco no usuário, sem a preocupação, neste momento, com as funções subjacentes do sistema. É necessário investigar quais são seus objetivos, o que ele faz para alcançá-los, como o faz, de que informações precisa para avançar nesta direção, e que informações gera neste processo. representação da estrutura das tarefas: Com base na análise realizada, as tarefas que se pretende apoiar devem ser representadas em um modelo que permita explorar a estrutura das tarefas, visando revelar conhecimento tácito ou escondido. representação da interação: Uma vez definidas as estruturas das tarefas que serão apoiadas pelo sistema, a solução de design começa a ser moldada. Para isto, é necessário um modelo que permita não apenas representar soluções de design, mas que facilite a comparação de soluções alternativas e a identificação de padrões de solução. apoio ao re-uso: A partir de padrões identificados no modelo de interação, pode-se construir uma base de padrões (soluções positivas) e anti-padrões (soluções negativas) de design. Esta base de padrões pode levar em conta estilos de interação e domínios de aplicação distintos. Além disto, pode-se representar mapeamentos entre soluções de aplicações similares em tecnologias distintas. Estes mapeamentos podem ser qualificados de acordo com as avaliações realizadas sobre os sistemas resultantes. rastreabilidade: Devido à natureza evolutiva do software e à freqüência de mudanças ocorridas em tempo de design, o designer precisa ser capaz de apontar quais são os efeitos de uma mudança pontual em um modelo de design. É necessário, então, garantir a rastreabilidade entre os modelos de um sistema. 4 Modelagem de Tarefas O primeiro passo da modelagem de tarefas consiste em extrair dos cenários as metas ou objetivos que os usuários terão ao utilizar o sistema, e criar uma lista de metas do usuário. Cada cenário pode descrever mais de uma meta, e uma meta pode ser descrita em mais de um cenário. Por exemplo, no cenário a seguir, destacamos a expressão que identifica a meta Consultar documento. Carolina entrou agora na pós-graduação. A fim de melhor conhecer o trabalho de seu grupo de pesquisa na área que mais lhe interessava ela resolve informar-se sobre as publicações feitas por eles. Paulo, seu colega mais sênior, lhe indica que existe um ambiente eletrônico do grupo, onde todas as publicações estão disponíveis, e que todas as pessoas podem acessá-lo, mesmo não sendo do grupo, através de um login de visitante. Ela resolve recorrer a esse ambiente para consultar os documentos de sua área. Após entrar como visitante, ela busca os documentos desejados e vê que pode visualizá-los no momento, lendo, ou posteriormente, imprimindo-os ou salvando-os para arquivos. Ela escolhe um documento que parece mais abrangente, e o imprime para ler em casa. Usou-se, inicialmente, durante o reprojeto de um sistema interativo, a técnica Hierarchical Task Analysis (HTA) [Annett e Duncan 1967] para modelar as metas extraídas dos cenários. O objetivo era obter uma visão global da estrutura das tarefas,

44 utilizando uma notação tão simples quanto possível. Entretanto, à medida que o projeto evoluía, sentiu-se a necessidade de representar elementos adicionais, não contemplados pela HTA, dentre os quais citamos: re-uso de trechos do modelo; estruturas de tarefas que não sigam uma seqüência predefinida; tarefas que podem ser efetuadas em qualquer ponto da realização da meta; pré-condições para a realização de tarefas; informações utilizadas em cada tarefa; e prevenção e tratamento de erros. Embora alguns destes elementos já tenham sido contemplados em outras notações propostas, como o modelo de tarefas não é o ponto central de nossa pesquisa, optamos por fazer uma adaptação ao HTA a bem da simplicidade. A modelagem de tarefas utilizada consiste principalmente em uma representação diagramática, complementada por especificações textuais. A cada meta identificada nos cenários será associado um modelo de tarefas, que consiste em uma decomposição hierárquica das tarefas e subtarefas necessárias para atingi-la. Estas tarefas podem ser organizadas nos seguintes tipos de estruturas: seqüenciais, independentes de ordem, alternativas e iterativas. Dependendo do ponto em que se pára a decomposição das tarefas, existem ações tão simples que poderão em um passo seguinte ser mapeadas diretamente a um elemento de interface ou interação. Estas ações são representadas no modelo como operadores. O objetivo da representação diagramática é dar uma visão geral das metas e sua hierarquia de tarefas. A Figura 1 apresenta a representação da meta ressaltada no cenário descrito. META A Consultar documento Cenário Associado: cenário 1 Papéis: visitante, membro A Consultar documentos Sair 1 Efetuar login 2 Buscar documentos 3 Verificar resultado * da busca 1 Fornecer login 2 Fornecer senha 1? Informar critérios 2? Escolher forma de apresentação 1 Examinar resultado 2 Escolher documento 3 Visualizar * (documento) (a) <<Visualizar (OBJETO)>> Legenda Meta Estereótipo A B Ler (OBJETO) Imprimir (OBJETO) C Salvar (OBJETO) Tarefa Iteração * Operador Seleção (b) Figura 1. Representação diagramática da meta A, Consultar documentos (a) e detalhamento do estereótipo usado em A.3.3, Visualizar(objeto) (b) Todos os elementos do modelo de tarefas (meta, tarefas, operadores) devem ser expressos do ponto de vista do usuário (como Consultar documentos, Efetuar login, Fornecer login). Há marcações especiais para indicar a que tipo de estrutura estão associadas

45 tarefas ou operadores (números para estruturas seqüenciais, números e? para independentes de ordem, letra e para alternativas e * para iterativas). Algumas subtarefas podem ser efetuadas em qualquer ponto da realização da meta. Estas tarefas, chamadas ubíquas, são representadas por um círculo preenchido (como Sair). Outras dependem de (pré-)condições que precisam ser satisfeitas para que se possa dar início à tarefa. Estas pré-condições são representadas no modelo utilizando-se callouts ligados à tarefa correspondente. Com freqüência, a estrutura de algumas tarefas pode ser reutilizada como parte de diversas outras. Neste caso, elas são definidas como estereótipos, que são representados por um retângulo com bordas duplas. Uma vez criado este estereótipo, pode-se então utilizá-lo no modelo de qualquer tarefa, passando-se os parâmetros especificados, quando necessário (como <<Visualizar (OBJETO)>>). Esta representação diagramática, embora apresente a hierarquização das tarefas, não apresenta as informações (ou signos) nela apresentadas ou manipuladas, nem os tipos de prevenção e tratamento de erro vinculados a cada tarefa. Sendo assim, a representação diagramática é complementada com uma especificação textual. Dentro de nossa proposta de Engenharia Semiótica, os signos têm um papel fundamental na construção de linguagens de interfaces, o qual será retomado mais adiante. Cada signo que for utilizado em apresentação (dado de output) é representado por seu nome seguido de ponto de exclamação (signo1!). Já um signo correspondente a um dado que será fornecido ou manipulado pelo usuário (dado de input) é representado por seu nome seguido de ponto de interrogação (signo2?). Durante a realização das tarefas, pode haver erros do usuário ou do próprio sistema. Para cada tarefa, deve-se especificar os tipos de prevenção e tratamento de erro que podem ocorrer. São propostos seis tipos de prevenção e tratamento de erro: prevenção passiva: Erros que devem ser prevenidos por documentação (por exemplo, o usuário não possui acesso ao sistema). prevenção ativa: Erros que devem ser prevenidos ativamente pelo sistema (por exemplo, impedir ou obrigar que certa tarefa seja realizada. No modelo de interface 1, isto poderá ser mapeado em: habilitar ou desabilitar botões de acordo com o status atual da aplicação; impedir que o usuário digite letras ou símbolos em campos numéricos; e assim por diante). alerta: Situações que o sistema consegue detectar como sendo erros em potencial, mas cuja decisão recai sobre o usuário. Geralmente são realizados na interface por mensagens de confirmação (por exemplo, arquivo já existe, deseja sobrescrever?). captura de erro: Erros que são identificados pelo sistema e devem ser notificados ao usuário, sem que haja qualquer passo corretivo possível (por exemplo, o arquivo está corrompido). 1 O modelo de interface é aquele que, dado um modelo de interação definindo abstratamente as conversas entre usuários e aplicação e seus efeitos pragmáticos, representa os elementos e estruturas que concretamente traduzirão e viabilizarão estas conversas nas interfaces fisicamente perceptíveis da aplicação.

46 tratamento apoiado: Erros que devem ser tratados pelo usuário com apoio do sistema (por exemplo, apresentar uma mensagem de erro e uma oportunidade para o usuário corrigir o erro). tratamento automático: Erros que devem ser tratados pelo sistema (por exemplo, autosave & recovery). As tarefas do diagrama da Figura 1 poderiam ser detalhadas da seguinte forma: Meta A: Consultar documentos A.1.1 Fornecer login SIGNO: usuário.login? TRATAMENTO APOIADO: login incorreto A.1.2 Fornecer senha SIGNO: usuário.senha? TRATAMENTO APOIADO: senha incorreta A.2.1 Informar critérios SIGNOS: documento.área?, documento.título?, documento.autor?, documento.data? A.2.2 Escolher forma de apresentação SIGNO: forma de apresentação? A.3.1 Examinar resultado da busca SIGNO: conjunto(documento.*, 1..n)! A.3.2 Escolher documento SIGNO: documento? 5 Modelagem de Interação A partir da consolidação do modelo de tarefas, projeta-se a interação. Tradicionalmente, os modelos de interação em IHC foram concebidos privilegiando certos estilos de interação. Por exemplo, UAN privilegia manipulação direta, enquanto TAG e CLG privilegiam linguagens de comando. No entanto, considerando a rápida evolução das tecnologias de interação, é fundamental modelar a interação em um nível mais alto de abstração, sem incluir detalhes de interface que tornem a notação complexa e de difícil compreensão. O objetivo aqui é permitir a reflexão sobre o design [Schön 1983], sem especificar ainda os storyboards ou a interface propriamente dita. A metáfora que utilizamos para a construção do modelo proposto é a de interação como conversas que os usuários podem travar com o sistema [Brennan 1990]. Acreditamos que a metáfora de interação como conversação seja uma metáfora poderosa, que sirva igualmente bem para projetar a interação em diferentes ambientes ou dispositivos. Para projetar todas as possíveis conversas, propomos utilizar um diagrama de interação complementado por especificações textuais. Os elementos básicos de um diagrama de interação são cenas, processos do sistema e processos externos. Uma cena corresponde a uma entidade (componente estruturado) de interface, tal como tela, janela ou página, na qual podem ocorrer um ou mais diálogos entre usuário e sistema, sendo todos sobre um mesmo tópico. Cada diálogo faz referência a um ou mais signos, que podem refletir ou alterar o estado da conversa. Quando ocorre uma mudança de tópico na conversa, temos uma transição entre cenas. Esta transição pode levar o usuário de uma cena a outra diretamente, ou mediado por um processo do sistema. O objetivo do modelo diagramático de interação é representar as conversas entre usuário e sistema, dando uma visão global aos designers do discurso interativo como

47 um todo. A Figura 2 apresenta a representação da interação correspondente à meta Consultar documentos. Browser [fornece URL] _busca F e _login F _login = T [buscar documento] Legenda Cena (fala do usuário) Efetuar login Buscar documentos Processo (fala do sistema) A.1 [fornecer login e senha] [confirmar] Processa login erro: login incorreto ou senha incorreta _login F sucesso: _login T _busca=t [examinar documentos encontrados] A.2 A.3.1 [informar critérios] [escolher forma de apresentação] [confirmar] Busca documentos Examinar resultado da busca sucesso: documento encontrado _busca T nenhum documento encontrado _busca F [escolher documento] tarefa relacionada A.3.3 Figura 2. Representação diagramática do modelo de interação Cena ubíqua transição: pré-condições [fala do usuário] pós-condições Visualizar (documento) Uma cena descreve o tópico dos diálogos que podem nela ocorrer (como Efetuar login). Os diálogos que ocorrem em uma cena também podem ser descritos, entre colchetes, separados do nome da cena por uma linha horizontal (como [fornecer login e senha]). Um processo do sistema é representado por um retângulo simples, contendo sua descrição (como Processa login). As transições entre cenas e processos do sistema são representadas por setas direcionadas e com rótulos. O rótulo de uma transição que sai de uma cena corresponde ao enunciado do usuário que causa a transição (como [escolher documento]). Já o rótulo de uma transição que sai de um processo do sistema corresponde ao resultado do processamento (como sucesso: documento encontrado). Caso haja pré- e pós-condições para que uma transição seja feita, estas devem estar antes e depois do rótulo da transição, respectivamente. Com freqüência, as possibilidades de interação, bem como o comportamento de cada cena, variam conforme o estado atual da aplicação. Quando isto ocorre, precisamos definir signos de controle que correspondem a determinados estados da aplicação (como _busca). A correspondência entre cenas e tarefas deve ser feita utilizando-se um retângulo de cor cinza representando a tarefa que engloba a(s) cena(s). Este elemento é essencial para aumentar a rastreabilidade entre os modelos. Algumas cenas podem ser acessadas em qualquer ponto da aplicação, ou seja, a partir de qualquer outra cena. O acesso a estas cenas, chamado ubíquo, é marcado por uma transição a partir de uma cena vazia preenchida de cor cinza. Assim como no modelo de tarefas, existem trechos de interação que podem ser reutilizados em diversos diagramas. Para estes trechos, criam-se estereótipos, que são diagramas parametrizados, representados por um retângulo com bordas duplas arredondadas (como Visualizar(documento)).

48 Observa-se que, no mapeamento do modelo de tarefas para o modelo de interação, alguns operadores tornam-se diálogos (como [fornecer login e senha]), enquanto outros tornam-se transições entre cenas (como [escolher documento]). Como complementação do diagrama de interação, é necessário definir em detalhes cada diálogo, incluindo os tipos de signos de interface nele contidos e informações adicionais como obrigatoriedade de signos e presença de valores default. O quadro a seguir ilustra os detalhes da cena Buscar documento. Buscar documentos [informar critérios] { documento.título? <texto livre ou escolha simples: últimos valores fornecidos> documento.autor? <texto livre ou escolha simples: últimos valores fornecidos> documento.área? <texto livre ou escolha simples: últimos valores fornecidos> documento.data? <texto livre; default:mês/ano atual> } usuário fornece valor para no mínimo 1 signo [escolher forma de apresentação] { forma de apresentação? <escolha simples: relatório, tabela; default=relatório; obrigatório> } Os signos que aparecem na representação textual do modelo de interação são os mesmos que estão representados no modelo de tarefas. Enquanto no modelo de tarefas eles aparecem ligados a uma atividade (tarefa, subtarefa ou operador), no modelo de interação eles aparecem como foco de falas de usuário ou sistema, contextualizadas pelos diálogos e cenas que compõem. O modelo de interação proposto não apresenta detalhes de interface ou de plataforma tecnológica. Entretanto, os projetistas devem levar em consideração tais fatores, pois as características do ambiente computacional em que o sistema deverá executar determinam se uma solução é ou não adequada àquele ambiente. Em outras palavras, as decisões de design dependem do estilo de interface e da tecnologia, mas não sua representação. Podemos exemplificar os tipos de decisões tomadas com base no modelo de interação através de duas situações distintas: Exemplo 1: resultado negativo de busca Quando nenhum documento é encontrado em uma busca, na solução inicial o usuário receberia uma mensagem indicando o insucesso da busca, e então seria levado novamente à cena Buscar documentos, para tentar realizar nova busca (Figura 3a). Esta solução, embora bastante comum no ambiente Windows, era inadequada ao ambiente Web, no qual a razão custo/clique é mais alta. Sendo assim, optou-se por retornar diretamente à cena Buscar documentos (Figura 3b). Note que esta cena, ao ser apresentada ao usuário, pode sofrer mudanças que indiquem o ponto de origem desta conversa: 1) uma fala do usuário solicitando uma busca; ou 2) uma resposta do sistema, em cujo caso deve apresentar uma mensagem indicando o insucesso da busca.

49 Buscar documentos [informar critérios] [escolher forma de apresentação] [confirmar] Busca documentos nenhum documento encontrado MENSAGEM nenhum documento encontrado A.2 (3a) [OK] A.2 Buscar documentos [informar critérios] [escolher forma de apresentação] [confirmar] Busca documentos (3b) nenhum documento encontrado _busca F Figura 3. Soluções alternativas de interação para indicar um resultado de busca negativo (nenhum documento encontrado). Exemplo 2: acesso ao resultado (bem-sucedido) de busca Quando a busca é bem sucedida, ou seja, quando há documentos encontrados, a solução de design investigada inicialmente consistia em permitir o acesso ao resultado da busca logo após a própria busca ou a partir da visualização de um dos documentos nela encontrados (destaque na Figura 4a). Entretanto, os projetistas julgaram útil manter a lista de documentos encontrados disponível durante toda a sessão, possibilitando futuras consultas do usuário a esta lista (acesso ubíquo para Examinar resultado da busca, destacado na Figura 4b). Para esta última solução, foi necessário introduzir um signo de controle _busca, que indica se há ou não um resultado de busca válido. Busca documentos Examinar resultado da busca sucesso: documento(s) encontrado(s) [examinar documentos encontrados] Visualizar (documento) A.3.1 A.3.3 [escolher documento] (4a)

50 _busca=t [examinar documentos encontrados] Busca documentos sucesso: documento(s) encontrado(s) _busca T Examinar resultado da busca Visualizar (documento) A.3.1 A.3.3 [escolher documento] (4b) Figura 4. Soluções alternativas de projeto de interação para indicar acessos distintos ao resultado de busca. As decisões de design que são tomadas durante a construção do modelo de interação precisam, com freqüência, ser apresentadas aos usuários para sua apreciação. Para isto, pode ser necessário gerar cenários que reflitam as alternativas de solução propostas. Para avaliar a opinião dos usuários sobre as alternativas apresentadas nas Figuras 3 e 4, cenários foram gerados e apresentados aos usuários, que optaram, junto com os projetistas, pelas opções (b), tal como apresentado na Figura 2. 6 Discussão A utilização de modelos de IHC no projeto de sistemas interativos é essencial para permitir que os designers reflitam sobre suas soluções desde as etapas iniciais de projeto, e não apenas como avaliação pós-implementação. No entanto, abordagens correntes de modo geral tendem a utilizar modelos de tarefas complexos para abranger diversos níveis de abstração, o que dificulta a compreensão da solução. Nossa proposta é utilizar modelos mais simples, cada qual com um foco bem definido: um modelo de tarefas focando a decomposição hierárquica das atividades do usuário, e um modelo de interação focando as estruturas discursivas projetadas pelo designer. A conexão entre os modelos apresentados é regulada por dois princípios semióticos: a Abstração Interpretativa e o Contínuo Semiótico [de Souza et al. 2001]. Para explicar estes princípios, consideramos o nível de abstração das representações utilizadas em IHC como ilustrado na Figura 5: alto cenários modelos de tarefas modelos de interação especificação da interface (storyboards) linguagem de implementação baixo linguagem de máquina Figura 5. Esquema de níveis de abstração das linguagens de representação utilizadas em sistemas interativos.

51 O princípio de Abstração Interpretativa requer que um modelo de um nível mais alto possa ser compreendido por seu leitor sem que este precise conhecer ou compreender o modelo correspondente em um nível mais baixo (ou sua linguagem de representação). Por exemplo, um modelo de tarefas deve ser compreensível em si, sem qualquer dependência do conhecimento ou capacidade de interpretação do modelo de interação correspondente. O princípio de Contínuo Semiótico requer que, não apenas os modelos sigam o princípio de Abstração Interpretativa (p.ex., do modelo de tarefas para o modelo de interação e deste para a especificação da interface), mas também que um usuário que conheça a linguagem de representação de modelos em diferentes níveis de abstração seja sempre capaz de traduzir corretamente um elemento ou estrutura do modelo de mais baixo nível de abstração em termos de elementos ou estruturas do modelo de mais alto nível de abstração. Por exemplo, um projetista que leia o modelo de interação deve ser capaz de responder a que elementos ou estruturas do modelo de tarefas está associada uma determinada conversa. É por isto que a presença dos signos na especificação dos modelos é tão importante para a Engenharia Semiótica. Os signos são o fio condutor deste processo de tradução entre níveis distintos de abstração. Já o princípio da Abstração Interpretativa explica porque é tão importante ter-se a especificação das condições de erro (e seu tratamento) nos modelos de IHC. É isto que vai levar o designer a cuidar para que a interface sempre dê ao usuário explicações, instruções e condições necessárias e suficientes para que ele saia de uma situaçãoproblema sem ter de conhecer detalhes do sistema operacional, da linguagem de implementação ou outros componentes que não raramente despontam nas mensagens de erro das aplicações de hoje. O seguimento destes dois princípios não apenas trata da rastreabilidade entre os modelos, mas também da adequação dos cortes realizados na definição dos níveis de abstração. Conforme mencionado na introdução deste artigo, os modelos de design de IHC descritos foram utilizados no reprojeto e no projeto inicial de sistemas interativos em ambientes distintos. Dois destes projetos caracterizam-se por pertencer a domínios não triviais, difíceis de serem compreendidos e modelados: aplicação de redes neurais no reconhecimento de padrões litológicos e aplicação multi-usuário para anotações e avaliações de documentos. O uso de modelos permitiu um entendimento mais profundo e organizado sobre o domínio, e potencializou a reflexão sobre soluções de design alternativas, provendo melhores insumos para a tomada de decisões por parte da equipe. No primeiro projeto, os modelos, acompanhados por uma breve descrição da notação, foram fornecidos por dois especialistas em IHC para os membros da equipe de projeto responsáveis por ratificar ou retificar a solução junto ao cliente. Com base nos modelos, foi possível refletir e discutir sobre as soluções dadas aos problemas apresentados, antes de partir para a criação dos storyboards ou para a implementação. Os modelos utilizados propiciaram a reflexão em ação [Schön 1983]. Esta reflexão ocorre quando se utiliza qualquer representação de modelos de design. Entretanto, a maior parte dos modelos existentes costuma representar soluções em um baixo nível de abstração onde se omitem aspectos importantes da solução, tais como a representação de falhas e cursos alternativos e dos diálogos travados entre usuário e sistema. Em particular, esta conversa permite refletir sobre os possíveis caminhos de

52 interação, que incluem os diálogos entre usuário e sistema, pois na medida em que a modelagem vai sendo realizada, o designer consegue perceber mais claramente os efeitos de suas decisões de design e, assim, determinar soluções mais adequadas à situação em questão. Pôde-se observar que a notação proposta para a modelagem de interação não apresentou dificuldades para ser utilizada pelos desenvolvedores, mas seu uso na criação das soluções apresentou dificuldades iniciais, principalmente pela ausência de heurísticas que orientassem o mapeamento ou transporte dos elementos representados no modelo de tarefas. A ação corretiva tomada pelos proponentes destes modelos foi oferecer uma breve instrução aos designers, que então prosseguiram sem dificuldades. Além disto, observou-se positivamente que o design pode ser efetuado tanto por uma única pessoa como por uma equipe. Por exemplo, parte de uma equipe pode fazer o modelo de tarefas e outra o de interação, sem que haja dúvidas sobre os modelos em si. Foi detectada também alguma interseção entre dois dos projetos investigados. De posse dos modelos de um deles, o designer do outro pôde reaproveitar partes dos modelos no seu próprio projeto, o que dá uma indicação de que o requisito de re-uso foi neste caso promissoramente satisfeito. Os projetos citados encontram-se em fase de implementação. Posteriormente, a qualidade de uso dos sistemas produzidos será avaliada, fornecendo uma base para a análise de custo/benefício da utilização dos modelos propostos. 7 Considerações Finais O objetivo dos modelos aqui apresentados é apoiar o design, fornecendo representações que favorecem a compreensão do domínio e das tarefas (modelo de tarefas), bem como a reflexão sobre soluções alternativas (modelo de interação). Com a representação diagramática utilizada na modelagem de tarefas, conseguiu-se uma visão global das atividades do usuário, do ponto de vista do usuário. A representação textual complementar permitiu explicitar os signos usados e o tipo de prevenção e tratamento de erros em cada tarefa, fornecendo subsídios para a concepção da solução de interação. O modelo de interação foi concebido considerando-se a importância de se manter uma referência entre seus elementos e os elementos do modelo de tarefas. Esta referência pretende assegurar a rastreabilidade entre os modelos, facilitando a avaliação do impacto de evolução ou mudanças que possam ocorrer, bem como a manutenção da consistência entre modelos, a cada nova versão. Um fator determinante na construção do modelo de interação foi sua independência das questões relacionadas a interface, mantendo a notação independente da tecnologia e da plataforma a ser utilizada. Esta consideração não apenas facilita o re-uso de modelos, como também evita que decisões sobre a interface sejam tomadas prematuramente, dificultando a exploração de soluções alternativas por parte dos projetistas. O foco atual desta pesquisa é a utilização destes modelos para a construção de bases de padrões e anti-padrões de tarefas e de interação, voltados para determinados domínios e tecnologias. Estes padrões devem ser utilizados na geração de protótipos que serão avaliados, de forma a qualificá-los quanto à sua adequação e aplicabilidade. Está em andamento uma investigação sobre a utilização destes modelos em ambientes multi-usuários síncronos, tomando como estudo de caso um ambiente de colaboração

53 através de vídeo-conferência. Iniciou-se também uma investigação sobre a integração destes modelos com modelos de especificação de sistemas utilizados amplamente na Engenharia de Software, visando melhorar a qualidade do design de IHC sem causar um impacto negativo no ciclo de desenvolvimento de software. Referências Annett, J., & Duncan, K. D. (1967). Task analysis and training design. Journal of Occupational Psychology, 41, Beyer, H. e Holtzblatt, K. (1998) Contextual Design: Defining Customer-Centered Systems. San Francisco, CA: Morgan Kaufmann Publishers, Inc. Brennan, S. (1990) Conversation as Direct Manipulation in B. Laurel (ed.) The Art of Human-Computer Interaction. Reading, MA: Addison-Wesley. Card, S., Moran, T. e Newell, A. (1983) The Psychology of Human-Computer Interaction, Lawrence Erlbaum. Carroll, J. M. (ed) (1995). Scenario-based design: envisioning work and technology in system development, New York, Wiley. de Souza, C.S., Barbosa, S.D.J., da Silva, S.R.P. (2001) Semiotic Engineering Principles for Evaluating End-user Programming Environments, Interacting with Computers, 13-4, pp Elsevier. Hix, D. and Hartson, H. (1993) Developing User Interfaces: Ensuring Usability Through Product and Process. John Wiley and Sons. Johnson, P., Johnson, H., Waddington, R., Shouls, A. (1988) Task related Knowledge Structures: Analysis, Modelling, and applications. Em Proceedings of HCI 88, Cambridge University Press. Moran, T. (1981) The Command Language Grammars: a representation for the user interface of interactive computer systems. Em International Journal of Man- Machine Studies 15:3-50, Academic Press. Norman, D. e Draper, S. (eds., 1986) User Centered System Design. Hillsdale, NJ. Lawrence Erlbaum. Payne, S. e Green, T.R.G. (1989) Task-action grammar: the model and its developments. Em D. Diaper (ed.) Task Analysis for Human-Computer Interaction. Chichester: Ellis Horwood. Paternò, F. (2000) Model-Based Design and Evaluation of Interactive Applications, London, Springer-Verlag. Preece, J., Rogers, Y., Sharp, E., Benyon, D., Holland, S., Carey, T. (1994) Human- Computer Interaction, Addison-Wesley. Scapin, D. e Pierret-Golbreich, C. (1989) Towards a method for task description, Proceedings of Work with Display Units Conference, Montreal, Canada, Elsevier. Schön, D. (1983) The Reflective Practitioner: How Professionals Think in Action, New York, Basic Books. van der Veer, G.C., Lenting, B.F. e Bergevoet, B.A.J. (1996) GTA:Groupware Task Analysis - Modeling Complexity, Acta Psychologica, 91, 1996, pp

54 Evaluating Usability of Information Visualization Techniques Carla M. Dal Sasso Freitas 1, Paulo R. G. Luzzardi 1,2, Ricardo A. Cava 1,2, Marco A. A. Winckler 3, Marcelo S. Pimenta 1, Luciana P. Nedel 1 1 PPGC/Instituto de Informática Univ. Federal do Rio Grande do Sul (UFRGS) Caixa Postal Porto Alegre RS Brazil 2 Universidade Católica de Pelotas, Pelotas, RS, Brazil 3 LIHS Université Toulouse 1, Toulouse, France {carla,mpimenta,nedel}@inf.ufrgs.br {cava,luzzardi}@atlas.ucpel.tche.br winckler@univ-tlse1.fr Abstract. Several information visualization techniques have been developed in the last few years due to the need of representing and analyzing the huge amount of data generated by several applications or made available through the World Wide Web. These techniques are usually interactive and provided as part of a graphical user interface. Information visualization techniques are usually reported showing their use in experimental situations, employing some kind of analysis. Nevertheless, few studies have specifically addressed the evaluation of such techniques. This paper reports our results towards the definition of criteria for evaluating information visualization techniques, addressing evaluation of visual representations and interaction mechanisms. Resumo. Várias técnicas de visualização de informações foram desenvolvidas nos últimos anos devido a necessidade de representar e analisar a grande quantidade de informações geradas por diversas aplicações ou disponíveis através da World Wide Web. Estas técnicas são geralmente interativas e fornecidas como parte de uma interface gráfica. Técnicas de visualização de informações são normalmente relatadas analisando seu uso em situações experimentais em geral limitadas. Entretanto, poucos estudos tratam efetivamente da avaliação dessas técnicas. O presente trabalho apresenta resultados na direção da definição de critérios para avaliar técnicas de visualização, em relação a representações visuais e mecanismos de interação. 1. Introduction and motivation In the last few years the increasing volume of information provided by several applications, different instruments and mainly the Web has lead to the development of techniques for selecting among a bulk of data the subset of information that is relevant for a particular goal or need. Research on visual query systems, data mining and interactive visualization techniques has resulted in a wide variety of visual presentation and interaction techniques that can be applied in different situations. However, although there is a great variety of models and techniques for information visualization [Card et al. 1999], each application requires a particular study

55 in order to determine if the selected technique is useful and usable. The type of data that should be represented and the user tasks or analysis process that the visualization should help or support usually guides these studies. By observing several applications it has become evident that we cannot separate the visual aspects of both data representation and graphical interface from the interaction mechanisms that help a user to browse and query the data set through its visual representation. Moreover, it is clear that evaluating these two aspects is an important issue that must be addressed with different approaches including, of course, empirical tests with users. Potential users of information visualization often have their own analysis tools (statistical ones, for example) and are not aware of the benefits of visualization techniques as a first phase in the data analysis process. Besides visual representation characteristics and interaction mechanisms, a third aspect should concern the use of an information visualization technique as the core of an application interface: data usability. Usually, usability is a term employed to describe the quality of use of applications by end-users [Bevan 1995]. In the context of interfaces for information visualization users not only interact with widgets on the interface but also with data supporting decision-making, which could be affected by the way information is presented. Due the nature of gathering or processing data, noise could be included in the data set affecting original data. In addition, a huge amount of information must be cut and summarized to be useful for supporting decision-making; even though the kind of information processing could alter the quality of original data set. These problems are not related to interaction mechanisms provided by the interface but with the data processing itself. That is why we use the term data usability to describe quality of information or quality of data in the context of information visualization applications. Data usability can be associated to three principles: a) data reliability, which describes the feasibility of the gathering data process as well as the confidence level, including interval for errors, etc. that can cause distortion between reality and model (reality represented by the system); b) minimal impact on data changing, i.e., the system must avoid changing the information and it must allow recovering original information whenever it is needed. However, in practice, this data stability is not feasible because frequently data must have to be adapted to visualization constraints such as the reduction of dimension when presenting n-dimensional data in a 2D or 3D visualization, for example. This 2D or 3D representation breaks down the usability of original data. It is clear that we cannot avoid some changes during the visualization process but we can try to reduce their impact; and c) support decision-making, which means that data representation should be understandable by end-users and help them to make decisions. Since information visualization is intended to provide insight from data, it becomes clear that both visual representation and interaction techniques must not affect the ways the user needs to use the data in a variety of analysis procedures. Based on the above discussion, we separate usability issues in three main categories: i) visual representation usability, referring to the expressiveness and quality of the resulting image; ii) interface usability, related to the set of interaction mechanisms provided to users so they can interact with data through the visual

56 representation; and iii) data usability, devoted mainly to the quality of data for supporting users tasks. Our approach is to link interface usability knowledge, concepts and methods with evaluation of the expressiveness, semantic content, and interaction facilities of visualization techniques. The first step was to define criteria for the evaluation of visual representations and interaction mechanisms provided by different techniques. We are investigating classical techniques employed for evaluating user interfaces (for example, usability inspection methods and user testing) in order to select an adequate framework for a methodology of usability testing at all the three levels mentioned above. At present, we have empirical evidences collected from case studies suggesting that we can distinguish these three categories. The paper is organized as follows. Section 2 presents a further discussion on usability methods and a framework for classifying information visualization techniques. Section 3 addresses the set of criteria that should be considered when evaluating information visualization techniques, whereas section 4 reports a case study on the evaluation of a specific visualization technique. Finally, section 5 discusses our contribution when compared to other reports on the issue of evaluating visualization techniques, and concludes stating what should be done next in order to advance towards a usability method tailored to information visualization techniques. 2. Usability methods and information visualization techniques Usability evaluation methods have been developed for many years in order to evaluate the efficiency, interaction flexibility, interaction robustness, and quality of use of user interfaces. Most methods are based on user testing [Rubin 1994] where usability is measured by observation of users interacting with the interface. Other usability evaluation methods are based on the inspection of interfaces by an expert, which is able to recognize usability problems [Nielsen and Mack 1994]. The main aim of usability evaluation is to identify problems that avoid/interfere with users tasks, causing stress or reducing user performance. These techniques are quite efficient for evaluating usability in interface when concrete tasks are considered. However it is much harder to evaluate usability when abstract tasks such as understand data or make decision based on information are considered. In addition, interfaces for information visualization include a set of 2D and 3D structures (such as 3D objects, polygons, scenarios and virtual worlds) that are unusual in most WIMP interfaces. As a consequence, it is much more difficult to describe and to identify usability problems on this kind of interface than in WIMP ones. The absence of criteria for evaluating information visualization interface is another great barrier since most metrics used to evaluate usability such as accomplishment of tasks and user performance are less important for such interfaces where the most important goal could be measured by the effective usage of information. While most traditional evaluation methods fail to provide useful results on usability evaluation of interfaces for information visualization there are only a few experiences trying to evaluate aspects of this kind of interface. Recently the naming time method, a special kind of usability evaluation method based on user testing, was used to evaluate the effect of the reduction of quality of 3D images and the quality of information provided [Watson et al. 2000]. That study has demonstrated the use of some cognitive aspects of visual representation quality and user performance related to the

57 time spent for identifying objects and understanding information. Some other related works are discussed in Section 5. In order to establish a framework either for facilitating the understanding of information visualization or for evaluating, and consequently comparing and choosing among different techniques, several authors have distinguished classes of information visualization techniques [Shneiderman 1996; Card and Mackinlay 1997; Chi and Reidl 1998]. We can separate techniques regarding their facilities to display and allow interaction with one-dimensional, two-dimensional, three-dimensional or multidimensional data, as well as temporal, hierarchical or multilinked data. In this work, we follow Freitas et al. (2001) and distinguish information visualization techniques in two broad groups: i) techniques for displaying data characteristics and values and ii) techniques for displaying data structure and relationships. Both groups use visual representations dependent on the data that should be displayed. In the first group, we include all the traditional function graphs, icons and glyph displays, pseudo-color, contour lines and vector maps, useful either for displaying entity-related data and spatial data. The second group is actually the class of techniques that deployed the area of information visualization. The display of linear structures (documents, texts, temporal data, etc.) was the motivation for techniques like Bifocal Display [Spence and Apperley 1982] and Perspective Wall [Mackinlay et al. 1991]. Hierarchies and graphs can be displayed using geometric objects implementing different metaphors [Robertson et al. 1991; Tesler and Strasnick 1992], space-filling approaches like Treemaps [Johnson and Shneiderman 1991] and Information Slices [Andrews and Heidegger 1998], and node-edge diagrams [Lamping et al. 1991; Munzner 1997]. When we turn our attention to the needs of interacting with the data through visual representations, we find three main classes of interaction mechanisms that should be considered: help and orientation mechanisms, browsing and searching/querying tools, and data reduction functions. We are not concerned here in describing which reported technique presents which interaction functions but in identifying characteristics that can be used to evaluate and compare techniques by means of interface usability methods. 3. Evaluation of information visualization techniques The evaluation of information visualization techniques should be based in both testing the visual representation and the interaction mechanisms. For example, usual and critical aspects of visual representations are object occlusion and visual disorder, while visual disorientation is caused by changes in the visual representations due to some user action. Thus, there are situations when one aspect (interaction) affects the other (visual representation). All such characteristics should be verified in order to evaluate a specific visualization technique. Our approach is to establish two sets of criteria, with associated metrics: the first being for usability testing of visual representations and the second one, for evaluating interaction mechanisms. Two initial sets were defined based on case studies with different visualization techniques. Then, those two sets were refined taking into account characteristics found mainly in information visualization techniques, thus excluding

58 many scientific data visualization techniques. The resulting two sets are examined in the following sections Visual representation criteria Figure 1 presents a diagram depicting criteria for evaluating visual representations. They are commented in the following paragraphs along with examples of metrics, when appropriate. Figure 1. Criteria for the evaluation of visual representations of information visualizations techniques. The semantic contents of the data to be displayed may be affected by limitations, which are geometric or visual constraints like size of the display or maximum number of data elements, imposed by the visual representation as well as by its cognitive complexity. Moreover, the cognitive complexity of an image can be measured by data density, data dimension and by the relevance of the displayed information. For example, the number of points in a graph can measure data density, while data dimension is related to the number of dimensions simultaneously displayed. Spatial organization is related to the overall layout of a visual representation, which comprises analyzing how easy it is to locate an information element in the display and to be aware of the overall distribution of information elements in the representation. Locating an information element can be hard if some objects are occluded by others, and if the layout does not follow a logical organization depending on some characteristics of the data elements. So, degree of object occlusion and logical order are characteristics to be measured in the visual representation. The spatial orientation, which contributes for the user being aware of the distribution of information

59 elements, is dependent on the display of the reference context while showing a specific element in detail. Additional codification of information is another aspect one can use for evaluating visualization techniques. Besides the mapping of data elements to visual elements, the use of additional symbols or realistic characteristics can be used either for building alternative representations (like groups of elements in clustered representations) or to aid in the perception of information elements. Finally, an important aspect of information visualization techniques is the result of rebuilding part or the entire visual representation after a user action. The time the technique takes to do that and the changes in spatial organization of the resulting image are important factors that can affect the perception of information Interaction mechanisms criteria The set of criteria for evaluating interaction mechanisms is represented in Figure 2 and ultimately comprises functions that support common user tasks. The analysis of interaction mechanisms provided by an information visualization technique corresponds to a usability test of the tool that implements the technique. Figure 2. Criteria for the evaluation of interaction mechanisms. Functions like support for the user to control level of details, redo/undo of user actions and representation of additional information (for example, the path a user followed while navigating in a complex structure) define help and user orientation features, for which usability should be evaluated. Considering navigation and querying features, techniques should be analyzed regarding the possibilities and easiness of selecting a data element, changing the user point of view, manipulating geometric representations of data elements, searching and querying for specific information, and expanding clustered/hidden data elements. A last subset of criteria is related to the data set reduction features provided by the technique. Filtering allows reduction of information shown at a certain moment, leading more rapidly to adjustment of the focus of interest, and clustering allows

60 representing a subset of data elements by means of special symbols, while pruning simply cuts off information irrelevant for the understanding of a visual representation. 4. Case study: evaluation of the Bifocal Browser We have investigated the benefits of our criteria by means of a case study. In the following subsections, we describe shortly an information visualization tool called Bifocal Browser and then we show how the criteria presented above were used for its evaluation Bifocal Browser: a short description The Bifocal Browser [Cava and Freitas 2001] is an alternative way to explore large hierarchies in a node-edge diagram, incorporating some features borrowed from spacefilling approaches [Johnson and Shneiderman 1991; Andrews and Heidegger 1998] and the hyperbolic browser [Lamping et al. 1991]. The technique is based on the focus + context approach, and uses two foci instead of one. In this technique, the hierarchy is represented as a node-edge diagram separated in two connected sub-diagrams, defining separate areas in the window: a detail area, which shows the node of interest and its subtree, and a context area, that displays its parent and siblings subtrees. Although it is not based on the hyperbolic geometry, the technique has similar characteristics. In Figure 3, the hierarchy is anchored on two main nodes called the context and detail focus, displayed at the center of the context and detail areas, respectively. The central rectangle in the right (Figure 3b) represents the detail focus at a certain moment, i.e., a node of interest, while the left one (Figure 3a) is the context focus. Thus, at the same time that it provides information on hierarchical relationships, the technique shows a detailed view of the subtree containing the node of interest. Both context focus and detail focus are located side by side separated by an arbitrary (and parameterized) distance, defining separate circular areas in the window. Once the user indicates a node as the point of interest, the whole subtree of this node is shown in the right area of the window, while its parent node and all other subtrees are displayed in the left half of the window. Each subtree is displayed in a radial layout, with the selected node at the center of a circle, and its descendants distributed in concentric circles depending on their level in the structure. In order to avoid occlusion among objects, each subtree is actually displayed in a circle sector. Nodes are displayed as rectangles with the size depending on their location in relation to the focus point. A node that is distant from the focus is shown with less detail than nodes nearer the focus, while nodes beyond a certain distance are not shown. This strategy was adopted to avoid displaying and manipulating elements that are far from the point of interest, based on the idea that a user browses a structure until reaching a specific node. Moreover, due to the reduced size these nodes would have if displayed near the border of the circle, the user probably would not point at them. A different color is used to display the subtree that has recently occupied the detail area. Also, the root node is always displayed in red, in order to keep the user aware of what level in the hierarchy is currently in the context focus. This intends to minimize a possible disorientation that might happen due to rotations and translations applied to the subtrees when the user selects another node.

61 Distribution of nodes around the root node takes into account the number of leaf nodes in each subtree. Therefore, the subtree with more leaf nodes occupies the largest sector in the circle. This rule is applied recursively to each subtree in the structure. On the other hand, in the detail area, the goal is to provide the representation of the hierarchical relationships by means of a tree with the interest node as root. To achieve this goal, nodes at the first level are uniformly distributed around the inner circle. Their subtrees, however, are displayed in sectors with size proportional to the number of leaf nodes, following the same rule applied in the context area. This difference in the layout is more evident in unbalanced trees. The selection of a node is the main interaction mechanism provided to the user; it can be applied to any node in order to bring to the detail focus the node along its subtree. This operation imposes a translation of the subtree to the detail area, as well as a rotation in the structure displayed in the context area. (a) (b) Figure 3. A hierarchy with 760 nodes Evaluating the Bifocal Browser A first analysis of the Bifocal Browser was conducted to verify the completeness and applicability of the proposed evaluation criteria. Several hierarchies were used, the larger one being a 1000-nodes hierarchy. Following a checklist containing objective questions related to criteria presented in section 3, we inspected the visual representations and performed common browsing and selection tasks. The major task in performing the analysis was to determine the metric for each criterion, since it depends both on data type and visual representation type.

62 Limitations: Geometric and visual constraints are not evident, except for the display area that is divided into two, for showing context and detailed information. Upper bound for depth is 10; deeper hierarchies are shown with pruning of elements beyond that limit. Clustering limits were not used because there is no clustering function in the Bifocal Browser. Cognitive complexity: the metrics were both the number of nodes, for data density, and a qualitative measure of legibility, in terms of occlusion of nodes. Although a large hierarchy with 1000 nodes was used, the pruning mechanism and the good distribution of elements in both areas guaranteed low occlusion and adequate legibility. Spatial organization: Analysis of spatial organization was done using qualitative measures of the easiness in locating an object and the awareness degree users have with respect to the information space. The logical order was measured in terms of user s orientation in the information space, distribution of elements in the layout, for precision and legibility, efficiency in space usage and distortion of visual elements. Occlusion of objects was calculated in terms of the percentage of nodes shown in relation to the total number of nodes in the hierarchy. The spatial orientation that directly affects awareness of the information space was measured in terms of the possibility and easiness of specifying which nodes should be displayed in the context area and which ones should appear in the detail area. In the Bifocal Browser, when a node is selected, it is moved to the detail focus and the user does not have direct control over what is displayed in the context area. Codification of additional information into visual attributes: this is practically absent in the Bifocal Browser because of the simplified representation of nodes; the only distinction between nodes is the colors used for the root node and the detail focus. No realistic techniques like shading or transparency are used for improving perception, mainly because that is not appropriate for 2D representations. There is no explicit clustering based on nodes content, but pruned subtrees are represented by a different symbol. State transition characteristics: Transitions between two consecutive representations can be done with or without animation in the Bifocal Browser. Both were rapid mainly because no huge hierarchies were used. Immediate transitions can cause a temporary spatial disorientation because the two areas, context and detail, change entirely with the new distribution of subtrees. Since the technique is not based on hyperbolic geometry, animation is accomplished by rotations and translations, which appear rather discrete. As for interaction mechanisms, usability tests conforming to some methodology were not performed. However, in a checklist style of evaluating a user interface, the criteria guided an analysis that checked the availability or absence of each feature in the browser as well as the possibility of its implementation if it is absent. Help and user orientation: The browser allows control of the level of detail since the user can select a node and see its entire subtree in the detail area. Undo operation is not directly implemented and the user needs to select the last visited node to rebuild the previous display. This is facilitated by the display of that subtree in a different color to minimize spatial disorientation that might happen when the focus changes.

63 Navigation and querying: all the features needed for browsing are implemented except for search and query. Nodes can be selected by pointing at them, which causes an automatic change in the user viewpoint as well as expansion of subtrees that might be previously pruned. Data reduction features: the Bifocal browser does not have filtering nor contentbased clustering functions. Pruning (that would be better classified as structure-based clustering, in our case) is automatic when the depth of a subtree that have to be displayed is beyond Discussion and final comments Evaluating user interfaces is usually accomplished to detect design problems in the layout as well as in the interaction. The evaluation of image quality in computer graphics applications can be done through visual inspection by experts. In information visualization techniques, interface usability issues, expressiveness of visual representation (image semantic quality) are both as important as a third issue data usability, since the main concern in this applications are to give insight to expert users regarding data they are analyzing. Our case study, although brief, demonstrates the benefits of our criteria as an important aid to the task of evaluating information visualization techniques. We have performed inspections on the Bifocal Browser based on the criteria defined in Section 3 and we could find some potential problems concerning representation and interaction usability. The main problems detected in the visual representation are the occlusion of nodes in the context area in large hierarchies and the disorientation produced by the change in the overall layout, when one selects a different node as the interest node. Although the first one is a well-known problem in node-edge diagrams, pruning and clustering (with a good symbol design for representing clusters) will for sure minimize it. The disorientation associated to state transition is overcome by animation, as mentioned earlier. Regarding interaction mechanisms, some features like filtering are missing, and the identification of nodes to point at one of them is only performed based on the name of the node. An additional attribute can be associated with color (for example, file extension, if the hierarchy is a file tree) but this is hard-coded in the current implementation and not a user-defined mapping, which would be more useful. Our approach in evaluating information visualization techniques considering criteria, which are up to now categorized by visual representation characteristics and interface usability, addresses larger issues than those reported in recently published literature. Wiss et al. (1998) describe the evaluation of three visualization techniques (Cam Trees, Information Cube and Information Landscape) based on the tasks defined by Shneiderman (1996). The authors implemented the three mentioned techniques and analyzed them in terms of which tasks they support. Brath (1997) proposes quantitative metrics to evaluate the efficiency of 3D static representations, basically graphs, thus not addressing interaction mechanisms. For each display, he measured the number of data points (for data density), number of dimensions (for cognitive complexity), occlusion rate, and identifiable data points. We included Brath's metrics in our set under the Cognitive Complexity and Spatial Organization criteria. Different visual representations provided by NIRVE (the NIST Information Retrieval Visualization Engine) have also been the subject of evaluation by Cugini et al. (2000). Usability experiments were

64 carried out to verify completion of tasks and difficulties in interaction using selected visual representations for a query result. Their goal, however, was not to set a framework for evaluating visualization techniques but to specifically test design features adopted in the alternative visual representations in relation to the cognitive load. We defined criteria which more directly relate to the usability of information visualization techniques and our criteria has been shown useful to discuss usability issues at the information visualization scenario in a broader sense. These can be used to clarify the notion of usability, which has been relatively inadequate in this domain. In so doing, we have addressed two important aspects, namely, (a) an extensive list of criteria to guide the design of usable information visualization software; and (b) an organization for structuring these criteria which can be easily extended to account for other properties or guidelines. Next step includes to thoroughly testing the criteria with non-hierarchical information, such as spatial data and virtual reality environments. Later on, different usability methods will be experimented to establish which ones are more appropriate in each situation and why. References Andrews, K. and Heidegger, H. (1998) Information Slices: Visualizing and exploring large hierarchy using cascading, semi-circular discs. In Proceedings of the IEEE Information Visualization (Late Breaking Hot Topics Procs.), Raleigh Durham, North Carolina. IEEE Computer Society, pages Bevan, N. (1995) Usability is quality of use. In: Anzai & Ogawa (eds) Proceedings of the 6th International Conference on Human Computer Interaction. Brath, R. (1997) Concept Demonstration: Metrics for Effective Information Visualization. In: Proceedings of the IEEE Symposium on Information Visualization, Phoenix, Arizona. IEEE Computer Society. pages Card, S.K., Mackinlay, J.D. and Shneiderman, B. (1999) Readings in Information Visualization - Using Visualization to Think. San Francisco, Morgan Kaufmann. Card, S.K. and Mackinlay, J. (1997) The structure of information visualization design space. In: Proceedings of the Information Visualization Symposium, Phoenix, Arizona. IEEE Computer Society, pages Cava, R.A. and Freitas, C.M.D.S. (2001) Visualizing Hierarchies using a Modified Focus+Context Technique. In Proc. of IEEE Information Visualization (Interactive Poster - Late Breaking Hot Topics Proceedings), San Diego, California. IEEE Computer Society. Chi, E.H. and Reidl, J.T. (1998) An operator interaction framework for visualization systems. In: Proceedings of the Information Visualization Symposium, Salt Lake City, Utah. IEEE Computer Society, pages Cugini, J., Laskowski, S. and Sebrechts, M. (2000) Design of 3D visualization of search results: evolution and evaluation. NIST.

65 Freitas, C.M.D.S., Chubachi, O., Luzzardi, P.R.G. and Cava, R.A. (2001) Information Visualization. Revista de Informática Teórica e Aplicada 8(2): Johnson, B. and Shneiderman, B. (1991) Tree-maps: A space-filling approach to the visualization of hierarchical information structures. In: Proceedings of the IEEE Visualization'91, San Diego, California. IEEE Computer Society, pages Lamping, J., Rao, R. and Pirolli, P. (1991) A Focus+Context Technique Based in Hyperbolic Geometry for Visualizing Large Hierarchies. In Proceedings of the CHI 95 - ACM Conference on Human Factors in Computing Systems. ACM, pages Mackinlay, J. D., Robertson, G.G. and Card, S.K., (1991) The Perspective Wall: Detail and Context Smoothly Integrated. In: Proceedings of ACM CHI'91 - ACM Conference on Human Factors in Computing Systems. ACM, pages Munzner, T. (1997) H3: Laying Out Large Directed Graphs in 3D Hyperbolic Space. In: Proceedings of the IEEE Information Visualization Symposium, Phoenix, Arizona. IEEE Computer Society Press, pages Nielsen, J. and Mack, R. L. (1994) Usability Inspection Methods. New York, John Wiley. Robertson, G., Card, S. and Mackinlay, J. (1991) Cone Trees: Animated 3D Visualizations of Hierarchical Information. In: Proceedings of ACM CHI'91 - ACM Conference on Human Factors in Computing Systems. ACM, pages Rubin, J. (1994) Handbook of Usability Testing: How to Plan, Design, and Conduct Effective Tests. New York, John Wiley. Shneiderman, B. (1996) The eyes have it: a task by data type taxonomy for information visualization. In: Proceedings of the IEEE Visual Languages, Boulder, CO. IEEE Computer Society, pages Spence, R. and Apperley, M.D. (1982) Data Base Navigation: An Office Environment for the Professional. Behaviour and Information Technology, 1(1): Tesler, H. and Strasnick, S. (1992) FSN: The 3D File System Navigator. Mountain View, Silicon Graphics. Watson, B., Friedman, A. and McGaffey, M. (2000) A. Using naming time to evaluate quality predictors for model simplification. In: Proceedings of the CHI 2000 ACM Conference on Human Factors in Computing Systems. ACM, pages Wiss, U., Carr, D. and Jonsson, H. (1998) Evaluating 3-Dimensional Information Visualization Designs. In: Proceedings of the IEEE Conference on Information Visualization, London, England. IEEE Computer Society Press, pages Acknowledgments This works has been sponsored by CNPq, FAPERGS, and CAPES.

66 Considering Human Factors in Workflow Development Lucinéia Heloisa Thom 1,2, Cirano Iochpe 1,2, Ida Gus 2 1 Instituto de Informática Universidade Federal do Rio Grande do Sul (UFRGS) Caixa Postal Porto Alegre RS Brazil 2 Projeto SINPLI Fundação Estadual de Proteção Ambiental (FEPAM), Rua Carlos Chagas Nº 55, Sala 812 Porto Alegre RS Brasil {lucineia,ciochpe}@inf.ufrgs.br, idagus@terra.com.br Abstract. This article presents a proposal to integrate organization structure analysis and human resistance identification and treatment as integral stages of a workflow development process. The main goal of the article are to emphasize that implementing a workflow causes changes to organizations and that people may resist such changes, thus making implementation more difficult. The article is based mainly on the experience of developing SINPLI an Information System for the Environmental Licensing Process. The article brings forth two main contributions, which are a) to warn the Project Team of the importance of identifying and treating human resistance during development; and b) to suggest ways of minimizing the effects such resistance has on the Software project. Resumo. Neste artigo é apresentada uma proposta de integração da análise da estrutura organizacional e da identificação e tratamento das resistências humanas como fases integrantes do processo de desenvolvimento do workflow. O principal objetivo do artigo é ressaltar que a implantação de um workflow provoca mudanças na cultura organizacional e estas mudanças podem gerar resistências por parte das pessoas, dificultando a implantação do mesmo. A base do artigo está centrada, nas experiências adquiridas no desenvolvimento do Sistema de Informação para o Processo de Licenciamento Ambiental (SINPLI). As duas principais contribuições do artigo são: alertar a Equipe de Projeto quanto à importância da identificação e do tratamento das resistências humanas durante o desenvolvimento e sugerir meios de minimizar os efeitos destas sobre o projeto de Software. 1. Introduction This article is about workflow-based Information Systems. Such Systems receive information from an organization, then treat it and distribute it [Leyman 2000]. A workflow is a type of Information System that is defined as the total or partial automatization of a business process, in which documents, information and/or tasks are sent from part to part in order to have actions taken in accordance with a set of rules and proceedings [Fischer 2001]. An analysis of the current market shows the need for greater interoperability between workflow management systems, which are different from one another

67 concerning architecture, available functionalities, modeling and concepts [Thom 2000]. In 1993, the Workflow Management Coalition was created with the goal of promoting workflow by informing about the technology and development of standards for workflow interoperability with other workflows as well as other applications. In spite of WfMC s efforts, the complexity involved in workflow development goes beyond interoperability. It is a new technology that causes changes in the organization culture. Such changes may create what Psychology defines as human resistance or resistance to change. From a psychological view, human resistance is a kind of barrier created by human beings when faced with change. Therefore, the main goal of this article is to emphasize the importance of identifying and treating human resistance in the making of a workflow application. The article is based on the experience acquired during the development of SINPLI an Information System for the Environmental Licensing Process. This Project ran from October 1998 to November 2000 and was developed by the joint efforts of the Federal University at Rio Grande do Sul (UFRGS) and the Henrique Luis Roessler State Foundation for Environmental Protection (FEPAM-RS). The Project Team had eight members, including professionals and researchers on Workflow, Databases and Psychology. Basically, this article presents a method to develop workflows that is based on the development process of SINPLI. It also defines the techniques considered by the SINPLI Project Team in identifying and treating the human resistance that emerged during the development stages. Finally, it presents a proposal for integrating organization structure analysis as a part of the workflow development process. This analysis allows identification of organization characteristics, which determine a specific kind of organization structure. At a later stage, such analysis can be used to determine organization-dependent workflow aspects. The article is structured as follows. Section 1 describes the SINPLI Project development process. Section 2 presents techniques to identify and treat human resistance taken into account on the SINPLI Project. Section 3 introduces a proposal for integrating the analysis of the organization structure as a part of the workflow development process. Section 4, then, contains conclusions and references for future work within the scope of the article analysis. 2. The SINPLI Project Development Process Environmental Licensing is one of the main processes performed by FEPAM. It determines whether a given enterprise may start up or proceed with operations in accordance with environmental requirements [Gus 1999]. The main reasons favoring the implementation of workflow at FEPAM are related to i) the dissatisfaction of management and employees concerning the performance of the Environmental Licensing process, ii) the need to add capabilities to the process and iii) the fast retrieval of information about the stage of a given Environmental Licensing process. The development of SINPLI involved several stages, analogous to those comprised in a Cascade Model Iochpe, Pressman (1995, 1995). The following text describes the approach taken for each stage.

68 During the Requirement Analysis stage, SINPLI s Project Team interviewed the sectors of the organization at length, aiming to obtain detailed knowledge of the process and its deficiencies. Because the application required access to a data base, at that point the team was divided into three: Data Base Team, Workflow Team and Change Management Team. The Data Base Team was in charge of treating the data, the Project Team captured the workflow view and the Change Management Team observed the interview and user training stages. To do so, the latter had the assistance of psychologists who investigated the cultural aspects of the organization. At the Project Stage, the Data Base Team built an Entity-Relationship Diagram (ER) and a Function Hierarchy Diagram (DHF). On its turn, the Workflow Team modeled the workflow by using the Oracle Workflow Builder. The following stages included Codifying the information and then Tests, which were run within the development environment in order to test the integrity of code when compared to the user s early requirements. When observing the development methodology used on the SINPLI Project, it can be seen that it does not explicitly contain two stages that can be fundamental in a workflow development program. Such stages are analyzing the organization structure and identifying and treating human resistance. 3. Human Resistance Within Workflow The organization culture influences the way people decide, work in groups and assess their work and that of others. When responsibilities are not clear and people perform several roles simultaneously, it is more difficult to capture and model a business process. Imposing a working standard may cause negative reactions by the employees if such standard is not compatible with the organization culture. Such reactions are manifest in many ways and become human resistance to workflow implementation. Resistance is defined by [Ferreira 1986] as the act or effect of resisting; opposition; obstacle; manner in which someone sabotages a service or activity by being unreliable to carry out its duties in a certain sector of an organization. From a Psychology viewpoint, it is understood that all forces that contribute to the stability of personality or social systems can be perceived as resistance to changes Henn and Michael (1999, 1995). The SINPLI development process allowed the identification of some techniques that can be used to minimize and treat human resistance. The coming sections give details about them. However, it should be emphasized that the purpose of this article is to report the experience gained in a real workflow application. A more generic approach will require a greater number of experiments Techniques to Identify Human Resistance The following techniques could be used to identify acts that define resistant behavior. Wave sabotaging: users present themselves publicly and formally as supporters of the cause, project or transformation. However, they seem to be worried and

69 skeptical in private conversation. Since private conversation has greater influence power than open talks, such behavior starts a negative wave. Settling down that opposes change: the change caused by the introduction of new technology creates a feeling of setting to zero the score of a game being won. Therefore, organization members tend to foster insecurity and focus on the difficulties the change will bring forth. Omitting information during the analysis stage: users hide the truth, that is, they don t say anything unless questioned. Such omission can be a result of the employees lack of knowledge about their own work. Fearing loss of power control of productivity and quality : in general, people attempt to keep the power/prestige they have by preventing the introduction of new ideas that may yield more positive effects than those of their own projects. They see all who are involved in the project as internal competition. This problem was manifest to SINPLI when attempted interviews were called off by users, mostly chief managers. Identifying resistance is a key stage for the good development of a workflow process. However, it is important that developers have the ability to minimize such resistance Techniques to Minimize Human Resistance The following techniques can be used in order to minimize emerging human resistance: Creating a Change Management Team: The Change Management Team created for SINPLI was made up of an organization psychologist and a system analyst. The Team goals were to spread the use of SINPLI at FEPAM and to develop an awareness project with general and office management in order to create support for the workflow development process; Avoiding great expectations: Great expectations can be considered a miraculous and final solution for everything that disturbs people. The earlier expectations are brought down to realistic levels, the fewer frustrations and problems there will be; Minimizing anxiety concerning the change: Anxiety should not be created before knowing what should be changed and how. This avoids creating resistance before due time; Keeping a balance of gains and losses: Think of the key people in the workflow system. Then, balance their personal gains and losses individually; Creating a computer environment: A new Division (DIS Computer and Systems Division) was created for FEPAM. This Division supported the restructuring of their computer sector. In addition, the Change Management Team developed a previous discussion and sensitization program in internal seminars, aiming to present the benefits of the workflow technology;

70 Training Program: Before starting use of the SINPLI Project, a training program raised awareness of the system. Mixed teams put users who had more knowledge of computers in contact with others who had less Techniques to Treat Human Resistance In case human resistance has already set in, some techniques can minimize its propagation or even solve it. SINPLI used the following: Addressing the causes of the conflicting behavior towards the change: the Change Management Team and the Workflow Team must check why people are reacting negatively to the change cause by the introduction of the workflow. Having analyzed it, the reasons should be addressed; Addressing the causes of regressive behavior: regressive behavior is defined as a step back in accepting the change, i.e., when working with the Change Management Team, users were in favor of implementing workflow and other changes necessary to its introduction. However, when on their own, they showed the same conflicting behavior as before. That happened in a few instances of the SINPLI development process. 4. Integrating Organization Structure Analysis as a Stage of the Workflow Development Process The organization structure sets the roles, responsibilities and distribution of activities throughout the organization Chiavenato and Mintzberg (2000, 1995). A specific kind of organization structure is defined as a set of organization features. Also, the organization structure is reflected on an organization chart that comprises the organization units and their relationship. According to Araujo and Davis (1994, 1996), organization units are, for instance, divisions, managers, helpers, departments, agencies, branches and sectors. For the purpose of this article, analyzing the organization structure means investigating the values taken by the organization features that define such structure. From that point, check which workflow aspects depend on such features. It is important to emphasize that this approach is currently being researched by us. Therefore, the topic is only presented here, but not expanded. An organization structure can be functional, divisional, hybrid, matrix-like or process-oriented [Chiavenato 1999]. Each type is determined by a set of features such as, for instance, the level of formalization in running activities of a productive process, the authority distribution, which has implications on the concentration of decisionmaking on management, and the means for communication, either written, in reports and opinions, or oral, in meetings Iochpe, Thom and Thom (2001, 2001, 2002). The ongoing research aims to analyze workflow aspects that depend on organization features. For instance, such aspects relate with: the workflow signature chain, which can be influenced by the organization s authority distribution; the means for communication, which can influence the workflow communication scheme, i.e., it is more likely the workflow will have to support the transmission of memos, opinions and reports according to the way they communicate.

71 Figure 2 has the stages that may define a workflow development process. The analysis of the organization structure is mainly linked to the stages of knowledge immersion, requirement analysis and workflow modeling. The phases Knowledge immersion, Training and Pilot were introduced in the proposed method, from the development of SINPLI. Figure 1. Workflow development methodology Table 1 presents the semantics of the stages of a workflow development process, as shown in Figure 1, which are most likely to cause emerging human resistance. It should be emphasized that no method was adopted to prevent human resistance from emerging on other stages. This mapping aims at stressing and suggesting procedures a Project Team should consider in order to minimize human resistance.

72 Stages Knowledge immersion Requirement Analysis Workflow system modeling Training Pilot 5. Conclusions Table 1 Human resistance and workflow development stages Objectives to obtain previous knowledge of the business; to make requirement analysis easier and avoid user s omitting information; to empower the Project Team with the ability to realize information omission; to make requirement analysis more objective and complete to allow detailed understanding of the business. to produce a viable workflow through which the way work is performed can be visualized, thus giving users an understanding of their roles in the system. to create a training program, aiming to form groups with less resistant users. Avoid training only top managers so that no user will feel left out by the workflow. Contrarily, the importance of each user must be emphasized; to emphasize the importance of correctly carrying out each activity to achieve the ultimate goal of the workflow, warning users of the problems arising from activity delays. to get users in touch with the workflow technology, focusing on the advantages and possibilities the workflow brings forth for the organization and for individual work as well. A workflow application can describe each activity of a business process at a concept level that facilitates the understanding and assessment of processes Leyman and Thom (2000, 2000). However, such application is placed into organizations formed by people who have a working culture and routine. Faced with this organization, workflow implementation changes the work and the way people relate. This article, based on the development of a real workflow application (SINPLI Project), has proposed the integration of organization structure analysis and the identification and treatment of human resistance as integral phases of a workflow development process. The Project Team must be aware that implementing workflow will create cultural changes on the organization and, consequently, each person affected by the change will individually evaluate his/her losses and gains concerning the success or failure of the implementation. The result of this evaluation will cause the person to support or sabotage the project. Therefore, it is important to observe change impacts constantly in order to minimize human resistance. The main contribution of this article concerns the Workflow Project Team. Considering the points under discussion, this article emphasizes that: a motivated workflow participant who likes the technology will cooperate and make a greater effort to achieve good results; the Project Team must pay special attention to the organization structure analysis stage. Learning the organization features may facilitate workflow development and increase its efficiency;

73 finally, the Project Team should take into account that one of the main aspects that make workflow successful is cooperation, which depends mostly on the participants, who are human beings with individual goals and ambitions. The approach presented in this article is currently undergoing a follow-up study regarding the organization structure analysis. That includes a thorough review of related bibliography. The next step will include the investigation of likely interferences of organization features on workflow aspects. 6. References Araujo, Luis César G. de. Organização e Métodos : Integrando comportamento, estrutura, tecnologia e estratégia. São Paulo: Atlas, 4ª ed., Chiavenato, Idalberto. Introdução à Teoria Geral da Administração. 5 ed. Rio de Janeiro: Campus, Chiavenato, Idalberto. Administração : teoria, processo e prática. 3 ed. São Paulo: Makron Books, Davis, Margaret R.; Weckler, David A. A Practical Guide To Organization Design. Boston: Crisp Publications, Ferreira, Aurélio Buarque de Holanda. Novo Dicionário da Língua Portuguesa. 2. ed. Rio de Janeiro: Nova Fronteira, Fischer, Layne. Workflow Handbook. Florida: Future Strategies Inc Gus, Ida. Relatório da Consultoria em Psicologia. Porto Alegre: SINPLI Project, p. Hehn, Herman F. Peopleware : Como Trabalhar o Fator Humano nas Implementações de Sistemas Integrados de Informação (ERP). São Paulo: Ed. Gente, Iochpe, C.; Figueiredo, Elza Marisa Paiva. Estudo das Interações Humanas no Processo de Desenvolvimento Software. In: SIMPÓSIO BRASILEIRO DE ENGENHARIA DE SOFTWARE, 9., 1995, Recife. Anais... Recife, PE: [s.n], Iochpe, Cirano; Thom, Lucinéia H.; Lopes, Filipe. Incrementando a Usabilidade de Sistemas de Workflow em Organizações: Modelagem Integrada e Redesenho de Processos de Negócio. Revista Politécnica.Gaya: Instituto Superior Politécnico de Gaya, 2001, v.4, n. 4, p , dez ISSN: Leyman, Frank; Roller, Dieter. Production Workflow : concepts and techniques. 2.nd ed. New Jersey: Prentice-Hakk, Michael, G. de. Computer Support for Cooperative Work: Computers between Users and Social Complexity. Milan: COMIC Esprit Basic Research Projetct 6255, Mintzberg, Henry. Criando Organizações Eficazes : estruturas em cinco configurações. São Paulo: Atlas, Pressman, Roger S. Engenharia de Software. São Paulo: Makron Books, Thom, Lucinéia H.; Iochpe, Cirano; GUS, Ida; VICARI, Simone. Desenvolvimento de Sistemas de Workflow Considerando Fatores Humanos e a Análise da Dinâmica

74 Organizacional. In: INTERNATIONAL SYMPOSIUM ON KNOWLEGMENT MANAGEMENT / DOCUMENT MANAGEMENT, ISKM-DM, Anais... Curitiba: Universitária Champagnat, 2000, p Thom, Lucinéia H.; Iochpe, Cirano. Relying On The Organizational Structure To Model Workflow Processes. In: International Conference on Enterprise Information Systems, ICEIS, 3, Proceedings Setúbal: Escola Superior de Tecnologia de Setúbal v.2, p Thom, Lucinéia H.; Iochpe, Cirano. Inferring Aspects Of The Organizational Structure Through Workflow Process Analysis. In: International Conference on Enterprise Information Systems, ICEIS, 4, Proceedings Ciudad Real: ICEIS Press v.2, p

75 The Bifocal Tree: a Technique for the Visualization of Hierarchical Information Structures Ricardo A. Cava 1,2.,3, Paulo R. G. Luzzardi 1,2 and Carla M. D. S. Freitas 1 1 Universidade Federal do Rio Grande do Sul, Instituto de Informática Caixa Postal Porto Alegre RS Brazil 2 Universidade Católica de Pelotas 3 Centro Federal de Educação Tecnológica Pelotas RS Brasil carla@inf.ufrgs.br, {cava,luzzardi}@atlas.ucpel.tche.br Abstract. This paper reports a new technique for visualizing hierarchies which is based on the focus + context concept, but uses two foci instead of one. The technique allows improving the presentation of details related to some item in the information space as well as the context. This is achieved by displaying the hierarchy as a node-edge diagram separated in two connected sub-diagrams. One corresponds to the subtree with the node of interest as root. The other one represents the context and contains the selected node parent and remaining subtrees. Interaction issues regarding browsing and other operations are also discussed. Resumo. Este trabalho apresenta uma nova técnica para visualização de hierarquias, a qual é baseada no conceito de foco+contexto, mas utilizando dois focos e não apenas um. A técnica apresenta vantagens na representação tanto de um item de informação em detalhe como de seu contexto. Isto é obtido pela exibição da árvore como um diagrama de nodos e arestas separado em dois sub-diagramas conectados. Um dos sub-diagramas representa a subárvore cujo nodo raiz é o nodo de interesse do usuário num determinado instante. O outro representa o contexto, e contém o nodo pai do nodo de interesse e as demais sub-árvoes. Questões de interação relativas a navegação e outras operações são também discutidas. 1. Introduction Information hierarchies like genealogical trees, organization charts, file systems, class diagrams, and websites documents are usually represented by node-edge diagrams. Besides the usual retrieving of data associated to entities in such structures, users need to browse and explore them to extract relationships between pieces of information. The exploratory nature of data analysis [Tukey 1977] and the application of graphics to this process [Bertin 1981] has led to the development of many visualization techniques where visual design play a role as important as interaction mechanisms provided for users. In the last few years, several techniques have been developed to allow navigation in hierarchical information spaces: Treemaps [Johnson and Shneiderman

76 1991; Shneiderman 1992], Cone Trees [Robertson et al. 1991] and the Hyperbolic browser [Lamping et al. 1995] to name a few. These techniques either convey a better perception of some attributes or provide additional interaction features that go beyond traditional navigation with two-dimensional (2D) scrollbars or three-dimensional (3D) cameras, in 2D or 3D visualizations respectively. They base the representation of the information space in geometric features. For example, Treemaps [Shneiderman 1992] is a space-filling approach where a node of the file system tree is represented by an area in the window; other techniques use node-edge diagrams to represent a file system or web site structure [Lamping et al. 1995; Munzner 1997]. Many visualization techniques are classified either as overview+detail or focus+context methods because they provide a visual representation of the entire information space as well as a detailed view of some selected item or region of interest. Overview+detail techniques show the whole information space and the region of interest (ROI) in well-separated areas, usually separate windows, while focus+context techniques employ an integrated view of the information space and some effect emphasizes the ROI [Card et al. 1999]. These techniques require interaction mechanisms to change the focus showed in detail, keeping the context as stable as possible. Node-edge diagrams based techniques like the Hyperbolic browser [Lamping et al. 1995] and the technique presented by Munzner (1997) incorporate the focus+context concept. The Microsoft Windows Explorer browser and the Information Slices technique [Andrews and Heidegger 1998] are examples of overview+detail approach. This paper presents the Bifocal Tree, an alternative way to represent large hierarchies in a node-edge diagram, incorporating some features borrowed from spacefilling approaches. The Bifocal Tree, implemented by the Bifocal Browser, allows a better perception of information, both in context and focus, while being more spaceefficient. In our technique a node-edge diagram is divided in two sub-diagrams defining separate areas in the window: a detail area shows the ROI, which is a selected node and its subtree, while a context area displays its parent and siblings subtrees. Each area has its own focus point. Selecting a different node to be the new ROI causes a transition that can affect the whole diagram. Interactive techniques devised for navigation and querying of node information were also implemented. The paper is organized as follows. In Section 2 we present related work while in Section 3 our approach is detailed regarding both visual representation and possible user actions to explore the hierarchy. Section 4 discusses some relevant aspects comparing our technique with the related ones and describes ongoing experiments for evaluating the technique. Finally, some conclusions and future work are drawn in the last section. 2. Related work As mentioned before, there are many visualization techniques suitable for the exploration of information hierarchies, each one trying to incorporate extra features to enhance user s perception or to provide better interaction mechanisms to achieve the goal of supporting the process of knowledge discovery or decision-making. Treemaps [Johnson and Shneiderman 1991, Shneiderman 1992] provides a visual representation of a hierarchical structure by recursively dividing a rectangular

77 area, which represents the root, in rectangles symbolizing nodes. The size of the rectangles is proportional to some attribute (e.g. the size of files if the structure represents a file system). So, although it represents some important attributes, it does not communicate structure as well as traditional node-edge diagrams. However, a later extension of this technique, Cushion Treemaps [Wijk and Wetering 1999] uses 3D shading to represent structure. While Treemaps employs rectangle subdivision as the space-filling approach, other techniques are based on disc filling and slicing to represent structure in large hierarchies [Andrews and Heidegger 1998, Stasko and Zhang 2000]. In the Information Slices technique [Andrews and Heidegger 1998] a semi-circular disc is used to represent multiple levels of a hierarchy. Concentric regions in the semi-circles represent different levels in the hierarchy, while the slices in each subregion represent the inner structure of each level. For deeper hierarchies, the technique uses cascading discs: a slice of a semicircular disc is fanned out to the right opening up as another semi-circular disc. Since only two semi-circular discs are shown at the same time, the first ones are iconified. Stasko and Zhang (2000) present three improved visualization methods incorporated to the Sunburst file system examination tool to enhance perception and navigation in large hierarchies. The original Sunburst visual representation of a hierarchy was a disc with internal circles filled in different ways to represent hierarchical levels. After a comparison with a Treemaps-style tool, three alternative visualizations were proposed [Stasko and Zhang 2000], all of them based on shrinking the initial (overview) disc and growing up the selected (focus) item, which is part of a slice. The alternative designs differ in how the focus item is depicted after growing up: (a) as a large slice occupying almost the entire window (the overview disc is drawn at a corner); (b) as a ring around the overview disc, which is shrunk at the center; and (c) a large center circular area with the overview disc shrunk and pushed outward to a peripheral ring. Due to space constraints in 2D representations, 3D techniques were developed to take advantage of the extra dimension in the display of large hierarchies. Cone Trees [Robertson et al. 1991] depicts trees and sub-trees as cones with the root node at the apex and leaf nodes in a circle around its basis. Some variations of this technique were proposed such as Cam Trees [Robertson et al. 1991], where the cones are shown in a horizontal orientation, and Reconfigurable Disc Trees [Jeong and Pang 1998], where disks are used instead of cones to reduce the occurrence of node occlusion. The Hyperbolic browser [Lamping et. at. 1995] consists of a diagram built in the hyperbolic plane and mapped to a unit disc in such a way that a node size is dependent of its distance from the disc center. This is a focus+context technique, where the whole hierarchy is shown in an integrated view. The ROI (i.e., the selected node) is in the disc center; the nodes are largest near the center, and become smaller towards the disc perimeter. A 3D variation of the hyperbolic browser was also proposed by Munzner [1997]. All these techniques have brought benefits to the communication of large information spaces [Card et al. 1999] but they still have some drawbacks. For example, the occlusion of objects when displaying large hierarchies with the Hyperbolic browser

78 and the thin slices that come out when displaying broad hierarchies using the Information Slices technique. Although our technique does not entirely overcome these specific problems, it is an alternative node-edge diagram that incorporates the advantages of using two smoothly integrated viewing areas: one for maintaining the context and the other for displaying the ROI, minimizing the problem of node occlusion and enhancing context perception. 3. The Bifocal Browser: focus + context visualization using two foci 3.1. Visual representation: the Bifocal Tree As mentioned above, our technique implements the concept of focus+context by showing the entire hierarchy of nodes divided in two integrated areas: a context area and a detail area. Each area has its own focus node: the node selected by the user is in the focus of the detail area, and its parent is the focus of the context area (Figure 1). Thus, at the same time that it speeds up the perception of hierarchical relationships, the technique shows a detailed view of the subtree containing the node of interest. Although it is not based on hyperbolic geometry, like the technique developed by Lamping et al. (1995), the Bifocal Tree has similar characteristics, as can be seen in Figure 1. The hierarchy is displayed anchored on two main nodes that we call context and detail focus, which are located side by side separated by an arbitrary (and parameterized) measure. A line connects the two foci decreasing the context separation that exists in other browsers like Microsoft Windows Explorer, for example. Figure 1. A hierarchy with approximately 370 nodes

79 The two subtrees are arranged in the context and detail areas following a set of basic rules with few differences that are explained later on. Each subtree is displayed in a radial layout, where the selected node is at the center of a circle and its descendants are distributed in concentric circles depending on their level in the structure. In order to avoid occlusion among objects, each subtree is actually represented by a circle sector and not by an entire circle. Figure 2 presents the maximum sectors in the two circles used to represent context and detail areas. The left and right rectangles correspond to the context and detail focus respectively. The size of child nodes and their distance from the nodes at the foci are calculated depending on their position relative to these nodes. This provides a fish-eye effect, although our technique does not involve distortion like the original fish-eye view idea [Furnas 1986] where a controlled transformation was applied to information distant from the point of interest, which was displayed in enlarged form. A node that is distant from the focus of its area is shown with less detail than nodes nearer the focus, and nodes beyond a certain distance are not shown. This strategy avoids displaying elements that are far from the point of interest, based on the idea that a user browses a structure until reaching a specific node. Moreover, due to the reduced size these nodes would have if displayed near the border of the circle, a user probably would not point at them. Figure 2. Circular sectors used to represent context and detail areas. Nodes are displayed as rectangles with the size depending on their location in relation to the focus point. The same function that calculates the distance of a node from a focus point is used to calculate the width of the rectangle that represents it. The height of rectangles is fixed in a suitable size for text displaying. A threshold distance is used to change the node representation to a smaller, fixed-size rectangle, instead of the calculated one. This changing in representation minimizes the occlusion of objects due to their proximity decreasing the cognitive effort needed to distinguish a specific node. Text is not displayed in the smallest rectangles. Different colors are used to display the subtree that has recently occupied the detail area. This minimizes a possible disorientation that might happen due to the rotations and translations that are applied to the subtrees when the selection of another focus node makes a change in the whole diagram. To provide a global perception of the whole structure in the context area, distribution of nodes around the root node is made taking into account the number of leaf nodes in each subtree. Thus, the subtree with more leaf nodes occupies the largest sector in the circle. This also provides a better space occupancy. This rule is applied recursively to each subtree in the structure. On the other hand, in the detail area, the goal

80 is to provide a better perception of the hierarchical relationships represented by the tree that has the interest node as root. To achieve this goal, nodes at the first level are uniformly distributed around the inner circle. Their subtrees, however, are displayed in sectors with size proportional to the number of leaf nodes, following the same rule applied in the context area. This difference in the layout is more evident in unbalanced trees. With respect to the initial, absolute total size of the circle sector used to display context, the default value is 315 o (Figure 3a), but this can be reduced depending on the numbers of nodes in the subtree (Figure 3b). However, when the root node is at the detail focus, the whole circle is used for node distribution. Figure 3. (a) Using a 315o sector in the context area and (b) using a smaller sector proportional to the number of nodes. Besides the width of circular sectors another important geometrical characteristic in the layout is the actual distance between the focus and the rectangles. Although the technique is based in mapping nodes onto rectangles distributed in concentric circles, we slightly increase the distance from the center if the rectangle is located in the first or fourth quadrant. For rectangles located in the second and third quadrant however, the distance is kept constant. Figure 4 shows the difference between our technique (Figure 4b) and one actually using a circle for nodes distribution (Figure 4a) Interaction The selection of a node is the main interaction mechanism provided to the user; it can be applied to any node in order to bring it along its subtree to the detail focus. This operation modifies also the context area since the parent of the newly selected node is brought to the context focus. Indeed, this operation imposes a translation of a subtree to the detail area as well as a rotation in the structure displayed in the context area both to avoid occlusion and to relocate the parent node to the context focus (Figures 5 and 6). Of course, when the new selected node is a sibling of the current one, the change in the context area is only a rotation.

81 Figure 4. Nodes distribution using (a) a fixed distance and (b) a variable distance from the root node. Figure 5. Layout before selecting node navbar. Another suitable feature for navigation in large hierarchies is the display of the siblings of a node in a different, separate window to allow the selection of a different one as the new detail focus. This is important if the desired node is located at a deeper

82 level in the hierarchy, and is being displayed in the peripheral region of the context or detail area. As usual in hierarchy visualization, pruning and expansion are also available to deal with large hierarchies. By pruning, an entire subtree can be excluded from the visual representation decreasing the cognitive overload caused by the display of a great number of nodes, while expansion would restore the complete visualization. A node representing the root of a pruned subtree is marked with a small rectangle in its left side. Figure 7 shows part of the diagram (a) before and (b) after the pruning of subtree with 1.1 as root. Another feature provided in the technique is undo/redo, which allows navigation in past paths. Figure 6. Layout after selection of node navbar. Figure 7. Layout of a subtree before (a) and after (b) pruning subtree 1.1

83 4. Discussion Although our node-edge diagram is not based on the hyperbolic geometry, it has some similar characteristics as the radial layout. The diagram is based on distributing nodes of the hierarchy around two specific points, one to represent the context and the other to show a particular subtree in detail. This subdivision of context and detail areas is more space-efficient than the one employed by the Hyperbolic browser, with the same spacesaving motivation that guided the design of Information Slices [Andrews and Heidegger 1998] and the improvements of Sunburst visualizations reported in [Stasko and Zhang 2000]. However it must be noticed that the context area does not show the entire hierarchy but the siblings subtrees of the selected node linked to their common parent node. The subtree containing the node of interest is displayed only in the detail area. This is a quite different approach than that adopted in Information Slices technique [Andrews and Heidegger 1998], besides the fact that it is not based on a node-edge diagram, of course. In the Information Slices technique the cascading semi-circular discs redisplay information already presented in the preceding disc, but with more detail. This technique also allows going further in the expansion of information displayed in the first disc by successively fanning out slices. However, hierarchical structure is not as evident as in a node-edge diagram. Regarding nodes distribution in the context area we have adopted a solution similar to the range-based layout employed by Wilson and Bergeron (1999) for displaying a hyperbolic tree. In our technique the range value of each node is the number of leafs in its subtree. In the detail area, however, as mentioned in Section 3, the first level nodes are uniformly distributed around the focus node, following a subnodebased solution (which is another layout algorithm reported by Wilson and Bergeron 1999). For the deeper levels the range-based layout is used. The main interaction mechanism provided by our technique is the selection of a node to be the new detail focus, which causes translation and rotations either to bring the selected node to the detail focus as to display its parent node in the center of the context area. This could probably cause some temporary loosing of the context sensation, but since we keep the subtree that is leaving the detail area in a different color, this effect is minimized. In the Hyperbolic browser, the selection of a node brings that node to the center of the area and the whole tree layout changes. To evaluate the Bifocal Browser, we are conducting experiments with potential users, which execute tasks related to browsing specific hierarchies. The same tasks are performed with the Microsoft Windows Explorer browser and MagniFind, a hyperbolic browser by Inxight 1. Measures like time to accomplish each task and number of errors are taken during the experiments and will undergo statistical analysis. The subjects are 12 undergraduate Computer Science students, all of them with knowledge about hierarchical structures. The first set of experiments allows verifying how much the size of the hierarchy affects performance in each browser, to test the hypothesis that user performance is 1 Inxight ( is a spin-off company from Xerox Co.

84 improved in the Bifocal Browser due to the two-focus approach. The first hierarchy has 300 nodes and the second, 1000 nodes. To avoid a previous knowledge of the structures, both were randomly generated from a set of road names. Tasks were defined to evaluate the easiness in the identification of parent-node relationships, user disorientation due to layout change during navigation, and user performance in (a) searching for a specific node in the hierarchy and (b) navigation through a specific path. Preliminary results point out that the drawback of the technique is the lack of stability of the context area layout when a change of the detail focus node occurs. However, we still have to analyze data collected during experiments to conclude the effect of this in all three browsers, not only in the Bifocal browser. 5. Conclusions We have presented an alternative technique for exploring information hierarchies that incorporate some features of the hyperbolic browser and information slices technique. Considering the design guidelines used by Stasko and Zhang (2000) for the improvement of Sunburst, with the appropriate adaptation to the node-edge approach, our technique: Maintains a global view of the entire hierarchy. Allows a more detailed examination of small peripheral items of information but keep in context the entire information structure, i.e., both are visible. Maintains a balance between the visibility of both hierarchy overview and detail focus display. Is more space-efficient because it uses the entire rectangular window even if based in a radial layout. Does not use scrollbars or separate window. A separate window can be used only when user asks for it to observe a separate node-edge diagram for a subtree. Allows the user to keep track of display changes. The transition between two different layouts is animated and the subtree that has exited the detail area is shown in a different color in the context area. As mentioned before the drawback of our technique is the lack of stability of the context area layout when a change of focus node occurs. Depending on the new focus node, the diagram can be drastically different from the previous one. However, the experiments will give us a more precise conclusion about this issue. Next step includes experiments with larger hierarchies. Some geometric and visual characteristics like distances between concentric circles, thresholds for pruning subtrees and layout methods can be parameterized, and will be used to refine the visual representation, which is likely to depend on the size of the hierarchy. Acknowledgements We are grateful to J. B. de Oliveira for interesting discussions during the earliest phase of this project, and to L.P. Nedel for helpful comments on the first version of this paper. This work is partially supported by CNPq, FAPERGS and CAPES.

85 References Andrews, K. and Heidegger, H. (1998) Information Slices: Visualising and exploring large hierarchy using cascading, semi-circular discs. In: Proc. of IEEE Information Visualization (Late Breaking Hot Topics Procs), 1998, pages 9-12, Raleigh Durham, North Carolina, October IEEE Computer Society. Bertin, J. (1981) Graphics and Graphic Information Processing, Walter de Gruyter, New Yourk, Card, S., Mackinlay, J., Shneiderman, B. (1999) Reading in Information Visualization: Using Vision to Think, Morgan Kauffmann, São Francisco, Furnas, G. (1986) Generalized fisheye views. In: Proc. of the ACM SIGCHI Conference on Human Factors in Computing Systems, 1986, pages Jeong, C. and Pang, A (1998). Reconfigurable disc trees for visualizing large hierarchical information space. In: Proc of IEEE Information Visualization 98, pages 19-25, Raleigh Durham, North Carolina, October 1998, IEEE Computer Society. Johnson, B. and Shneiderman, B. (1991) Tree-maps: A space-filling approach to the visualization of hierarchical information structures. In Proc. IEEE Visualization 91, pages , San Diego, California, October IEEE Computer Society. Lamping, J. Rao, R. Pirolli, P. (1995) A Focus+Context Technique Based in Hyperbolic Geometry for Visualizing Large Hierarchies. In: Proc. of CHI 95 ACM Conference on Human Factors in Computing Systems, 1995, pages Munzner, T. (1997) H3: Laying Out Large Directed Graphs in 3D Hyperbolic Space. In: Proc. IEEE Information Visualization 97, pages 2-10, Phoenix, Arizona, October IEEE Computer Society. Robertson, G. Mackinlay, J. and Card, S. (1991) Cone Trees: Animated 3D Visualizations of Hierarchical Information. In: Proc of CHI 91 ACM Conference on Human Factors in Computing Systems, 1991, pages Shneiderman, B. (1992) Tree visualization with Treemaps: a 2d space filling approach In: ACM Transactions on Graphics. Vol. 11, No. 1, September 1992, pp Stasko, J. and Zhang, E. (2000) Focus+Context Display and Navigation Techniques for Enhancing Radial, Space-Filling Hierarchy Visualization. In Proc. of IEEE Information Visualization 2000, pages 57-65, San Francisco, California, October 2000, IEEE Computer Society. Tukey, J.W. (1977) Exploratory data analysis, Addison Wesley, Reading Mass, Wijk, J.J. van and Wetering H. van de, (1999) Cushin Treemaps: Visualization of Hierarchical Information. In: Proc. of IEEE Information Visualization 99, pages 73-78, San Francisco, California, October IEEE Computer Society. Wilson, R.M. and Bergeron, R.D. (1999) Dynamic Hierarchy Specification and Visualization. In: Proc. of IEEE Information Visualization, 1999, pages 65-72, San Francisco, California, October IEEE Computer Society.

86 The Definition of an End-User Programming Language for Extensible Applications Sérgio Roberto P. da Silva 1, Clarisse Sieckenius de Souza 2 1 Departamento de Informática Universidade Estadual de Maringá (UEM) Av. Colombo, 5790, zona Maringá PR Brazil 2 Departamento de Informática Pontifícia Universidade Católica do Rio (PUC-Rio) R. Marquês de São Vicente, 225, Gávea Rio de Janeiro RJ Brazil srsilva@din.uem.br, clarisse@inf.puc-rio.br Abstract. This paper describes a type-language for end-user programming that is part of the Semiotic Model for Extensible Applications. It is derived from a restricted set of the natural language, allowing its users to employ pronouns, quantifiers, anaphors, and figures of speech such as ellipsis in the expressions of references to objects in their extensions. Besides that, it also allows for the expression of user interactions for the acquisition and delivery of data in their extensions. The introduction of these features, combined with the other parts of the Semiotic Model, contributes to make the task of end-user programming less demanding to both learning and use. Resumo. Este artigo descreve uma linguagem-tipo para programação por usuários finais que é parte do Modelo Semiótico para aplicações extensíveis. Esta linguagem deriva de um conjunto restrito da linguagem natural, possibilitando a seus usuários o uso de pronomes, quantificadores, anáforas e figuras de linguagem, tais como elipses, na expressão de referências a objetos em suas extensões. Além disso, ela também possibilita a expressão das interações do usuário para a aquisição e apresentação de dados em suas extensões. A introdução destas características, combinadas com as outras partes do Modelo semiótico, contribue para fazer a tarefa de programação mais fácil de ser aprendida e realizada pelos usuários finais. 1. Introduction Over the years some software companies have tried to solve the problem of software evolution by introducing extension environments in their software suites [MICROSOFT 1996] [LOTUS 1996] so that end-users are able to configure and adapt the application to their specific needs. This trend has promoted end-user programming (EUP) [NARDI 1993] [CYPHER 1993], but unfortunately end-users do not normally have, or want to acquire, the necessary knowledge and skills to reprogram their applications. As a rule, the main problem with current extension environments is the fact that their extension language is derived from full-fledged programming languages (PLs) such as Basic or Lisp. This kind of language is very difficult for end-users for two reasons. One is that they incorporate programming abstractions that are totally unfamiliar for typical users (e.g. variables, functions, procedures). The other is that they lack representational and communicative features found in natural language (NL), par excellence the means by which users represent and communicate intentions, instructions, definitions,

87 necessary for software customization and extension. Furthermore, PLs are normally disconnected from the user interface language (UIL) and explanation language (UEL) i.e. the help system which the end-users know. In Section 2, we make a few considerations about our EUP theoretical framework. Next, in Section 3, we first show the main results of a linguistic analysis we made of a subset of the natural language used by ordinary people to express daily plans. Then, using the findings of this analysis, others results from our research and results from the literature, we define a EUP type-language that can be much easier to learn and use than the ones found in current extensible application. Finally, in Section 4 we make some conclusions and propose some future research. 2. Some theoretical considerations Most research done in EUP to date [CYPHER 1993] [GOODELL 1999] [LIEBERMAN 2001] is carried out in the absence of an explicit theoretical model to support practical developments. Ours, however, is based on a conceptual model [DA SILVA 2001B] the Semiotic Model for the EUP task as an integral part of Semiotic Engineering [DE SOUZA 2001] [de Souza 1993]. In this approach, software is seen as a unique highlevel one-shot message from the software designer to the user, a meta-communication artefact (a rule-based intentionally constructed message that can generate and receive other messages). In this approach, the communicative aspect of software is central and requires a more careful design of communication and representation processes made available to users through the interface. Bringing together Semiotic Engineering and Jakobson s Verbal Model of Communication [JAKOBSON 1960], we explore the role of users as designers in the field of extensible applications. In [DE SOUZA 2001A], we show that the UEL is the centrally crucial resource of any extensible software, since it is responsible for metalinguistic communication, in Jakobson s terms the type of communication centred around the (content) of the message being conveyed. This metalinguistic function is the one that supports the users knowledge acquisition concerning software use and applicability. The introduction of end-user programming brings forth a major consequence for software use: The users semantic model of the application is open-ended. Every new extension modifies this semantic model. Therefore, in order to maximize the value of knowledge acquired from previous experience with unextended versions of the application, we propose that all extensions made by users must only add, reorganize, or customize the UIL within a range of possible extension types anticipated by the designer. Thus, extending software in our model is equivalent to generating tokens of actual or potential interactive types present in the designer s original message to users [DE SOUZA 2001]. This allows us to predict how the UEL must be updated for each new extension inserted in the software. Without an updating mechanism, it is impossible to maintain the metalinguistic function, and users are likely to miss explanations about extensions and their relationship with the rest of the application. In order to regulate this relationship, Semiotic Engineering defines two principles, the Interpretive Abstraction and the Semiotic Continuum principle [DE SOUZA 2001]. Together, they guarantee that users will not have to penetrate into the implementation details of underlying programming structures (the basic idea behind the Interpretive Abstraction Principle) and that the language in which they will express the extensions they are willing to add will keep up cohesive references with the interface

88 and explanation languages (the basic idea behind the Semiotic Continuum Principle). We also propose the existence of the Minimum Cycle of Interaction (MCI), a three-turn recursive conversational structure that opens with an explicit (re)presentation of the system state and affordances (turn 1), proceeds with the user expressing his/her intent or attempt (turn 2), and closes with the system s feedback (turn 3) that becomes the first turn of the next conversational round [DE SOUZA 2001]. The distinctive feature of MCI is an explicit account of intentionality, in association with coherence and cohesion of conversational turns. Thus, the specification of EUPLs includes a text construct that is syntactically marked (at a higher order than that of instructions, blocks or executable programs). It is then possible to associate a pragmatically valid intentional interpretation to text constructs (in the EUPL). The practical effect of this syntactic constraint is that users cannot build extensions that do not refer to a specific desired effect of the program that will be tied to a change in the system state and affordances, as conveyed in the UIL. Figure 1 shows the kind of structure required by the Semiotic Model for a EUPL. <EUPL text> i,j ::= <prior system-user message> i, <triggering of action> i,j, <subsequent system-user message> i,j <triggering of action > i,j ::= <user input message> i, <activated function> i,j Figure 1: High-level grammar of a text in the EUPL. In order to illustrate the value introduced by the MCI and the two Semiotic Engineering principles that guide the definition of EUPLs in our model, we will take the extension shown in Figure 2 as an example. We can observe that: Removing the relative clause that is activated by the menu from sentence will cause the MCI turn 1 to be absent and the text will not constitute a real extension according to our proposal as there will be no UIL sign linked to the EUPL text and, thus, no way for the user to activated the extension. Removing sentence will cause the MCI turn 3 to be absent as there will be no system response in the UIL, for the case in which no appointment contains the word looked up. Consequently, the end-user will not receive any information about the result of its action. Removing sentence will cause the Semiotic Continuum principle to be violated as although the extension will be correct from a functional point of view, from a communicative point view, there will be no way to inform the data to be processed without this sentence, since there will be no connection between the UIL and the EUPL text. Thus, it will not be a correct extension by our proposal either. Removing sentence will cause the Interpretive Abstraction principle to be violated, because there will be no error contextualization for this extension making it necessary for the user to have access the program s inner structure to interpret the error message.

89 Agenda File Edit Lookup Message No appointment was found that contains this text. 1) To look up <words> is an action of the agenda that is activated by the menu. It follows these instructions: 2) For all the appointments in the agenda, if you find the <word> in the appointment, show it. 3) If not, show the message "No appointment was found that contains this text". 4) When the <words> are not indicated, ask for them using the get-data dialog. 5) When there is an error, show the message "Some error has occurred during the find process. Please, check your data and try again." using the error-handling dialog. Lookup words Enter word: OK Error Message Cancel Some error has occurred during the find process. Please, check your data and try again. Figure 2: An example showing an extension written in an instance of the EUPL type-language here proposed (described in section 4), with the necessary UIL signs, and the commands numbered for the sake of example. 3. An EUP type-language The specification of a programming language always raises questions about which mechanisms must be present. Dertouzos [DERTOUZOS 1992] and Cordy [CORDY 1992] have rather different proposals for the design of extension languages, all of them followed by relevant justifications. Myers, Smith, and Horn [MYERS 1992] demonstrate that an extension language must have the same basic mechanisms of any programming language. It should include mechanisms for the declaration of objects and values for them; for the sequencing and iteration of actions; for the creation of conditionals; and for the application of functions and the creation of abstractions, hence making the creation of new types and actions possible. The relevant question they pose is: What differentiates end users extension languages from programming languages? The main distinction between EUPL and PL design principles is that end-users do not (and need not) have any formal knowledge of programming. For them, adding and modifying program behaviour is similar to describing processes, giving instructions or spelling out action plans. But since current EUPLs are generally derived from fullfledge PLs, such as Basic and Lisp, end-users need to overtly describe much more details for the realization of a task than they are used to in their daily plans. More recent work by Pane et al. [PANE 2001] shows that the natural ways of expression adopted by end-users in EUP-like situations are very different from the one employed in PLs. The work shows that the control mechanisms commonly used by endusers are expressed in an event language or a production rule style, and that interaction on multiple objects is commonly expressed implicitly, through operations on sets of objects. Moreover, end-users resort to different linguistic forms to create sets (e.g. the use of the determiner all, each, every, and the use of plurals). Such results are

90 sufficiently significant for the definition of end-users extension languages, since they express the need for more elaborated linguistic mechanisms than the ones found in the current PLs. We have made modest studies similar to Pane et al. s, starting from a different point of view. We assumed Linden s work [LINDEN 1991] to be correct when he says that programming and planning are analogous activities. We then added Nardi s perspective to Linden s, and also assumed that common people are fully apt to use formal languages [NARDI 1993] (e.g. the language of mathematics and the language used to represent knitting schemes). From there, we conceived software extensions as plans elaborated by end-users. For inspiration, we examined a small set of plans (about 15 texts) expressed in the form of recipes, like Dale [DALE 1992], and do-it-yourself instructions. Although this number is limited, our purpose was to investigate the rhetorical structures of this subset of natural language and to confirm Linden, Nardi and Pane s proposals. Through a basic syntactic analysis of such texts, we tried to identify not only the structures of sentences they included, but also some discourse structures (in particular the communicative aspects that make these plans easy to understand). We looked for structural similarities and differences between NL and PL texts. Although our conclusions are in line with the ones achieved by Pane et al, we found out some other relevant information they have not mentioned [DA SILVA 2001A]. Firstly, we noticed that plan languages employ a unique reference mechanism that presents a natural way to operate with the structure of objects by using commonsense knowledge, quantifiers, qualifiers, anaphors, and figures of speech such as ellipses, metaphors, and metonymies. Such mechanisms can help people when referring to features of complex objects, as they hide many details about the implementation of its structure. For example, in the text get all the <type> appointments of the agenda and show them 1, the end-user did not need to specify how to navigate through the agenda s structure or to repeat the full reference after the show action. The handling of such mechanisms has not been totally forgotten by the PL community. Hypercard [HYPERCARD 1993] has a type of anaphoric reference mechanism. However, this mechanism handles anaphors generically by always recalling the last result of some special action. Moreover, in many instances this procedure is inappropriate. Secondly, we aligned the structure of recipes with that of programs developed for current PLs. The ingredients list, which is equivalent to the program s declaration part, comes first and later come the plan steps, the programs commands. In addition, we notice that people use two types of plans. Operative plans i.e. operational instructions and user manuals only provide instructions on how to use a specific functionality of a system, whereas generative plans i.e. recipes and do-it-yourself instructions provide instructions on how to modify the nature of the objects of a system. It is relevant to notice that a paragraph in end-users plans realizes a step, and a step creates or modifies only one object, by means of other steps and by object 1 In the examples that follows, elements in boldface denote language defined elements and the ones between < > denote variables.

91 manipulation. However, it is usually difficult to differentiate the end of an action from the end of a step by using strictly syntactic criteria. Furthermore, the syntactic order of appearance of objects and actions is not fixed. The possibility of swapping the order is usually caused by focal restrictions that support text cohesion in the NL as, for example, in the text for every <day> of this years, create the <appointment>, where we can see a NL common inversion with some parameters coming before the create action. These facts, along with the way the object features are specified, make the reference mechanism of this language more flexible than the ones available in current PLs. Thirdly, at first sight, there is not a direct notion of variable. However, at closer analysis we see that some words refer to types an entire class of object and, therefore, they symbolize variables. This is possibly due to the use of a specific anaphoric mechanism. In this way, the nouns that appear in the plans declaration part denote types and are preceded by a quantifier (as in an appointment ). When the same nouns appear in the plan body they will denote, generally, a specific unique object or a set a token, and they will have to be preceded by a definite article (as in the appointment ). This is a critical difference between ordinary daily life plans and programming plans expressed in current PLs. It draws our attention to the fact that the differentiation between token/type in common people plan languages is subtle and sensitive to the context. Finally, we also observed that the operative part of the object manipulation language has conditionals and iterators. However, there are not while iterations used in the same sense as in the current PLs, since it is used to express time intervals in NLs, as in the text while the onions are coking, cut the potatoes. Its generative part allows for the application of actions i.e. sub-plans that can have explicit and/or implicit parameters. Implicit parameters refer to objects that belong to the current step context and are the result of tracking the focus of the discourse the set of objects about which we are talking. Nevertheless, there is not a direct notion of attribution, what is found is an implicit mutation of the object i.e. an object having some of its features changed due to transformation that the object itself suffers. Thus, recipes and do-it-yourself instructions capitalize on our capacity for categorization [Lakoff 1990] in order to make the process of transformation of generative plans especially natural. While consolidating our observations, we characterized two main groups of imperative sentences: 1) a group of basic forms given by the rule: S V O [A [A]] (where S - Sentence, V - Verb, O - Object, and A Adjunct); and 2) a group of complex forms given by the rule: S A, V O [A]. Complex forms present transformations used for rhetorical purposes to maintain the focus of the discourse. Some of these transformations are compulsory, when they are used to prevent the loss of text cohesion; while others are optional, when they are used to emphasize a certain element in the sentence. We also noticed a common use of ellipses, confined to basic forms, to hide objects of paragraph sentences. The hidden pronoun always refers to an object previously mentioned in the context formed by the previous sentences. Thus, it can be omitted without causing any interpretation problem. This type of mechanism prevents the need to write and, therefore, to interpret very long sentences, which is particularly laborious for people, and is absent in the current PLs. The structures mentioned are not the only ones in this subgroup of NL. However, they are the most common in this context and can be summarized by the

92 following rule: S [A, ] V [O] [A [A]]. These structures are related mainly to a procedure call in the current PLs and have semantics comparable to the functional approach for the PLs, where the parameters are specified by the adjuncts (A). Our main finding was that the NL object referring mechanism is very different from the one used in PLs. The general structure of objects is particularly complex in NLs and uses an intricate set of restrictions rules over the elements present in its final form [Quirk 1972]. Such structure provides a rich set of possibilities to refer to objects within a domain. We can use the following grammatical rules, simplified and without considering the restrictions for objects: O PrM N [ of PrM N] and PrM [PrD] D [[Ord] [Card] [N]], (where PrM pre-modifier, N noun, PrD pre-determiner, D determiner, Ord ordinal, and Card cardinal). We also observed that in NL the iterations are, mostly, described by the predeterminer all, the determiners each and every, and the plural nouns. These iterations are implicitly defined within reference to objects and normally occur in the whole-part relations hierarchy that exists between the elements of the domain. Determiners and nouns can be substituted by pronouns of various types, when they are normally used as anaphors, allowing a conveniently controlled and safe use of pointers in the NL. Moreover, ordinals are normally used for traversal within the structures in the domain. Although this type of traversal is natural for people, it does not occur in current PLs. Most of our observations are in line with the decade-long work in Natural Language Processing, be it applied to NL understanding or generation [ALLEN 1987] and [DALE 1990]. This gives us more confidence in the implications they may have for EUPL design, and the conclusions we drew from them. We concluded that the use of an extension language based on planning is a good way to approach the end-user of an extension environment without, however, compelling them to learn a great set of specific concepts of the computation area. On the other hand, it will be necessary to set the scope of this language very clearly. First, so that users do not presume that the entire NL is available to be used, and, second, to keep its computational handling within a range of reasonable efficiency, so that we do not make its implementation unfeasible. 4. The outline of an EUP type language Given our vision of an extension as a plan developed by end-users, a possibility would be to use as extension language a planning language already developed in the area of artificial intelligence (AI). However, in [DA SILVA 1997] our revision of such languages shows that they have some important shortcomings (e.g. they employ first-order logic to express actions, goals and states that are not known by end-users, their implication mechanism has a semantic that is rather different from the one end-users use, and they do not favour the communication goals that end-users need). Therefore, we decided for a new language based on planning, but that values pragmatic and communicative aspects needed to facilitate text understanding by end-users. The EUP type-language proposed in this work is a multiparadigm language. It generates a functional language with aspects of object-oriented languages, mainly in reference to the manipulation of domain entities. However, its object-reference mechanism is rather different from that employed in current PLs in order to handle

93 textual cohesion and reduce cognitive loads imposed on end-users regarding the interpretation and generation of programs. Our language has two components: an operative core and a metalanguage. The operative core of an instantiated EUPL of the type-language proposed contains the object reference mechanism and the control mechanisms that can be used in the description of actions. The metalanguage contains mechanisms for the declaration of new entities or extension of old ones. Due to space limitations, we will just outline our EUP type-language here, and give punctual illustrations of token language spans. A full description of it can be found in [DA SILVA 2001A]. Our EUP type-language allows users to employ DETERMINERS (e.g. all, every, each and an) that operate as quantifiers on objects of an action; ORDINALS (e.g. next, first, last and previous) which operate as selectors for the traversal of structured objects; ANAPHORS, in the form of pronouns or determiners (e.g. it, them, their, and its, and the, this and these) which operate as pointers for previously referred objects; and ADJECTIVES and PRE-MODIFIER NOUNS (e.g. red car and the message text) and PREPOSITIONAL PHRASES (e.g. of the to car or in the box ) which operate as qualifiers in the specification of an attribute or part of an object. Table 1 presents a sample of the kinds of references that have a valid semantic mapping in a EUPL instantiated from the type-language proposed in the Semiotic Model. The examples presented in this table were taken from of the domain of applications that receive and send s. Table 1: Examples of the types of valid object references for a EUPL instantiated from the type-language proposed in the Semiotic Model. Reference type Example noun personal <noun> (a variable) <message> [a/an] noun [a] message the/this noun the message the noun ip of [the] noun the sender of the message its noun its sender the ordinal noun the last message (where ordinal = next/last/first/previous) the ordinal adjective noun the first urgent message (where ordinal = next/last/first/previous) all [the] noun(s) all the messages each/every noun each message the adjective noun(s) the urgent messages pronoun (it/them) send them all [the] noun 1 (s) of/in the noun 2 all the messages in the mailbox To define the semantics of the reference sub-language, the existence of a domain ontology will be necessary to help solve complex references. Such ontology will be given by the application design knowledge base (ADKB) and will be composed by the domain model and the computational model for each specific application. The semantics of an object reference will be given by a mapping of this reference onto the elements

94 present in the ADKB. This mapping will result in a compositional semantics that will generate three classes of references: (a) the ones that determine a unique instance and thus operate on a unique ADKB entity; (b) the ones that determine a unique instance but for this reason, need to operate on a set of ADKB entities; and (c) the ones that determine a set of ADKB instances. The details of such complex mappings can be found in [DA SILVA 2001A]. The core part of an EUPL that deals with the control mechanisms contains rules that enable the definition of conditional actions, explicit iterators and the application of action on references. It is important to observe that the semantics of control mechanism for the description of conditionals is similar to production rules. The logical expression that functions as a guard for actions can contain tests to verify specific system conditions (e.g. belongs to, there is, and is accepted). The mechanism also accepts the specification of negated conditions (e.g. if not) that trigger actions whenever a previous test fails i.e. it is part of the scope of the previous test. An example can be seen in the text if the <group> belongs to the <address-book>, add the <contact> to the <group>. If not, show the message. Explicit iterators will only have practical use when it is necessary to repeat a set of actions on one particular object. There are three types of iterators: repeat that test a iteration condition after carrying out a task set; structures that operate as implicit iterators, carrying out a set of actions on the structure elements; and iterators that operate on an interval of elements allowing for the limitation of the number of structure elements that will be affected by the set of actions. For all other cases, the use of implicit iterators is more natural. As an example, in the text repeat, if the colour of <object> is <colour>, go to its places and pick it, up to the last <colour object> of the world., the actions go to and pick are repeated together. The application of functions on references has a functional semantics but can contain implicit iterators in its parameters. In this case, semantic interpretation will have to be rewritten in order to express an explicit iteration. This point can be illustrated by the situation shown in the text mark all the <sender> mails in the <mailbox> as <colour>, where it is necessary to expand the all quantifier before executing the action. Its syntax uses the structures suggested by the analysis of plan languages, as previously described. Thus, an action in an EUPL derived from the EUP type-language proposed here can operate on up to four sets of variables, which constitute the object of the action and the adjuncts which compose the cases of a verb. An example of the effect brought about by this feature can be seen in the text change the colour of an <object> at <place> from <colour-1> to <colour-2>, that uses the object the colour of an <object> and the adjuncts <place>, <colour-1>, and <colour-2>. The semantics of this part of the language is based on AI planning languages (e.g. the ACT language proposed for Wilkins et al. [WILKINS 1995]). The choice for this mapping is due to the ease of text generation from such formalism, as demonstrated by Hovy [HOVY 1988] and Moore [MOORE 1995]. The accurate planning language to be used will vary according to the needs of text generation of the UEL that the application will have to support. Another main distinctive feature of our EUP type-language is that it allows for the specification of the interfaces for an entity in the ADKB. Thus, end-user extensions can describe new interfaces for representing a new system state implied by the

95 extension. Such definition is not easy for end-users and the extension environment should provide software agents to help users achieve this goal. The activation of mechanisms supported by the operating system in which the application executes can only be achieved by specifically designed interface construction software agents. The names of the activation mechanisms will act as hyperlinks that activate the agents (e.g. To verb. It is activated by a menu or by a shortcut, where menu and shortcut act as hyperlinks). Figure 3 summarizes most of the points made above with an extension codified in a token EUPL instantiated from our EUP type-language. The domain for this illustration is that of a simple client. We should remember that the domain model that composes the ADKB will only express the elements that are visible to the end-users through the software interface i.e. it is the software usability model perceived by the user. Moreover, the model also expresses the system primitive functions for which the explanation is composed of a designer s pre-defined text. To send a <message> to a <group> is an action of the agenda. It is activated by the menu and follows these instructions: If the <group> belongs to the address-book, send the <message> to all contacts of the <group>. If not, show the message "The specified group does not exist. Please, check your data and try again." using the error-handling dialog. When the <message> or the <group> are not indicated, ask for them using the get-data dialog. When there is any error, show the message "Some error has occurred during the sending of the messages. Please, check your data and try it again" using the error-handling dialog. Figure 3: Extension code for a behaviour to send a <message> to a <group>. Thus, the EUPLs generated from the EUP type-language proposed in the Semiotic Model presents a less expressive power than the ones of the current PLs. This happens because it restricts the action of programming on the part of end-users to the change of domain elements of the extensible application that has some representation in the application s UIL. It is extremely important to point out that it is very this limitation that grants Semiotic Model its better adequacy for the description of the EUP task. This happens because it enables users to create extensions without allowing them to corrupt the software designer original message. 4. Conclusions In this paper we described an EUP type-language that accompanies our Semiotic Model for extensible applications [DA SILVA 2001]. We report how this type language was derived from findings of previous work in EUP and PL, along with a linguistic analysis of plan-related texts non-experts are likely to encounter in their daily life (e.g. recipes or do-it-yourself instructions). We have shown that the maintenance of the Semiotic Continuum between the languages involved in extensible applications is the result of a deliberate construction effort i.e. designers and software engineers must define an ADKB that contains the initial semantic core of the language when creating the application. This core will need to include a model of the application domain and the computational system (in particular the part that describes interaction elements) and the

96 set of design rules used in the definition of the unique application interaction language. This requirement is certainly costly in a software development environment, but efforts in the area of Computer-Aided User Interface Design (CADUI) give us hope that many such models will be easier to build and maintain in the future, and that the payoffs may eventually outweigh the costs [PATERNÒ 1999] [VANDERDONCKT 1999]. At present, we are dealing with the implementation of a system for the creation of extensions based on the Semiotic Model, which will prove the practical relevance of our model. Firstly, we are working in a parser for an instance of the EUPL-type language proposed here. Its availability will allow us to make evaluative experiments with end-users to confirm our findings and to determine the real expressive power of this class of language. In parallel, we are studying the problem of defining interface construction software agents for the different kinds of activation mechanisms. Theses two mechanisms are connected by the definition of the ADKB s structure and the need for an evolving explanation mechanism. The implementation of these agents, together with their integration with the parser, will be done by the construction of an extension environment that follows the extension realization process advocated by the Semiotic Model. It is only when we have a working environment, integrated in a real application, that we will be able to fully evaluate the power of our theoretical model. References ALLEN, J. (1995) Natural Language Understanding 2 nd Redwood City, CA. Edition. The Benjamin/Cummings. CORDY, J.R. (1992). Why the Use Interface Is Not the Programming Language and How It Can be. In: MYERS, B. (ed.) Languages for Developing User Interfaces. Jones and Bartlett, Boston. p CYPHER, A. (1993) Watch What I Do: Programming by Demonstration. The MIT Press. Cambridge MA. DA SILVA, S.R.P. (2001A) Um Modelo Semiótico para Programação por Usuários Finais. Tese de Doutorado. Departamento de Informática. PUC-Rio. Rio de Janeiro. Maio, DA SILVA, S.R.P. AND DA SOUZA, C.S. (2001B) Um Modelo Conceitual para Programação por Usuários Finais. In: Proceedings of the 4 th Workshop on Human Factors in Computer Systems (IHC 2001). Florianópolis, DA SILVA, S.R.P.; DE SOUZA, C.S. AND IERUSALIMSCHY, R. (1997) A Communicative Approach to End-User Programming languages. In: LUCENA, C.J.P. (ed.) Monografias em Ciência da Computação. Departamento de Informática. PUC-Rio. Rio de Janeiro. MCC 47/97. DALE, R. (1992) Generating Referring Expressions: Constructing Descriptions in a Domain of Objects and Processes. MIT Press. DALE, R; MELLISH, C AND ZOCK, M. (eds) (1990) Current Research in Natural Language Generation. Academic Press. DE SOUZA, C.S. (1993) The Semiotic Engineering of User Interface Languages, In: International Journal of Man-Machine Studies. No. 39, p DE SOUZA, C.S.; BARBOSA, S.D.J AND DA SILVA, S.R.P. (2001) Semiotic Engineering Principles for Evaluating End-user Programming Environments, In: Interacting with Computers. Vol. 454 (4). p

97 DERTOUZOS, M.L. (1992) The User Interface is The Language. In: MYERS, B. (ed.) Languages for Developing User Interfaces. Jones and Bartlett, Boston. p ECO, U. (1976) Theory of Semiotics. Indiana University Press. Bloomington. GOODELL, H.; MAULSBY, D.; KUHN, S. AND TRAYNOR, C. (1999) Report of the CHI 99 Workshop on End-User Programming and Informal Programming. HYPERCARD (1993) Apple HyperCard Script Language Guide. Apple Computer, Inc. HOVY, E.H. (1988) Generating Natural Language under Pragmatic Constraints. Lawrence Erlbaum, Hillsdale, NJ. JAKOBSON, R. (1960) Closing Statements: Linguistics and Poetics, In: SEBEOK, T. (ed.) Linguistics and Communication. MIT Press, New York, NY. LAKOFF, G. (1990) Women, Fire, and Dangerous Things. University of Chicago Press. LIEBERMAN, H. (2001) Your Wish is My Command: Programming by Example. Morgan Kaufmann. LINDEN, T.A. (1991) Representing Software Designs as Partially Developed Plans. In: LOWRY, M.R. AND MCCARTNEY, R.D. (eds.) Automating Software Design. AAAI Press, Merlo Park, CA. LOTUS (1995) IBM Smart Suite 96. Software Documentation. LYONS, J. (1981) Language and Linguistics. Cambridge University Press. London, UK. MICROSOFT (1996) Microsoft Office 97. Microsoft Corporation. Software Documentation MOORE, J.D. (1995) Participating in Explanatory Dialogs: Interpreting and Responding to Questions in Context. The MIT Press, Cambridge, MA. MYERS, B.A. SMITH, D.C. AND HORN, B. (1992) Report of the End-User Programming Working Group. In MYERS, B.A. (ed.) Languages for Developing User Interfaces. Jones and Bartlett, Boston. NARDI, B. (1993) A Small Matter of Programming. MIT Press, Cambridge, MA. PANE, J.F.; RATANAMAHATANA, C.A. AND MYERS, B.A. (2001) Studding the Language and Structure in Non-Programmers Solution to Programming Problems. In: International Journal of Human-Computer Studies. To appear. PATERNÒ, F. (1999) Model-based Design and Evaluation of Interactive Applications, London: Springer Verlag. PEIRCE, C.S. (1931) Collected papers. Cambridge, Ma. Harvard University Press. In: BUCHLER, J. (ed.) Philosophical Writings of Peirce. New York: Dover, QUIRK, R; GREENBAUM, S.; LEECH, G. AND SVATVIK, J. (1972) A Grammar of Contemporary English. Longman, Essex. VANDERDONCKT, J AND PUERTA, A.R. (eds.), (1999) Computer-Aided Design of User Interfaces II, In: Proc. of 3 rd International Conference of Computer-Aided Design of User Interfaces CADUI 99, October 1999, Kluwer Academics, Dordrecht, WILKINS, D.E. AND MYERS, K.L. (1995) A Common Knowledge Representation for Plan Generation and Reactive Execution. In: Journal of Logic and Computation.

98 An Environment to Support Developers in Elaborating a Collaborative and Evolutionary Style Guide Elizabeth Furtado 1, Kênia Sousa 1 and César Colera 2 1 Universidade de Fortaleza (UNIFOR) Av. Washington Soares, 1321 Bairro Edson Queiroz Fortaleza - CE, Brazil 2 Secrel SSA Av. Dom Luis, 500, andar 20- Aldeota Fortaleza - CE, Brazil {elizabet,kenia}@unifor.br, cesar@gruposecrel.com.br Abstract. People involved in system development in organizations face problems during the user interface design phase. Some of these problems are lack of consistency among systems developed, lack of support by development tools and lack of documentation on recommended style guides and difficulties in choosing the best interaction styles. In order to avoid these problems, this paper defines an approach in which a style guide can be created and used in an organization. If a developer encounters a problem when using a development tool, the style guide can be accessed in order to find answers to the developer s doubt, since the approach for elaborating a style guide proposed in this paper is structured with questions and answers, which can also be used as documentation for new developers. Resumo. Pessoas envolvidas no desenvolvimento de sistemas em organizações encaram problemas durante a fase de projeto da interface do usuário. Alguns dos problemas são falta de consistência entre os sistemas desenvolvidos, falta de apoio das ferramentas de desenvolvimento, falta de documentação sobre os guias de estilos recomendados e dificuldades em escolher os melhores estilos interativos. Para evitar esses problemas, esse artigo define uma abordagem na qual um guia de estilos pode ser criado e usado em uma organização. Se um desenvolvedor encara um problema quando está usando uma ferramenta de desenvolvimento, o guia de estilos pode ser acessado pelo desenvolvedor com o intuito de encontrar respostas as suas dúvidas, já que a abordagem para elaborar um guia de estilos proposta neste artigo é estruturada com perguntas e respostas, que também podem ser usadas como documentação para novos desenvolvedores.

99 1. Introduction It is common for developers in an organization to stop developing an interactive system under their responsibility for many reasons, such as, they change to a new organization or they have been allocated to develop another system. This can cause serious problems to the usability of a system. In addition, it is very difficult to find an organization worried about doing style guides documentation; instead they do conceptual models as a relationship-entity model. But if there is some documentation, the documents have an extent that makes their handling uncomfortable [Vanderdonckt, 1999]. Style guides are one type of ergonomic source, which can be called User Interface (UI) guidelines when designing UIs. The style guides are usually hard to interpret and apply [Myers, 1993]. For these reasons, we verify that in an organization, the UI of the same interactive system can be different, lacking consistency among windows developed. To solve the problem related to lack of consistency, the organization generally assigns the responsibility of UI evaluation to one person. Instead of assigning the responsibility for the creation of the style guide to one person, it is important to provide assistance to the entire development team involved in order for them to do it well and to know how to work with it. This means to have a tool, which provides developers good examples based on ergonomic principles, the opportunity to participate in decisions of UI design [Gale, 1996] and the possibility of maintaining and accessing the style guide easily. This paper defines a collaborative approach in which a style guide can be created and used in the organization. This approach is implemented through a tool, which supports the participatory and evolutionary process of creation of a style guide. This approach for elaborating a style guide is structured with questions and answers and it can be used to help if a developer encounters a problem when using a development tool or as documentation for new developers. 2. Style Guide Development Principles The style guide is often used to check a UI after its implementation during the user testing process. However, it is more productive to use it right from the beginning of a project. It is important to note that the production of a style guide cannot be seen as a substitute for iterative design and user testing [Vogt 2001]. A good style guide must respect some development principles, which we consider very important. Participation and Collaboration. Many developers do their work on their own and this contributes to re-work inside an organization. On the other hand, developers who share information among each other have better productivity since products of many phases during the development cycle can be reused. The participation of developers in a group to create a style guide is useful to them because they can share not only technical knowledge but also practical knowledge that a developer acquires through experience in the design of UIs. Another way to ensure a better application of a style guide is to make it possible for users to reflect about their difficulties on their own and with others. Several educational theories claim that learning depends on the individual's knowledge being built by social interactions [Vigotski, 1984] and [Bourne et al, 1997].

100 Evolution. The evolution of the style guide is extremely important to make it a dynamic process, in order to constantly expand and evolve the style guide. A style guide should reflect the corporate image of an organization and the evolution of interaction styles. Documentation. The style guide can be used as documentation for the guidelines to be followed by developers. It is important for developers to have basis on ergonomic principles, instead of adapting each interface based solely on personal opinions. Association of Theory and Practice. Researchers who have scientific basis on a domain of their interest, but do not apply this expertise in practice have missed the experience of finding real results for their research. Likewise, practitioners who lack expertise on a domain, but learn with practice find many problems along their work. The application of theory and practice simultaneously is an important factor in defining the success of a work, e.g. the usability of a UI. Considering this principle, people involved in building this style guide come from a university (researchers) and from an organization (practitioners). 3. Procedures to Create the Style Guide Consistency and usability problems can be avoided when developers have a defined pattern to follow by applying definitions of the style guide. To help an organization define this pattern, we defined a process for the creation of a style guide by considering the principles described previously. This process was composed of the execution of the following phases Definition of Online Communities and Needs A partnership was established between a private organization (SECREL) and us, a private university (UNIVERSITY OF FORTALEZA - UNIFOR). Secrel developers are responsible for developing usable systems and Unifor professors specialized in HCI are responsible for defining and preparing the fundamental base for the style guide, which will be accessed by Secrel developers in order to achieve their goal. The set in assessing community needs is to clearly identify the main purpose of communities that focus in development [Preece, 2000]. Secrel s purpose is to satisfy their users with usable systems. Unifor has the need to apply the knowledge acquired by its professors and researchers in real situations in order to evaluate the output of new methodologies. These communities purposes helped to build an integrated practicetheory style guide and to motivate them to use it Definition of the Software Taking into account that communities need a virtual space to work in order not to compromise their activities, we chose an online software on the web. The software chosen to elaborate a style guide was MC2 [Furtado and Colera, 2000], ( which incorporates organizational learning principles to help ensure the motivation and participation of users. MC2 brings together a set of tools that contribute to the knowledge management process by allowing the creation and

101 maintenance of organizational memory. To achieve this goal, the approach taken by MC2 is aimed at establishing favorable conditions for interaction between the personnel within an organization as well as with the system itself. Another main goal of MC2 is to enhance personnel awareness as to the importance of their participation in the process, thereby creating an organizational culture of continuous learning. To have a tool to support the continuous learning of UI guidelines is in accordance with our interests of ensuring the evolution and documentation principles. MC2 has a participatory space, which makes computerized procedures available that seek to contribute to the formation of better relationships among online communities. The style guide will be available at this software, aiming to be used by developers from the beginning of every project in the organization. This software is useful for developers who have difficulty in finding development tools that support the use of style guides, and for new developers in the organization, facilitating the applicability of defined guidelines. The goal is not to get a huge amount of rules very quickly, but rather to transfer the knowledge about HCI issues as efficiently as possible from the experienced experts to all others [Vogt, 2000] Definition of Roles and Responsibilities People responsible for creating the style guide have to be properly assigned in order for its effects to be visible, such as the assurance of usability on developed systems [Gale, 1996]. Developers in an organization and experts on HCI are responsible for developing a style guide that will be done by the definition of questions and answers related to the style of the UI design. The main roles of this community are the following: Administrator, the development cycle coordinator, is responsible for (i) verifying the existence of answers to questions; (ii) proposing questions and answering them; (iii) deleting these questions from the software; and (iv) proposing discussion on the creation of new style guides, which will lead to voting and a decision-making process. We have defined two administrators, one from the organization and the other one from the university. Multiplier, who has knowledge on a specific area and is interested in propagating this knowledge. In more details, the multiplier is someone who (i) stimulates others to participate; (ii) brings scientific basis to the decisions by suggesting articles, and promoting courses; (iii) proposes reflective questions; (iv) proposes questions and answers them; (v) proposes basis to an answered question by inserting guidelines associated to the question; (vi) deletes visualization questions from the software; (vi) participates on the discussion of new style guides; and (vii) votes on proposed guidelines. The multiplier is represented by a human factors expert from UNIFOR, who is experienced in cognitive principles and may assume that guidelines are sorted by them, and pays attention to high levels guidelines [Vogt, 2000]. General participants, who are responsible for (i) proposing reflective and basis questions; (ii) proposing visualization questions and answering them; (iii) suggesting

102 new style guides; (iv) discussing about new style guides; and (v) voting on proposed style guides. These participants can be designers and programmers, the first one isolates specific guidelines and solves conflicts between them by ranking them into ordered sequences, and the latter is responsible for the creation of widgets in the program, which should be reflected in the organization of the style guide Specification of the Method on Defining Questions and Answers for the Style Guide Questions defined for Style Guides are composed of expression and complement. The type of expression varies according to the kind of question. Examples of expressions for reflective questions are what, which, where, and how, an example for basis questions is why it is necessary, two examples for visualization questions are how it is visualized, and where it is visualized. The complement is used to specify interaction objects and interaction styles, asking about standard names, formats, color, type, fonts, ordering sequence and so on [Delgado and Nielsen, 1996]. The complement includes the following aspects: a) Screen layout and design, which may be characterized by the following types of information about windows: window interaction opening, closing, navigating between windows, etc.; window layouts depending on its type control, data presentation, data maintenance, search, main, dialogue, pop-up, etc. b) Interaction objects design, which may be characterized by: types of interaction objects input, output, I/O, message, tables, graphics, and diagrams; and menu and push buttons for activating tasks. c) Interaction styles asking about variations of input and feedback to meet target user requirements. For example, how to provide information with text-only without extensive graphics. 4. Elaboration of the Style Guide This section provides information and an example about the participatory and collaborative online community process for the style guide elaboration Accessing and Maintaining the Style Guide As we have mentioned, the organization style guide is documented with questions and answers based on guidelines. This documentation is used as a help for developers and is accessed through MC2 tools. So, we can say that the help is automatically created as the questions and answers are defined in the style guide knowledge base. The creation of this help is set by the interaction of the participants with the guide (See Figure 1). When the guide is consulted, an auto-reply question can be submitted and the guide is changed with the answer to this question (1) or a question can be submitted to be answered by participants (2). Administrators and multipliers read the question (3) and may answer it changing the guide (4) or they may answer it and the answer to the requester, not

103 changing the guide (5). Another option is to send the question to the group using the Forum (6). The question can be discussed by the group personally (7a) or using the forum (7b). To come to a consensus, the group can vote (8) and the decision can be inserted in the guide as an answer to the question (9) or it can be ed to the requester, not changing the guide (10). Figure 1 Maintaining and accessing the style guide The guide uses some of MC2 tools, such as queries, forum, groups, voting, and article. Queries is a tool in MC2, through which the community can research questions, make questions, and create knowledge bases depending on the user s permission. When designers encounter problems during the UI design phase, they can find answers to their doubts by accessing the style guide base, or they can submit the question to be answered by experts on the subject (multiplier), by the administrator, or by participants of a group. The Group is defined based on the theme of interest, which in this case is style guides. Participants of a group share knowledge disseminated by the multiplier by accessing the Article. It is useful to write information about guidelines. The discussion in-group is made by using the Forum. At this moment, the articles can be accessed, what brings basis to the decision process. Since many participants find it difficult to come to a consensus, the Voting tool is used in order to simplify this process An example using MC2 Developers who face problems during the development process may search for questions in the style guide in order to solve it. Figure 2 depicts a participant searching

104 for questions related to hints, and finding three reflective questions (what a hint is, how a hint is used, when a hint is used), one basis question (why a hint is needed), and one visualization question (how a hint is viewed). The goal of these questions is to present guidelines, which should be followed by developers who have access to the style guide. Figure 2 Searching for questions When developers do not find the answer to their question in the style guide, they have the option of asking a question to other participants by submitting the question to a group. The group participants will discuss the question in order to come to a consensus and define guidelines that should be applied in the development process. Figure 3 shows a question being submitted to participants. There is also the option of administrators answering their own question, which happens when there is the intention of enhancing the style guide base. Figure 3 Submitting a question

105 If the group does not come to a consensus, the discussion is finished through a voting process, in which all participants express their opinions by choosing one of the options presented. Figure 4 depicts the meeting and voting results. The administrator answers the question based on the result and decides to change the guide or not based on the relevance of the matter. Figure 4 Visualizing the meeting and voting results 5. Conclusion We have described an original process for the style guide elaboration based on the participation of an online community (organization - university) through MC2 tools. The style guide can be easily accessed and maintained. Moreover, the results of the discussion process about the style guide (articles, question-answer, meeting results) can be used as documentation for developers. Using a style guide, it is possible to have benefits in both sides: users and developers. The user productivity can increase because a consistent style reduces what users need to learn and remember, resulting on shorter training time and fewer user errors. The developer productivity can increase because it is more effective to start with standards than to attempt personally to achieve consistency re-inventing new standards formats. Our work is still at an early stage; however the evidences encourage us to believe that the overall environment being developed has considerable possibilities. The style guide knowledge base should be based on concrete experiences, obtained from discussions with a group of professors and developers. During these discussions, the groups will debate and share their practice, and the knowledge mobilized in this practice. These discussions will help us discover developers' beliefs, and their experience level. The method application will be composed of the following activities: i) group definition with the role specification for each member, considering the experiences identified in the discussions; ii) training on the method; iii) proposal of

106 themes concerning style guides, which will be in the knowledge base, e.g. Web Pages; and iv) the environment use. In the whole process, the method will guide us, but we will be very privileged by the group cooperation. References Bourne, J.R., McMaster, E., Rieger, J. & Campbel, J.L. Paradigms for on-line learning: a case study in the design and implementation of an asynchronous learning networks course Available on Delgado, E.; Nielsen, J. International User Interfaces. New York: Wiley, FURTADO, J. J. P.; COLERA, C. Learning Organization through the integrated use of Information Systems and knowledge Engineering In. AMERICAS CONFERENCE ON INFORMATION SYSTEMS, 2000, Long Beach, CA Proceedings of Americas Conference on Information Systems - AMCIS, New York AIS, 2000, v. 1, n. 1. Gale, S., A collaborative Approach to Developing Style Guide, In: Proc. Of ACM conf. on Human Factors in Computing Systems CHI 96. Vol Also Accessible at Myers, B.A. why are Human-computer interfaces difficult to design and implement? Technical Report, no CMU-CS Carnegie Mellon University, School of Computer Science. July, Preece, I. Online Communities Designing Usability, Supporting Sociability. New York: Wiley, Vanderdonckt, J. Development Milestones Towards a Tool for Working with Guidelines. Interacting with computers September Vigotski, L. S. A formação social da mente. São Paulo: Martins Fontes Vogt, T., Difficulties in Using Style Guides for Designing User Interfaces. In proc of Tools for Working with Guidelines. Ed. Jean Vanderdonckt and Christelle Farenc. Biarritz, France

107 Uma extensão da LEMD e a sua integração com a WAE/UML no Design de Sistemas Web Multimídia Antônio J Portella Almeida 1, 2, Jair C Leite 1 1 Departamento de Informática e Matemática Aplicada Universidade Federal do Rio Grande do Norte (UFRN) Campus Universitário Natal RN Brasil 2 IBGE - Instituto Brasileiro de Geografia e Estatítica Dipeq/RN Divisão de Pesquisas do Rio Grande do Norte RN - Brasil aja@ibge.gov.br, jair@dimap.ufrn.br Abstract. Our work focus the research in Web multimedia systems design and evaluation. We study user interface design methods and techniques and based on the results we realize a case study with IBGE website. We develop three prototypical versions of an audiovisual website. We use of the Semiotic Engineering approach, which perceives interactive systems as metacommunication artifacts, and other user interfaces design methods and formalisms. After implementation of the website in HTML language, we conducted a evaluation to compare the prototypes. Resumo. Nosso trabalho se concentra na pesquisa do design e da avaliação de sistemas multimídia na Web, iniciando pelo estudo das técnicas e métodos de design de interfaces de usuário. Realizamos um estudo de caso com um site para o IBGE, desenvolvendo o processo de design de um website multimídia audiovisual em três variantes. Utilizamos a abordagem da Engenharia Semiótica, juntamente com métodos e formalismo de design de interfaces com o usuário já existentes. Após a implementação em linguagem HTML, conduzimos um estudo para avaliar e comparar essas variantes propostas. 1. Introdução A World Wide Web (Web ou WWW) tem proporcionado uma revolução na utilização de computadores. Milhões de usuários de diferentes culturas e faixas etárias têm tido acesso a informações. A cada dia aparecem enormes quantidades de novos sistemas web e vários deles contêm conteúdo multimídia. Poucos estudos têm discutido métodos e técnicas sobre como projetar tais combinações efetivamente. Muitas vezes não existe uma preocupação entre os designers em colocar estas mensagens multimídias de um modo que sejam úteis e causem satisfação para o usuário. É papel dos designers organizar esta grande quantidade de conteúdo empregando mídias e formas de representação adequadas, de modo a permitir uma melhor utilização pelos usuários. As diretrizes hoje existentes dão conselhos contraditórios que, por um lado, encorajam o uso de multimídia e, por outro lado, advertem sobre os efeitos prejudiciais no sistema. Por exemplo, Nielsen conclui que páginas com multimídia são úteis para proporcionar representações gráficas enriquecidas, mas adverte que o uso sem restrição de

108 multimídia resulta em interfaces de usuário que confundem os usuários e dificultam o entendimento da informação [Nielsen00]. A usabilidade de um sistema web multimídia envolve diversos fatores. Dentre eles pode-se destacar a recuperação da informação, a interpretação correta, memorização, aprendizado e vários outros que serão discutidos mais adiante. A Engenharia Semiótica é uma abordagem baseada em teoria que tem por objetivo apoiar o design de sistemas interativos fornecendo conceitos, modelos, técnicas, diretrizes e formalismos [de Souza93]. Esta perspectiva considera que o sistema envia uma mensagem única e unidirecional do designer para os usuários. Através desta mensagem, expressa através da própria interface, o designer deve comunicar para os usuários o que ele pode fazer e como ele pode utilizar o sistema. A Engenharia Semiótica já foi aplicada no design de interfaces gráficas, interfaces multi-usuário, programação pelo usuário final, sistemas de ajuda e vários outros tipos de sistemas interativos. Entretanto, ela ainda não foi utilizada na especificação de sistemas web multimídia. Para apoiar a especificação de interfaces de usuário de acordo com a proposta da Engenharia Semiótica, foi criada a LEMD (Linguagem de Especificação da Mensagem do Designer) [Leite99]. A LEMD permite ao designer descrever de forma abstrata e estruturada a interface de usuário do sistema. Ela enfatiza a especificação dos componentes funcionais e de interação como elementos a serem comunicados ao usuário. Este trabalho apresenta a LEX (LEMD Extendida), uma extensão da LEMD, que tem por objetivo possibilitar a especificação de um sistema web multimídia. Além da LEX, este trabalho mostra como ela pode ser completada através da utilização da WAE/UML (Web Application Extension to the Unified Modeling Language) [Conallen00]. Este formalismo complementa a LEMD permitindo a especificação do modelo de navegação de um sistema Web. Para verificarmos a aplicação prática desta proposta, foi realizado um estudo de caso como desenvolvimento de três versões de um site. Estas três versões do sistema foram implementadas e, posteriormente, testadas e avaliadas. 2. Formalismo e Métodos de Design No processo de desenvolvimento de um sistema web multimídia é necessário um método de design. Na utilização de um método é fundamental que exista uma forma de representação do design. A representação do design é importante não apenas para fins de documentação e comunicação, mas também para permitir avaliação formativa de usabilidade. A utilização de um formalismo para representar o design é conhecida como especificação. Um bom formalismo de especificação deve direcionar e restringir o design visando assegurar a qualidade do produto final. A especificação correta visa diminuir o processo de constroi-e-corrige que torna o processo lento, dispendioso e de baixa qualidade. Existem vários métodos de design de sistemas web, mas nem todos abordam de forma satisfatória a integração de informações multimídia de modo a melhorar a sua

109 usabilidade. Mais importantes ainda, estes métodos não apresentam formalismos ou notações que permitam a especificação de objetos multimídia em interfaces Web. O método desenvolvido por Ford [Ford97] considera as intenções do cliente, as necessidades da audiência e questões específicas para websites, descrevendo o processo de design de um website para o Departamento de Design da Universidade de Carnegie Mellon (EUA). A metodologia centrada no usuário desenvolvida por Fuccella [Fuccella97], tem como objetivo principal ajudar aos designers a identificar a audiência alvo, identificar e organizar o conteúdo do site e verificar a usabilidade do design resultante. A eficácia dessa metodologia está demonstrada em diferentes websites dentro do portal da IBM na Web. A técnica RNA (Relationship Navigation Analysis) faz parte do primeiro estágio de uma abordagem criada para projetar aplicações WWW [Bieber98]. Essa abordagem leva em consideração dois estágios, sendo o primeiro a RNA e o segundo um mecanismo para geração automática de aplicações hipermídia (DhymE). A técnica RNA analisa uma aplicação nova ou já existente, especialmente em termos de seus intra e interrelacionamentos, conduzindo a um melhor entendimento da complexidade da aplicação. O processo de design proposto por Nigel Bevan é centrado no usuário e está baseado no padrão internacional ISO DIS para o desenvolvimento de páginas Web [Bevan00]. Sua prioridade principal é proporcionar orientação, ferramentas e métodos para ajudar organizações e/ou designers, que tenham experiência com usabilidade a produzir sistemas. Seguindo os padrões ISO de usabilidade, esse processo de design foi elaborado com o objetivo de construir um produto que possa ser usado por usuários específicos, para alcançar metas específicas com eficácia, eficiência e satisfação em um contexto de uso específico. O método WSDM (Web Site Design Method) é centrado no usuário e está concentrado no design de Websites em Kioskes [De Troyer98]. Para o design deste tipo de website há necessidade de estruturar o domínio da informação e apresenta-lo aos usuários de um modo claro e facilmente acessível. Portanto, neste método, o ponto principal é o conjunto de visitantes em potencial do website. Estes usuários são classificados dentro de classes e os dados utilizados são modelados em diferentes classes de usuários. O resultado é uma maior usabilidade e, conseqüentemente, uma maior satisfação do usuário. O método RMM (Relationship Management Design Methodology) está baseado no modelo ER (Entidade-Relacionamento), abordando as fases de modelagem e implementação, particularmente as que são voltadas à especificação do domínio e modos de acesso da aplicação [Isakowitz95]. O nome relationship managenement origina-se da visão de hipermídia como um veículo para gerenciar relacionamentos entre objetos de informação. O RMM modela itens da aplicação usando a abordagem ER, e produz uma aplicação com links entre as entidades relacionadas e entre os atributos, dentro de cada entidade. Possui ainda o RMDM (Relationship Managenement Data Model), que é um modelo de dados utilizado na construção dos modelos de objetos da informação e navegação.

110 O método STRUDEL propõe um modelo gráfico simples em que diferentes fontes de dados (por ex., sites já existentes e vários tipos de banco de dados externos) são uniformemente modeladas [Fernandez97]. Permite aos usuários manipular os dados básicos independentemente de onde estão armazenados ou como são apresentados, criando diferentes visões sobre os dados fundamentais. A idéia chave desse método é a separação da visão lógica da informação disponível em um website, a estrutura daquela informação em páginas ligadas e a apresentação gráfica das páginas em HTML. O método OOHDM expõe as tarefas a serem realizadas desde a análise do domínio da aplicação até a implementação [Schwabe95]. Ele usa abstração e mecanismos de composição em uma estrutura orientada a objetos, para permitir uma concisa descrição de complexos itens de informação e a especificação de complexos padrões de navegação e de construção de interfaces. Ele apresenta esta abordagem para o design de interfaces de usuário com conteúdo hipermídia e tem sido utilizado para projetar diferentes tipos de aplicações, tais como sites, sistemas de informação na Web e apresentações multimídia. O método proposto por Tavares, Leite e Souza Filho segue a abordagem da Engenharia Semiótica e propõe um processo iterativo-evolutivo no qual a cada ciclo deve ser realizado três etapas: a especificação, a prototipação e avaliação [Tavares00]. O processo é iniciado a partir da análise de usuário e de tarefas. A especificação é realizada utilizando o formalismo LEMD, que permite uma descrição abstrata e estruturada das soluções de design. Durante a prototipação, a especificação abstrata é concretizada através da utilização de objetos de interface e aplicação de técnicas de comunicação visual. A avaliação tem por objetivo verificar aspectos de usabilidade e de comunicabilidade, através de inspeções e testes. Como vimos na introdução, a Engenharia Semiótica considera que a interface de usuário de um sistema é uma mensagem enviada pelo designer. A Web foi concebida como um meio de comunicação através do qual se pode comunicar informações e oferecer serviços. O design de um sistema web é, portanto, um processo comunicativo no qual o designer deve elaborar a mensagem sobre informações e serviços. A abordagem da Engenharia Semiótica, junto com os seus métodos e formalismos, é bastante adequada para o design de sistemas web. Desta forma, consideramos que o método de Tavares, associado a LEMD, deve ser utilizado para este propósito. Entretanto, a LEMD não possui mecanismos que permita a especificação de conteúdos multimídia. 3. LEX: uma Extensão para LEMD A LEMD original é uma notação para ser utilizada na especificação de interfaces de usuário convencionais, conhecidas como interfaces WIMP, por conter como elementos principais as janelas, ícones, menus e apontadores (o acrônimo WIMP, vem de Windows, Icons, Menus, Pointer). Como nosso trabalho tem como foco o design de sistema Web multimídia, há necessidade de se propor novas mensagens, comandos e funções que tratem de aspectos específicos em aplicações Web. A LEX é uma extensão da LEMD que oferece elementos construtores da especificação, que são específicos do modelo Web. O modelo Web está baseado nos modelos de hipertexto e da arquitetura cliente-servidor. Ele deve conter estruturas que permitam a especificação de elementos hipertextuais. Além disso, são necessárias funções de

111 aplicação pré-definidas que realizem as tarefas de busca de conteúdos a partir de um link, e a sua apresentação na forma desejada. Na LEMD, um dos elementos fundamentais é a mensagem que é especificada pelo construtor message. Elas são utilizadas para que o designer organize a interface em blocos de mensagens que comunicam os principais objetos da aplicação. Para a especificação de sistemas web multimídia, propomos a criação de três novos tipos de mensagens. Uma mensagem de frame (Frame-Message), que estrutura as páginas que serão apresentadas, uma mensagem de página (Page-Message), que estrutura todas as ações e conteúdo necessários que podem ser feitos em uma página Web e uma mensagem de mídia (Media-Message), que estrutura todas as ações para a ativação de uma função de apresentação de alguma mídia dinâmica, tais como, áudio, vídeo e/ou animação. A especificação dessas três novas mensagens pode ser feita de acordo com o esquema da figura Frame-Message <frame-name> { Page-Message <page-name> } 2. Page-Message <page-name> { Page-Message <page-name> } 3. Media-Message <media-name> presentation-function <presentationfunction-name> { Page-Message <page-name> } Figura 1: Esquema para especificação das novas mensagens Duas novas funções são necessárias. A primeira delas visa permitir a descrição do processo de recuperação de uma página ou conteúdo multimídia a partir do clique na âncora de um elo (link), de acordo com o modelo de hipertexto. A segunda função permite a especificação da apresentação de um conteúdo multimídia. Ao contrário das mensagens textuais ou gráficas que são estáticas, as mensagens de áudio e vídeo são dinâmicas e apresentadas durante a sua exibição. A especificação da função de recuperação é feita através de uma Retrieval-Function. Ela deve determinar qual a página que será carregada dentro da estrutura do website, após um comando do usuário. A função de apresentação é especificada usando a Presentation-Function, que consiste em apresentar alguma mídia dinâmica (ex. áudio, vídeo, animação) através da ativação de um plug-in. Em sistemas web multimídia, uma mensagem multimídia pode ser ativada a partir de um comando do usuário ou automaticamente quando uma página é carregada. Para o primeiro caso, a mensagem pode ser especificada na LEMD usando-se a interação básica Activate. Entretanto, a LEMD original não possui uma forma de especificação destas mensagens de mídia que são ativadas automaticamente. A LEX possibilita a especificação da mensagem automática através de Automatic. A especificação desta mensagem determina a ativação de uma mídia dinâmica através de um plug-in embutido em uma página Web. A forma geral das mensagens de interação para esse caso é: Automatic <message-control> Video-Message <command-name> Por exemplo:

112 Automatic start Video-Message Censo2000 Os controles operacionais utilizados em conjunto com as interações básicas acionar (Activate) e automática (Automatic) são vários, tais como, iniciar (start), parar (stop), cancelar (waive), etc, dependendo dos recursos disponíveis. Mas, para um sistema Web, há a necessidade de se criar um controle que mostre a ativação de uma função de recuperação (Retrieval-function). Sendo assim, propomos a mensagem de controle link, podendo ser assim exemplificado: Activate link Historico for Retrieval-Function Consulta-informações-TxViE 4. Integrando a LEX com a WAE/UML A UML (Unified Modeling Language) é uma notação para expressar visualmente os modelos de um sistema de software. Seus principais criadores foram Grady Booch, Jim Rumbaugh e Ivar Jacobson, que são conhecidos também como os três amigos. A UML, em sua versão original, não possui estereótipos suficientes para modelar aspectos específicos de aplicações Web. Para resolver esse problema, foi criada uma extensão da UML, chamada de WAE (Web Application Extension for UML), que oferece à linguagem UML uma semântica adicional para permitir a modelagem de elementos de arquitetura específicos para serem utilizados em projetos para a Web, como parte do modelo do sistema principal [Conallen00]. Segundo Conallen, a WAE é expressa em termos de estereótipos, valores rotulados e restrições. Combinados, estes mecanismos possibilitam criar novos tipos de blocos que podem ser usados no modelo. Os aplicativos de hipermídia são projetados para efetuar navegação através de um espaço de informações. Por isto, o projeto da estrutura de navegação de tais aplicativos é uma etapa crucial no processo de desenvolvimento. A estrutura de navegação de um documento hipermídia é descrita definindo-se os nós, elos e âncoras. A extensão WAE/UML para aplicação na Web define uma notação para expressar os componentes de um sistema com tecnologia Web. Utilizando a WAE, é possível representar páginas, links e o conteúdo dinâmico no lado cliente e no lado servidor. Utilizamos essa nova extensão dada para a UML na etapa de design, mais especificamente no design do Projeto de Navegação. O projeto de navegação visa definir como os diversos blocos de mensagens estão estruturados. Nos sistemas Web esta estrutura segue o modelo de hipertexto. Os estereótipos propostos pela WAE não contemplam a especificação de conteúdos multimídia, como os filmes audiovisuais que são exibidos pela maioria dos browsers. Propomos mais dois estereótipos a esta notação. O primeiro, denominado Player (Figura 2a), permite especificar um conteúdo de vídeo ou animação que é exibido por um aplicativo externo, conhecido por helper. Chamaremos este caso de vídeo externo. O Player vem a ser um componente associado a uma página cliente, onde será apresentada a mídia proposta após comando do usuário. Ele se restringe a ser um estereótipo que representa a apresentação do conteúdo da mídia escolhida através de um aplicativo externo, não havendo necessidade de passar nenhum valor rotulado. Somente o nome do arquivo de vídeo ou animação é mapeado diretamente para linguagem HTML, através da tag A no atributo HREF. Ex: <A HREF= video.mpg >, onde video.mpg é o URL do filme a ser exibido pelo aplicativo externo.

113 O segundo estereótipo, denominado Embed (Figura 2b), permite especificar a ocorrência de um componente de vídeo ou animação que é exibido por um plug-in, isto é, um aplicativo que é interno ao browser. Chamaremos este caso de vídeo embutido. O Embed vem a ser um componente associado a uma página cliente, onde será apresentada a mídia proposta após comando do usuário. Ele se restringe a ser um estereótipo que representa a apresentação do conteúdo da mídia específica por um aplicativo interno ao browser, não havendo necessidade de passar nenhum valor rotulado. Durante a implementação mapeada diretamente para linguagem HTML, através da tag EMBED, pode-se atribuir valores conforme a necessidade do desenvolvedor nos atributos WIDTH e HEIGHT, que são respectivamente a largura e a altura do filme em pixels. Ex: <EMBED SRC= video.mpg WIDTH=20 HEIGHT=10> EMBED Figura 2: a. Estereótipo do Player b. Estereótipo do Embed O objetivo de propor estes dois novos estereótipos à WAE/UML, foi com o intuito de serem utilizados em casos de aplicações que necessitem diferenciar um vídeo embutido de um vídeo externo, integrando-os com os outros estereótipos(figura 5) já existentes definidos pela linguagem. Com isso, os desenvolvedores terão mais recursos de apoio à especificação do contexto navegacional em sistemas Web multimídia, facilitando e tornando mais compreensível o processo de design do modelo de navegação. Finalizando, enquanto a LEMD serve para apoiar a especificação do modelo conceitual para aplicações convencionais, a LEX apoia a especificação do modelo conceitual de aplicações Web multimídia, enquanto que a WAE serve para apoiar a especificação do modelo de navegação destas aplicações. Com isso a LEX, além de ser uma extensão complementar à LEMD pode ser integrada com a WAE no processo de design de interfaces de usuário multimídia para a Web. 5. Estudo de Caso A seguir iremos mostrar um exemplo do uso destas extensões da LEX. Nosso estudo de caso consiste no desenvolvimento de 3 variantes de um sistema web com informações de divulgação preparatória do Censo As 3 versões do sistema diferenciavam-se entre si pelo tipo de mídia utilizada para as informações. A versão 1 contém apenas informações na forma de texto. A versão 2 possui, além do texto, um vídeo que é exibido automaticamente na página. A terceira versão é semelhante à segunda, mas exibe o vídeo através de um aplicativo externo (helper). O objetivo de termos construído as três versões foi de verificar como a especificação de cada uma delas poderia ser feita usando a LEX e a WAE/UML. Um segundo objetivo foi avaliar qual das versões permite uma melhor usabilidade e uma melhor assimilação do conteúdo veiculado. Este segundo objetivo foge ao foco principal deste artigo. Seus resultados eram de interesse de uma outra pesquisa e podem ser encontrados em [Almeida02].

114 Para exemplificarmos a especificação, vamos utilizar apenas um caso de uso da versão 3. Mostraremos inicialmente uma das telas do protótipo para que se tenha uma idéia melhor da aplicação que especificamos. Em seguida, mostraremos a especificação em LEX e o modelo de navegação em WAE/UML. Figura 3. Página com texto e vídeo externo Utilizando a LEX, especificamos na mensagem de comando para o caso de uso fazer consulta sobre Censo Neste caso de uso a tarefa do usuário é realizar uma consulta sobre as informações textuais e audiovisuais do IBGE, obedecendo a uma seqüência de tarefas.esta mensagem é especificada com o nome Fazer-Consulta-Inf- TxViR-Censo2000 que está descrita na figura 4. Para que o usuário possa realizar esta tarefa, o designer especificou uma mensagem organizada em três partes (frames). A primeira parte é apenas informativa, contendo o cabeçalho. A segunda parte contém os comandos de acesso, na forma de links, às diferentes informações do IBGE. A terceira parte exibe as informações que o usuário quer consultar. Estas idéias são especificadas em LEX através de uma Frame-Message. Esta Frame-Message por sua vez agrupa (Join) três mensagens de página (Page- Message) que correspondem as páginas de um hipertexto web, como descrito na figura 5. A mensagem de página Cabeçalho é formada por duas visualizações (View) que também podem ser visualizadas em qualquer ordem (Join). Na mensagem de página Links, o usuário tem as opções de selecionar (Select) um dos assuntos relacionados (Histórico, Censo2000, Objetivos e VamosContar) através da ativação (Activate) de seus links correspondentes. Na página Informação-TxViR-Censo2000, o usuário tem a opção em qualquer ordem (Join) para visualização (View) do texto selecionado na

115 página Links e para acionar (Activate) o vídeo da mensagem de mídia (Media- Message) correspondente ao texto. Frame-Message Fazer-Consulta-Inf-TxViR-Censo2000 { Page-Message Cabeçalho Join { Page-Message Links Page-Message Informação-TxViR-Censo2000 } Page-Message Cabeçalho { Join { View Information of Logo-IBGE View Information of Cabeçalho-Título } } Page-Message Links { Select { Activate Link Historico for Retrieval-Function Consulta-informações-TxViR Activate Link Censo2000 for Retrieval-Function Consulta-informações-TxViR Activate Link Objetivos for Retrieval-Function Consulta-informações-TxViR Activate Link VamosContar for Retrieval-Function Consulta-informações-TxViR } } Page-Message Informação-TxViR-Censo2000 { Join { View Information of Texto-Inf Activate Start Media-Message Censo2000 } } Media-Message Censo2000 for Presentation-Function Censo2000 { Select { Activate Pause Application-Function Pausar-video Activate Stop Application-Function Finalizar-video Activate Restart Application-Function Reiniciar-video } } Figura 4: Especificação do protótipo com a LEX A função de apresentação (Presentation-Function) da mensagem de mídia Censo2000 permite a ativação (Activate) dos controles operacionais pausar, parar e reiniciar. O usuário tem as opções de seleção (Select) de um desses controles. Voltando à figura 3, podemos descrever o modelo de interação especificado em LEMD para a mensagem de comando Fazer-Consulta-Inf-TxViR-Censo2000. Neste caso, a especificação View também é mapeada em Figuras, textos e vídeo. O Activate é mapeado de maneira a exibir as informações correspondentes. Neste caso a informação na forma textual é mostrada, mas o vídeo apenas é acionado após uma nova ativação do usuário. Na especificação, isto é descrito pelo Activate Start Media-Message. Após o acionamento do vídeo, além do texto e do comando para acionamento de início do vídeo para o tópico Histórico, também é visualizado o vídeo exibido no player que se realça com relação à página, após o usuário acionar o comando. A figura 5 mostra a arquitetura de informação e o modelo de navegação especificado utilizando a WAE/UML. Este modelo mostra de forma mais clara todo o esquema de ligação entre os elementos do sistema.

116 Figura 5. Modelo de Navegação A partir da página inicial (HOME), o usuário tem acesso ao frameset (PAGINA TxViR). Neste ele tem a opção de selecionar, em uma das páginas que formam o frame, o link do assunto de seu interesse. Dependendo do link selecionado, uma das 4 páginas cliente(historico, CENSO2000, VAMOSCONTAR, OBJETIVOS) será exibida no frame de APRESENTAÇÃO. Nessas páginas, o usuário tem a opção de seleção para acionar o comando para vídeo externo (PLAYER) correspondente ao assunto tratado no texto. Portanto, a partir da especificação da mensagem do designer utilizando a LEX/LEMD, assim como do design do contexto navegacional pela WAE/UML, pode-se então elaborar a mensagem final, mapeando as mensagens abstratas em objetos de interfaces disponíveis pela linguagem HTML, como já foi mostrado na figura Avaliação do Sistema Web do Censo 2000 do IBGE O modelo de processo de design que adotamos para o nosso sistema web multimídia inclui uma etapa de avaliação a cada passo da iteração. Realizamos uma avaliação em duas etapas. A primeira tinha por objetivo avaliar aspectos de usabilidade das três versões do sistema. A segunda tinha por objetivo avaliar qual das versões do sistema melhor comunica a informação para o usuário. Os protótipos foram avaliados através de questionários, cujo objetivo principal foi medir quantitativamente o valor alcançado pelo sistema em cada um dos fatores de usabilidade de interesse. Os fatores utilizados foram Aprendizagem, Facilidade de Uso, Satisfação, Eficiência e Memorização. Uma discussão mais aprofundada sobre a escolha destes fatores pode ser encontrada em detalhes em [Almeida02].

117 Durante os casos de teste utilizamos 20 participantes, com variados níveis de conhecimento e escolaridade, sendo 11 funcionários do IBGE e 9 alunos universitários. O primeiro questionário serviu para avaliar as reações dos usuários em relação ao produto, onde os 20 participantes atribuíram notas de 0 a 4 para cada uma das 30 declarações a serem avaliadas, após terem utilizado por tempo suficiente as 3 versões do site proposto. O segundo questionário serviu para avaliar a assimilação do conteúdo do produto, em termos de percepção, interpretação e memorização. Neste questionário foram selecionados somente os 9 universitários, pois para responder às questões consultadas, os participantes não poderiam ter conhecimento sobre as funções do IBGE na sociedade. Eles responderam as 20 questões objetivas de múltipla escolha, após terem utilizado por um tempo determinado os três variantes. De posse da análise dos dados resultantes desta avaliação, observou-se no primeiro questionário, entre outras conclusões, uma melhor avaliação do fator memorização em relação à versão somente texto. Mas, pelos testes de assimilação do conteúdo feitos através do segundo questionário, ficou evidente que as versões com vídeo tiveram um maior número de acertos sobre os assuntos questionados do que a versão somente com texto, contradizendo assim, o resultado sobre o fator memorização observado pelo primeiro questionário. De um modo geral, os participantes aprovaram as 3 versões do site proposto, nos estimulando através de suas reações positivas a continuar tentando aperfeiçoar as versões com vídeo para sua implementação real. 7. Conclusão Este trabalho descreveu a extensão do formalismo LEMD e a sua integração com a UML, através do WAE, para a especificação de sistemas web multimídia. A utilização de formalismos de especificação permite não apenas documentar o design, mas também orientar em direção a boas soluções. Ao contrário da maioria dos métodos convencionais pesquisados que estão centrados no relacionamento das informações (seção 2), o nosso método, baseado na Engenharia Semiótica, enfatiza a organização daquilo que o designer quer comunicar. A LEX oferece um conjunto de estruturas que permite ao designer se concentrar apenas na essência da mensagem que ele deve enviar para o usuário. Com a LEX, ele pode estruturar as mensagens de forma a indicar agrupamentos, seleção de opções, seqüência ou repetição de tarefas e combinação de objetos. Com ênfase na comunicação e organização do modelo de interação, a LEX permite uma especificação mais precisa e possibilita uma inspeção da complexidade e consistência da interface. Por ser uma linguagem textual, a LEX torna difícil a visualização e avaliação do modelo de navegação entre as diversas mensagens (no caso, as páginas) do sistema. Por este, motivo, este trabalho argumenta que o método de design deve ser integrado com uma linguagem visual. A WAE/UML, utilizada para a especificação do modelo de componentes de sistemas web foi adaptada com o acréscimo de 2 novos estereótipos para permitir a especificação dos componentes multimídia. A combinação LEX e WAE/UML mostrou ser suficiente para a construção dos protótipos que foram avaliados e aprovados pelos usuários.

118 Vários profissionais de pesquisa e desenvolvimento podem ser beneficiados pelos resultados deste trabalho. Os especialistas em IHC, em particular os que trabalham com Engenharia Semiótica, poderão aplicar os métodos, técnicas e formalismos para design e avaliação formulados em um projeto de interfaces para a Web, identificando problemas e propondo outras opções de design ou de avaliação. Webdesigners poderão utilizar as técnicas de avaliação utilizadas para prognosticar ou diagnosticar problemas de interação durante a criação de uma interface. Além disso, caso uma das versões com vídeo seja aplicada ao site do IBGE, todos os usuários da Web serão beneficiados diretamente, pois terão uma nova opção de informações multimídia audiovisual sobre os dados geográficos e estatísticos do Brasil. Referências Almeida, A.J.P. (2002) Design e Avaliação de Sistemas Multimídia para a Web: Um Estudo de Caso. Dissertação de Mestrado. UFRN, 2002 Bevan, N. (1999) Usability Testing World Wide Web Sites. European Usability Support Centres. Bieber, M. (1998) Hypertext and Web Engineering. University Heights. Hypertext 98. Pittsburg, PA. USA. Conallen, J. (2000) Building Web Applications with UML, Addison Wesley, USA. De Souza, C. S. (1993) The Semiotic Engineering of User Interface Languages. International Journal of Human-Computer Studies. Academic Press. De Troyer,0.; Leune,C. (1998) WSDM: A User-Centered Design Method for Web Sites. Proceedings of the 7th International World Wide Web Conference, Elsevier. Fernandez,M.; Fiorescu, D.; Kang,J.; Levy,A. And Suciu, D. (1997) STRUDEL: A Web-site Management System. ACM SIGMOD. Ford, S.; Boyarski, D. (1997) Design@Carnegie Mellon: A Web Story. DIS `97 Amsterdam, The Netherlands. Fuccella, J. (1997) Using User Centered Design Methods to Create and Design Usable Web Sites. IBM Corporation. SIGDOC 97. Snowbird Utah. USA. Isakowitz, T.; Stohr, E. And Balasubramanian, P. (1995) RMM: A Methodology for Structuring Hypermedia Design. Comm. ACM, pp Leite, J. C. & de Souza, C. (1999) Uma Linguagem de Especificação para a Engenharia Semiótica de Interfaces de Usuário, anais do II Workshop sobre Fatores Humanos em Sistemas Computacionais, Campinas, Brasil. Nielsen, J. (2000) Projetando Websites. Ed. Campus Ltda. Rio de Janeiro. Schwabe, D. & Rossi, G. (1998) An Object Oriented Approach to Web-Based Application Design. Theory and Practice of Objects Systems, 36p. Tavares, T. A.; Leite, J. C.; Araújo, A & Souza, G. L. (2001) Applying HCI Methods and Techniques to Design a VoD System User Interface Proceedings of International Conference on Intelligent Multimidia and Distance Education, Fargo, USA.

119 Sistemas de Reputação: Arquitetura, Propriedades e Desafios Bruno Dias Abrahão, Fernando Caixeta Sanches, Wagner Meira Jr. Departamento de Ciência da Computação Universidade Federal de Minas Gerais Av. Antônio Carlos, ICEx, Pampulha Belo Horizonte, MG brut,caixeta,meira@dcc.ufmg.br Abstract. The construction of online communities is a task which involves challenges not only technological, but also sociological. Trust has always been crucial to the accomplishment of transactions between partners. Providing the construction of this trust, measured as reputation, is a necessity in such environments due to the impersonality of the relationships and the lack of information about the participants. This work describes aspects of the architecture of reputation systems and the minimun set of properties required for a robust management of trust metrics. Following this, we consider a implementation that in addition to making it able to evaluate the discussed properties, it also reveals the challenges faced in the design of reputation systems in online environments. Resumo. A construção de comunidades virtuais apresenta desafios não somente tecnológicos, mas principalmente sociológicos. Confiança sempre foi essencial para a realização bem sucedida de transações entre parceiros. Prover a construção dessa confiança, medida como reputação, é uma necessidade em tais ambientes devido à impessoalidade das relações e à falta de informações sobre os participantes. Esse trabalho descreve aspectos sobre a arquitetura de sistemas de reputação e o conjunto mínimo de propriedades necessárias para um gerenciamento robusto de métricas de confiança. Em seguida, consideramos uma implementação que, além de viabilizar a avaliação das propriedades discutidas, também revela os desafios do projeto de sistemas de reputação em ambientes virtuais.

120 1. Introdução O escopo do conceito de comunidades virtuais (online communities) [Donath, 2001, Flake et al., 2002] é bastante abrangente, podendo capturar desde alguns usuários que trocam s sobre um determinado assunto de interesse mútuo, até sítios Web com milhares de usuários que interagem entre si pelas mais diversas finalidades. Na tentativa de trazer para o mundo virtual relações fundamentais em um contexto social, como a comercialização de bens, compartilhamento de conhecimento e busca por parceiros para algum tipo de transação, observamos que os desafios da construção dessas comunidades não são apenas tecnológicos, mas principalmente sociológicos. Alguns fatores são essenciais para a realização bem sucedida de interações sociais. Dentre esses fatores, a confiança sempre foi determinante para o sucesso das transações e recomendações realizadas pelos homens. Pessoas sempre buscam referências confiáveis para se protegerem. Entretanto, todos os fatores utilizados no mundo real para estabelecer confiança entre parceiros, como o contato face-a-face, o tom de voz, a linguagem corporal, recomendação por fontes confiáveis e o senso comum são completamente perdidos ou distorcidos na interação com essas comunidades. Isso ocorre devido ao uso de diversos tipos de interface de comunicação entre os parceiros(geralmente baseadas em telas gráficas ou de texto) e ao alcance geográfico das tecnologias envolvidas, fazendo com que a distância dificulte a ligação entre nossas fontes confiáveis e nossos parceiros virtuais. O problema torna-se ainda mais pronunciado, quando levamos em consideração a facilidade e baixo custo da troca de identidade dos usuários em sistemas computacionais. Surge, portanto, a necessidade de um agente capaz de classificar o comportamento social de participantes no contexto das sociedades regidas por software. Essa classificação, medida como reputação, tem por finalidade prover uma fonte confiável para encorajar as transações entre as entidades participantes 1 de uma comunidade virtual. De forma abstrata, pode-se dizer que a construção da reputação de uma entidade está intimamente relacionada a fatos ocorridos ou ações realizadas por ela, e que são consideradas pelas demais entidades como sendo bons indicativos. As entidades se avaliam, classificando as ações umas das outras e uma seqüência dessas ações faz com que se obtenha a reputação atual das entidades avaliadas. A partir desse cenário, definimos reputação como sendo a tradução quantificada dos conceitos que uma entidade tem sobre outra, onde conceitos são um conjunto de avaliações realizadas sobre a entidade reputada. O estudo da reputação é, portanto, motivado tanto por questões econômicas quanto sociais. Ele está diretamente associado, não apenas aos trabalhos teóricos sobre cooperação e confiança, como também à construção de mercados, pois o poder de previsão de um indivíduo sobre uma entidade depende da suposição de que o comportamento passado é um indicativo do comportamento futuro. Devido à emergente necessidade do desenvolvimento de sistemas que fazem uso de técnicas para o uso da reputação por partes de suas entidades, alguns trabalhos têm sido apresentados, propondo técnicas e modelos cujo objetivo é aumentar a confiança mútua entre as entidades envolvidas. Podemos também observar uma primeira geração de sis- 1 pessoa, ítem ou serviço que participa de uma comunidade.

121 temas que tentam classificar, de formas ainda primitivas, o comportamento de suas entidades através de recomendações, avaliações (notas) e atribuições de níveis de confiança. Um exemplo é o sítio de leilões virtuais ebay [ebay Foundation, 1998], cujas entidades reputadas são os usuários que utilizam o serviço para comprar e vender produtos. Um modelo mais refinado é aplicado no sítio Advogato [Levien, 2000], que consiste em uma comunidade de desenvolvedores de software que trocam experiências através de pequenos artigos postados no próprio sítio. Essa comunidade, além de atribuir uma métrica de confiança aos autores, apresenta também resistência a ataques, ou seja, usuários que tentam deteriorar intencionalmente a confiança de um autor. Esses sistemas têm se tornado conhecidos como Sistemas de Reputação. Objetivamos, nesse trabalho, dar mais um passo em direção a construção de sistemas de reputação, expondo aspectos sobre a arquiteturas e desafios de conceito e projeto, assim como as propriedades desejáveis para que se obtenha um gerenciamento robusto de reputação em uma comunidade virtual. O artigo também apresenta uma implementação de um sistema de reputação simples seguindo esses critérios aplicado a uma comunidade virtual existente. Essa experiência viabilizou a avaliação das propriedades discutidas e revelou as dificuldades e desafios de se concretizar o conceito de reputação em sistemas baseados em interfaces virtuais. 2. Sistemas de Reputação Um sistema de reputação pode ser definido como um ambiente cujas entidades estão associadas a valores (geralmente números) que quantificam o conceito que as demais entidades têm sobre ela. Esse sistema deve prover uma aplicação cuja função é prover as funcionalidades necessárias para gerar e coletar avaliações e construir a reputação das entidades desejadas presentes nesse ambiente. Expandindo a proposta apresentada em [Kollock, 1999], sistemas de Reputação podem ser divididos em dois grandes grupos: o primeiro, conhecido como Sistema de Reputação Negativo ou Positivo, é definido como sendo um sistema público de distribuição de informações sobre negociantes. Consiste basicamente de listas negras com informações negativas sobre esses participantes ou em uma lista de boas referências. O segundo grupo, constituído pelos Sistemas de Reputação Mistos, é o mais comum e completo, pois apresenta os usuários em diversos níveis na escala de reputação. A construção da reputação, bem como seu entendimento nesse trabalho, pode ser visualizada na Figura 1, onde a reputação de uma determinada entidade é obtida a partir de uma seqüência de avaliações (provenientes das entidades avaliadoras do sistema). Estamos ilustrando uma abordagem centralizada, na qual as avaliações individuais criam uma confiança pessoal sobre a entidade avaliada e o conjunto dessas confianças individuais se traduzem como sua reputação no sistema como um todo. As transações através de comunidades virtuais têm peculiaridades que tornam a construção de reputação bastante mais complexa e difícil nesse contexto. Uma delas está no fato de a quantidade de informação disponível sobre as entidades avaliadas em uma comunidade virtual ser, de forma geral, muito reduzida. Soma-se a essa, o problema de serem essas comunidades altamente voláteis (por exemplo, devido à facilidade da troca de identidade por parte dos usuários hoje em dia diante dos inúmeros serviços de

122 Entidade 1 Avaliaçãop Cria Confiança 1p Tradução Entidade p Reputação Entidade n Avaliaçãop Cria Confiança np Figura 1: Esquema Funcional da Construção da Reputação gratuitos oferecidos). A utilização do conceito de reputação, como uma espécie de garantia subjetiva na Internet, poderia facilitar e incentivar as transações entre os participantes e ainda diminuir o tempo gasto na seleção e filtragem da informação utilizada pelos usuários da rede Fluxo de Informações Para que se possa realizar o cálculo e a manutenção da reputação das entidades do sistema, é preciso que as informações necessárias sejam enviadas para o sistema de reputação de forma a ser tratada e utilizada. A informação chega até o sistema através de um dos atores existentes. A Figura 2 mostra não apenas os atores, mas também o fluxo da informação no sistema de reputação que será utilizada para a construção dos índices de reputação. Entidades Avaliadoras Cadastro Avaliação Sistema de Reputação Cadastro Reputação (visualização) Servidor da Communidade Cadastro Reputação Entidades Avaliadas Figura 2: Esquema Funcional da Arquitetura de um Sistema de Reputação Descrevemos abaixo os atores presentes em sistemas de reputação, assim como o seu escopo de ação. Entidades Avaliadoras: são os usuários (compradores, vendedores ou alocadores de serviço) que podem avaliar as demais entidades. Realizam basicamente dois tipos de ações: avaliam outras entidades e realizam o seu próprio cadastro, onde podem fornecer informações que eventualmente serão usadas para auxiliar no cálculo da reputação de entidades avaliadas, ou mesmo da sua própria reputação. As avaliações podem ser definidas como insumos do sistema de reputação. É a partir das avaliações que o sistema poderá gerar ou atualizar a reputação das entidades avaliadas.

123 Entidades Avaliadas: são as entidades que recebem as avaliações. Os valores de reputação calculados se referem a esses atores. As entidades avaliadas podem ser prestadores de serviço, vendedores, ou mesmo bens, como artigos, livros ou revistas. Devem, necessariamente, ser cadastrados. No contexto descrito pela Figura 2, o sistema de reputação, como descrito na seção 2.1., atua como analisador das avaliações e comentários recebidos além de poder fazer uso de outras possíveis fontes de informação para gerar ou atualizar o valor da reputação das entidades avaliadas. Esse sistema deve interagir com o servidor da comunidade virtual à qual foi aplicado. As demais entidades existentes no sistema fazem uso da reputação criada para tomarem suas decisões. Quando essas passam a realizar transações, começam a se portar como entidades avaliadoras e serão, conseqüentemente, avaliadas. Nesses sistemas, não há necessariamente uma disjunção entre papéis que as entidades podem exercer no sistema. Assim, é bastante comum que a mesma entidade possa atuar, em momentos distintos, como avaliador e avaliado. Os atores interagem entre si da forma mostrada na Figura 2, possibilitando a construção e manutenção da reputação das entidades participantes. Outras informações podem ser úteis no cálculo da reputação, como, por exemplo, os resultados de técnicas de mineração de dados [Agrawal et al., 1993] nos dados coletados pelo próprio sistema no ato do cadastro. Buscando um equilíbrio entre o poder de influência de uma entidade avaliadora na reputação de seus avaliados e seu histórico de avaliações, consideramos nesse trabalho uma estratégia onde cada entidade avaliadora é associada a um valor - o senso crítico. Esse valor é atualizado com o passar do tempo, ou a cada vez que o avaliador interage no sistema, e mede a capacidade de avaliação de uma entidade. O senso crítico influencia diretamente no quanto a avaliação atribuída irá incidir sobre o índice de reputação do avaliado em questão [Dellarocas, 2000]. O cálculo da reputação de uma entidade é bastante delicado, tendo em vista os requisitos que devem ser alcançados. O efeito desejado é a imunização das entidades avaliadas contra avaliações injustas ou incoerentes e a validação das avaliações sensatas e coerentes Propriedades de um Sistema de Reputação O projeto de sistemas de reputação é uma tarefa complexa, uma vez que esses utilizam, não só inúmeras variáveis, como também apresentam como saída, a quantificação da reputação de determinada entidade, que certamente influenciará uma eventual transação envolvendo a entidade reputada. A construção de sistemas de reputação mostra-se, dessa forma, uma tarefa que precisa satisfazer alguns requisitos para que possa ser utilizada sem que existam injustiças e enganos quanto ao valor da reputação divulgada para as entidades existentes em uma comunidade. A seguir, definimos o conjunto mínimo de propriedades necessárias para garantir que o sistema criado associe a cada entidade, o índice de reputação que mais se adequa a ele, de acordo com as avaliações por ele recebidas.

124 Completeza Não existe comportamento que não seja classificável. Em outras palavras, é possível classificar as entidades dentro do espectro de índices de reputação. Consistência Entidades com o comportamento semelhante devem possuir índices de reputação semelhantes dado um mesmo universo. Convergência A qualidade do índice de reputação gerado deve ser minimamente dependente do número de avaliações já realizadas. Eficiência A construção e a atualização dos índices de reputação das entidades devem ser obtidos a baixo custo. Estabilidade A reputação de uma entidade deve estar sempre associada a ela, ser intransferível e perene. O maior desafio relacionado a essa característica está vinculado ao problema da troca de identidade por parte dos participantes da comunidade. Modularidade O sistema deve poder ser inserido em comunidades virtuais sem afetar a funcionalidade desse serviço. Versatilidade O sistema deve funcionar e ser aplicável em qualquer comunidade virtual existente, ou seja, deve ser empregado para quantificar a reputação das entidades de qualquer universo. Transparência Qualquer entidade presente no sistema deve ser capaz de interagir com mecanismo ou paradigma utilizado para o cálculo e manutenção da reputação, podendo ou não, ter ciência do funcionamento do mesmo. Incorruptibilidade Os índices de reputação não podem ser influenciados por companheirismo ou desavenças pessoais. Justiça A reputação das entidades deve refletir na contribuição das avaliações recebidas por outrem, considerando-se, por exemplo, uma ponderação baseada no senso crítico das entidades avaliadoras. Para garantir os requisitos citados, alguns padrões de usuários injustos são procurados pelo Sistema. Um problema clássico, conhecido como o problema do amigo, ocorre quando os usuários favorecem ou depreciam o avaliado (Unfairly Rattings), atribuindo uma nota excessivamente alta ou baixa, visando aumentar - ou diminuir - sua reputação. Esse problema pode existir devido, por exemplo, a desavenças pessoais e quando há avaliações entre concorrentes. Outro problema que surge é a troca de identidade, que, como citado anteriormente, beneficia o usuário que apresenta má classificação e abandona sua reputação corrente(também chamada de karma) para começar uma nova vida virtual livre do fardo negativo que possuía anteriormente. 3. Implementação de um Sistema de Reputação Para ilustrar a arquitetura e as propriedades definidas, desenvolvemos uma implementação de um Sistema de Reputação aplicado a uma comunidade virtual existente na Universidade Federal de Minas Gerais. Nesse ambiente, os alunos, ao final do semestre letivo, realizam avaliações através de um sítio Web sobre as disciplinas cursadas, experiência com os professores e também uma auto-avaliação. Os dados que utilizamos são constituídos de avaliações de alunos, coletadas após o término da avaliação do primeiro semestre letivo de As avaliações serão utilizadas para o cálculo do senso crítico dos alunos, que são, nesse contexto, as entidades avaliadoras e da reputação das entidades avaliadas -

125 disciplinas e professores. As auto avaliações serão utilizadas como fatores de peso para as avaliações realizadas pelos alunos e fazem parte dos fatores que determinam o senso crítico. Espera-se, com a utilização desse sistema, imunizar as entidades avaliadas de avaliações injustas, determinando a reputação das disciplinas, professores e o senso crítico de cada aluno, à medida que as avaliações são feitas. Observaremos a discrepância entre reputação e a nota que essas entidades teriam caso o sistema não fosse utilizado. Desejase também demonstrar a corretude de execução, segundo às propriedades anteriormente discutidas, bem como a viabilidade da implementação de um sistema de reputação em um ambiente onde haja sua necessidade Algoritmo utilizado A implementação faz uso de avaliações - notas - realizadas incrementalmente sobre as entidades avaliadas e faz uso da técnica de senso crítico, descrita anteriormente. O algoritmo proposto computa e atualiza, para cada avaliação atribuída, o senso crítico do avaliador e a reputação da entidade avaliada. Para não comprometer a ordem de complexidade do algoritmo, utilizamos apenas as informações instantâneas das avaliações e a reputação e senso das entidades no estado atual para o cálculo dos novos valores. O cálculo do senso crítico da entidade avaliadora é baseado em duas entradas: a avaliação realizada por ela e a sua auto-avaliação. O novo senso é constituído de um valor, tal que, calculado a partir da média ponderada do senso atual e o senso instantâneo. Um problema que surge quando tratamos de valores sociais, ou seja, parâmetros que determinam o valor de uma atitude dentro do contexto de uma sociedade, é a escolha desses parâmetros para o cálculo do senso crítico das entidades avaliadoras. Parâmetros que podem ser bons indicativos em dada comunidade, podem ter a conotação negativa em outra. Esses parâmetros devem ser determinados a partir de uma análise da natureza, cultura e valores da comunidade em questão. Os fatores considerados na nossa implementação são apenas exemplos de como poderia ser feito o mapeamento de valores sociais ou atitudes típicas para fatores de influência. Descrevemos abaixo os fatores considerados: Distância das avaliações em relação à reputação: Quanto mais distante uma entidade avaliadora atribui uma avaliação a uma entidade do valor da reputação atual do avaliado em questão, mais é penalizada em seu senso crítico. Fator de Coerência: Fator que determina a coerência entre a auto-avaliação e a avaliação atribuída à entidade avaliada. Se, por exemplo, uma entidade avaliadora se auto-avaliou com um valor negativo, ela deve se conter a avaliações neutras. Avaliações que indicam opiniões extremas são consideradas incoerentes e penalizam o senso crítico desse avaliador, pois esse avaliador foi considerado inapto a atribuir esse valor. Fator de Radicalização: Este fator verifica se o avaliador participa com interesse e seriedade no processo de avaliação 2 e o penaliza no caso de sempre atribuir a mesma nota a todas as entidades avaliadas, ou se a taxa de avaliações extremas é alta. 2 No nosso contexto, a avaliação por parte do aluno é obrigatória.

126 Fator Auto-Avaliação: Penaliza a entidade avaliadora que tem uma alta taxa de autoavaliações negativas, pois isso sugere uma perda de influência, devido à falta de interesse, com o passar do tempo. Para representar cada um desses fatores no sistema, utilizamos funções, como exponenciais e sigmoides, com parâmetros que refletem como uma dada configuração de valores deve influenciar no senso crítico. A reputação é definida como um valor, tal que. O cálculo é feito através da média ponderada entre a reputação atual e a reputação instantânea. A última é igual à avaliação recebida, ponderada com o senso crítico e com a auto-avaliação do avaliador em relação a esta entidade. Como todos os participantes estão presos a uma única identidade no sistema, devido ao uso do número de matrícula como identificador, decidimos iniciar a reputação de um novo usuário com um valor neutro, ou seja,. Como o sistema é baseado no processamento dos dados coletados e não em uma interação online, apresentamos, na saída do algoritmo, os índices de reputação finais das entidades avaliadas e o senso crítico final de cada avaliador. Para alguns casos, apresentamos também o histórico da reputação e do senso crítico a cada interação de uma entidade com a comunidade Análise da Implementação Análise das Propriedades Para verificar se a implementação satisfaz as propriedades apresentadas na Seção 2.2., realizamos testes com a carga real e geramos dados sintéticos visando exercitar cada aspecto relacionado à arquitetura e a fatores que influenciam as propriedades. Uma forma simples de verificar as propriedades de completeza, consistḙncia e justiça é através da criação de entidades avaliadas(sintéticas) que tivessem perfis claros e bem definidos. Para isso, adicionamos uma avaliação em cada conjunto de avaliações, feitas pelas entidades avaliadoras, que será processada após todas as avaliações reais. Isso fará com que o senso crítico a que essa avaliação estará associada seja o senso crítico das entidades no estado final do sistema. Em um primeiro momento, direcionamos a avaliação adicionada a uma entidade avaliada sintética, sempre com valores de avaliações ruins. No segundo momento, direcionamos as avaliações a uma segunda entidade avaliada, porém com valores de avaliações positivas. Pela Figura 3, observamos claramente que boas avaliações tendem a bons índices de reputação e que o contrário também é verdadeiro, desde que essas avaliações sejam um consenso em toda a comunidade. Uma vez que utilizamos a mesma referência de senso crítico(as mesmas entidades avaliadoras no estado final do sistema nos dois casos), as propriedades que verificamos são satisfeitas. A eficiḙncia do sistema é observada em seu grau máximo, uma vez que realiza a atualização dos valores do senso crítico e reputação instantaneamente, sem que haja a necessidade de considerar ou recalcular todas as interações do passado envolvendo a entidade. A convergḙncia do sistema pode ser verificada observando a Figura 4, onde é apresentada a diferença entre a média final das avaliações de cada entidade e seus respectivos índices de reputação finais. Mostramos uma curva para entidades que receberam mais do que vinte avaliações e uma com todas as entidades. A diferença observada é

127 1 Variação do Índice de Reputação segundo o Perfil do Avaliado Avaliações Positivas Avaliações Negativas Relação da Reputação com o Conhecimento Variação Reputação,Média das Avaliações Variação Reputação,Média das Avaliações com Conhecimento 0.3 Índice de Reputação Índice de Reputação Número de Avaliações Avaliados (Professores) Figura 3: Reputação em Diferentes Perfis Figura 4: Convergência Algoritmo do devido à influência do senso crítico dos avaliadores para a construção da reputação das entidades avaliadas. A transparḙncia e modularidade do sistema também é uma propriedade existente no algoritmo uma vez que o usuário pode interagir transparentemente com o algoritmo e os fenômenos podem ser facilmente entendidos pelo usuário do sistema, como é descrito na Seção Garantimos a propriedade de Estabilidade fazendo com que cada usuário esteja preso a somente um identificador no sistema, que nesse caso é o número de matrícula. A Incorruptibilidade é sustentada pelos fatores que influenciam o senso crítico, pois eles conseguem capturar e penalizar o senso crítico de um avaliador que sempre favorece ou desfavorece alguma entidade avaliada. Discutiremos mais sobre essa propriedade nas próximas seções. Por fim, a propriedade de versatilidade não se aplica para o caso estudado, uma vez estamos aplicando o sistema em uma comunidade específica Análise da Saída e Comportamento do Sistema Essa seção pretende descrever os pontos críticos tanto do projeto quanto do comportamento do sistema, baseando-se na saída gerada e também descrever os desafios de se concretizar o conceito de reputação em ambientes virtuais. O primeiro desafio encontrado foi em relação às incertezas para a quantificação das respostas das avaliações. Por exemplo, uma das perguntas da auto-avaliação é relacionada ao tempo de dedicação à disciplina. Se o aluno responde que dedica pouco tempo, a causa do pequeno investimento é devido à falta de interesse ou facilidade nos estudos? Para tomar essas decisões, utilizamos o que acreditamos ser mais provável, baseando-se no bom senso. Isso geralmente leva a quantificações imprecisas. O maior ponto crítico, tanto do projeto, quanto do comportamento do sistema, surgiu na análise do comportamento inicial. Quando o sistema começa a receber as primeiras avaliações, é muito provável que não exista nenhum conhecimento sobre as entidades avaliadoras. Podemos, então, adotar duas estratégias para esse caso: Ingênua Nesse tipo de comportamento, o sistema acredita em todas as avaliações

128 que recebe e aos poucos vai determinando o senso crítico dos avaliadores até que o conhecimento da comunidade seja obtido. A desvantagem desse processo, é que avaliadores ruins podem ter grande influência na reputação dos avaliados, simplesmente por serem os primeiros a avaliar. Conservadora O sistema atribui pouca relevância para as avaliações que recebe até que se adquira algum conhecimento sobre a massa de avaliadores. Nesse caso, a avaliação de bons avaliadores podem ser irrelevadas quando esses iniciam o processo de avaliação. Cautelosa O sistema somente apresenta o índice de reputação de uma dada entidade se possuir informações suficientes para gerar um valor justo e coerente. A atualização do senso crítico dos avaliadores é feita após a divulgação da reputação do avaliado pelo sistema. Apesar dessa abordagem sempre divulgar informações mais precisas sobre reputação, ela não provê informações sobre todas as entidades e o cálculo do senso é atrasado, possibilitando, por exemplo, que avaliadores atuem por um certo tempo com um bom senso crítico mesmo que tenham cometido injustiças(avaliando as entidades que ainda não tenham seus índices de reputação divulgados). Implementamos a abordagem conservadora no sistema, porém, sem utilizar um critério muito rigoroso devido ao pequeno número de avaliações disponíveis por aluno. Veremos, a seguir, que, usando essa abordagem, a determinação do senso crítico e reputação demora a convergir e é imprecisa até que o tempo necessário para a aquisição do conhecimento seja atingido. Para atenuar essa questão e prover uma abordagem mais satisfatória, seria adequado fazer um aquecimento inicial do sistema com valores de senso crítico obtidos a partir da análise de dados de cadastro. O aquecimento do sistema tem influência não só na reputação, mas também no cálculo do senso crítico. Quando uma entidade avaliada tem um pequeno número de avaliações, é injusto determinar o senso crítico através do critério da distância das avaliações em relação à reputação. Poucas amostras de avaliações podem fazer com que o sistema julgue incorretamente um avaliador segundo essa métrica. Para evitar o problema, o cálculo do senso crítico é filtrado por uma função que tem como objetivo calibrar a penalização do senso crítico em relação ao número de avaliações, às quais o avaliado foi sujeito. Como efeito colateral, garantindo esse requisito relacionado à justiça, comprometemos a propriedade de convergḙncia. Em sistemas de reputação que utilizam uma abordagem centralizada, encarregamos um agente central da tarefa de referência dos participantes. Entretanto, no mundo real, cada indivíduo tem o seu próprio conceito sobre as entidades com as quais interage. Se a referência sobre algum avaliador muda, podemos, em questão de poucos segundos, reconsiderar todas as avaliações feitas por esse avaliador no passado. Dessa forma, uma avaliação que poderia ter sido considerada injusta no passado e ter prejudicado (ou favorecido) o avaliado, poderia ser justa no presente, dado o melhor conhecimento sobre o avaliador e, portanto, teríamos que alterar o índice de reputação das entidades avaliadas. Esse fator impõe um compromisso entre as propriedades de eficiḙncia e justiça, pois, para garantir a segunda, deveríamos recalcular todas as avaliações passadas de uma entidade assim que determinarmos o novo senso-crítico do avaliador. Essa consideração retroativa compromete a eficiência, podendo até inviabilizar o projeto. Se levarmos ao extremo essa re-avaliação, as ligações entre reputação e senso crítico formariam um laço infinito

129 para o cálculo da reputação, pois o cálculo do primeiro depende do valor do segundo e vice-versa. Como reputação e senso crítico estão intimamente relacionados, o fator citado afeta também o senso crítico. Um exemplo seria o avaliador que sempre soube da incompetência ou desonestidade da entidade avaliada, mas como era o único a saber, sua avaliação se distanciou da reputação corrente e seu senso crítico foi penalizado. Após algum tempo, outras pessoas descobrem esse fato, mas o senso do avaliador não é reconsiderado. Para que se possa visualizar os aspectos discutidos, assim como a utilidade e influência da reputação na comunidade, foram comparadas as médias das avaliações recebidas pelos professores e disciplinas com os índices de reputação dos mesmos em um dado instante. Essa comparação pode ser visualizada na Figura 5. Essa figura mostra, no gráfico da esquerda, a comparação de todas as entidades avaliadas, em um dado instante do sistema, e, no outro gráfico, a comparação do histórico de uma única entidade avaliada a cada interação de seus avaliadores. Notamos que as médias das avaliações muitas vezes não refletem o índice de reputação da entidade. Há ocasiões em que são significativamente distantes, devido, nesses casos, ao baixo senso crítico dos avaliadores. Quanto mais essa distância for acentuada, mais esse avaliado recebeu avaliações injustas e foi imunizado pelo sistema. Podemos também dizer que a massa de avaliadores dessa entidade tem, em geral, um senso crítico baixo. 1 Diferença entre a Reputação e as Avaliações Realizadas Reputação Média das Avaliações Diferença entre Reputação e Avaliação Reputação Média das Avaliações Índice de Reputação Índice de Reputação Avaliados (Disciplinas) Número de Avaliações Figura 5: Diferença entre o Índice de Reputação e as Avaliações Recebidas O gráfico da direita da Figura 5 mostra a dificuldade do sistema em reputar as entidades quando existem poucas avaliações. Pode-se perceber que, enquanto o tempo de aprendizado não é atingido, as notas influenciam muito pouco na reputação dos avaliados. O problema do pouco conhecimento inicial do sistema diante às entidades faz com que os índices de reputação demorem para convergir, levando a índices relativamente ruins quando se têm poucas avaliações realizadas. 4. Conclusões Com o aumento das transações e negociações em comunidades virtuais, a confiança mútua entre os envolvidos está se tornando cada vez mais crítica. Os sistemas de reputação vêm de encontro a essa necessidade, agindo de forma a encorajar as transações entre as

130 entidades e prover uma métrica que represente um fator fundamental para a realização de interações entre indivíduos na sociedade a confiança. Dentre as contribuições desse trabalho, estão a apresentação de uma arquitetura para um sistema de reputação e a definição de um conjunto mínimo de propriedades a que esses sistemas devem satisfazer, visando um gerenciamento robusto e confiável de métricas de confiança. Além disso, ilustramos as idéias discutidas através de uma implementação aplicada a uma comunidade existente. Essa experiência nos revelou os pontos críticos e desafios que devemos considerar no projeto de tais sistemas. Objetivamos, em trabalhos futuros, além de um aprimoramento das técnicas utilizadas, o tratamento de aspectos sobre a calibragem desses sistemas para obtenção de índices de reputação mais consistentes (por exemplo, considerando um aquecimento inicial do sistema). Nesse aspecto, exploraremos técnicas de inteligência artificial para substituir as funções de cálculo de senso crítico, visando uma melhor aproximação dos fatores de influência com essa métrica. Finalmente, avaliaremos outros cenários para a aplicação do sistema. Por exemplo, em redes onde os participantes têm o papel de servidores e clientes de informações ao mesmo tempo as redes Peer to Peer. Como não há uma hierarquia nessas redes, é necessário certificar os provedores de informação, criando uma rede de nós confiáveis. A aplicação do sistema nesse contexto, além de satisfazer aos objetivos de provimento de métricas de confiança, também pode reduzir o tráfego na rede(por exemplo, broadcast), uma vez que a busca por parceiros passa a ocorrer somente dentro das redes de confiança. Referências Agrawal, R., Imielinski, T., and Swami, A. (1993). Mining association rules between sets of items in large databases. In Proc. of the ACM SIGMOD Conference on Management of Data, Washington D.C. Dellarocas, C. (2000). Immunizing online reputation reporting systems against unfair ratings and discriminatory behavior. Proc. of the ACM Conference on Eletronic Commerce - Menneapolis, Minnesota, USA, pages Donath, J. (2001). Identity and Deception in the Virtual Community. Berkeley: University of California Press. ebay Foundation (1998). ebay.com, último acesso: 01 de maio de Flake, G. W., Lawrence, S., Giles, C. L., and Coetzee, F. (2002). Self-organization of the web and identification of communities. IEEE Computer, 35(3): Kollock, P. (1999). The production of trust in online markets. Advances in Group Processes (Vol. 16), JAI Press. Levien, R. (2000). Advogato, último acesso: 01 de maio de Wagner Meira Jr., Cristina D. Murta, S. V. A. C. and Neto, D. O. G. (2001). Sistmas de Comércio Eletrˆonico - projeto e desenvolvimento. Editora Campos - SBC.

131 Design de Sistemas de Ajuda Online baseado em Modelos Milene Selbach Silveira 1,2, Clarisse Sieckenius de Souza 2, Simone Diniz Junqueira Barbosa 2 1 Faculdade de Informática Pontifícia Universidade Católica do Rio Grande do Sul (PUCRS) Avenida Ipiranga, 6681 Prédio 30 Porto Alegre RS Brasil 2 Departamento de Informática Pontifícia Universidade Católica do Rio de Janeiro (PUC-Rio) Rua Marquês de São Vicente, 225 4º andar RDC Rio de Janeiro RJ Brasil {milene, clarisse, simone}@inf.puc-rio.br Abstract. This paper discusses a model-based development of online help systems. A set of HCI design models is presented, together with an analysis of how they were refined and extended in order to include information necessary to generate answers to help requests. The usage of such information and its relation with help content is illustrated using as an example an application that is currently being developed. Resumo. Este artigo discute o desenvolvimento de sistemas de ajuda online, baseado no uso de modelos de design de IHC. É apresentado um conjunto destes modelos, e como os mesmos foram refinados e estendidos a fim de incluir as informações necessárias à construção das respostas às solicitações de ajuda. O uso das informações contidas nestes modelos e sua relação com o conteúdo da ajuda é ilustrado através de seu uso em uma aplicação atualmente em desenvolvimento. 1 Introdução Geralmente, ao utilizar uma aplicação, o usuário tem uma ou mais metas específicas a cumprir, que podem até ser modificadas (criadas, eliminadas ou alteradas) motivadas pela própria interação. Para cumprir estas metas, o usuário necessita realizar uma série de tarefas que, muitas vezes, ele não sabe como executar, ou, até mesmo, não sabe nem que precisa executar. Em momentos como este, o usuário precisa de ajuda. Mas, ao buscar ajuda, o que ele comumente encontra são informações não sobre como realizar estas metas e tarefas, mas sim, informações locais sobre os elementos com os quais está interagindo na interface (resposta típica às questões do tipo O que é isto?) ou sobre questões de funcionalidade da aplicação (Como faço isto?). Estas informações são necessárias, mas não suficientes. Imagine o empregado de uma empresa que acaba de ter suas tarefas informatizadas. Ele necessita saber por que isto aconteceu, ou seja, por que é melhor utilizar a aplicação para realizar o que ele já fazia manualmente. E o empregado novato, que acaba de ser

132 contratado por uma empresa onde todo o fluxo de trabalho está refletido em uma aplicação? Ele precisa não só compreender como realizar estas tarefas por meio da aplicação, mas, também, compreender o que significam estas tarefas no seu domínio de trabalho. Outro tipo de usuário, já conhecedor da aplicação, pode descobrir que existem caminhos diferentes de interação para realizar a mesma tarefa ou tarefas diferentes para cumprir uma determinada meta. Ele pode querer saber por que determinadas tarefas e/ou determinados caminhos de interação são preferenciais em relação a outros, e como estas escolhas são refletidas em seu trabalho. Mas como responder a estas questões do usuário? De onde obter informações necessárias a estas respostas? Estas informações advêm de momentos distintos durante todo o processo de design de IHC, estando, muitas delas, descritas nos diferentes modelos de design utilizados. Entretanto, importantes questões de design, essenciais para o sistema de ajuda online, não são contempladas nestes modelos. Este artigo descreve um conjunto de modelos de design que podem ser utilizados durante este processo e como os mesmos foram estendidos a fim de incluir as informações necessárias à construção das respostas às necessidades de ajuda ao usuário. Esta é uma evolução significativa em relação a trabalhos existentes [Silveira et al e 2001], pois aproveita as informações presentes nos diversos modelos que são desenvolvidos durante o ciclo de design. Em outras palavras, a idéia é substituir o modelo específico de ajuda proposto anteriormente, o qual levaria, certamente, à duplicação do trabalho dos designers, pela captura dos elementos necessários à composição do conteúdo da ajuda, extraídos dos modelos de design. 2 Abordagem utilizada A abordagem adotada neste trabalho (proposta em [Silveira et al e Silveira et al. 2001]), ressalta a importância de aumentar o poder de expressão do usuário, quando do acesso ao sistema de ajuda online, e, também, de qualificar a forma como as respostas a suas perguntas são construídas. O poder de expressão do usuário é aumentado através do uso de um conjunto de expressões para acesso ao conteúdo da ajuda, o qual incorpora as expressões comumente utilizadas em aplicações de cunho comercial, O que é isto? e Como faço isto?. O conjunto completo das expressões utilizadas é: O que é isto? Como faço isto? Existe outra maneira de fazer isto? Onde está? A quem isto afeta? O que aconteceu? E agora? De quem isto depende? Por que não funciona? Epa! Onde eu estava? Por que devo fazer isto? Para que serve isto? Socorro! Não são criadas novas expressões apenas. As respostas a estas questões obtêm, também, um tratamento especial. Elas são apresentadas em um formato minimalista, onde o usuário obtém pequenas porções de informações a cada questão, podendo aprofundar estas respostas obtidas, através do uso recorrente das mesmas [Farkas 1998]. Um exemplo que engloba

133 estas respostas minimalistas e o uso da recorrência de expressões sobre a resposta obtida pode ser visto na figura 1. Este é um exemplo fictício, elaborado a partir das respostas às solicitações de ajuda encontradas sobre controle de alterações, no editor de textos MS Word. E agora? Para revisar um texto, selecione a opção Controlar alterações, no menu Ferramentas. Como faço isto? Como faço isto? Para controlar alterações, selecione a opção Controlar alterações, no menu Ferramentas. Se você deseja ativar/desativar o modo de revisão, selecione o sub-item Realçar alterações. Se você quiser aceitar ou rejeitar cada uma das revisões, selecione Aceitar ou rejeitar alterações. Por fim, se você quiser comparar dois Existe outra maneira documentos, de fazer selecione isto? Comparar documentos. Figura 1. Respostas minimalistas e recorrência de expressões. Além de possibilitar o acesso através destas expressões, a proposta também contempla um módulo de ajuda a parte, onde não só estão detalhadas estas informações e exemplificados cenários de seu uso, como, também, é possível encontrar informações relacionadas ao domínio da aplicação como um todo. Mas onde buscar as informações necessárias? Nesta abordagem via-se estas informações como advindas de um único modelo, o modelo de ajuda (figura 2). Domínio baseia Aplicação pertencem a utilizam composta por executam Tarefas operacionalizadas por Ações Agentes efetuadas sobre Elementos de Interface Figura 2. Modelo de ajuda. Após contrastar-se o modelo de ajuda proposto com os demais modelos de design utilizados durante o processo de design de IHC, verificou-se que uma parte das informações necessárias a construção da ajuda já encontrava-se disponível nos mesmos. Assim, no intuito de reduzir o trabalho do designer do módulo de ajuda e de aproveitar o trabalho realizado pelos demais membros da equipe de design, optou-se pela captura destas informações a partir dos demais modelos de design utilizados durante o processo de design de IHC em vez de construir-se mais um modelo, específico para a ajuda.

134 3 Design de Ajuda Online baseada em Modelos Dentro do processo de design de IHC, são utilizados diversos modelos que permitem representar soluções de interação de forma a apoiar a reflexão e a tomada de decisões sobre o design. É grande a diversidade de modelos existentes. Os modelos de tarefa são os mais comumente encontrados, mas encontram-se também referências a modelos de usuário, de domínio, de apresentação e de diálogo, dentre outros [Paternò 1998, Preece et al. 1994, Puerta 1996 e 1997]. Em [Puerta 1996] ressalta-se que, através dos modelos de design, deveriam poder ser obtidas informações para responder a uma série de questões, que guiariam o trabalho da equipe durante todo o processo. Dentre estas questões, estão: Quem são os usuários da interface? Que tarefas os usuários executam usando a interface? Que objetos de domínio a interface necessita para prover acesso a ela? Como os componentes da interface são apresentados a cada usuário? Que comandos e ações o usuário pode executar na interface? Estas informações são essenciais para o design da aplicação, mas não suficientes para o design do sistema de ajuda online da aplicação, seguindo a abordagem aqui apresentada. Além destas questões mais funcionais, são fundamentais para o conteúdo da ajuda informações que cubram questões como: Qual a natureza do trabalho no domínio da aplicação? Qual a projeção da tecnologia sobre este domínio? Por que é necessário realizar esta ou aquela tarefa ou ação? A quem isto irá afetar? De quem isto depende? Por que determinado caminho de interação é preferencial a outro? O conjunto completo destas questões já foi amplamente discutido em [Silveira et al. 2000] e as informações advindas de suas respostas compunham o modelo de ajuda citado anteriormente. Tendo em vista a possibilidade de reutilizar-se as informações que já estivessem disponíveis, bem como de suprir a necessidade das informações específicas à ajuda, foi feito um estudo aprofundado dos modelos de design encontrados. A partir deste estudo, foi definido um conjunto de modelos e, a suas informações, foram acrescidas informações específicas para uso no conteúdo da ajuda. O conjunto é composto pelos modelos de domínio, de aplicação, de tarefas, de usuário, de interação e de interface. O modelo de ajuda discutido foi eliminado e as informações necessárias ao mesmo são obtidas deste conjunto (figura 3).

135 Modelo de Domínio Domínio baseia Modelo da Aplicação Aplicação pertence a utilizam composta por Tarefas Modelo de Tarefas executam operacionalizadas por Modelo de Usuários Agentes Ações efetuadas sobre Modelo de Interação Elementos de Interface Modelo de interface Figura 3. Modelo de ajuda x modelos de design propostos. A maior parte destes modelos (modelos de domínio, de aplicação, de tarefas, de usuário e parte do modelo de interação) está desvinculada de qualquer tecnologia específica. Já a porção do modelo de interação que trata da operacionalização das tarefas e o modelo de interface, estes, sim, irão depender de como a aplicação está sendo especificada, ou seja, irão depender da tecnologia empregada e do estilo de interface a ser implementado. A criação destes modelos é feita durante períodos distintos do processo de design de IHC. O diagrama da figura 4 apresenta um esquema genérico do ciclo de vida deste processo e em que período(s) cada um destes modelos é elaborado. Modelo da Aplicação Modelo de Tarefas Modelo de interface Levantamento do problema do usuário Design da interação Especificação da interface Modelo de Domínio Modelo de Usuários Modelo de Interação Figura 4. Criação dos modelos de design durante o processo de design

136 Uma questão interessante, que pode surgir a partir desta definição dos períodos de elaboração de cada modelo é se o período em que cada um deles é elaborado importa no processo de construção do sistema de ajuda online proposto. Pode-se pensar que não, que o período não importa, desde que as informações estejam disponíveis quando necessário. Mas um bom design de IHC presume, de certa forma, esta mesma ordem proposta, e, na concepção da construção da ajuda aqui descrita segue-se esta mesma definição. Por exemplo, é possível capturar-se os elementos de domínio quando o modelo de tarefas estiver sendo construído? Sim, nada impede. Mas o conhecimento global do domínio mesmo que este conhecimento venha a ser refinado posteriormente - é essencial antes de começar esta modelagem (tarefas). Como saber como as tarefas são cumpridas (extra aplicação) para modelá-las corretamente sem antes ter conhecimento do domínio no qual elas estão inseridas (e como são executadas normalmente)? E aquelas tarefas que não eram executadas (pré implantação da aplicação)? Como já poder determinar seu impacto no dia-a-dia dos usuários e modelá-las a fim de minimizar este impacto? É possível, também, modelar-se as tarefas visualizando diretamente sua realização na interface ( para fazer X clique no botão Y ). Mas, e se a tecnologia e/ou o estilo de interface a serem empregados mudarem? E se a mesma aplicação for utilizada em ambientes diferentes? Será necessária outra modelagem de tarefas. Além destes fatores, ligados ao processo de design de IHC como um todo e não, apenas, à construção do sistema de ajuda, segue-se defendendo a construção deste durante o processo de design da aplicação [Silveira et al. 2000], para que as informações necessárias possam ser capturadas no momento em que são geradas, não sendo necessário capturá-las novamente, no período final de desenvolvimento, quando a maioria dos sistema de ajuda costumam ser elaborados. Com o uso dos modelos propostos, e sua criação nos períodos descritos, estas informações não apenas servem de insumo às discussões/elaborações da própria equipe de design de IHC, mas também aos responsáveis pelo design do sistema de ajuda, que já podem ir desenvolvendo-o pari passu ao design e desenvolvimento da aplicação. Assim, ao final do desenvolvimento da aplicação já é possível ter, também, boa parte do sistema de ajuda desenvolvida, restando apenas ajustes finais do mesmo. A seção seguinte discutirá em detalhes as informações contidas em cada um destes modelos, exemplificando como elas estão relacionadas as respostas às solicitações de ajuda. 4 Descrição dos Modelos de Design utilizados e sua Relação com o Sistema de Ajuda Online Foram analisados diversos modelos de design distintos a fim de obter-se um conjunto mínimo de informações que pudessem, não só, ser importantes para o processo de design como um todo, mas também, que suprissem a carência de informações para a construção do conteúdo da ajuda. A seguir serão descritos os modelos propostos, explicitando-se as informações necessárias a cada um deles e destacando-se aquelas informações que são essencialmente voltadas à construção do sistema de ajuda. É importante ressaltar que estes modelos não necessariamente devem ser especificados na notação descrita a seguir, e sim, que as

137 informações contidas nos mesmos é que são essenciais para a composição das respostas às solicitações de ajuda propostas. A relação de alguns destes modelos com as respostas às solicitações de ajuda será ilustrada a partir de exemplos de um ambiente de apoio ao trabalho de voluntários em uma ONG, que está sendo desenvolvido atualmente [ORÉ 2002]. O módulo deste ambiente que será utilizado como exemplo é o Quadro de Avisos. Em termos gerais, este módulo permite que os voluntários e funcionários da organização possam postar e verificar avisos referentes a seu trabalho e/ou a organização como um todo. Estes avisos estarão disponíveis para toda a comunidade (membros ou não da organização), através da Internet Modelo de Domínio Este modelo contém informações relativas ao domínio da aplicação, com foco na definição do domínio, da natureza do trabalho no mesmo 2 e, também, no detalhamento dos signos (informações apresentadas ou manipuladas) de domínio utilizados. Além disto encontram-se os papéis que os usuários podem desempenhar neste domínio, as tarefas relacionadas a cada papel, bem como os conhecimentos básicos necessários a cada papel. <modelo de domínio> ::= <descrição> <natureza> {<papel>} {<signo de domínio>} <papel> ::= <nome> [<conhecimento básico>] {<tarefa>} <signo de domínio> ::= <nome> <descrição> <utilidade>... PAPEL Visitante{ TAREFA(Consultar avisos Imprimir avisos Solicitar inscrição) } PAPEL Membro{ TAREFA(Consultar avisos Imprimir avisos Gerenciar avisos) } PAPEL Administrador{ TAREFA(Consultar avisos Imprimir avisos Gerenciar avisos Administrar o quadro) }... 1 A especificação completa deste módulo pode ser encontrada em 2 As informações que são destinadas especificamente a construção do conteúdo de ajuda, estão destacadas em negrito tanto na descrição do modelo quanto na especificação do mesmo. É importante ressaltar, entretanto, que estas não são as únicas informações necessárias à ajuda, e, sim, as que não são tradicionalmente - contempladas nestes modelos.

138 4.2 Modelo de Aplicação Este modelo contém informações relativas à própria aplicação (a ser) implementada. Aqui o foco está na descrição da aplicação, sua utilidade, vantagens, atividades e opções possíveis, e nos signos desta aplicação. <modelo de aplicação> ::= <descrição> <utilidade> <vantagens> <atividades> <opções> {<signo de aplicação>} <signo de aplicação> ::= <nome> <descrição> <utilidade>... SIGNO DE APLICAÇÃO quadro_geral{... UTILIDADE(Para determinar se o aviso será postado no quadro geral (primeira página) do Quadro de Avisos.) }... Para que serve isto? Para que serve isto? Para determinar se o aviso será postado no quadro geral (primeira página) do Quadro de Avisos. 4.3 Modelo de Tarefas Este modelo contém informações relativas às tarefas que os usuários podem realizar. Para cada tarefa possível, é relacionada a descrição da mesma, sua utilidade, o motivo pelo qual ela deve ser realizada (ponto de vista do designer), de qual tarefa-mãe ela provém, o operador 3 que a conecta a próxima tarefa, estabelecendo, assim, a forma de execução da mesma, as condições necessárias para sua execução e os signos de domínio e de aplicação relacionados à ela. 3 Os operadores utilizados na versão atual são os propostos em [Paternò 1999].

139 <modelo de tarefas> ::= <tarefa>{<tarefa>} <tarefa> ::= <nome> <tarefa-mãe> {<pré-condição>} [<descrição>] <utilidade> [<motivo>] <operador> <seqüência> {<signo de domínio>} {<signo de aplicação>}... TAREFA fornecer os dados do aviso{ TAREFA-MÃE(postar um aviso) UTILIDADE(Para informar os dados que permitirão compor o aviso a ser postado.) OPERADOR seqüência SEQÜÊNCIA 1 SIGNO DE DOMÍNIO(título data autor texto detalhes prazo seção) SIGNO DE APLICAÇÃO(quadro_geral login) } TAREFA inserir o aviso{ TAREFA-MÃE(postar um aviso) UTILIDADE(Para que o aviso seja postado no Quadro segundo as especificações dadas.) OPERADOR seqüência SEQÜÊNCIA 2 }... Como faço isto? Como faço isto? Para postar um aviso, você deve fornecer os dados do aviso e inserir o aviso. Como faço isto? Para postar um aviso, você deve fornecer os dados do aviso e inserir Para o aviso. que serve isto? Para que serve isto? Para informar os dados que permitirão compor o aviso a ser postado. 4.4 Modelo de Usuários Este modelo contém informações relativas aos usuários da aplicação. A cada usuário é relacionado seu nome, os papéis que ele pode desempenhar e seu perfil, o que identifica a forma como ele prefere ou pode interagir com a aplicação. <modelo de usuários> ::= <usuário>{<usuário>} <usuário> ::= <nome> <papel>{<papel>} [<perfil>] <perfil> ::= <nome> {<tarefa>}... USUÁRIO João da Silva{ PAPEL(membro administrador) } USUÁRIO Ana Luiza Pereira{ PAPEL(membro) } USUÁRIO Carlos Eduardo Pontes{ PAPEL(membro) }...

140 4.5 Modelo de Interação Este modelo contém informações sobre as formas de interação possíveis na aplicação, ou seja, sobre como efetivamente realizar uma determinada tarefa na aplicação. Para cada tarefa há as alternativas de operacionalização possíveis para sua execução. E, para cada alternativa, há o motivo pelo qual ela deve ser executada (do ponto de vista do designer), a condição para sua execução, a indicação se esta é a forma preferencial de execução da tarefa (do ponto de vista do designer) e a seqüência de ações necessárias para sua execução. Para cada ação, há o valor default da mesma bem como a forma de desfazê-la, além do operador que a conecta a próxima ação. <modelo de interação>::= {<alternativas de operacionalização>} <alternativas de operacionalização>::= <tarefa> <operacionalização> {<operacionalização>} <operacionalização> ::= <nome> [<motivo>] [<condição>] <preferência do designer> <ação>{<ação>} <ação>::= <nome> <seqüência> <operador> [<valor default>] [<forma de desfazer>]... ALTERNATIVAS DE OPERACIONALIZAÇÃO TAREFA inserir o aviso { OPERACIONALIZAÇÃO confirmar a inserção do aviso via botão{ PREFERÊNCIA DO DESIGNER sim AÇÃO pressionar o botão Postar { OPERADOR seqüência SEQÜÊNCIA 1 FORMA DE DESFAZER (apagar o aviso postado, ou então, editar seu conteúdo.) } } OPERACIONALIZAÇÃO confirmar a inserção do aviso via Enter{ PREFERÊNCIA DO DESIGNER não AÇÃO pressionar a tecla Enter no último campo após ter preenchido todos os campos { OPERADOR seqüência SEQÜÊNCIA 1... Como faço isto? Para postar um aviso, você deve fornecer os dados do aviso e inserir o aviso. Para que serve isto? Como faço isto? Por que devo fazer isto? Para que serve isto? Para que serve isto? Para que o aviso seja postado no Quadro segundo as especificações dadas. Como faço isto? Como faço isto? Para inserir o aviso, você deve pressionar o botão Postar. Existe outra maneira de fazer isto? Existe outra maneira de fazer isto? Uma forma alternativa de realizar esta mesma tarefa é pressionar a tecla Enter no último campo após ter preenchido todos os campos.

141 4.6 Modelo de Interface Este modelo contém informações sobre os elementos de interface da aplicação. Para cada elemento, encontra-se o tipo do mesmo, os valores que o mesmo pode assumir, seu valor default, sua localização na interface e os signos de domínio e aplicação relacionados. <modelo de interface> ::= <elemento>{<elementos>} <elemento> ::= <nome> <tipo> [<valor possível>] [<valor default>] <localização> {<signo de domínio>} {<signo da aplicação>}... ELEMENTO texto do aviso{ TIPO caixa de texto LOCALIZAÇÃO (tela Postar Aviso ) SIGNO DE DOMÍNIO (texto) } ELEMENTO seção{ TIPO lista LOCALIZAÇÃO (tela Postar Aviso ) SIGNO DE DOMÍNIO (seção) } ELEMENTO quadro principal{ TIPO checkbox LOCALIZAÇÃO (tela Postar Aviso ) SIGNO DE APLICAÇÃO (quadro_principal) }... 5 Considerações Finais O maior problema dos sistemas de ajuda atuais é que seu conteúdo está intimamente relacionado à interface da aplicação, mas freqüentemente sem qualquer referência às tarefas reais que o usuário necessita realizar. A ajuda relacionada a solicitações do tipo O que é isto?, por exemplo, apresenta o significado de um determinado elemento dentro da aplicação e, não necessariamente, ao(s) conceito(s) correspondente(s) no domínio da aplicação. O mesmo ocorre com solicitações do tipo Como faço isto?, que enumeram a seqüência de passos operacionais (funcionais) a serem realizados sem, no entanto, considerar o contexto mais abrangente da tarefa que os usuários visam realizar, isto é, suas metas, o que corresponderia a um nível tático de informação. O diferencial da proposta aqui apresentada é reconhecer que os usuários precisam ter proficiência (e conseqüentemente devem receber ajuda) não só no nível operacional, com a apresentação de uma ( O que é isto? ) ou mais informações operacionais ( Como faço isto? ) mas, principalmente, nos níveis tático e estratégico. O nível tático relaciona uma ou mais tarefas (compostas de um conjunto de ações) com uma meta que se deseja alcançar. Já o nível estratégico, apresenta os motivos pelos quais se deve realizar determinada(s) tarefa(s) dentro do contexto de trabalho do usuário e, também, quando um caminho de interação pode ser considerado preferencial em relação a outros 4. 4 Para uma discussão aprofundada sobre os níveis operacional, tático e estratégico, vide [de Souza et al. 2000].

142 Informações que possibilitem a construção de respostas às solicitações de ajuda, que abranjam mais do que, simplesmente, como fazer determinada função, indicam a necessidade de uso de diferentes modelos de design e da geração do sistema de ajuda a partir de todos eles. O uso destes diferentes modelos requer, também, o acompanhamento de sua construção, durante o período de design, para que as informações necessárias possam ser capturadas no momento em que são geradas, não sendo necessário capturá-las novamente, quando da construção do sistema de ajuda online. É preciso ressaltar-se, também, que o uso de modelos de design não é considerado apenas para poder obter-se as informações desejadas para o conteúdo da ajuda. O que não foi aqui discutido, por não ser foco deste trabalho, é que estes modelos são extremamente importantes para o processo de design de IHC como um todo. É através de sua construção que as idéias são discutidas e refinadas, até chegar-se a concepção final da aplicação. Dentro destas perspectivas, estuda-se, no momento, a melhor forma de os designers trabalharem com estes modelos (de que forma eles vão formalizar estas informações, se por meio de técnicas diagramáticas e/ou textuais), e como os mesmos afetam o design da aplicação. Em paralelo, está sendo feita a especificação via modelos de design de diversos módulos da aplicação descrita, e efetuada a geração automática dos acessos via expressões e do conteúdo às respostas aos mesmos. Referências de Souza, C.S., Prates, R. e Carey, T. (2000) Missing and Declining Affordances: are these appropriate concepts?. Em Journal of the Brazilian Computer Society, Number 1, Volume 7, July pp Farkas, D.K. (1998) Layering as a Safety Net for Minimalist Documentation. Em Carroll, J.C. (ed.) Minimalism Beyond the Nurnberg Funnel. Cambridge, The MIT Press, Cambridge. Paternò, F. (1999) Model-Based Design of Interactive Applications, Londres, Springer- Verlag. Preece, J., Rogers, Y., Sharp, E., Benyon, D., Holland, S., Carey, T. (1994). Human- Computer Interaction, Reading, Addison-Wesley. Puerta, A. (1996) The Mecano Project: Comprehensive and Integrated Support for Model- Based Interface Development. Em Vanderdonckt, J. (ed) Computer-Aided Design of User Interfaces. Namur, Presses Universitaires de Namur. Puerta, A. (1997) A Model-Based Interface Development Environment, IEEE Software, 14(4), July/August, pp Silveira, M.S.; Barbosa, S.D.J.; de Souza, C.S. (2000) Modelo e Arquitetura de Sistemas de Help Online. Em Anais do IHC2000, Gramado, SBC, pp Silveira, M.S.; Barbosa, S.D.J.; de Souza, C.S. (2001) Augmenting the Affordance of Online Help Content. Em Proceedings of IHM-HCI 2001, Lille, Springer-Verlag. ORÉ, Projeto (2002). Em

143 Analyzing Influences of Context in a Game-mediated Collaboration Marcos Augusto F. Borges, M. Cecilia C. Baranauskas Institute of Computing State University of Campinas (IC-Unicamp) marcosborges@ig.com.br, cecilia@ic.unicamp.br Abstract. Interaction within a group can be understood as an articulation of relationships of reciprocal influences among individuals. In collaborative systems, the actions must be somehow coordinated in order to provide users with interaction protocols useful to reach the objectives of the group. In this work we approach the influence and coordination of the actions by analyzing interaction through conversations mediated by a shared artifact: a collaborative synchronous game. It presents a framework to analyze interaction mediated by a collaborative system and illustrates it by comparing two different contexts of usage: a training process in a factory and a workshop activity in a university. The results address the nature of speeches taking place during the activity in each situation, the role of the players and the ways speeches compose conversations. Resumo. A interação em um grupo pode ser definida como um encadeamento de relacionamentos de influências recíprocas entre indivíduos. Em sistemas colaborativos, as ações devem ser de alguma forma coordenadas para prover os usuários com protocolos de interação úteis para que se alcance os objetivos do grupo. Neste trabalho discute-se a influência e a coordenação das ações de colaboração a partir de uma análise da interação em conversaçõies mediadas por um ferramenta compartilhada: um jogo colaborativo síncrono. O trabalho apresenta um framework para analizar a interação mediada por um sistema colaborativo e ilustra o framework com uma comparação entre dois contextos reais de uso do jogo apresentado: um processo de treinamento em uma fábrica e uma atividade desenvolvida em uma universidade. Os resultados indicam a natureza das falas que ocorrem durante a atividade em cada situação, o papel dos jogadores e a forma como as falas compõe as conversas. 1. Introduction In the past few years we have seen a fast development of computer-based systems that embed tools to support synchronous and asynchronous communication between individuals and groups. Examples include systems for Distance Education, Collaborative Work, Collaborative Learning, as well as systems for entertainment.

144 Most computer-supported environments for distance learning, as well as environments for group work, include some tools to support conversation among individuals. Electronic chat spaces support informal conversations, which are usually ephemeral, lasting only while the current session is alive. Despite the fact that these applications allow conversations to be recorded, analyses of the interaction in these environments are seldom reported in literature. This work aims at investigating the interaction that takes place among participants of learning activities using a collaborative synchronous simulation game. Interaction within a group can be understood in a broad sense as an articulation of relationships of reciprocal influences among individuals; each individual is under the action or influence of others and, at the same time, s/he has the possibility of acting or influencing others [Antillanca 1999]. Thus, interaction among users of a collaborative system can be defined as a sequence of influence actions; the first one, an action of a user that influences other users, followed by the reciprocal actions initiated by the influenced users, and so on. In collaborative systems, the influence actions must be somehow coordinated in order to provide users with interaction protocols useful to reach the objectives of the group. In this work we approach the influence and coordination of the actions by analyzing interaction through conversations mediated by a shared artifact: a collaborative synchronous game. Common ground is a concept used to explain conversation. Common ground means the mutual knowledge, beliefs and assumptions between two or more people, necessary to maintain conversational activity. Collaborators construct and maintain common ground through a process known as grounding [Flor 1998]. Grounding includes the entire process of turn taking when the speakers need to detect and correct misunderstandings. While there is a sound theory around the grounding mechanisms that explain conversation, this concept could be extended to explain collaboration that is required for achieving some common goals. This work uses and evaluates the effectiveness of a conceptual framework for analyzing interaction mediated by a collaborative system: the Framework to Analyze Conversations (FAnC) [Borges and Baranauskas 2003]. The framework is illustrated by comparing the interaction of two different groups of users, in a scenario where they are mediated by a collaborative computer game designed to address concepts of manufacturing processes. The paper is organized as follows: we first present the scenario of the work: the Factory Game. Then we describe the groups involved in the observational study, the framework proposed for analyzing results, and a preliminary analysis of interaction among the players during game running. Finally we discuss some findings and conclude. 2. The Scenario for the study: the Factory Game The Factory Game [Baranauskas et al. 2000, Baranauskas et al. 2001] is a collaborative synchronous simulation game designed for supporting learning of manufacturing concepts. It is a computer supported collaborative learning (CSCL) game in which users from different places, even different factories, can work together to simulate the production process of a hypothetical factory. The users are supposed to collaborate each other to reach a production goal in the factory plant they are simulating. All players share a common view of the game settings, detecting the movements and actions of each other. To allow communication between players, there is an electronic chat

145 space in the center of the Factory Game interface, through which the users can talk to each other in a public or a private way. The game allows the definition of some parameters for the production line such as: the range of machine production by day, the number of working days, the total production goal (which can be calculated by the system based on the other parameters), the Kanban size (number of pieces transferred from one production cell to another by unit of time), the amount of material in each cell at the beginning of the work day, the selection between pull or push production systems, etc. Before starting the game, the users should discuss how these parameters are expected to affect the production cycle of the factory. Based on the discussion, they should define values for setting up these parameters in order to improve productivity of the production line. Once they have defined the best values to these parameters, a special player, the coordinator, is responsible for setting up these parameters. The coordinator is also the player who starts the game and each production day. Each player controls one production cell in the simulated production line. If there are not enough players to control all eight cells, the exceeding cells are controlled by the software. The cells have places for the raw and the processed material. In a simulated day, the players can produce and/or transfer processed material to the next cell in a synchronized way. The amount of production for each cell at each turn is a number inside the range previously defined by coordinator (a random factor define the exact number, simulating a real machine production variation). Figure 1 illustrates a snapshot of the Factory Game interface. Supplier Warehouse Production Cells Space for discussion Figure 1. A snapshot of the Factory Game During the game running, the users can follow visually the plant situation, analyzing what is happening with the production line and pointing out problems when they appear. They can define and change strategies to reach the goal. For example, extra work hours can be attributed to some players, and the implications of this can be explored. They can evaluate

146 how the initial settings are impacting the results. They can, finally, propose new settings and try them in another simulation, looking for improving results. It is during the process of constructing hypotheses and raising explanations for the results that the users can learn, in a motivating process of discovery. The embedded chat is used by the players to discuss these questions, in a collaborative process of learning about concepts of synchronized manufacturing. The aim of the game is to provide the user with opportunities to detect how the production line could be continuously improved. By running the game again with new configurations the users can discuss and test their own hypothesis about the involved concepts. All the discussion that takes place during the game through the chat, and also the game settings defined, can be saved and used for post-event analyses and reflection. This process of learning is important to help the user to practice his role in the company: an active way of detecting problems and suggesting solutions is encouraged nowadays in the daily work of factories. More important than learning about manufacturing concepts, the game provides an environment for learning about working towards a common goal as a team. This new worker is someone that the companies are trying to prepare and this game can help in this. Nevertheless, understanding how interactions take place and what type of conversation lay the basis for collaboration among the players remain to be explored. This type of information could be useful in designing communication-mediated environments, especially for the context of learning. The next section investigates how different contexts of use are reflected in the types of conversation taken place during collaboration in the Factory Game. 3. Comparing Interaction in Two Different Contexts of Use This work is based on an observational study carried out in two different contexts of use for the Factory Game. The first one was conducted in a training situation in a factory involving workers from the factory personnel. The second one took place in a workshop session in the university and involved researchers and graduate students. We intended to evaluate how the groups collaborate in tasks conducted in the Factory Game. It is out of scope of this work to evaluate the learning resulting from the activities. The first observation was conducted during the training of the workers who would be in charge of coordinating the game usage with their colleagues in a factory. The practice occurred in a training room of the company and some findings of this activity were reported in [Borges e Baranauskas 2001]. The authors conducted the second experiment in the university with researchers and graduated students of the group. This experiment took place in the laboratory where this group usually works. The experiments were video recorded and the log file of the embedded chat was saved for future analyses. This work evaluates the differences in interaction we could detect between the two contexts of collaboration among users. FAnC is the framework used to do this evaluation. The main goal is to study the FAnC adequacy in the analysis of interaction and collaboration mediated by a computer system application.

147 3.1. The Framework to Analyze Conversations: (FAnC) The term speech is used by FAnC to denominate each individual chat message sent by a user or by the system itself (the speech acts theory would call it utterance [Liu 2000, p. 84]). These speeches are classified according to three dimensions: - the speaker; - the listener; - the type of information carried on. FAnC group the speeches into three classes, according to the type of information carried on: - strategic: the message addresses results of the game being played, cause-effect relations and considerations about how to reach a better result; - coordination: the message addresses help with the system operation and the synchronization of the players; - side talk: the message is not related to the game subject or to its results. These three classes were then distributed into twelve subclasses for a more detailed analysis. Table 1 shows this classification. Some speeches are long enough to contain two independent segments, from two different subclasses. In these cases, FAnC consider these speeches as two independent ones.

148 Class Subclass R Definition Strategic Theory Et Discussing and relating theory of manufacturing process to the game issues. Previous Analysis In course Analysis Post Analysis Ea Discussing game settings and the strategy to reach the goals before the starting of the game. Ei Discussing game settings and relating it to the results during the game. Discussing the strategy to reach the goals. Ep Discussing game settings and relating it to the results obtained after the game. Discussing the defined strategy. Mixed Analysis Em Discussing game settings and the strategy to reach the goals before starting the game, based on the results of a finished running. Coordination System help Ca Help with the software use. Mapping Commitment Activity help Cx Mapping software activities with the related concepts. Cc Informing actions someone did or will do and what some other player is supposed to do. Cd Discussing what should be the next steps in the game. It is not related to how these steps could be done (Ca), but what could be done based on the defined strategy. Side talk Contextual Lc Comments that uses the game as context for the speech. Not contextual Development Ld Discussion not related to the game subject. La Discussing the system itself. Table 1: Speech and conversation classification (column R presents the subclass representation) FAnC define conversation as a group of speeches that share the same line of discussion (a sequence of related speeches). A conversation was classified according to five dimensions: - starter: the user who initiated the conversation; - class: the class of information carried on of most speeches; - size: the number of speeches that composes it;

149 - parallel: if it has conversations occurring at the same time; - branched: if it subdivides in branched dialogues that continue in parallel Preliminary Results of Analysis Based on FAnC, each speech in the chat log files was analyzed and its class and subclass identified. The conversations were delimited. After that, the chat interaction of each session was represented graphically in a conversation graphic. This graphic represents users as horizontal lines and speeches as diagonal lines connecting the horizontal ones; each line connects the sender to the receiver horizontal line (from left to right). When the message has more than one addressee, this will be represented by lines having the same origin (the left side of the line). Lines are labeled with the speech classification. A square marked with an x identifies the receiver of each speech and a numbered square the sender. A bold number is used in the first speech of a conversation. The time line increases from left to right. A * mark identifies the coordinator. Figure 2 shows a segment of a conversation graphic for three users (J, W and E) of a chat log. Analyzing the graphical representation of figure 2, we can identify two conversations (1 and 2), each one composed by a group of speeches. The first conversation starts with J sending an in course analysis speech (Ei) to the other two players (the two lines having the same origin are representing that the speech was addressed to W and E). Then, W answers also to the other two players (two lines going from W to J and from W to E, having the same origin in time) and the conversation continues. The number inside the squares represents the conversation: the conversation 1 has six speeches and the conversation 2 three. We can also observe that in this case there are not conversations occurring in parallel and the conversations do not have branches. Figure 2: A conversation graphic Using the conversation graphic as a basis, we made a qualitative and a quantitative analysis of the speeches and conversations for the two scenarios of use. We aimed to identify the start of conversations and the singular characteristics of the larger ones, as they supposedly suggest more collaboration among users. All the information collected was entered into a system we are developing to evaluate interaction in group discussion: the CoPA (Collaboration Post Analyses). As one of the results, we have got tables showing the computed types of speeches and conversations

150 distributed into FAnC dimensions. Tables 2 to 7 summarize some of the results, discussed in the next session. Factory # Speeches (%) All Sizes University =1 <=2 <=5 <=10>10 All Sizes 1 <=2 <=5 <=10>10 Total Side talk Ld Lc La Strategic Et Ei Ea Ep Em Coordination Ca Cx Cc Cd Table 2: General quantitative results for conversations (in percentage)

151 Factory University Side Talk 4 Strategic 52 Coord. 44 Side talk 14 Strategic 36 Coord. 50 Ld Et 3 Ca 2 Ld 19 Et 1 Ca 25 Lc 100 Ei 94 Cx 8 Lc 26 Ei 67 Cx 3 La Ea Cc 17 La 56 Ea 15 Cc 18 Ep 3 Cd 73 Ep 14 Cd 54 Em Em 3 Table 3: General quantitative results for speeches (in percentage) University Industry Coordinator 79% 21% 44% 56% Others Table 4: The starters of conversations University 76% 24% Industry 33% 67% Coordinator Others Table 5: The speakers of speeches 0% 50% 6% 12% 86% 26% Industry University Side talk Strategic Coordination Table 6: Conversation started by coordinator, by class. 3,7 3 Industry University Table 7: Average for conversation size

152 3.3. Discussion One important difference we could detect in the game interaction in the two groups is that the university group, even spending a third of the time spent by the group in the factory, carried out three times more conversations and about 2.5 more speeches than the factory group. The results showed that conversations have a tendency to keep the same classification of their first speech. There is no conversation in a class different from the class of its first speech in the factory context and less than 1% in the university context. Analyzing Tables 2 and 3 to compare the two groups, we verify that in the university group we have twice the percentage of the side talk in conversations and 3.5 more side talk speeches. Among the university side talk speeches, the subclass of development is responsible for more than half of the total. The proportion of strategic conversations in the university group is about half of the result of the factory group, but this proportion decreases if we consider speeches instead of conversations. It is important to observe that the proportion is lower, but there are much more speeches and conversations in absolute number in the university group. The difference in proportion of coordination conversations in the two groups is smaller, but the system help (Ca) subclass of the university group is more than four times the proportion found in the factory group. This result seems to be occurred because more than half of the players in the university group were running the Factory Game for the first time, while in the factory group, everyone had already been exposed to the Factory Game before. Summarizing the results shown in Tables 2 and 3, we found that the proportion of conversations in the strategic category is smaller than the proportion of the speeches of this class in both contexts: the university and the factory groups. The medium size of strategic conversations is higher than the size of the other categories of conversation. We can see also that regarding conversations with more than ten speeches, 67% are from strategic type in the factory group and 50% in the university group. Considering the strategic class, we only found the subclass of in course analysis (Ei) conversations in the factory group. This result suggests that these users did not discuss the game settings neither before starting the game nor after it to analyze results. This type of discussion occurred in the university group. It is worth noticing that in the university group, a multi-branched post-analysis conversation took place after running the game, having almost all the players as speech generators and almost all messages directed to all players. This moment resembles a face-to-face meeting, in which everyone is discussing the results around a table. Looking at Tables 4 and 5, we can observe that the coordinator in the factory group started 67% of the conversations (Table 4), while the coordinator in university group started only 21% of the conversations. This result seems to suggest that the factory group use to have their actions more coordinated than the university group. In the university group, one of the players started more conversations and speeches than the coordinator. It seems that the coordinator in the university group spent more time making the coordinator-specific activities required by the software, decreasing his participation in the chat. The coordinator started 86% of the coordination conversations in the factory group and only 26% in the university group, as shown by Table 6. These numbers are higher than the general coordinators conversations. This result suggests that, as it would be expected,

153 coordinators usually start more conversations from the coordination category. The coordinators in the factory started no side talk conversation and the coordinator in the university group started a very small number of this class of conversation. In the experiments developed with the factory group, speeches and conversations of the side talk class were not expressive, according to Tables 2 and 3. Table 2 shows that every conversation in this category has size one, i.e., there is no continuation for side talk speeches. This result is different in the university context in which we can observe side talk conversations of all sizes. The university group produced many more speeches. They also showed less unitary speeches in proportion and the longer conversation of all experiments. But, in average the conversations carried out among the members of the university group are almost 20% shorter, as shown by Table 7. 39% of the speeches produced by the factory group and more than 50% of the speeches produced by the university group were directed to all the other players. This proportion is much smaller in the subclass of activity help (Cd) because the speeches related to activities of helping the players are usually directed to a specific player. 4. Conclusion The results achieved in the analysis conducted in this work confirm that the social context has an important influence in the way users interact each other even considering the mediation of the game. Thus, the design of the interaction and collaboration in a CSCL environment such as the Factory Game has the context of usage playing a crucial role. It seems that in the university group evaluated, the participation in discussions using a chat tool is more common practice to the users routine. We observed much more speeches sent by all users, including side talk conversations. Also, previous and post analysis of the desired outcomes occurred much more frequently, showing multi-branched conversations rich in learning opportunities. Both contexts that were analyzed seem to have negative and positive influences in the collaboration among users through the game. Some results are common to both contexts. For example, the strategic conversations are larger among the university group and among the factory group as well. Based on this result it is possible to say that the Factory Game design affords this type of conversation. This results shows that FAnC can be successfully used in the evaluation of collaboration taking place in chat based CSCL environments. We are now working in the improvement of CoPA, a tool to support other types of analyses of the interaction among people collaborating through electronic chat spaces of a CSCL environment. We intend to analyze, for instance, the distribution of speeches and classes of conversation and their frequency during the game running. This type of information could improve both the design of collaborative systems and the learning process that must take place during it. A tool to provide the coordinator with information about the nature of interaction and collaboration during the game running (CollabSS) is also in development.

154 Acknowledgement FAPESP and CNPq have supported this work. We would also like to thank Delphi Automotive Systems Organization and Nied-Unicamp for their collaboration and support in this work. References Antillanca, H.B., Fuller, D.A. (1999) Refining temporal criteria to classify collaborative systems, International Journal of Human-Computer Studies, 50, p Flor, N.V. (1998) Syde-by-syde collaboration: a case study, International Journal of Human-Computer Studies, 49, p Baranauskas, M. C. C., Gomes Neto, N. G., Borges, M. A. F. (2000) Gaming at Work: a Learning Environment for Synchronized Manufacturing, Computer Applications In Engineering Education, 8 (3 and 4), p Baranauskas, M. C. C., Gomes Neto, N. G., Borges, M. A. F. (2001) Learning at Work through a Multi-User Synchronous Simulation Game, International Journal of Continuing Engineering Education and Life-Long Learning, 11 (3), p Borges, M.A.F., Baranauskas, M. C. C. (2001) Analysing Interaction in a Collaborative Game: a Case Study, Proc.12th SBIE (Brazilian Symposium of Informatics in Education), Vitória-ES, p Borges, M.A.F., Baranauskas, M.C.C. (2003) Supporting the Facilitator in a Collaborative Learning Environment, International Journal of Continuing Engineering Education and Life- Long Learning, accepted. Liu, K. (2000) Semiotics in information systems engineering, Cambridge University Press.

155 Implementação de técnicas de interação no Presenta um software de edição de apresentações na Web Lirisnei G. Sousa Elton S. Oliveira Jair C. Leite Departamento de Informática e Matemática Aplicada Universidade Federal do Rio Grande Do Norte Campus Universitário - Lagoa Nova , Natal - RN {lirisnei,esantana}@lcc.ufrn.br jair@dimap.ufrn.br Abstract. This work introduces a software tool for editing slide presentations using Internet browsers. The Presenta is a WYSIWYG browser-based software and it was developed to attend usability and low-cost requirements. It should be easy to use, easy to learn, and run in low-performance computers. In order to achieve these requirements, Presenta was implemented using Internet standard technologies such as DOM, HTML, JavaScript, Cascading Style Sheets (CSS) and browsers. It can be used both with connected and notconnected computers. The main points of this paper is to discuss some interaction techniques and how they were implemented using Web technologies. We also develop an Application Programming Interface using Javascript that could be used elsewhere to implement the interaction techniques. Resumo. Este trabalho apresenta uma ferramenta que permite a edição e a exibição de apresentações de slides através de browsers na Internet. O Presenta é um software aplicativo baseado-em-browser que permite a edição de slides no modo direto (WYSIWYG) e foi construído baseado em requisitos de baixo custo, hardware de baixo desempenho, portabilidade e facilidade de uso e de aprendizado. A ferramenta utiliza tecnologias padrões para a World Wide Web, como DOM, HTML, JavaScript, CSS e pode ser usada em máquinas ligadas a Internet ou máquinas individuais desconectadas, desde que possuam um browser. O ponto principal deste trabalho é discutir algumas técnicas de interação que podem ser utilizadas em software para Web e quais os seus requisitos de implementação. O trabalho apresenta uma Interface de Programação de Aplicação (API) escrita em Javascript com as funções que podem ser utilizadas para implementar as técnicas de interação empregadas. 1 Introdução A necessidade de ampliar o acesso à Internet é fundamental para o avanço de qualquer sociedade e deve ser uma prioridade em programas de governos, de universidades, de empresas e de organizações não-governamentais. Temas como Universalização do Acesso 1 ou Acessibilidade Universal 2 têm sido bastante enfatizados em projetos e 1 I WUA Workshop sobre a Universalização do Acesso, em Belo Horizonte, MG, março de 2001.

156 programas. No Brasil, o programa Sociedade da Informação é uma iniciativa de governo e dentre as suas prioridades está "produzir e disponibilizar no mercado brasileiro dispositivos (hardware + software) de baixo custo... para a geração de conteúdo, bem como para outros usos mais específicos em atividades didáticas em todos os níveis de todas as áreas" (Takahashi, 2000, pag. 41). O sentido dado ao termo Universalização do Acesso no programa Sociedade da Informação é o de atingir um número cada vez maior de pessoas de diversas classes sociais. Entendemos que este também deve ser um dos objetivos principais da área de Interação Humano-Computador. Neste sentido, deve haver esforços para ampliar cada vez mais a interação entre pessoas e computadores, para que elas possam adquirir conhecimento, utilizar serviços e exercer plenamente sua cidadania. A produção de conteúdo para a Web é um grande desafio para a Universalização do Acesso. Dentre as diversas formas de divulgação de conteúdos, as apresentações em slides são bastante comuns no meio acadêmico e empresarial como uma maneira de divulgar informações de uma forma sintética e objetiva. Esta forma de divulgação é bastante comum em palestras, aulas, exposições e conferências, o que significa que existe muito material pronto e que poderia ser divulgado para um público bem maior. Existem diversas ferramentas convencionais que possibilitam a editoração e apresentação de slides. Podemos citar o MS PowerPoint, o Corel Presentations 9, o StarOffice Impress e o Lotus Freelance. Estas ferramentas caracterizam-se principalmente pela complexidade de uso, alto custo de compra e pela necessidade de hardware de alto desempenho (espaço em disco, memória e velocidade de processamento) que têm como conseqüência um acesso restrito para diversas pessoas. Um outro problema comum que estas ferramentas de software apresentam é a dificuldade de divulgação do material produzido devido a problemas de portabilidade. Cada ferramenta produz as apresentações em formatos específicos e proprietários que não são compatíveis entre si. As possibilidades de conversão entre um formato e outro são bastante limitadas. O projeto Comunet é uma iniciativa que tem por objetivo a pesquisa teórica e o desenvolvimento de tecnologias de software que possibilitem a comunicação de conteúdos para a comunidade através da Internet [Leite 2001]. No escopo da pesquisa teórica busca-se desenvolver modelos de interatividade que proporcionem softwares mais fáceis de aprender e de usar. Isto requer o desenvolvimento de técnicas de interação usuário-sistema dirigidas a pessoas não especializadas e que sejam adequadas às características da Internet. No desenvolvimento de tecnologia de software, nossas principais metas são o desenvolvimento de software simples e de baixo custo que possibilitem a edição e divulgação de conteúdos nas diferentes formas texto, gráfico, fotográfico, áudio, vídeo através da Internet. Como parte dos objetivos do projeto Comunet, este trabalho descreve o Presenta um software baseado-em-browser para a elaboração de apresentações em slides a serem divulgadas através da Internet. A seguir, a seção 2 descreve o que é software baseadoem-browser e discute as características de algumas aplicações. A seção 3 descreve o 2 Entrevista de Prof. John Karat à Profa. Clarisse de Souza no site

157 Presenta suas principais características, funcionalidades e modos de utilização. A seção 4 apresenta as técnicas de programação utilizadas para implementar as técnicas de interação do Presenta. Por fim, a seção 5 apresenta as conclusões do trabalho. 2 Software baseado-em-browser Para satisfazer aos requisitos de simplicidade, baixo custo, portabilidade, usabilidade e acessibilidade, optamos por desenvolver um software para a Web baseado-em-browser. Um software baseado-em-browser é aquele que se utiliza dos recursos integrantes de um browser como plataforma para sua utilização e execução. Dentre os principais recursos de um browser atual estão o DOM (Modelo de Objetos de Documento) interpretadores para as linguagens HTML, XML, CSS (Cascading Styles Sheets) interpretadores para linguagens script, como JavaScript, integração para objetos executáveis com applets Java e componentes ActiveX/COM. Com estes recursos, uma aplicação baseada-em-browser pode utilizar a área de exibição do browser para gerenciamento de seus componentes de interface e as facilidades de tratamento de eventos para controlar a interação com o usuário. Os softwares baseados-em-browser on-line necessitam de uma conexão com a Internet para operar porque possuem componentes que dependem de um servidor Web. Um software baseado-em-browser off-line opera em computadores locais sem a necessidade de conexão com um servidor Web. Não estamos considerando baseado-em-browser os sistemas Web cujo núcleo funcional (componentes de negócio e dados) opera no servidor Web e apenas a interface opera no browser. Ainda são poucos os aplicativos de software baseados-em-browser. Existem alguns editores de texto, editores de HTML e jogos. Os editores podem ser WYSIWYG quando permitem que a edição seja feita diretamente na forma final que o conteúdo será visto pelo usuário.vejamos alguns exemplos. O ActivEdit é um editor WYSIWYG baseado-em-browser para desenvolvimento e gerenciamento de páginas HTML [CFDEV, 2002]. Ele é implementado por um componente ActiveX DHTML que, embutido no browser, gera elementos de interface dinamicamente em formato HTML. Por esta característica, este editor apenas funciona em browser Internet Explorer em ambiente MS Windows. O ActivEdit é um produto comercial que deve ser instalado como um componente binário e, portanto, com código fechado. O ewebeditpro é um editor de conteúdos para Web (HTML/XHTML), WYSIWYG, fácil de usar, com interface semelhante à do editor MS Word (WIMP) [Elektron, 2002]. Ele é implementado em Javascript e pode ser introduzido em sistemas Web num local onde normalmente se coloca um textfield. Ele pode ser integrado a sistemas Web de plataformas como ASP, APS.NET, PHP, JSP, Cold Fusion e outras. Para funcionar, o usuário precisa baixar o arquivo Javascript, instalar e comprar uma licença que permite a integração com um servidor Web, sem o qual ele não funciona. O EditLive é um editor HTML, com uma interface no estilo do MS Word (WIMP), e permite a WYSWYG [Ephox, 2002]. Ele é implementado em duas versões. Uma versão com componentes ActiveX/COM para ambiente Windows que permite a integração com outros produtos daquela plataforma. Uma versão em Java que permite a instalação em plataformas Linux/Unix ou Mac OS X. É também um produto comercial.

158 O WebEditPro possui as mesmas características dos outros editores HTML [Webedpro 2002]. Ele permite a edição WYSWIG de conteúdos Web em HTML, em uma interface WIMP. O WebEditPro não é exatamente um software-baseado-em-browser, mas um sistema web, uma vez que todo o processamento ocorre no servidor Web. Existe uma versão em Perl e PHP para a plataforma Linux/unix e uma versão ASP para o ambiente Windows. 3 O Presenta Nesta primeira edição do Presenta nosso objetivo principal foi desenvolver tecnologia para a implementação de técnicas de interação. Não houve uma preocupação excessiva em desenvolver uma interface com a melhor usabilidade, mas verificar como técnicas já conhecidas em interfaces WIMP poderiam ser implementadas em um software baseadoem-browser. A interface do Presenta segue o padrão WIMP da maioria dos aplicativos de edição. Existe uma barra de menu, uma barra de ferramentas, uma área de edição WYSIWYG que permite ao usuário visualizar o slide com será apresentado e várias caixas de diálogo que permitem ao usuário realizar diversas tarefas auxiliares. O Presenta oferece as tarefas básicas necessárias para se editar uma apresentação. Os Casos de Uso estão descritos da figura 1 e foram descritos em detalhes através de Cenários e Diagramas de Atividades UML (Unified Modeling Language) em [Sousa, 2002]. A partir desta descrição elaborou-se o modelo conceitual. 1. Criar uma nova apresentação 2. Abrir uma apresentação existente 3. Escolher estilo/modelo da apresentação 4. Adicionar novo slide 5. Eliminar um slide 6. Editar slide a. Inserir objetos b. Mover objetos c. Eliminar objetos d. Modificar propriedades 7. Modificar seqüência de slides 8. Salvar apresentação Figura 1: Casos de Uso do Presenta 3.1 O Modelo Conceitual O modelo conceitual tem por objetivo descrever a aplicação de forma abstrata e simplificada. Através dele pode-se especificar os principais objetos da aplicação, suas propriedades, relacionamentos e as funções que os manipulam. O Presenta possui dois componentes conceituais distintos: a apresentação e editor. Esta separação permite uma independência entre a apresentação e os elementos de interface necessários para a sua edição. A apresentação determina os componentes conceituais de uma apresentação e a forma que ela deve ser estruturada na aplicação. O modelo conceitual está descrito através de diagramas de classe UML mostradas na figura 2 que ilustra os conceitos, seus relacionamentos e propriedades. O storepresentation é o ambiente dentro do browser que permite o armazenamento de uma apresentação de forma estruturada. A apresentação (present) possui várias propriedades tais como title, author, date, file,

159 comments e slidesnum, e é composta por um cabeçalho (presentheader), rodapé (presentfooter) e uma seqüência de slides. Cada slide é composto por um cabeçalho (slideheader), rodapé (slidefooter) e um conjunto de elementos (slideelem). O cabeçalho e rodapé da apresentação são comuns a todos os slides. Quando o usuário define um cabeçalho ou rodapé para um slide específico, este tem prioridade sobre os da apresentação. Um elemento do slide (slideelem) é um conceito genérico que permite definir propriedades de posicionamento e interação com cada elemento do slide de forma a permitir a interação WYSIWYG. São elementos de slide o text, image, table, ordlist, unordlist, link, fileobj. Figura 2: Modelo conceitual de uma apresentação O editor define os elementos da aplicação que permitem a edição da apresentação. Isto envolve objetos de interface que permitem a interação e a visualização dos elementos da apresentação. A figura 3 mostra um diagrama de classes UML que descreve os componentes conceituais que formam a interface. Podemos identificar que o editor é composto por menubar, toolbar, editorwindow, e pelas janelas de diálogo slideproperties, presentationproperties, text, Properties, tableproperties newslidemodel, openfile e objectaction. Estes componentes conceituais são implementados através do Document Object Model (DOM) e de funções em JavaScript. 3.2 A Interface do Presenta A partir do Modelo Conceitual foram elaborados alguns rascunhos de telas da interface que permitissem a realização dos Casos de Uso previstos. As diversas telas de interface foram analisadas com o objetivo de avaliar problemas de usabilidade e viabilidade de implementação das técnicas de interação empregadas. A figura 4 mostra a versão final da interface da tela principal do Presenta. Nela podemos identificar uma Barra de Menus Pulldown em Cascata, uma Barra de Ferramentas; a Área de Edição e uma Janela de Diálogo. Estes elementos de interface são bastante comuns em aplicações WIMP. Isto permitiu mostrar como elas podem ser implementadas em software baseado-em-browser.

160 Figura 3: Modelo conceitual do editor A Barra de Menus permite ao usuário acessar as principais funções do Presenta. Ela esta organizada seguindo o padrão da maioria das aplicações WIMP. Optou-se por esta estrutura por ela ser bastante conhecida dos potenciais usuários. A Barra de Ferramentas permite a realização das tarefas mais comuns de edição. Ela possibilita uma interação mais direta. Além disso, ela oferece widgets que permitem modificar as propriedades de objetos selecionados. Neste caso, o usuário deve selecionar um objeto do slide na área de edição e em seguida modificar o valor da propriedade desejada (cor do texto, tamanho da letra, alinhamento, etc.) A Área de Edição permite ao usuário visualizar e interagir com os elementos que compõem um slide. Ela permite a interação WYSIWYG, isto é, o usuário interage diretamente com a forma final do slide que esta sendo editado. Esta área de edição permite ao usuário utilizar técnicas de interação de manipulação direta como selecionar (point-and-click) e mover (drag-and-drop) os objetos do slide. Estes objetos podem ser um texto, uma imagem, uma tabela, uma lista, um link, etc. A figura 4 mostra um slide contendo um texto (título), duas figuras e uma lista. O usuário pode mover cada objeto diretamente com o mouse para qualquer ponto da área de edição. O texto do título teve a cor modificada através da seleção do objeto e a escolha da cor vermelha através do menu drop-down na Barra de Ferramentas. Diversas Janelas de Diálogo no Presenta permitem ao usuário realizar tarefas mais específicas. Elas são utilizadas na interface quando existe um conjunto de interações que o usuário deve necessariamente realizar (interação modal) ou quando estas interações formam um conjunto de opções relacionadas. A figura 4 mostra uma janela de diálogo que é mostrada quando o usuário quer inserir um novo slide na apresentação. Esta janela permite o usuário escolher entre 4 modelos de slide previamente definidos. Caso o usuário não queira seguir algum dos modelos ele deve escolher o modelo em branco na janela de diálogo.

161 Figura 4: Interface de Usuário do Presenta 4 Implementação O Presenta foi implementado utilizando quatro tecnologias principais HTML, DOM, CSS e JavaScript. A linguagem HTML 3 é utilizada para definir os elementos do Presenta e de sua Interface. O DOM (Document Object Model) oferece os recursos para se definir toda a estrutura que implementa o modelo conceitual da apresentação e da interface. O DOM possui uma rica estrutura de objetos que permite controlar e estruturar cada um dos elementos HTML. As Folhas de Estilo em Cascata (CSS) permitem definir os aspectos estéticos de cada elemento HTML. Podemos dizer que a CSS define a aparência dos objetos enquanto que o HTML define o seu esqueleto. O DOM permite modificar estes elementos dinamicamente. Para que o Presenta pudesse ser implementado era necessária uma linguagem de programação para manipular os elementos estruturais do HTML e os seus estilos em CSS através do DOM. Utilizamos a linguagem Javascript por ser interpretada pela maioria dos browsers e possuir os principais requisitos necessários para viabilizar a programação de um software baseado-em-browser. A arquitetura global do Presenta pode ser vista na figura 5. Os dois principais componentes conceituais do Presenta, a apresentação e o editor, descritos na seção 3, são implementados na forma de estruturas do DOM. Estas estruturas são manipuladas por funções JavaScript das APIs (Interfaces de Programação da Aplicação) da interface 3 Na verdade foi utilizada a XHTML que é a HTML definida a partir da XML. Utilizaremos o termo HTML no restante do artigo.

162 (InterfaceAPI) e da apresentação (ApresentAPI). As funções da API são ativadas pela ocorrência de eventos que são detectadas pelo browser. DOM Estrutura da Apresentação Estrutura da Interface 3UHVHQWD browser Figura 5: Arquitetura Global do Presenta Para que seja visualizado em um browser, o Presenta possui a estrutura básica de um arquivo HTML, como mostra a figura 6. Os elementos de estilo e as funções script são fixos. Os elementos que estão no corpo (body) são gerados dinamicamente. As seções a seguir descrevem as principais soluções que foram empregadas para viabilizar a implementação da estrutura de apresentação e da interface do Presenta. <html> <head> <style> Estilos utilizados pelo Presenta e não pela apresentação do usuário. </style> <script> Funções da API. </script> </head> <body> Elementos do Presenta modificados dinamicamente. </body> </html> Figura 6: Estrutura HTML do Presenta presentapi InterfaceAPI JavascriptAPI 4.1 A estrutura da apresentação A estrutura conceitual da apresentação descrita na figura 2 precisa ser definida em HTML para que possa ser armazenada e manipulada através do DOM durante o processo de interação. Esse tipo de estrutura não pode ser armazenado diretamente em um arquivo HTML, pois não seria um documento válido. Armazenamos esse tipo de estrutura simulando os objetos com elementos HTML. A estratégia usada é a seguinte. O BODY contém o corpo da apresentação. O elemento HTML DIV é usado para representar elementos de uma apresentação para isso o atributo title do DIV é utilizado com um valor que identifique o elemento (title ="tipodoelememto ) que esse DIV representa. Os atributos de um elemento da apresentação são armazenadas em um elemento(html) input onde o atributo name do input é igual a properties e o atributo value tem os atributos e os valores dos atributos (<input type="hidden" name="properties" value="top=230//left=200//"/>).

163 O elemento DIV representa a apresentação <div title="present" >, ou seja, o elemento present que é o elemento raiz da apresentação,. o elemento slide (<div title="slide" id="slide numero 1" > ), o atributo ID é armazenado dentro na definição da tag do DIV, para auxiliar a procura. O DIV ainda representa o spaceelement (<div title="spaceelement" >). O elemento espacial é uma caixa que contem os elementos visuais da apresentação (imagem, texto,...). O DIV que representa o spaceelement tem como filho um elemento html visível ( p, img, table,...). <body > <div title="apresent" > <input type="hidden" id="properties" value="title=pesquisadores de Ciências da Computação//slidesNumber=2//"/> <div title="slide" id="slide numero 1"><input type="hidden" name="properties" value="oeder=1//bgcolor=blue//"/> <div title="spaceelement" > <input type="hidden" name="properties" value="top=130//left=200//"/> <p>modelo Conceitual </p> </div> <div title="spaceelement" > <input type="hidden" name="properties" value="top=230//left=200//"/> <img src="../modconc.bmp" alt="ok" /> </div> <div title="spaceelement"> <input type="hidden" name="properties" value="top=300//left=350//"/> <ul> <l i > <p><input type="hidden" name="properties" value="fontcolor=black//"/> A bs t raç ão da Ferramenta </ p> </ l i > <l i > <p><input type="hidden" name="properties" value="fontcolor=black//"/> Visão de Interação </p> </li> </ul> </div> </div> { fim do primeiro slide} <div title="slide" id="slide numero 2" > Elementos do Slide número 2 </div>{fim do segundo slide} </div>{ fim da apresentação} </body> Figura 7: Estrutura de uma apresentação em XHTML A figura 7 ilustra a estrutura de uma apresentação com 2 slides de acordo com esta estrutura. Apenas os elementos do slide 1 estão descritos na figura. 4.2 As funções de exibição de uma apresentação As funções de controle da apresentação estão na presentapi e são responsáveis pela dinâmica da apresentação. Quando o arquivo é carregado no browser uma função é chamada e divide o browser em dois frames um visível, onde os slides são mostrados e um invisível que armazena a estrutura da apresentação. No frame visível, inicialmente são carregados o primeiro slide da apresentação e um menu para navegação entre os

164 slides. O menu fica na tela durante toda a apresentação. Quando o usuário solicita a exibição da apresentação de um slide, esse é procurado no frame que está invisível decodificado e mostrado ao usuário. Existem várias funções que manipulam as estruturas através do DOM. Parte da API pode ser vista na figura 8. As funções structtohtml e htmltostruct são utilizadas para transformar um slide da apresentação da forma estruturada para a sua versão em HTML que será visualizada no browser. Esta função também é utilizada para exportar toda a apresentação em formato HTML. As funções changeslide, insertslide e deleteslide permitem gerenciar os slides. A descrição completa está em [Sousa, 2002]. function structtohtml() function structelemtohtml() function htmltostruct() function changeslide() function insertslide() function deleteslide() Figura 8: Funções da presentapi 4.3 Implementação das Técnicas de Interação A seção 3.2 descreveu as principais técnicas de interação que são utilizadas na interface do Presenta. Nesta seção descreveremos as funções da API que permitem implementalas. Esta API foi construída de forma genérica para que possa ser reutilizada na programação de outras aplicações. Algumas funções estão baseadas em [Goodman, 1998]. Implementação da Barra de Menus A barra de menus é definida utilizando três módulos de funções Javascript: menuconfig.js, menufunctions.js, menuwrite.js. O arquivo menuconfig.js é onde se guarda as configurações do menu. Para alterar os dados do menu é necessário apenas modificar dados das variáveis deste módulo. A estrutura de um menu é formada por uma matriz chamada menu. A linha corresponde a um menu, e a coluna corresponde a um item. Quando referenciado menu[0][1], estaremos falando do menu 0, item 1. Esta estrutura e as funções que gerenciam o menu estão mostrada na figura 9. O item [26,22,150] descreve, respectivamente, a posição na esquerda que o menu vai aparecer (atributo left), a posição na altura em que ele irá aparecer (atributo top), e o seu tamanho. No arquivo functions.js encontram-se as funções que manipulam o menu. menu[0]=[ [26,22,150], ["Novo","#",[],1], ["Abrir","#",[],1], ["Salvar","#",[],1], ["Salvar Como","#",[],1], ["Fechar","#",[],1] ] Function setmenu(p1,p2,p3) Function setmenuitem() Function initializelayers() Function dynlayer(obj,parent) Figura 9a: Estrutura do Menu Figura 9b: Funções da InterfaceAPI Barra de Ferramentas

165 A barra de ferramentas (toolbar) do Presenta foi construída para oferecer um acesso rápido às funções de uso mais freqüente, ele é estático, e foi construído em cima da biblioteca de ícones do Gnome que é de distribuição gratuita [Gnome, 2002]. Janelas de Diálogo As janelas de diálogos são criadas dinamicamente. A função createwindow (Object, type) recebe um objeto e o tipo de janela que deverá ser criada, a partir de uma estrutura de janela definida na função, que é uma janela limpa (modelo de janela). A função carrega as propriedades do objeto nos casos necessários ou simplesmente monta a janela de acordo com sua finalidade. Por exemplo, para Inserir Slide não é necessário nenhum objeto como parâmetro apenas o tipo de janela como parâmetro. Na função são atribuídos valores a algumas propriedades tais como, left, top, height, width, definindo assim todos os parâmetros necessários à criação de uma janela. Após o uso da janela, a função destroywindow( ) será chamada, esta função tem como objetivo recolher a janela que não está sendo usada. Ela será chamada pelo botão close, pelo botão cancel e pelo botão OK. Outras funções da InterfaceAPI que permitem a manipulação direta de objetos podem ser vistas na figura 10. A descrição completa está em [Oliveira, 2002]. function gotoxy() function selectelement() function unselect() function release (evt) function engage (evt) function edit () function delete() Figura 10: Funções da InterfaceAPI 5 Conclusão O Presenta é o primeiro resultado do projeto Comunet que tem por objetivo o desenvolvimento de software para elaboração e divulgação de conteúdos através da Internet. Ele cumpre os requisitos pretendidos por ser um software simples, fácil de usar e de aprender, que necessita de um hardware de baixo custo e que pode funcionar em diversos tipos de sistemas operacionais e com qualquer tipo de browser. Espera-se com isto estar atendendo aos requisitos de um acesso mais universal à Internet. A implementação do Presenta utiliza apenas as linguagens HTML e JavaScript, o DOM e as Folhas de Estilo em Cascata (CSS). Por utilizar estas tecnologias, o Presenta pode ser utilizado em diversas plataformas que possuam um browser compatível com as tecnologias citadas, o que garante uma maior portabilidade. Além disso, toda a tecnologia utilizada é livre o que possibilita que o Presenta seja também um software livre e de código aberto. Por fim, o Presenta implementa apenas as funcionalidades mínimas que os usuários necessitam para desempenhar as suas tarefas, visando a simplicidade na utilização. A plataforma Web oferece vantagens e desvantagens em relação à usabilidade. Uma das vantagens é a grande expressividade do meio, uma vez que a Web tem como principal objetivo a divulgação de informações nas mais diversas formas de comunicação: texto,

166 gráfico, animação, fotografia, filme, música, etc. Entretanto, a plataforma Web oferece ainda poucos recursos para a implementação de algumas técnicas de interação. Este trabalho apresentou soluções para este problema. Diversos trabalhos ainda estão por se realizar. Novas versões de protótipos da interface serão desenvolvidas para realização de testes comparativos de usabilidade com a implementação de diferentes técnicas de interação. Em relação à implementação, uma nova versão do Presenta está sendo implementada utilizando apenas XML. Com esta tecnologia será possível descrever a estrutura das apresentações de uma forma mais direta e clara e aumentar o poder de processamento. Pretende-se ainda introduzir mecanismos de groupware para permitir que o Presenta se torne uma ferramenta de trabalho cooperativo e possibilite a integração cada vez maior de comunidades distantes. A versão atual ainda não permite realizar a gravação em um disco local quando o usuário está trabalhando desconectado da Internet. Isto ocorre pelas limitações das implementações dos métodos do DOM que não possibilitam a realização de operações de gravação no disco rígido do cliente por motivos de segurança. Uma nova versão do DOM esta sendo preparada para resolver este problema. Atualmente a gravação ocorre com o auxilio de um servidor Web. 6 Referências CFDEV, ActivEdit, em acessado em 01/05/2002. Crespo, A. & Bier, E. WebWriter: A Browser-Based Editor for Constructing Web Applications Fifth International World Wide Web Conference, Paris, France, Elektron, ewebeditpro, em htp:// acessado em 06/06/2002. Ephox, EditLive, em acessado em 01/05/2002 Goodman, D. Dynamic HTML The Definitive Reference O Reilly, Gnome, em acessado em 05/03/2002. Leite, J.. Projeto Comunet, 2002, Relatório Técnico, UFRN, 2001 Oliveira, E.. Presenta um editor de apresentações na Web, Relatório Técnico de Pesquisa, UFRN, Sousa, L.. Presenta um editor de apresentações na Web, Relatório Técnico de Pesquisa, UFRN, Takahashi, T. (org.). Sociedade da Informação no Brasil, Livro Verde. Brasília: Ministério da Ciência e Tecnologia, Webedpro, WebEditPro, em acessado em 05/05/2002.

167 Scalable Vector Graphics como Ferramenta para Construção de Interfaces Baseadas em Zoom Contínuo Carlos Cristiano Carneiro, Gabrielle D Annunzio Cavalcanti, José Bezerra da Silva Filho, Pedro Porfírio M. Farias Universidade de Fortaleza (UNIFOR) Mestrado em Informática Aplicada (MIA) Fortaleza-Brasil, 2002 cristiano@sefaz.ce.gov.br, gabrielle@sead.ce.gov.br, {bezerra, porfirio}@unifor.br Abstract-The challenge of building user interfaces to manipulate a wide range of information has motivated many researches aimed at proposing solutions based on zoom, such as Spacial Data Management System [1], Fisheye Views [2], Perspective Wall [3], Document Lens [4], Pad++[5], Jazz [8], Bifocal Display [6] and Flip Zooming [7]. The XML technology (Extensible Markup Language) has come consolidating, since its sprouting in 1997, as a standard for representing diverse forms of information. SVG in special is a standard based on XML for vetorial graphics representation in two dimensions. The main objective of this study is to confront the requirements of the interfaces based on zoom, called ZUIs, with SVG technology, in the direction of investigating the adequacy of the SVG use in the construction of this type of user interface. Resumo - O desafio de construir interfaces para manipulação de um grande número de informações, motivou muitos estudos com o objetivo de propor soluções baseadas em zoom contínuo, tais como: Spacial Data Management System [1], Fisheye Views [2], Perspective Wall [3], Document Lens [4], Pad++ [5], Jazz [8], Bifocal Display [6] e Flip Zooming [7]. A tecnologia XML vem se consolidando, desde seu surgimento em 1997, como um padrão para representação de diversas formas de informação. SVG (Scalable Vector Graphics), em especial, é um padrão baseado em XML para representação de gráficos vetoriais em duas dimensões. O objetivo principal deste trabalho é confrontar os requisitos das interfaces baseadas em zoom, chamadas ZUIs com a tecnologia SVG, no sentido de investigar a adequação da utilização de SVG na construção desse tipo de interface. Palavras Chaves: Scalable Vector Graphics, SVG, XML, ZUI.

168 1. Introdução Desde seu surgimento, Java tornou-se a linguagem preferida para implementações de interfaces de zoom contínuo. São exemplos de implementações de interfaces de zoom contínuo utilizando a linguagem Java, Pad++ [5], Jazz [8] e Zoom Browser [9]. Para Bederson [10], que implementou a ferramenta Pad++, a tecnologia Java 2 possui cinco aspectos necessários para construção de interfaces baseadas em zoom: (1) linguagem clara; (2) abstração de detalhes de baixo nível, tais como gerenciamento de memória; (3) grande disponibilidade de bibliotecas de funções utilitárias; (4) suporte a renderização de imagens 2D de alta qualidade, e (5) opera nas plataformas Microsoft Windows e UNIX. Também para BEDERSON [10], a forma mais fácil e intuitiva de construir interfaces de zoom contínuo é a partir de uma abordagem orientada a objetos, considerando cada elemento gráfico como um objeto. Esta última afirmação reforça ainda mais a escolha da linguagem Java como plataforma de construção de Interfaces de zoom contínuo. Construir aplicações para o ambiente Web impõe uma série de restrições que vão desde de fatores objetivos, como o desconhecimento da largura da banda de comunicação com a qual o usuário está conectado, até fatores muito subjetivos, como o desconhecimento do perfil do usuário. Applet é a tecnologia Java mais utilizada para construir aplicações para o ambiente Web. Para CHANG [11], uma das maiores vantagens na construção de interfaces gráficas utilizando applet Java é que esse permite uma grande flexibilidade no projeto, bem como, melhora a performance por permitir que muitas operações sejam feitas do lado do cliente, sem necessidade de acesso ao servidor. Porém, CHANG cita alguns problemas enfrentados com o uso de applets Java: (1) problemas de portabilidade resultantes de diferenças na implementação da JVM (Java Virtual Machine) em diferentes plataformas; (2) restrições no acesso ao sistema de arquivos do cliente, e (3) algoritmos ineficientes para conversão de cores e resolução de imagens. Para TRINIDAD [12], atualmente não existe nenhum software que opere em todas as plataformas de hardware da Internet, nem mesmo Java. Nos últimos anos, XML [13] impôs uma forte tendência em unificar a representação e o intercâmbio de diversas formas de informações, tais como, documentos, bancos de dados, repositórios de objetos, gráficos e imagens. Após seu surgimento, muitas outras tecnologias, baseadas em XML, foram propostas, com finalidades específicas. Diferente de HTML [15] que permite manipulação exclusivamente pelo homem, os dados no formato XML são apropriados tanto para a compreensão humana como também podem ser processados automaticamente por computador. Essa é uma das características forte de XML. Scalable Vector Graphics (SVG) [14], foi reconhecido como um padrão da Web pelo World Wide Web Consortium * em setembro de O SVG é um vocabulário XML * O World Wide Web Consortium (W3C) é uma das principais organizações que normatizam padrões para a Web. Além de congregar as maiores empresas de software do mundo, editou padrões amplamente utilizados

169 específico para representação de gráficos vetoriais em duas dimensões. Diferente dos padrões baseados em bitmap, tais como JPG, GIF e BMP, que representam uma imagem através de uma matriz de pontos, um arquivo SVG possui instruções de como a imagem será renderizada, independentemente da resolução, de forma a permitir uma escalabilidade da imagem (efeitos de zoom-in e zoom-out) sem perda da qualidade. Atualmente, o principal desafio das pesquisas para desenvolver as interfaces ZUI é disponibilizar tais interfaces para o ambiente Web. Nesse sentido este trabalho pretende confrontar uma tecnologia tipicamente da Web, como SVG, com os requisitos das interfaces ZUI, objetivando determinar se SVG é ou não uma ferramente adequada para construção de interfaces baseadas em zoom contínuo.. 2. Motivação Muitos trabalhos têm sido publicados que ressaltam as vantagens das Web-Based Applications (aplicações desenvolvidas usando as tecnologias Web). Sendo o SVG uma tecnologia destinada a essa classe de aplicações, pode-se identificar o crescimento vertiginoso de tais aplicações como a primeira motivação para este trabalho. A necessidade das instituições, governos e empresas disponibilizarem um conteúdo cada vez maior na Internet é outra motivação importante, pois, as interfaces convencionais se mostram impróprias para manipulação de um grande número de informações pelos usuários. A forte tendência de XML em convergir diversas tecnologias da Web e possibilitar a produção de interfaces que sejam apropriadas tanto para a manipulação direta por seres humanos como para o processamento automático por computador, fecha o conjunto das motivações deste trabalho. 3. Zoomable User Interfaces (ZUI) ZUI ou interfaces baseadas em zoom, são descritas por POOK [16] como interfaces hierárquicas que apresentam para o usuário um espaço de informação. No primeiro nível, a informação é apresentada de forma incompleta, em uma escala que permite caber no espaço de uma tela. O usuário pode então aumentar o objeto, focando nas seções de seu interesse. A medida que os objetos gráficos tornam-se maiores, podem ser substituídos por outros de mesma semântica, com o objetivo de melhor detalhá-los. POOK [16] também defende que as interfaces ZUI devem ser providas de uma camada de contexto no sentido de melhorar sua usabilidade. A interação do usuário com as interfaces ZUI ocorre principalmente através de três operações básicas: (1) zoom-in, que corresponde ao aumento da escala dos objetos gráficos, podendo resultar na exclusão de objetos da janela visível; (2) zoom-out, que corresponde à redução da escala dos objetos gráficos, permitindo a inclusão de mais objetos dentro da na Web, tais como HTML, XML, DHTML, XSL, DOM, CSS, entre outros. O endereço do Site do W3C é

170 janela visível, e (3) pan, que consiste do deslocamento da janela dentro do espaço da informação, com o objetivo de focalizar áreas de interesse, sem necessariamente a alteração da escala dos objetos. FURNAS [17] propõe um embasamento teórico para os estudos das interfaces ZUI. Nesse trabalho FURNAS propõe o Diagrama Espaço-Escala *, como forma de compreender os mecanismos envolvidos nas interfaces ZUI. Um problema típico das Interfaces ZUI que pode melhor ser compreendido a partir do diagrama proposto por FURNAS é a execução conjunta de várias operações de pan e zoom, com o objetivo de deslocar a janela visível de um ponto a outro do espaço. FURNAS demonstra que o caminho mais curto entre dois pontos do espaço, em uma interface ZUI, não é necessariamente uma linha reta. Suponha que como resultado de uma pesquisa executada pelo usuário, em um documento eletrônico, a janela visível precise ser deslocada de um ponto a outro do espaço e que para isto sejam necessárias operações de pan e zoom. Esse não é um problema trivial, pois, as operações devem ser executadas de forma otimizada, porém, sem causar desorientação ao usuário. Por outro lado, se o deslocamento envolvendo pan e zoom é executado pelo próprio usuário, o melhor caminho não é meramente determinado por equações matemáticas mas por fatores cognitivos. Para ilustrar essa afirmação, suponha que o usuário deseja se deslocar entre dois pontos muito distantes um do outro. Uma maneira intuitiva de realizar essa transição poderia ser: (1) executar um zoom-out (diminuir) até que os dois pontos (origem e destino) ficassem visíveis; (2) executar um pan até o ponto destino, e (3) executar um zoom-in (aumentar) até restabelecer a escala original desejada. 4. Requisitos das Interfaces ZUI Uma plataforma de desenvolvimento, como Java, Delphi ou mesmo SVG, para que seja utilizado com sucesso no desenvolvimento de interfaces ZUI, deve atender a vários requisitos. A seguir são descritos uma série de requisitos para desenvolvimento de interfaces ZUI, de acordo com os artigos [BEDERSON, MEYER E GOOD] [8] e [BEDERSON, MEYER] [18]. 1. Capacidade para manipular um número muito grande de objetos gráficos, no sentido de atenderem a um vasto escopo de domínios, sem que, entretanto, haja comprometimento na performance da aplicação. Em [18] é arbitrado um número mínimo de objetos gráficos. 2. Processar todas as transições através de animações contínuas, eliminando as mudanças instantâneas da janela visível. Essa característica tem o objetivo principal de prover completo feedback das transições aos usuários, evitando a desorientação. * O nome Diagrama Espaço-Escala é uma tradução feita pelos autores deste trabalho. O nome original é Space-Scale Diagram.

171 3. Suportar gráficos 2D de alta qualidade, pois, sendo as interfaces ZUI, aplicações eminentemente gráficas, a qualidade da aplicação está diretamente vinculada à qualidade gráfica. Esse requisito pressupõe, além da qualidade da imagem, suporte a boas fontes e efeitos gráficos, tais como rotação e transparência. 4. Suportar componentes GUI convencionais, tais como botões, barras de rolagem, menus e barras de ferramentas. Tais objetos devem estar disponíveis no mesmo espaço dos demais objetos gráficos, permitindo total integração entre os mesmos. 5. Oferecer um framework para manipulação de eventos. O modelo de manipulação de eventos deve ser poderoso o suficiente para atender às necessidades dos vários tipos de objetos gráficos e simples o bastante para permitir um uso fácil e eficiente. 6. Suportar zoom semântico. Esse recurso corresponde a capacidade de um mesmo objeto possuir várias representações, dependendo do contexto e da escala em que o mesmo for mostrado. A versão mais reduzida de um objeto pode, por exemplo, ser um simples ponto e os detalhes poderão ser agregados a medida que a escala aumentar, ou seja, a medida que o usuário executar operações de zoom-in. 5. Características de SVG ( Scalable Vector Graphics ) Scalable Vector Graphics é uma linguagem, baseada em XML, desenvolvida pelo consórcio W3C (World Wide Web Consortium) [13] para descrever gráficos de vetores de duas dimensões. O SVG permite três tipos de objetos gráficos: shapes de gráficos de vetores (ex: linhas, curvas), imagens e textos. Os objetos gráficos podem ser agrupados, estilizados, transformados e compostos dentro de objetos antes de serem renderizados. O SVG é utilizado para armazenagem e distribuição de imagens na Web, e é cada vez mais suportado pelos softwares comercias e livres. Em contraste com os formatos como GIF, JPEG, e outros mais, que precisam armazenar a matriz individual de pixels que compõe a imagem, um arquivo SVG contém um conjunto de instruções para a resolução e formação da imagem [14]. Os gráficos SVG além de possibilitar a independência da resolução das imagens, prover outros benefícios imediatos. Os arquivos SVG freqüentemente são menores que os arquivos de imagem análogos, dessa forma, as páginas web levam muito menos tempo para serem transmitidas. O SVG integra a maioria dos esforços de padronização. O SVG é uma linguagem baseada em XML, e é compatível com XML-NS (namespace xml); utiliza Xlink (XML Linking Language) e Xpointer (XML Pointer Language), e o seu conteúdo pode ser estilizado através de outros CSS (Cascading Style Sheets) ou XSL (extensible Style Language) suportando relevantes propriedades comuns. Para manipular as imagens dinamicamente, o SVG inclui suporte a DOM (Document Object Model) em conformidade com as recomendações DOM nível 1 e tem um alto nível de compatibilidade com o HTML e DOM, suportando também várias facilidades descritas no DOM nível 2 [14].

172 O SVG usa elementos XML para representar os modelos básicos, incluindo, elipses, retângulos, linhas e polígnos. O SVG na sua essência é muito similar ao PostScript, mas usando a sintaxe XML em vez de notação postfix. No exemplo abaixo, um elemento SVG descreve um modelo para ser renderizado: <?xml version="1.0" standalone="no"?> <!DOCTYPE svg PUBLIC "-//W3C//DTD SVG //EN" " <svg width="500" height="500"> <rect x="20" y="10" width="200" height="100" style="fill:#92cacc; stroke:none;" /> </svg> Arquivo ZUI.SVG O retângulo está posicionado na coordenada 30,15 com uma largura de 200 unidades e um tamanho de 100 unidades. Coordenadas e tamanhos podem ser especificados explicitamente por unidades, no caso de serem omitidos, o sistema de coordenadas do espaço de usuário é usado [19]. Todos os modelos básicos usam o seu top-left como um ponto âncora. Um elemento especial SVG poderoso é o path. Seu atributo d contém uma string que codifica a descrição de contornos (delineamento) indiscriminadamente. Como exemplo, o elemento <path d= M L L L Z /> descreve um path retângulo de forma equivalente ao procedimento do elemento rect descrito anteriormente. Primeiramente o comando M (moveto) indica movimento até a coordenada (20,10). Em seguida o 1º comando L (lineto) desenha uma linha reta até a coordenada (30,10), o 2º comando L desenha uma linha até a coordenada (30,15) e o 3º comando L desenha uma linha até a coordenada (20,15). Por fim, o comando Z ( closepath) desenha uma linha reta até o ponto inicial, ou seja, a coordenada (20,10), fechando o retangulo. Outros elementos importantes são o defs e use para definir os objetos e depois referenciálos, o image para embutir arquivos de imagens antigas, text para incluir textos e o g para agrupar os sub-elementos para serem renderizados como uma única entidade. O SVG

173 também possui vários elementos de animação animate que descrevem movimento baseados no tempo. Podem ser usados para se obter uma animação ao longo dos paths. Um programa que ler um arquivo SVG tem acesso às suas definições internas de imagem através do SVG DOM (Document Object Model). O DOM permite acessar a árvore de elementos, inclusive permite a manipulação dos atributos dos elementos. No exemplo anterior, pode-se alterar as coordenadas do retângulo manipulando os dados dos elementos de posicionamento. O SVG permite aumentar (zoom-in) ou diminuir (zoom-out) em qualquer parte da imagem sem haver qualquer degradação do objeto. Você pode também, diferente das imagens de bitmap, pesquisar pelo conteúdo de texto dentro da imagem formada. Por exemplo: pode-se procurar por strings de texto específicos, como cidades, dentro de um mapa [21]. O SVG, possui também uma integração direta com a tecnologia Java, estabelecendo fortemente a integração com os padrões abertos de mercado Exemplos SVG Os exemplos apresentados nesta seção têm o objetivo de complementar, de forma prática, a análise do item anterior. A apresentação dos exemplos foi feita com o Adobe SVG Viewer, utilizando-se o Microsoft Internet Explorer Versão 6.0. A Figura 1 [23] explora os recursos avançados de Path, na construção de um Mapa Geográfico. Nesse exemplo, os recursos de Zoom e Pan são providos pelo Adobe SVG Viewer. Figura 1 viola.svg

174 A Figura 2 [24], mostrada a seguir, combina recursos de SVG com programação JavaScript, para conseguir o efeito de fazer com que diferentes elementos tenham comportamento distinto, com relação às operações de zoom e pan. Nesse exemplo, o texto pode sofrer pan e zoom, porém a moldura permanece inalterada. 6. ZUI X SVG Figura 2 Java.svg Responder à pergunta se o SVG é ou não uma linguagem apropriada para desenvolvimento de interfaces ZUI, implica em investigar se os recursos de SVG atendem aos requisitos das interfaces ZUI. Para alcançar o objetivo principal deste trabalho, cada um dos requisitos de ZUI, listados anteriormente, foram analisados, no sentido de determinar qual o nível de conformidade desses requisitos, com relação às características de SVG. Neste trabalho foram propostos quatro níveis de conformidade que são descritos a seguir: Nível 1 - conformidade total. Foram classificados neste nível os requisitos que são claramente atendidos por SVG, conforme suas especificações. Nível 2 conformidade parcial. Os requisitos que são atendidos, porém, de forma limitada, foram classificados dessa forma. Essas limitações devem-se, principalmente, ao fato de que SVG é uma linguagem declarativa e não procedural, ou seja, no SVG não é

175 necessário o programador especificar todos os passos a serem executados. Ao invés disso, um arquivo SVG contém uma descrição de um ou mais gráficos 2D, sem especificar os passos a serem executados para obtê-los. Nível 3 Dependente de implementação. Neste nível estão os requisitos dos quais a conformidade não é claramente excluída pelas especificações de SVG, podendo ou não serem atendidos, dependendo de como as ferramentas de suporte (Browsers, plug-ins e Editores) implementam SVG. Nível 4 Não conformidade. Nesta classificação estão os requisitos claramente excluídos pelas especificações de SVG ou que, mesmo não excluídos, não poderiam ser delegados às ferramentas de suporte, como os requisitos de Nível 3. A seguir, cada um dos requisitos identificados na seção 4 e classificados na Tabela 1, são analisados sob a ótica descrita acima. 1 Manipulação de um grande número de objetos: Para este requisito o nível de conformidade foi 3, pois gráficos SVG são descritos na forma de documentos XML, não tendo portanto, limitações na quantidade de objeto definidos. As limitações serão impostas pelas ferramentas de manipulação, tais como Browsers e Plug-ins, ou mesmo por fatores físicos como capacidade de memória e processamento. 2 Transições através de animações contínuas: Este requisito também tem o nível de conformidade 3, apesar de SVG possuir uma série de elementos de animação definidos em sua especificação [21], o efeito gráfico de algumas operações, tais como zoom-in, zoom-out e pan, depende do tratamento dado pela ferramenta que manipula o documento SVG. A maioria das ferramentas, tais como Adobe SVG Viewer e Batik SVG Toolkik implementam tais operações através de transições contínuas. 3 Suportar gráficos 2D de alta qualidade: Este é um requisito totalmente alcançado por SVG com o nível de conformidade igual a 1. Para PENG [25], gráficos SVG possuem alta qualidade, não importando se são mostrados em laptops, handhelds, monitores, tvs ou mesmo quando impressos em papel. 4 Suporte a componentes GUI convencionais: Apesar de SVG não definir elementos específicos para componentes, tais como botões, menus e barras de rolagem, a utilização de SVG com Javascript alcança plenamente este requisito sendo classificado no nível de conformidade 1. Esta afirmação pode ser comprovada através de projetos como SVGUI [26] e KEVLINDEV [27]. 5 Oferecer um Framework para manipulação de eventos: Com o objetivo de reduzir a necessidade de scripts no uso da tecnologia XML, dois grupos de trabalho do W3C (HTML Working Group e XForms Working Group) se reuniram para desenvolver um framework de propósito geral, para manipulação de eventos, denominado XML Events. Considerando que XML Events não é ainda uma recomendação W3C, este requisito foi classificado no nível de conformidade 2, sendo plenamente alcançado com o uso de scripts.

176 6 Suportar Zoom Semântico: Este não é um requisito alcançado diretamente por SVG. BRADOS [19] propõe uma extensão para SVG no sentido de alcançar este e outros objetivos. Zoom semântico pode ser alcançado com a utilização de scripts. Portanto, este requisito foi enquadrado no nível de conformidade 2 Tabela 1: Requisitos de ZUI versus Nível de conformidade com SVG Nível de Requisitos de ZUI Conformidade com SVG Manipulação de um grande número de objetos 2 Transições através de animações contínuas 3 Suportar gráficos 2D de alta qualidade 4 Suportar componentes GUI convencionais 5 Oferecer um Framework para manipulação de eventos 6 Suportar zoom semântico 7. Conclusão Como mostrado na seção 6, SVG atinge, ou de forma direta ou através do uso de outros recursos, tais como scripts e Plug-ins, todos os requisitos das interfaces ZUI identificados neste trabalho. Apesar de ser uma tecnologia recente nota-se um crescimento rápido na utilização de SVG. Para DUMBILL [22], SVG alcançará ampla adoção, em primeiro lugar, nos dispositivos com telas de tamanho limitado, tais como PDAs e Celulares. Confirmada esta previsão, SVG poderia se habilitar no desafio de levar as interfaces ZUI para tais dispositivos, pois as ferramentas atuais exigem recursos computacionais incompatíveis com PDAs e celulares. Os seis requisitos analisados na Tabela 1 a média do nível de conformidade foi 2 sendo que o nível 1 representa uma conformidade total enquanto que o nível 4 representa ausência de conformidade. Este resultado indica um forte indício da viabilidade do uso de SVG nas interfaces ZUI. A continuidade deste trabalho será a implementação de um sistema ZUI usando o SVG, e a realização de testes de usabilidade. Referências [1] W. Donelson. Spatial Management of Information, SigGraph, Atlanta, [2] George W. Furnas. Generalized Fisheye Views, Anais do CHI 86 Human Factors in Computing Systems, Boston, [3] Jock D. Mackinlay, George G. Robertson e S. K. Card. The Perspective Wall: Detail and Context Smoothly Integrated, Anais do CHI 91, 1991.

177 [4] George G. Robertson e Jock D. Mackinlay. The Document Lens, Anais do ACM UIST 93, Atlanta, [5] Ben Bederson e J. D. Hollan. Pad++: A Zooming Graphical Interface for Exploring Alternate Interface Physics, Anais do ACM UIST 94, Marina Del Ray, Canadá, Novembro de [6] M. D. Apperley, I. Tzavaras e R. Spence. A Bifocal Display Technique for Data Presentation, Anais do Eurographics 82, 1982 [7] Lars Erik Holmquist. Flip Zooming: Focus+Context Visualization of Linearly Ordered Discrete Visual Structures, disponível em [8] Ben Bederson, J. Meyer e L. Good. Jazz: An Extensible Zoomable User Interface Graphics Toolkit in Java, Anais do ACM UIST, Maio de [9] Lars Erik Holmquist. The Zoom Browser: Showing Simultaneous Detail and Overview in Large Documents, Human IT, número 3 volume 2, ITH, Suécia, [10] Entrevista de Ben Bederson concedida a Jon Byous, disponível em Setembro de [11] Yuh-Jye Chang, Paul Coddington e Karlie Hutchens. Viewing the Visible Human Using Java and the Web, Disponível em Julho de [12] Gerardo Trinidad, Ivan Cole e Wan-Yee Chan. Developing Internet-based GIS Applications, Anais do Phillipine Computing Congress (PCSC), [13] Tim Bray et.al. (editores). Extensible Markup Language (XML) 1.0, W3C Recommendation, Fevereiro de [14] Jon Ferraiolo (editor). Scalable Vector Graphics (SVG) 1.0 Specification, W3C Recommendation, Setembro de [15] Tim Berners-Lee e D. Connoly. Hipertext Markup Language 2.0, RFC 1866, Novembro de [16] Stuart Pook et. al. Context and Interaction in Zoomable user Interfaces, Anais do AVI 2000, Palermo, Itália, [17] George W. Furnas e Ben Bederson. Space-Scale Diagrams: Understanding Multiscale Interfaces. Anais do CHI 95 Human Factors in Computing Systems, Denver, Maio de 1995.

178 [18] Ben Bederson e Jon Meyer. Implementing a Zooming User Interface: Experience Building Pad++, Software: Practice and Experience, Volume 28, Número 10, Agosto de [19] Greg J. Brados, Will Portnoy, Jeff Nichols e Alan Borning. A Constraint Extension to Scalable Vector Graphics. UW Technical Report, [20] Bray, Tim at. al., Extensible Markup Language (XML) 1.0, Fevereiro [21] Scalable Vector Graphics (SVG) 1.0 Specification, [22] Edd Dumbill. Picture Perfect, Disponível em Setembro de [23] Disponível em [24] Disponível em

179 Uma Interface Visual para a Elaboração de Consultas em uma Ferramenta baseada no Modelo ERC+ Clodis Boscarioli 1, Laura Sánchez García 2, Marcos Sfair Sunye 2 1 Colegiado de Informática UNIOESTE Cascavel/PR 2 Mestrado em Informática UFPR Curitiba/PR {boscarioli@unioeste.br, laura@inf.ufpr.br, sunye@inf.ufpr.br} Abstract. The growth and the diversification of database systems end-user groups leads to the need for interfaces that make the interaction process between the user and the computer during query elaboration easer. This paper reports the treatment given to a visual database query system, more specifically, to the step of predicate elaboration, under the Semiotic Engineering view, using two support formalisms for interface design, the DMSL (Designer s Message Specification Language), that helps the message definition about the usability model; and STAG (Semiotic Task-Action Grammar), that aims to identify and to represent user tasks in a categorized way. Resumo. Com o crescimento e a diversificação do conjunto de usuários finais de sistemas de banco de dados, surge uma maior demanda por interfaces que facilitem o processo de interação entre o homem e o computador na formulação de consultas. Este trabalho descreve o tratamento dado a um sistema visual de consulta a banco de dados, mais especificamente, à etapa de elaboração de predicados, à luz da Engenharia Semiótica, utilizando no desenvolvimento do protótipo de interface dois formalismos de orientação, a LEMD (Linguagem de Especificação da Mensagem do Designer), que auxilia na definição da mensagem sobre o modelo de usabilidade e a STAG (Semiotic Task-Action Grammar), que objetiva identificar e representar tarefas do usuário de forma categorizada. 1. Introdução Uma dificuldade clássica no acesso a bancos de dados tem sido causada pela necessidade de utilização, pelo usuário final, de linguagens de consulta textuais. Uma linguagem de consulta consiste em um conjunto de operadores, definidos formalmente, que possibilitam ao usuário fazer a consulta a uma base de dados, obtendo desta forma resultados, extraídos dos dados armazenados, que são referentes às informações requeridas pelo usuário. Com o crescimento e a diversificação dos usuários de bancos de dados, tem-se acentuado o desenvolvimento de interfaces baseadas em diferentes princípios, cujo objetivo principal é o de facilitar o processo de interação entre o homem e o computador na elaboração de consultas (CATARCI et al., 1996a). Tradicionalmente, uma forma de fazer com que os usuários obtivessem conhecimento necessário sobre um sistema e sua utilização era por meio de materiais escritos (manuais de usuários) e help de software (nem sempre disponível e eficaz), sem utilizar-se da interface para transmissão deste conhecimento.

180 Os usuários de banco de dados, motivados em parte pela evolução no domínio de aplicação e em parte pela utilização cada vez mais freqüente e consistente de banco de dados, passaram a exigir muito mais quantidade e qualidade de informações, aumentando, desta forma, a necessidade de interfaces adequadas, principalmente no tocante à manipulação das informações constantes nas bases de dados. Nos sistemas em que o gerenciamento dos dados normalmente é realizado no nível sintático, é responsabilidade do usuário não somente formular corretamente suas consultas, como também interpretar os resultados advindos destas. De acordo com (PORTO, 1997), uma consulta feita a um banco de dados requer que o usuário possua um aprimorado conhecimento sobre as estruturas de armazenamento de dados (por exemplo, em um banco de dados relacional, deve conhecer entidades, relacionamentos, atributos, entre outros), além da sintaxe e da semântica da linguagem de consulta utilizada, o que não é uma tarefa trivial para um usuário final de aplicação, uma vez que a especificação da sintaxe que expresse a consulta semanticamente correta requer um profundo conhecimento do esquema. Para evitar que um usuário não familiar com o esquema perca tempo em um processo de tentativa e erro, uma solução é considerar as consultas em um nível mais alto, conceitual, traduzindo-as ao contexto do usuário. No entanto, o usuário não está eximido do conhecimento do esquema do banco de dados, porém, como o processo de consulta passa a ser mais expressivo por meio de uma interface visual, a aquisição deste conhecimento pode ser diluída no processo. Adicionalmente, sempre que uma solicitação é bem-sucedida, regras de estruturação começam, de forma condicional, a serem incorporadas no processo mental do usuário, que passa intuitivamente a executar uma operação mentalmente formulada a partir de sua percepção sobre a interface. Isto é o que se busca por meio de sistemas visuais de consulta (Visual Query Systems - VQSs). Cabe à interface preocupar-se mais em como o usuário deseja pensar sobre a base de dados e muito menos com a forma como o Sistema de Gerenciamento de Banco de Dados (SGBD) realmente opera. Contudo, manuais, sistemas de auxílio, tutoriais, seções de treinamento são exemplos de ferramentas de apoio também necessárias neste processo de ensino/aprendizado de complexidade substancial. No contexto recém apresentado, os sistemas visuais de consulta, dentre os quais aqueles descritos em (BATINI et al., 1992), (CATARCI, et al., 1996a), (CATARCI, et al., 1996b), são melhor indicados para atingir a usabilidade e comunicabilidade exigidas na execução da tarefa e na interação com a interface, por terem como objetivo aproximar os conceitos do mundo real, percebidos pelo usuário, dos esquemas que descrevem os dados dos sistemas de informação. Estes sistemas propõem a idéia de simplicidade de navegação pelo ambiente. O principal objetivo em se adotar uma representação visual num sistema de consultas é comunicar de forma clara ao usuário as informações referentes ao conteúdo do banco de dados, focando em características essenciais e omitindo detalhes desnecessários. As informações ao usuário devem ser apresentadas de forma clara, via interface. Entretanto, as informações devem ser mapeadas em conceitos internos da base de dados, para que desta forma o sistema possa tratar tais conceitos. Para lidar com esta natureza dual, uma representação visual deve se basear num formalismo visual, de forma a poder ser manipulado, compreendido e

181 comunicado por humanos e poder ser manipulado, analisado e mantido pelos computadores. O principal objetivo deste trabalho foi o design da interface para a ferramenta VIQUEN (Visual Query Environment) (GUEIBER, 2001), apoiado por formalismos da Engenharia Semiótica (SOUZA, 1993), visando o aumento da usabilidade e comunicabilidade deste ambiente de consulta visual centrado no usuário. Embora o processo de especificação de uma consulta visual passe por etapas relacionadas (seleção do sub-esquema, elaboração do predicado e apresentação do resultado), o foco deste trabalho está na fase de elaboração do predicado, ou seja, na qual o usuário interage com o ambiente para escolher os atributos que comporão a resposta, bem como para o estabelecimento de critérios a serem respeitados na execução da consulta. Este artigo está organizado da seguinte forma: a seção dois apresenta os formalismos da Engenharia Semiótica utilizados no trabalho, a LEMD e a STAG; a seção três descreve o ambiente VIQUEN e discute sua avaliação por meio da LEMD; a seção quatro descreve o ambiente de interface proposto e as seções cinco e seis apresentam conclusões e pesquisas futuras. 2. Dois Formalismos da Engenharia Semiótica Apesar de todas as suas características facilitadoras, as linguagens visuais requerem que o usuário tenha um conhecimento dos conceitos da linguagem e informações referentes ao domínio da aplicação bem como de seus mecanismos de interação. A apropriação dos conceitos e instrumentos da Engenharia Semiótica (SOUZA, 1993) possibilita a comunicação entre projetista e usuário necessária à percepção e compreensão dos conceitos do modelo e das informações do domínio constantes no banco de dados. A Linguagem de Especificação da Mensagem do Designer (LEMD) proposta por (LEITE, 1998) está baseada nas principais idéias da Engenharia Semiótica e tem por objetivo específico apresentar uma mensagem do designer que comunica para os usuários o modelo de interação e de funcionalidade do sistema, ao qual Leite denominou modelo de usabilidade. O modelo de funcionalidade determina o que o usuário pode fazer enquanto o modelo de interação determina como ele pode utilizar o sistema. Entre as vantagens de se utilizar a LEMD, pode ser citado que, na medida em que ela reflete um modelo global de comunicação humana por meio de artefatos de meta-comunicação (as interfaces de sistema), ela motiva o projetista de interface a considerar não somente os processos interpretativos do usuário, mas principalmente os processos comunicativos e expressivos que ele pode utilizar com maior consciência e intencionalidade para atingir metas comuns a todos os que visam aumentar a usabilidade de aplicações computacionais (LEITE & SOUZA, 1999). A Semiotic Task-Action Grammar (STAG) é uma notação para auxílio à especificação de Linguagens Visuais, que não se propõe a determinar o que deve ser usado, mas a orientar para a sistematização de escolhas expressivas. Incorpora implicitamente alguns princípios básicos da Engenharia Semiótica, de forma que estes princípios sejam automaticamente respeitados, pela simples utilização da mesma

182 (MARTINS, 1998). O objetivo da notação é registrar de que forma sistema e usuário se expressam a cada iteração. Entre as vantagens de se utilizar a STAG, pode ser citado que esta auxilia o projetista a tratar a linguagem de interface de forma sistemática, evidenciando eventuais falhas na linguagem e que a notação visa incorporar na linguagem de interação categorizações pré-existentes e conhecidas pelo usuário, o que torna a linguagem mais adequada em termos cognitivos (MARTINS, 1998). A utilização de ambos os formalismos é motivada pela necessidade de facilitar a interpretação do modelo do sistema de complexidade relevante pelo usuário, que tem como requisito a revelação das fases sucessivas de elaboração de consultas. A necessidade de uma boa comunicabilidade é, então, preponderante. O formalismo escolhido identificou as falhas da interface e orientou para o reprojeto adequado. O caráter complementar da Engenharia Semiótica em relação à Engenharia Cognitiva foi oportunamente destacado em (SOUZA, 1993). Nesta ótica, os formalismos foram aproveitados pela contribuição na minimização das distâncias entre os modelos mentais envolvidos, numa abordagem substancialmente cognitiva; por, em uma análise preliminar, ter-se detectado a carência clara de orientação verbal e, por apresentarem relativa facilidade de aprendizado e aplicação. Os processos completos de avaliação do ambiente VIQUEN e re-design da interface são apresentados detalhadamente em (BOSCARIOLI, 2002). 3. O Ambiente VIQUEN VIQUEN (Visual Query Environment) é um ambiente interativo para consulta visual e extração de esquemas de uma base de dados. Este protótipo foi construído e descrito por GUEIBER (2001) com o objetivo de atingir a categoria de usuários comuns, os quais buscam freqüentemente informações armazenadas em sistemas de banco de dados, mas desconhecem a sintaxe de linguagens de consulta, construídas tipicamente para uso por especialistas. Esta aplicação pertence à categoria de editores gráficos tais como Pasta-3 (KUNTZ & MELCHERT, 1989), QBD* (ANGELACCIO et al., 1990) e SUPER (SPACCAPIETRA et al., 1995a), que fazem uso da linguagem visual com a qual o usuário interage para formular suas consultas, sem ser necessário conhecimento prévio da linguagem textual de manipulação de dados utilizada pelo SGBD em questão. As operações disponíveis estão implícitas nas ações tomadas pelo usuário sobre o próprio esquema apresentado durante a formulação das consultas, ou seja, a consulta é construída por meio da manipulação direta de objetos do modelo mediante a linguagem visual aplicada sobre ele. O VIQUEN recupera um esquema de base de dados construído sobre o modelo relacional, de pouco poder de expressão do ponto de vista do usuário leigo, e o traduz para o modelo ERC+ 1 (SPACCAPIETRA et al., 1995b). Apesar de o VIQUEN ter sido construído com o objetivo de atender às necessidades dos usuários não-especialistas, o seu desenvolvimento não tinha a interface-usuário como uma das suas preocupações principais. 1 Uma extensão do modelo entidade-relacionamento, projetada para suportar objetos complexos

183 VIQUEN apresenta as seguintes etapas na interface com o usuário, conforme (GUEIBER, 2001): a engenharia reversa, que traduz uma base relacional para o correspondente modelo ERC+; a tarefa de seleção do sub-esquema desejado na consulta; a especificação do predicado; a visualização da resposta. No processo de engenharia reversa, o esquema contendo todas as tabelas e restrições pertencentes ao esquema selecionado pelo usuário é traduzido automaticamente pela aplicação para um esquema sob o modelo ERC+. Nesta representação podem ser visualizados entidades, relacionamentos e atributos complexos que são apresentados graficamente ao usuário em uma janela. As ligações entre os elementos desta janela são feitas por meio de arestas. Em uma outra janela, ativada pelo usuário a partir de uma caixa de diálogo, são apresentados os atributos atômicos. O fato de os atributos atômicos não serem exibidos no grafo permite que o esquema não se torne saturado, o que dificultaria a manipulação do modelo exibido. A partir do esquema recuperado, o usuário pode selecionar, por meio do mouse, os objetos desejados na formação da consulta. Esta seleção deve incluir tanto os objetos desejados na resposta como aqueles necessários na formação do predicado. Para submeter uma consulta o usuário deve determinar, também, qual visão deseja, escolhendo uma raiz para a consulta. A seleção da raiz da consulta é uma etapa bastante importante na seleção do esquema, pois é esta escolha que irá determinar a hierarquia dos objetos participantes da consulta a ser realizada. Em alguns casos, é preciso que o usuário elimine eventuais ciclos existentes entre os objetos da consulta. Por último, a fim de complementar a consulta, o usuário pode adicionar sub-esquemas a ela, que devem ser unidos ao sub-esquema inicial, eliminando objetos comuns a ambos. A especificação de predicados é considerada ponto crítico em consultas a bases de dados, por ser uma tarefa que pode atingir elevado nível de complexidade, em se tratando de usuários não-especialistas. Para realizar esta tarefa, o usuário deve selecionar o objeto da consulta, isto é, a entidade desejada e os atributos que irão compor a resposta. Na mesma janela, deve ser selecionada a complementação do predicado por meio da seleção dos operadores lógicos e relacionais e das constantes, para construir expressões booleanas sobre os atributos atômicos, conforme figura 1: Figura 1. Estabelecimento de Predicado no VIQUEN (Gueiber, 2001) A etapa de construção do predicado exige, para recebimento eficiente da mensagem, auxílio de fontes externas ao modelo de usabilidade, tais como helps,

184 manuais, treinamento ou suporte técnico, pois o usuário enfrentará a necessidade de manipular operadores lógicos, construindo expressões válidas no contexto da consulta em elaboração (o que se constitui numa tarefa de nível de complexidade relevante) e ainda, de optar por uma operação de redução ou simplificação (operações específicas da Álgebra ERC+). No VIQUEN, não fica claro como estas operações funcionam e o que exatamente elas representam. Desta forma, da interação com o sistema começam a surgir dúvidas quanto ao que escolher e quais as implicações desta escolha, comprometendo o processo de comunicação designer-usuário. Ainda nesta etapa, o sistema disponibiliza o código SQL da consulta em elaboração. Esta parte de apresentação em SQL do predicado construído tem papel fundamental no contexto de engenharia reversa. No entanto, possui expressividade mínima para o usuário, por não ser uma linguagem comum em seu cotidiano. A LEMD foi utilizada para verificar a efetividade da meta-comunicação designer-usuário presente na interface da ferramenta VIQUEN (BOSCARIOLI et al., 2001), tendo como ponto de partida a introdução deste formalismo por (LEITE & SOUZA, 1999) e avançando na sua utilização no processo de avaliação em relação ao trabalho relatado em (PRADO & BARANAUSKAS, 2000) que aplicou a LEMD em avaliação de interfaces num conjunto de janelas de uma aplicação. A análise por meio da LEMD revelou problemas específicos em cada sub-etapa. Em particular, a etapa de construção de predicados apresenta várias rupturas na metacomunicação da interface, como a falta de informações na interface quando esta sugere que se opte por uma operação de redução e/ou simplificação. A fase de aplicação de operadores lógicos (AND e/ou OR) também não deixa claro o que está sendo feito. As operações e valores selecionados para cada atributo apenas ficam visíveis com a seleção do mesmo (por meio de clique com o botão esquerdo do mouse). Ainda, o botão Limpar não revela se apenas o último critério será excluído ou se todos o serão. 4. O Ambiente de Interface Proposto Para esta fase da elaboração de predicados, o usuário já possui um sub-esquema ou esquema de trabalho determinado, que é um esquema visual produto da fase anterior onde o usuário selecionou, no esquema ERC+, quais os elementos que serão utilizados na elaboração da consulta (BASSI, 2002). Com base no resultado das análises de interação usuário-sistema no processo de elaboração de consultas feitas sobre ferramentas visuais como Pasta-3, QBD* e SUPER e na avaliação semiótica utilizando a LEMD elaborada sobre o VIQUEN e a partir da definição do estereótipo do usuário (experiente em interação com interfaces gráficas e conhecedor do estilo WIMP (Windows, Ícons, Menus e Pointing Devices)) foi possível definir a LEMD e a STAG que auxiliaram na construção da interface para o domínio em questão, de forma a aproveitar ao máximo o poder comunicativo da interface. Como várias são as etapas a serem cumpridas para a elaboração de uma consulta, é imprescindível que a interface possua mensagens, como aquelas veiculadas por um assistente, a guiar o usuário pela interface. No VIQUEN, sentiu-se muito a falta de expressividade, de mensagens que situassem o usuário no processo. Para suprir esta

185 necessidade, em toda tela da interface proposta há mensagens orientando o usuário na execução das ações, além do auxílio on-line disponível no sistema. A figura 2 traz a tela inicial do ambiente, onde, a partir do sub-esquema, sempre disponível para visualização, o usuário deverá escolher então, quais atributos farão parte da resposta, ou mesmo, retornar à etapa de seleção de sub-esquema, cancelando a ação desta fase (undo). Caso o usuário opte por escolher atributos para a resposta, ele deverá clicar no botão para abrir um formulário específico para esta tarefa, conforme ilustra a figura 3, onde claramente se observa as mensagens do designer na interface. Este padrão é seguido em todo o ambiente de interface. Apresentação e Controle Meta-comunicação direta Signo do Domínio Estrutura Sintática Signo do Domínio Figura 2. Tela Inicial do Ambiente Visual de Consultas Proposto Interações Básicas A decisão de separar formalmente a parte de seleção da parte de estabelecimento de critérios, ativando esta última somente após a conclusão da primeira, está embasada na necessidade de estabelecer uma seqüência de ação no modelo mental do usuário, facilitando o processo de construção do predicado. Para selecionar atributos para a resposta, a escolha é feita diretamente nas tabelas que formam o sub-esquema, pressionado-se o botão esquerdo do mouse com o cursor sobre seu nome e selecionando atributo(s). Se a seleção for simples, ou seja, de um único atributo, basta um clique sobre o atributo por meio do botão esquerdo do mouse. Para seleção de vários atributos da mesma tabela, a tecla CTRL deve ser pressionada enquanto pressiona-se o botão esquerdo do mouse com o cursor sobre os atributos desejados.

186 Figura 3. Escolha de Atributos Após seleção de todos os atributos necessários à exibição, o usuário deverá confirmar esta tarefa, retornando à tela principal da etapa de Construção da Consulta, que, automaticamente, habilita o botão de comando, permitindo estabelecer valores ou intervalo de valores, fazer comparações entre atributos e construir expressões booleanas que servirão de parâmetros de comparação na execução da consulta, como na figura 4. Esta sub-etapa exige que o usuário conheça a abstração do modelo ERC+, de forma que ele consiga expressar-se adequadamente para que o que ele deseja como resultado seja recuperado. Assim como na etapa anterior, o usuário pressiona o botão esquerdo do mouse com o cursor sobre as tabelas disponíveis e, em seguida, aponta com o cursor sobre o atributo desejado, selecionando-o. O ambiente orienta visualmente o usuário para que proceda executando os passos, da esquerda para a direita. Contudo, há uma certa liberdade na seqüência de passos para a criação da expressão relacional. Ele pode, por exemplo, entrar com um valor para comparação e depois definir o operador relacional apropriado. Ao ativar o botão o critério formulado será adicionado na Caixa de Construção dos Critérios. O usuário poderá incluir todos os critérios desejados e somente depois aplicar operadores lógicos para agrupá-los em uma única expressão, ou ir aplicando-os gradativamente, à medida que for inserindo os critérios, sempre de maneira pós-fixada e agindo sobre pares de expressões. Para aplicar um operador lógico, o usuário deverá selecionar o operador desejado e após, pressionar o botão. Ainda nesta fase, o usuário poderá escolher para aplicar os operadores redução e/ou simplificação à sua consulta. Estes operadores são descritos precisa e detalhadamente na interface, enquanto exemplos de utilização são disponibilizados no help. As decisões recém descritas estabelecem uma relativa flexibilidade da interface visando aumentar a usabilidade do sistema, bem como acomodar usuários novatos sem prejuízo dos usuários mais experientes.

187 Figura 4. Estabelecendo Critérios com Aplicação de Operador Lógico O sistema exibe a janela de feedback das ações efetuadas, definindo as regras sintáticas de mapeamento e as restrições semânticas do sub-esquema. Este feedback, exibido na figura 5 é fornecido em uma sentença que expressa a consulta idealizada, na forma de pseudo-código em português restrito a um padrão definido de forma a permitir ao usuário a verificação de que se a consulta em elaboração é a realmente desejada, antes da efetivação da mesma. A sentença resultante expressará ao usuário o que ele selecionou, o local de origem dos itens selecionados e as condições a serem respeitadas. A abordagem utilizada estabelece uma hierarquia de parênteses aninhados, expressando inclusive, a ordem de execução das comparações. Optou-se por esta notação devido ao fato de que uso de parênteses é relativamente familiar a qualquer usuário da aplicação. Neste ponto, o usuário poderá pressionar o botão sua consulta, passando à etapa de Visualização do Resultado. para efetivar É importante salientar que, a qualquer momento, o usuário poderá deixar o sistema, por meio do botão e que o sistema, além de mensagens de orientação em tela e ajuda on-line, disponibiliza várias janelas de alerta, com o intuito de viabilizar a correção de erros e orientar o usuário pela interface. Também, em todo o ambiente está ativado o recurso de hint (dica), conhecido do usuário no ambiente Windows, sensível ao contexto e ativado ao se posicionar o cursor do mouse sobre os componentes da interface.

188 Figura 5. Tela Principal com Consulta Elaborada 5. Considerações Finais Uma das contribuições principais deste trabalho está na especificação da interface em nível abstrato, permitindo a representação de associações entre intenções de comunicação do designer de interfaces visuais de consulta a banco de dados e expressões na interface utilizada para este fim. A aplicação da LEMD deu-se em dois estágios distintos: na avaliação de todo um ambiente de interface (o protótipo VIQUEN), dando um passo à frente em sua utilização, visto que em (PRADO & BARANAUSKAS, 2000) o método de avaliação tinha sido proposto em um conjunto de janelas que foram isoladas e trabalhadas com certa independência; e após, como ferramenta de orientação e apoio ao design da nova interface. O poder de expressão da interface (do ponto de vista da Interação Homem- Computador e não de Banco de Dados) foi aumentado em relação ao VIQUEN. A preocupação com a comunicação usuário-interface levou à exibição da consulta em elaboração de forma estruturada - mais natural ao usuário, à exibição de mensagens de orientação e de alerta ao longo de todo o processo, a um sistema completo e interativo de ajuda on-line, a mensagens de alerta, à não-disponibilização de expressões SQL e à explicação dos operadores redução e simplificação da álgebra ERC+ - que no VIQUEN eram apenas apresentados na interface para seleção, sem qualquer explicação sobre a

189 sua funcionalidade. Adicionalmente, o processo de interação tornou-se mais consistente, pois vai habilitando as opções à medida que se avança na tarefa de construção de consultas. Na descrição do dicionário de signos da interface, ficou nítida a necessidade de que o usuário tivesse um domínio mínimo da área de Banco de Dados, para que conseguisse interpretar os signos apresentados na interface. O uso de assistente para esta tarefa é mais um facilitador da interação. Ainda, uma sessão de treinamento aos usuários do sistema, principalmente sobre a aplicação de operadores booleanos, para que o usuário obtenha exemplos e possa construir mais rapidamente a sua correlação expressão-significante é oferecida adicionalmente pela interface proposta. O ambiente de interface proposto contribui na melhoria do processo de interação usuário-sistema na elaboração de consultas em ambientes visuais. No entanto, o processo está longe de ser trivial, exigindo, da interface, a disponibilização de um sistema de auxílio que proporcione todos os conhecimentos técnicos requeridos do usuário pelo sistema. Outrossim, a metodologia adotada, de apropriação dos formalismos oriundos da Engenharia Semiótica para facilitar a aquisição pelo usuário do modelo do sistema, mostrou-se particularmente adequada neste domínio de aplicação de complexidade relevante. 6. Trabalhos Futuros Dentre as perspectivas de continuidade deste trabalho, pode ser citada a integração da ferramenta VIQUEN com esta proposta de interface, bem como a utilização de uma ferramenta própria para construção de objetos para manipulação direta, sugerindo-se a ferramenta ILOG, utilizada no VIQUEN. Um estudo mais aprofundado sobre metodologias de avaliação diferentes da LEMD e aplicação destas na avaliação da ferramenta completa, de forma a identificar possíveis problemas que ainda dificultem a interação também se apresenta como uma perspectiva interessante. Ainda, avaliação da interface com usuários leigos neste domínio apresenta-se como uma tarefa complementar. 7. Agradecimentos Os autores agradecem as contribuições de Heloísa Rocha ao trabalho. Referências Bibliográficas ANGELACCIO, M.; CATARCI, T.; SANTUCCI, G. QBD*: A Fully Visual Query System. Journal of Visual Languages and Computing, Vol. 1, No. 2, p , BASSI, P. R. de. Um Ambiente de Interface Visual para a Geração de Sub-Esquemas para uma Ferramenta de Consulta baseada no Modelo ERC+. Dissertação de Mestrado. Departamento de Informática. Setor de Ciências Exatas, Universidade Federal do Paraná. Curitiba, BATINI, C.; CATARCI, T.; COSTABILE, M.; LEVIALDI S. Visual Query Systems

190 Technical Report Dipartimento di informatica e Sistemistica, Universitá di Roma La Sapienza, BOSCARIOLI, C.; GARCÍA, L. S.; RANTHUM, G.; BASSI, P.; SUNYE, M. S. Visual Databases Languages: A tool evaluation based on the Designer s Message Specification Language. Annales La conférence NîmesTIC. Nîmes, França, BOSCARIOLI, C. Um ambiente de interface visual para a elaboração de predicados para uma ferramenta de consultas a banco de dados sob o modelo ERC+. Dissertação de Mestrado. Departamento de Informática. Setor de Ciências Exatas, Universidade Federal do Paraná. Curitiba, CATARCI, T.; COSTABILE M. F.; LEVIALDI S.; SANTUCCI G. A Graph-Based Framework for Multiparadigmatic Visual Access to Databases. IEEE, , junho,1996 CATARCI, T.; COSTABILE M. F.; MASSARI, A.; SALADINI, L.; SANTUCCI, G. A Multiparadigmatic Visual Environment for Adaptive Acess to Databases. ACM SIGCHI Bulletin, special issue on The Role of HCI in Italy, Vol. 28, N. 3, pp , July GUEIBER, E. VIQUEN Um Ambiente Interativo para Consulta Visual e Extração de Esquemas. Dissertação de Mestrado. Departamento de Informática. Setor de Ciências Exatas, Universidade Federal do Paraná. Curitiba, KUNTZ, M.; MELCHERT, R. Pasta-3 s Graphical Query Language: Direct Manipulation, Cooperative Queries Full Expressive Power. Proceedings of the Fifteenth International Conference on Very Large Data Bases. Amsterdam, LEITE, J. C. Modelos e Formalismos para a Engenharia Semiótica de Interface de Usuário. Tese de Doutorado. Departamento de Informática. Pontifícia Universidade Católica do Rio de Janeiro. Rio de Janeiro, LEITE, J. C. SOUZA, C. S. Uma Linguagem de Especificação para a Engenharia Semiótica de Interfaces de Usuário, IHC 99, Campinas SP, MARTINS, I. H. Um Instrumento de Análise Semiótica para Linguagens Visuais de Interfaces. Tese de Doutorado. Departamento de Informática. Pontifícia Universidade Católica do Rio de Janeiro. Rio de Janeiro, PRADO, A. B.; BARANAUSKAS, M. C. C. Avaliando a Meta-comunicação Designer- Usuário de Interface. IHC 2000, Unisinos RS, PORTO, P. R. P. Bancos de Dados com Interfaces Inteligentes. Dissertação de Mestrado. Instituto de Informática. Universidade Federal do Rio Grande do Sul. Porto Alegre, SPACCAPIETRA, S.; DENNEBOUT, Y; GENTILE, M.; FONTANA, E.; YANN, D.; AUDDINO, A.; ANDERSSON, M. SUPER: Visual Interfaces for Object+Relationship Data Models. Journal of Visual Languages and Computing 5, Special Issue on Visual Query Languages, p , SPACCAPIETRA, S.; PARENT, C.; SUNYE, M. S.; YETONGNON, K.; LEVA, A. di. An Object + Relationship Paradigm for Database Applications. Readings in Object-Oriented Systems, D. Rine (Ed.), IEEE Press, SOUZA, C. S. de. The Semiotic Engineering of User Interface Languages. In: Int. Man- Machine Studies, 39, , 1993.

191 Um Modelo para Criação de Ferramentas de Apoio a Testes de Usabilidade de Interfaces Marcelo Vasques de Oliveira 1, Ana Cristina Bicharra Garcia 1 1 Instituto de Computação Universidade Federal Fluminense (UFF) Rua do Passo da Pátria, 155 Bl E 3 o. andar Niterói RJ Brasil vasquesistemas@openlink.com.br, bicharra@dcc.ic.uff.br Abstract. The article presents a model to develop new tools that support usability tests, helping the systematization of the process analysis. The model leads not only to a possible decrease of subjectivity but also to a more reflexive view about the process. The systematization is achieved by the possibility of handling the description of user-system interaction, favoring the search for patterns indicative of behaviors that raise the appraiser s attention. In addition, the article poses a critical discussion about the tools to support the usability tests that are already in the market. Resumo. Este artigo propõe um modelo para criação de ferramentas de apoio a testes de usabilidade que auxiliem a sistematização do processo de análise, levando não apenas a uma possível diminuição da subjetividade, mas também a uma postura mais reflexiva sobre o processo. A possibilidade de se manipular o histórico da interação usuário-sistema permite a sistematização, facilitando a busca por padrões indicadores de comportamentos que chamem a atenção do avaliador. Além do modelo, este artigo apresenta uma discussão crítica sobre as ferramentas existentes no mercado para apoio a testes de usabilidade. 1. Introdução Sendo requisito fundamental para a qualidade de um software, a interface necessita de ser testada e avaliada. Uma das principais abordagens para a medição da qualidade de uma interface é a usabilidade, que enfatiza o esforço demandado pelo usuário ao utilizar um software [Nielsen93]. A usabilidade é medida pela aplicação de diferentes métodos e/ou técnicas de avaliação sobre a interface em estudo, nas diferentes fases de seu ciclo de desenvolvimento. Cada método e/ou técnica de avaliação tem um objetivo específico e deve ser aplicado(a) de acordo com a fase em que o desenvolvimento do software se encontra [Jefries92]. Os métodos de avaliação de usabilidade são classificados em dois grandes grupos e devem ser aplicados de forma combinada. São eles: testes de usabilidade e inspeção [Rocha00]. Os métodos de testes de usabilidade são fundamentais, uma vez que pressupõem a participação de usuários utilizando uma interface implementada para execução de tarefas. A aplicação dos testes de usabilidade, no entanto, apresenta problemas,

192 merecendo destaque a subjetividade inerente ao próprio processo por requerer a observação e o julgamento de especialistas. Realizou-se um trabalho analítico sobre as ferramentas de apoio a testes de usabilidade existentes e constatou-se a ineficiência de todas no que tange à minimização da subjetividade. Este artigo apresenta um novo modelo para construção de ferramentas de apoio a testes de usabilidade cuja principal característica é a sistematização de alguns procedimentos na fase de análise das interações usuário-sistema. A sistematização concretiza-se ao se poder manipular o histórico da interação usuário-sistema, facilitando a busca por padrões reveladores de comportamentos dignos da atenção do avaliador. Acredita-se que a sistematização potencializa a redução da subjetividade e possibilita aos avaliadores de uma mesma equipe refletir e discutir acerca da subjetividade, melhorando o processo de avaliação da interface como um todo. 2. Fundamentação Teórica A avaliação não deve ser vista como uma fase única dentro do processo de design da interface e nem como uma atividade a ser feita somente ao final do processo e se houver tempo disponível. A interface deve ser gradativamente avaliada e, a partir dos resultados, melhorada. Não existe consenso na utilização de um único método de avaliação que seja sempre eficiente. Diferentes tipos de avaliações usando diferentes métodos são necessários durante o ciclo de desenvolvimento do software. [Rocha00]. A avaliação de interface possui três objetivos: Avaliar a funcionalidade do sistema, verificando sua adequação aos requisitos das tarefas do usuário, que deve poder executá-las de modo fácil e eficiente; Avaliar o efeito da interface junto ao usuário, ou seja, a sua usabilidade; Identificar problemas específicos com relação ao design no tocante à funcionalidade e à usabilidade, isto é, aspectos do design que levam a resultados inesperados ou causam confusão entre os usuários. São os chamados problemas de usabilidade. A aplicação de testes de usabilidade é o principal meio para avaliar interfaces e certamente o mais tradicional, visto que relata experiências reais de problemas durante a interação dos usuários com o software. Contudo o recrutamento de usuários reais tornase um processo difícil e caro quando se quer uma avaliação evolutiva da interface ao longo de seu ciclo de desenvolvimento. Estudos demonstram que muitos problemas identificados por métodos de inspeção não são encontrados ao usarem-se métodos de testes e vice-versa. Por isso é recomendada a combinação de ambos no processo de avaliação. Métodos de inspeção devem ser usados nos estágios iniciais, onde as idéias estão sendo exploradas e a usabilidade sendo avaliada. Os testes devem ser aplicados em estágios mais avançados do desenvolvimento da interface. Os testes de usabilidade, embora fundamentais no processo de avaliação da interface, têm inúmeros problemas inerentes à sua concepção e aplicação. O principal deles é a grande dependência da qualidade técnica e da experiência dos avaliadores, que

193 são os detentores do conhecimento de diagnóstico. Assim, por estarem baseados em diagnósticos de especialistas, os testes de usabilidade são extremamente subjetivos. A ausência de uma sistemática na fase de análise das interações usuário-sistema evidencia a vulnerabilidade dos testes de usabilidade quanto à subjetividade, visto que os resultados podem variar largamente quando avaliadores diferentes analisam a mesma interface. Freqüentemente, gerentes de projeto deixam de realizar testes de usabilidade alegando falta de tempo, de recursos humanos e financeiros e dificuldade técnica para sua realização. O tempo demandado pelos testes é de fato grande, devido a todas as etapas necessárias ao seu bom funcionamento. Dependendo da complexidade do software e/ou de sua interface, os testes podem contemplar várias sessões, tendo cada uma de uma a três horas [Rocha00]. Os recursos humanos necessários envolvem usuários reais e avaliadores. Para garantir o princípio da confiabilidade, os testes devem ser realizados com mais de um usuário, o que além de caro é difícil. Para enriquecer o diagnóstico final e minimizar o problema da subjetividade deve-se alocar mais de um avaliador por teste, acarretando aumento de custo. A dificuldade técnica deve-se à total dependência da qualidade dos avaliadores, visto que não há uma ferramenta que apóie com eficiência os testes de usabilidade. 3. Ferramentas de Apoio aos Testes de Usabilidade Devido à complexidade na aplicação dos testes de usabilidade e à grande quantidade de dados que precisam ser capturados durante a interação do usuário com o sistema sob avaliação, algumas ferramentas foram concebidas com o propósito de apoiar os avaliadores na aplicação dos testes Comparação entre as ferramentas Analisando as ferramentas pesquisadas, identificou-se o logging de software como a técnica de coleta de dados mais amplamente utilizada. Consiste em registrar em arquivos de forma sistemática e automática, os scripts da interação usuário-sistema [Matias00]. Além disso, identificaram-se os modelos de implementação dessas ferramentas apresentados abaixo dentro da seguinte taxonomia: Modelo de Captura: descreve a forma como são capturadas e registradas as ações decorrentes da interação do usuário com o sistema sob avaliação. São usadas diferentes técnicas, merecendo destaque : i) Captura e registro do tempo de acionamento das teclas; ii) Captura e registro dos eventos do mouse e teclado; iii) Captura e registro das ações de mouse e teclado; iv) Captura e registro da freqüência de uso de comandos e objetos da interação; v) Captura e armazenamento das imagens da interação. Modelo de Reprodução: descreve como são reproduzidas as interações capturadas e varia em função do modelo de captura. Nem todas as ferramentas analisadas possuem um modelo de reprodução, a exemplo das ferramentas que

194 implementam os modelos de captura i e iv acima descritos. Existem, basicamente, dois: o Modelo SCRIPT: consiste em reproduzir cada diálogo da interação, executando um Script sobre os dados capturados, repassando ao avaliador cada cena da interação na ordem precisa em que ocorreram. Este modelo de reprodução é utilizado nas ferramentas que implementam os modelos de captura ii e iii, acima descritos. o Modelo CINEMA: consiste em exibir o filme da interação para o avaliador, repassando a imagem da interação capturada. Este modelo de reprodução é utilizado pelas ferramentas que implementam o modelo de captura v, acima descrito. Modelo de Análise: descreve as funcionalidades que devem ser implementadas para auxiliar o avaliador na análise das interações homem-computador. Apesar da crescente preocupação quanto à qualidade da interface e do grande número de experiências publicadas sobre avaliação de usabilidade, o número das ferramentas de suporte a esta atividade ainda é reduzido e a qualidade, baixa, com limitadas funcionalidades no que se refere à automação da fase de análise dos registros das interações. A tabela 1, abaixo, ilustra a análise da adequação e performance das ferramentas, classificadas de acordo com a taxonomia apresentada acima. Tabela 1: Ferramentas de Apoio a Testes de Usabilidade Ferramenta Modelo de Captura Modelo de Reprodução Modelo de Análise Forma de Armazenamento Limitações ScreenCam CamCorder Captura a imagem da interação. Cinema Não implementa funcionalidades de análise. Arquivo de imagem Inviável a extração de dados para análise. Playback Captura o tempo de acionamento das teclas. Não reproduz Não implementa funcionalidades de análise. Arquivo seqüencial Resultado fornecido é pouco útil. Não captura eventos de mouse. Observer Captura as ações de Mouse e Teclado e registra o script da interação. Script Calcula métricas de desempenho. Exibe listagem dos eventos capturados. Dispõe de análise quantitativa com indicadores de problemas. Arquivo texto ou fita de vídeo Ferramenta de difícil uso. Não permite manipulação das cenas na reprodução. USINE Captura e registra as ações do usuário. Não reproduz. Compara ações dos usuários com modelo de tarefas. Arquivo texto As tarefas precisam ser cadastradas morosidade.

195 SPY x SPY Captura os eventos de mouse e teclado e registra o script da interação. Script Possui um visualizador não muito amigável dos dados dos eventos. Arquivo texto Não permite manipulação das cenas da interação na reprodução. QC/replay Captura os eventos de mouse e teclado e registra o script da interação. Script Não implementa funcionalidades de análise Arquivo texto O Arquivo pode ser editado pelo avaliador Falhas nas Ferramentas como instrumento de apoio Ao se analisar as ferramentas pesquisadas, identificaram-se falhas que as tornam vulneráveis quando usadas como instrumentos de apoio a testes de usabilidade. Tais falhas tornam oportuna a realização deste trabalho, servindo como incentivo à proposição de um novo modelo. A seguir, são especificadas as falhas detectadas, numa avaliação genérica das ferramentas analisadas. Constatou-se que a automação do procedimento de análise dos dados capturados restringe-se, basicamente, à utilização da técnica de medição de performance. As ferramentas calculam as métricas e apresentam-nas aos avaliadores que dependem da própria experiência para diagnosticar a interface, baseados em números. Segundo Nielsen, testes de usabilidade baseados em medição de performance devem considerar um número maior de usuários quando comparados aos métodos de testes de usabilidade que se baseiam em análise qualitativa dos dados, acarretando maior custo e tempo de análise [Nielsen00]. O uso de métricas nada diz sobre o porquê dos fatos, apenas indicam sua ocorrência, não sendo suficiente por si só. Em termos de análise qualitativa da interface, as ferramentas não dão grande apoio. Algumas delas (Spy x Spy e Observer) oferecem relatórios com a seqüência cronológica das ações ou eventos capturados que, na maioria das vezes, não possuem um formato útil à análise. Não se identificou em nenhuma ferramenta a possibilidade de comparação das interações de diferentes usuários sobre a mesma interface, o que é de extrema valia para o diagnóstico global da interface. As ferramentas pesquisadas não permitem que o avaliador manipule as interações registradas, filtrando as ações de interesse e separando as sem importância para o contexto. Esta funcionalidade seria muito valiosa, pois reduziria o número de interações a analisar, excluindo aquelas com ruídos (ações sem interesse) que dificultam a análise e o diagnóstico. 4. O Modelo Proposto As ferramentas que implementarem o modelo proposto terão como requisitos : Possibilitar o cadastramento de dados para a contextualização dos testes;

196 Capturar e armazenar os scripts das interações usuário-sistema; Reproduzir as interações capturadas exibindo-as ao avaliador; Permitir ao avaliador identificar e marcar cenas de interesse; Permitir ao avaliador marcar e eliminar cenas sem importância; Identificar e realizar marcação automática de repetições de cenas iguais ou semelhantes às previamente marcadas em busca de padrões indicadores de comportamentos dignos da atenção do avaliador Conceituação do Modelo Uma visão geral A Figura 1, abaixo, apresenta um diagrama que mostra a integração dos três sistemas que devem compor a ferramenta no modelo proposto: Sistema de Configuração, Sistema de Captura e Sistema de Análise. Figura 1. Visão Geral do Modelo O processo de avaliação apoiado pela ferramenta que implementar o modelo proposto deve ocorrer em três fases distintas: 1ª fase : uso do Sistema de Configuração, ilustrado na Figura 1 parte a

197 Antes de se iniciar a primeira sessão, deve-se coletar e cadastrar, através do Sistema de Configuração, todos os dados necessários à contextualização do teste a ser realizado. O Sistema de Configuração visa a manter a persistência dos dados, atualizando tabelas da base BD Configurações e a contribuir para uma prévia organização dos mesmos, constituindo-se na base para a utilização dos sistemas de Captura e Análise. 2ª fase : uso do Sistema de Captura, ilustrado na Figura 1 parte b Antes de se iniciar cada sessão de teste, o Sistema de Captura deve ser ativado, permanecendo residente em memória até sua desativação ao final da sessão. Durante a interação do usuário com o sistema, o Sistema de Captura intercepta cada evento de mouse e teclado recebido pelo Sistema Operacional e armazena o script da interação (log do usuário) na base log dos usuários. As interações usuário-sistema são armazenadas sob a forma de scripts, permitindo a automação da fase de análise. Através de uma linguagem marcada, similar ao HTML, o avaliador poderá manipular (fase de análise) o script da interação. Vale ressaltar que o Sistema de Captura é dependente do sistema operacional, uma vez que varia em função da forma como este trata as mensagens de evento, enviadas pelos dispositivos de entrada (mouse e teclado). 3ª fase : uso do Sistema de Análise, ilustrado na Figura 1 parte c Encerrada a fase de captura, o avaliador pode iniciar a terceira e última fase, em que irá analisar os scripts das interações. O Sistema de Análise automatiza o procedimento de análise das interações registradas e oferece subsídios ao avaliador para a confecção de um diagnóstico mais consistente, permitindo a ele : reproduzir e observar o filme da interação usuário-sistema; reproduzir e manipular as cenas do filme da interação usuário-sistema, podendo o marcar cenas relevantes, fazer anotações junto ao log da interação, incluindo atribuição de um rótulo (tag), registro de observações e associação com a tarefa do usuário (previamente cadastrada no Sistema de Configuração); o marcar cenas irrelevantes (ruídos). Toda ação que o avaliador julgar irrelevante para o contexto pode ser marcada como ruído e desconsiderada em análises futuras, assim reduzindo o número de interações e, conseqüentemente, o tempo gasto na análise; solicitar que o Sistema de Análise identifique, exiba e contabilize as ocorrências de situações (cenas) iguais ou semelhantes a uma das cenas que foram previamente marcadas (consideradas relevantes). Esta funcionalidade além de acelerar o processo de análise, visto que organiza as cenas de forma sistemática e automática, também contribui para a redução da subjetividade inerente ao processo de teste. A busca automática de repetições de cenas e exibição de suas

198 ocorrências dá subsídios objetivos ao avaliador para validar suas suposições (subjetividade) e apresentar um diagnóstico mais preciso. solicitar que o Sistema de Análise armazene na base Padrões de Marcação as cenas de interações que denotem padrões de comportamento que mereçam ser comparados, em análises futuras, com os registros das interações capturadas em sessões de outros usuários e até mesmo de outros sistemas. Esta funcionalidade contribui para uma postura mais reflexiva por parte do avaliador sobre o processo de avaliação, visto que auxilia na criação de uma padronização e sistematização da forma como as interações são avaliadas Sistema de Configuração O Sistema de Configuração permite atualizar (incluir, alterar e excluir) cada uma das tabelas que compõem a base Configurações. A tabela 2, abaixo, relaciona-as. Tabela Finalidade Tabela 2. Tabelas da base de dados Configurações Tempresas Armazenar dados cadastrais das empresas desenvolvedoras dos sistemas. Tespec Tsistemas Ttestes Tsessões Ttarefas Armazena dados cadastrais dos especialistas em avaliação de interfaces. Armazena dados das versões dos sistemas avaliados. Armazena dados dos testes de usabilidade realizados. Armazena dados de cada sessão de teste realizada. Armazena dados das tarefas a serem avaliadas em cada sessão de teste. O cadastramento das tarefas é opcional de forma a não tornar morosa a etapa de configurações. Contudo, para sistemas em que a comparação dos scripts registrados com o modelo de tarefas seja importante, as tarefas podem ser inseridas na base Configurações Sistema de Captura A Figura 2, abaixo, ilustra a composição e o funcionamento do Sistema de Captura, evidenciando a integração entre seus módulos.

199 Figura 2. Especificação do Sistema de Captura. Antes de cada sessão de teste, deve-se informar os parâmetros de captura, a saber: sistema sob avaliação, usuário e sessão do teste. Vale ressaltar que os dados de parâmetros informados devem ter sido previamente cadastrados através do Sistema de Configuração. Após a validação dos mesmos, o Sistema de Captura é iniciado e carregado em memória, onde fica residente até sua desativação ao final da sessão.o Sistema de Captura é composto de três módulos: Capturar Evento: simula a função de hook na memória e captura toda mensagem de evento do mouse e teclado recebida pelo Sistema Operacional durante a interação usuário-sistema; Decodificar Mensagem: identifica e interpreta a mensagem de evento capturada, do formato EventMSG, decodificando-a na estrutura de dados CamposMSG composta por: o Message tipo de mensagem, que pode ser de [M]ouse ou [T]eclado; o ParamL o valor deste campo varia de acordo com o tipo de mensagem. Se a mensagem vem do [M]ouse, representa a coordenada X(linha). Se a mensagem vem do [T]eclado, representa a tecla pressionada; o ParamH o valor deste campo varia de acordo com o tipo de mensagem: se a mensagem vem do [M]ouse, representa a coordenada Y(coluna); se a mensagem vem do [T]eclado, o campo fica em branco; o Handle contém o ponteiro para a janela que receberá a mensagem; o Time contém o momento em que a mensagem foi enviada (cronômetro); Registrar Log: monta o script da ação geradora do evento (log Modelo) a partir da estrutura de dados CamposMSG, armazenando-o na base Log dos Usuários.

200 4.4. Sistema de Análise O Sistema de Análise é composto por dois módulos : Manipulação: responsável pelas funcionalidades de reprodução dos diálogos da interação e pela marcação (início e fim) e atribuição de rótulos (tag) tanto das cenas de interesse quanto das irrelevantes (ruídos). Marcação Automática: responsável pela funcionalidade mais importante do sistema: identificação, no conjunto de interações registradas, das repetições de cenas previamente marcadas no Módulo de Manipulação. Módulo de Manipulação do Sistema de Análise A Figura 3, abaixo, ilustra o funcionamento do módulo de Manipulação e a integração de seus procedimentos. Figura 3. Especificação do Módulo de Manipulação do Sistema de Análise. Através da Interface de Manipulação, o avaliador interage com o Módulo de Manipulação, informando dados do teste a ser analisado e cada ação de manipulação desejada. O módulo de Manipulação é constituído pelos seguintes procedimentos: Controlar Manipulação: controla a execução dos demais procedimentos do Módulo de Manipulação. Validar Parâmetros: consulta a base Configurações para validar e buscar os dados necessários ao teste, conforme parâmetros (dados do teste) informados pelo avaliador. Player: localiza na base Log dos Usuários o registro do log corrente, executa seu script de reprodução e exibe a imagem da interação para o avaliador. O Player permite ao avaliador repassar cada log da interação, avançando, retrocedendo ou paralisado (stop) o filme da interação a qualquer momento.

201 Marcar/Desmarcar Cena: executa cada ação de manipulação possível, através de uma linguagem de marcação própria, similar ao HTML, sobre a cena que está sendo repassada ao avaliador. Este procedimento acrescenta à base log dos usuários os dados da marcação solicitada (log com marcação) e, caso o avaliador solicite, armazena na base Padrões de Marcação os respectivos scripts da cena (cena com marcação). Módulo de Marcação Automática do Sistema de Análise A Figura 4, abaixo, ilustra o funcionamento do módulo de Marcação Automática que compõe o Sistema de Análise. Figura 4. Especificação do Módulo de Marcação Automática do Sistema de Análise. Através da Interface de Manipulação avaliador interage com o módulo de Marcação Automática, informando o teste (dados teste) e a cena (cena ou tag) que deseja fazer a marcação.o Módulo de Marcação Automática é composto pelos seguintes procedimentos: Validar Parâmetros: consulta a base Configurações para validar e buscar os dados necessários ao teste, conforme parâmetros (dados do teste) informados pelo avaliador. Automatizar Marcação: procura e marca as repetições de cenas iguais ou semelhantes à Cena ou Tag selecionada pelo avaliador. O procedimento de efetivar a marcação automática de cenas consiste em : o consultar a base Padrões de Marcação para identificar a seqüência de logs (Padrão a Marcar) da cena. o consultar a base Log dos Usuários para identificar cada log usuário que compõe a cena, comparando a seqüência de ações registradas com a seqüência armazenada na base Padrões de Marcação (Padrão a Marcar).

202 o contabilizar cada cena válida e registrar o rótulo (tag) correspondente à cena selecionada em cada registro de log que a compõe (cenas com marcação), armazenando-as na base Logs com Marcação do Sistema. Exibidor de Ocorrências: apresenta ao avaliador o número de ocorrências, iguais ou similares, da cena selecionada (ocorrências). 5. Conclusões Está sendo implementada uma versão do modelo proposto acoplada à metodologia de Prototipação Evolutiva como base para validação do modelo. O protótipo encontra-se em fase avançada de desenvolvimento. Como o sistema de captura é dependente do sistema operacional, as ferramentas terão que ser desenvolvidas de acordo com este. O protótipo está sendo desenvolvido para operar em sistema operacional da plataforma Windows. Com o protótipo desenvolvido, será realizado um estudo piloto envolvendo dois grupos de especialistas em avaliação de interfaces, em que apenas um dos grupos usará o protótipo para testar e aferir a usabilidade da interface de um software a ser escolhido. O modelo proposto visa a apoiar testes de usabilidade de sistemas interativos em ambiente desktop. Não há intenção de que o modelo sirva de base para o desenvolvimento de ferramentas de apoio a testes de sistemas WEB ou Groupware. A principal contribuição do modelo proposto é a possibilidade de redução da subjetividade pela sistematização de alguns procedimentos da fase de análise, permitindo aos avaliadores terem uma postura mais reflexiva sobre o processo. Somemse a isso a redução do tempo e dos custos envolvidos na análise dos dados capturados, o auxílio na identificação de problemas comuns a todos os usuários participantes das sessões do teste e a não-necessidade do observador, reduzindo o constrangimento dos usuários e o custo com o pessoal envolvido. Por fim, este artigo contribui com uma discussão crítica sobre as ferramentas de apoio a testes de usabilidade existentes, servindo como referência a trabalhos correlatos. 6. Referências Jeffries, R. and Desurvire, H. Usability testing vs Heuristic evaluation: was there a contest, In: ACM SIGCHI bulletin, v. 24, n 4, Matias, M., Neto, S. M. & Santos, N., Uma Ferramenta de Apoio ao registro da interação humano-computador, IHC 2001 III Workshop sobre fatores Humanos em Sistemas de Computação, Nielsen, J., Usability Engineering, Academic Press, Chestnut Hill, Nielsen, J., Métrica de Usabilidade Consultado em Out/2001. Rocha, H. V. & Baranauskas, M. C.C., Design e Avaliação de Interfaces humanocomputador, Escola de Computação, Unicamp, São Paulo, 2000.

203 Metodologia de Aprendizagem a Distância de Recomendações Ergonômicas Contextualizadas em Casos de Uso Flávio Vieira 1, Elizabeth Furtado 2 1 Curso de Informática 2 Mestrado em Informática Aplicada - MIA Fundação Edson Queiroz - Universidade de Fortaleza - UNIFOR Av. Washington Soares 1321 Edson Queiroz Fortaleza CE Brasil flavio@unifor.br, elizabet@unifor.br Abstract. Human Computer Interaction (HCI) is most concerned with the design and evaluation of interactive computer-based systems, as well as with the multidisciplinary study of various issues affecting this interaction. For designing interfaces to reach better usability, accessibility and acceptability, we must take into account ergonomic recommendations. We propose an environment for designing interactive systems that helps the designer to learn, evaluate and apply ergonomic recommendations. This environment is guided by a methodology that provides distance learning in an interactive, collaborative and reflexive way where ergonomic recommendations are represented in situations in their context of use. Resumo. A Interação Humano-Computador (IHC) está focada principalmente no projeto e avaliação de sistemas interativos estudando aspectos que influenciam esta interação. Dentre estes aspectos destacamos as recomendações ergonômicas que orientam para o desenvolvimento de sistemas interativos com boa usabilidade, acessibilidade e aceitabilidade. Estamos propondo um ambiente que ajude ao projetista de interface aprender, avaliar e aplicar as recomendações ergonômicas no desenvolvimento de sistemas interativos. Este ambiente é guiado por uma metodologia de aprendizagem a distância baseada na colaboração e reflexão a partir de situações nas quais as recomendações ergonômicas são contextualizadas. 1. Introdução Várias propostas estão sendo apresentadas na área de IHC a fim de fornecer meios para projetar interfaces para atender aos diferentes requisitos de usuários, organizações, tarefas e outras particularidades. Dentre estas propostas, destacamos as recomendações universais que têm como objetivo facilitar e promover o projeto de interfaces para acesso universal, para garantir a usabilidade, acessibilidade e aceitabilidade de sistemas interativos [Stephanidis 2001]. O objetivo principal deste trabalho é definir uma metodologia que permita auxiliar o projetista na aprendizagem e aplicação das recomendações ergonômicas para a construção de interfaces de usuários para todos, durante todo o processo de desenvolvimento [Vieira 2002]. Definimos ainda como objetivos específicos: facilitar o aprendizado das recomendações ergonômicas; permitir a fácil atualização das

204 recomendações ergonômicas; permitir uma aprendizagem de forma prático-reflexiva de recomendações ergonômicas; ampliar a aplicação dos níveis de recomendações ergonômicas; e permitir a colaboração com outros projetistas. Este trabalho apresenta na seção 2 a problemática a respeito da dificuldade em aplicar as recomendações ergonômicas disponíveis na literatura. Em seguida, na seção 3, apresentamos o ambiente TeleCADI [Furtado et al 2002], sua concepção, características e funções, que fornecerá suporte computacional para atingirmos aos objetivos estabelecidos. Na seção 4 apresentamos a metodologia proposta para a aprendizagem das recomendações ergonômicas em duas etapas: a forma como as recomendações são contextualizadas usando casos de uso; e a forma de utilização pelos projetistas de IHC do ambiente TeleCADI para a aprendizagem destas recomendações. Na solução, são apresentados os fundamentos adotados no processo de aprendizagem das recomendações ergonômicas pelos projetistas. Na seção 5 apresentamos as conclusões deste trabalho. 2. Problemática Vanderdonckt [1999] analisa as dificuldades em aplicar as recomendações ergonômicas. As causas são principalmente devido à grande quantidade de publicações a respeito, à diversidade e ambigüidade de informações e à necessidade de recomendações atuais. Embora existam ferramentas que visam fornecer meios de amenizar estas dificuldades, muitas delas apresentam as recomendações na forma de receita de bolo, que podem ser um conjunto de regras pré-definidas e/ou de exemplos a serem seguidos para que se mantenha a consistência e coerência das interfaces [Bastien e Scapin 1993]. Além disso, o projetista de interface normalmente atua passivamente como um simples verificador de recomendações realizando consultas nestas ferramentas [Reiterer 2001]. Tal fato não ajuda o projetista a desenvolver a criatividade e inovar em formas de interação nem a capacidade de ajustar a situação oferecida à condição em que se encontra. Consideramos importante a participação ativa e construtivista do projetista de interface na busca do conhecimento necessário para a construção de interfaces. Acreditamos que as pessoas aprendem de forma construtiva quando são capazes de problematizar seus objetos de interesse [Schön 1987]. Além disso, para que o projetista tenha uma atitude reflexiva durante o desenvolvimento de uma interface, consideramos que a aprendizagem é um processo construtivo, onde ensinar através da solução de problemas é fundamental para desenvolver um processo reflexivo no aluno [Dewey 1959]. Consideramos também que as recomendações ergonômicas devem ser contextualizadas de acordo com as necessidades de uso do projetista. Estudos mostram que as pessoas têm maior facilidade de ajustar uma informação quando estas estão contextualizadas [Schank 1994]. Neste estudo, as situações de uso das recomendações ergonômicas são de projeto e avaliação de sistemas interativos. Isto implica numa nova forma de agrupamento das recomendações ergonômicas. Atualmente, a maioria das recomendações ergonômicas está organizada por tipo de interação, tais como estilos de interação e objetos de interação. Há, assim, carência de recomendações ergonômicas contextualizadas por situação de uso. Também constatamos que a maioria destas recomendações está restrita às regras de implementação e distribuição das informações em monitores de vídeo, uma vez que a

205 apresentação das informações e os retornos (feedbacks) são essencialmente realizados neste tipo de periférico. Percebemos ainda a falta de recomendações relacionadas ao contexto da interface como um todo (o ambiente onde se realiza a interação, às condições de uso dos dispositivos de interação, as metáforas propostas pela interface, etc). Ressaltamos também a necessidade de existirem ferramentas que permitam ao projetista vislumbrar a aplicação das recomendações ergonômicas num contexto de uso. Isto é possível, por exemplo, através da visualização de representações gráficas de uma situação real de interação vivida pelo usuário. Estas representações gráficas (cenários) servem para auxiliar o projetista na identificação de problemas sobre a aplicação de recomendações ergonômicas num projeto de interface para todos. Isto permitirá, conseqüentemente, instigar o projetista a refletir para chegar à solução mais adequada de problemas que são manifestados após ou durante o projeto de sistemas interativos. 3. O Ambiente TeleCADI Este trabalho tem a proposta de definir uma metodologia para usar o ambiente a distância, chamado TeleCADI, no domínio de aplicação de IHC. Este ambiente suporta a aprendizagem colaborativa e a ação prático-reflexiva do aprendiz na resolução de problemas [Dewey 1959]. Os usuários aprendizes do ambiente são projetistas de interface que buscam a solução de problemas de interface através da consulta e verificação da correta aplicação das recomendações ergonômicas. Tal ambiente possibilita ao projetista refletir e analisar interativamente, sozinho ou em grupo, usando recursos de colaboração, a aplicabilidade das recomendações de forma prática e reflexiva. Outro usuário do ambiente é o especialista em IHC, responsável em cadastrar as recomendações ergonômicas contextualizados para a consulta pelos projetistas. A figura 1 apresenta a arquitetura do TeleCADI. Figura 1 Arquitetura do TeleCADI A arquitetura do TeleCADI está organizada em três camadas. A camada de apresentação diz respeito ao componente de Interface; a camada de gerenciamento corresponde aos componentes CADI, TELE e CADInet; e a camada de armazenamento

206 de dados corresponde, obviamente, à base de dados. Estas camadas possuem vários componentes, cada um com funções distintas, que interagem entre si para a realização das atividades solicitadas pelos usuários. O componente CADI é responsável pela forma de interação do usuário quando este procura refletir sobre um problema relativo ao projeto ou avaliação de uma interface. Ele possui um módulo de assistência que controla a recuperação e apresentação de casos armazenados na base de dados que sejam semelhantes ao problema identificado pelo usuário. Os casos são representações de situações vivenciadas pelos projetistas com informações de recomendações ergonômicas para serem usadas como referências por projetistas de interfaces. Esta consulta aos casos é motivada pela busca da correta aplicação de um determinado elemento ou recurso. A forma de construção dos casos está descrita na seção 4. O componente TELE permite realizar a colaboração e comunicação com outros projetistas usando os recursos de comunicação da web, como bate-papo, transmissão de áudio e vídeo, assim como o compartilhamento de aplicações. Na figura 1, exemplificamos o TELE viabilizando o compartilhamento de um determinado gerador de interface. Este componente [Borges Neto et al 2000] é um aplicativo que permite uma interatividade em tempo real utilizando recursos de multimídia. Para sua implementação foram utilizados controles ActiveX do produto Netmeeting da Microsoft. O CADInet é o componente que oferece cursos na web compostos de temas. Na figura 1, ilustramos a existência de cursos de IHC sobre projeto e avaliação de interfaces de usuário, baseado em recomendações ergonômicas. O CADInet é uma ferramenta de educação a distância implementada para utilizar os recursos de comunicação disponíveis na internet. A base de dados é o componente que contém as informações a respeito das recomendações ergonômicas armazenadas na forma de casos e cenários. O componente da Interface é responsável direto pela interação do usuário com o ambiente TeleCADI, seja através da utilização de qualquer um dos componentes da camada hierárquica inferior, CADI, TELE e CADInet. 4. Metodologia Proposta Como foi dito anteriormente, a maioria das propostas que auxilia os projetistas na aplicação e avaliação de recomendações ergonômicas em projetos de interface, apresenta as informações de forma textual, agrupadas dentro dos estilos de interfaces. Propomos como diferencial o uso de casos de uso para grupar as recomendações ergonômicas e a representação destas através de cenários. Um caso de uso, descrita na Linguagem de Modelagem Unificada (UML) [Quatrani and Booch 1998], é uma descrição de ações de um sistema mediante o recebimento de um tipo de requisição de usuário. Cenários são variações (instâncias) de um caso de uso. Portanto, apresentamos nossa metodologia em duas etapas: na representação das recomendações ergonômicas contextualizadas em casos de uso associadas a cenários; e na utilização do ambiente TeleCADI para a aprendizagem destas recomendações pelos projetistas de IHC.

207 4.1. Contextualização das Recomendações Ergonômicas Nossa proposta consiste na contextualização das recomendações ergonômicas usando casos de uso e na associação destas a cenários gráficos, tarefa esta de responsabilidade do especialista em IHC. A figura 2 ilustra os passos que usamos para a contextualização das recomendações ergonômicas, desmembradas no procedimento apresentado em seguida. Situações Reais Recomendações Ergonômicas Casos de Uso Cenários Figura 2 Contextualizando as Recomendações Ergonômicas 1. Identificamos as situações vividas pelos usuários durante o projeto de um novo sistema ou durante a avaliação de um sistema já construído. Estas situações, chamadas de situações-modelo 1 são agrupadas em casos de uso; 2. Identificamos quais tipos de recomendações ergonômicas são possíveis de serem violadas em cada caso de uso, considerando as situações-modelo identificadas anteriormente; 3. Cadastramos as situações-modelo com seus respectivos casos de uso, juntamente com outras informações consideradas relevantes dentro do contexto de uso; 4. Construímos cenários e os relacionamos às situações-modelo. De acordo com o procedimento descrito acima, identificamos inicialmente os possíveis problemas que poderão surgir a partir de situações apresentadas pelos usuários durante a interação com um sistema. Para facilitar a identificação, associamos as situações a casos de uso, que representam a interação em que ocorre o problema. Na figura 3, ilustramos alguns exemplos de situações vivenciadas pelos usuários em casos de uso, relacionando-os a possíveis problemas durante a interação. É importante notar que um caso de uso pode ser decomposto em casos de uso específicos e se relacionam com qualquer caso de uso da estrutura formando uma organização hierárquica não rígida. 1 Chamamos as situações identificadas e cadastradas em seus respectivos casos de uso de situaçõesmodelo, pois este nome se refere a um formato padrão que definimos para descrevermos todas as informações relativas à situação, com os problemas detectados e as violações de uma recomendação ergonômica e suas possíveis soluções.

208 Interagindo no desktop Recebendo informações Solicitando retorno Entrando dados Visualizando Ouvindo Digitando Conversando Utilizando metáforas Organização das informações,, visualização das tarefas em paralelo e compreensão de problemas Problemas auditivos, culturais e poluição sonora do ambiente Diferenças linguísticas Correção de problemas de destreza manual Problemas culturais, ambientes barulhentos e compreensão verbal Problemas de destreza manual e culturais Usuário Interagindo na Web Navegando Pagando / Comprando Aprendendo à Distância Pesquisando Problemas de orientação e segurança Problemas de diferenças individuais Problemas de diferenças individuais e culturais Colaborando Problemas de controle de diálogo e meio social Casos de Uso Problemas Figura 3 Casos de Uso e Problemas para a Avaliação de um Projeto de Interface No passo 2 do procedimento, detalhamos os problemas associados a um caso de uso e identificamos as recomendações ergonômicas possíveis de serem violadas. Na figura 4, usamos o caso Visualizando Informações como exemplo.

209 Figura 4 Organização de Casos de Uso, Problemas e Recomendações Ergonômicas Observamos na figura 4 que uma mesma recomendação pode estar relacionada a várias situações e abrange os seguintes níveis de um sistema interativo: conceitual, contém recomendações ergonômicas relacionadas ao usuário e seu contexto de uso (uso adequado das metáforas; domínio sobre os dispositivos de interação; nível de conhecimento e familiaridade com sistemas interativos); semântico, contém as recomendações relativas ao acesso às informações (quantidade de informações; relevância das informações; teclas (recursos) de atalhos para usuários experientes; consistência das mensagens e informações de retorno); sintático, contém recomendações relativas às regras de utilização do ambiente (campos de dados com rótulos e unidades de valores adequados; consistência das mensagens e informações de retorno); e léxico, contém recomendações que tratam da compreensão dos códigos em geral (janelas com títulos e posição na tela adequada; possibilidade da configuração de campo, janela, língua, etc;). No passo 3 do procedimento ocorre o cadastro das situações-modelo vividas pelos usuários, de acordo com a tabela 1.

210 Tipo de Informação Situação: Recomendações Ergonômicas: Componentes de Interfaces: Níveis Recomendações Ergonômicas: Tipos de Tarefa: Casos de Uso: Palavras-chave: Sugestões: Descrição / Contextualização O usuário não consegue entender/perceber qual o ícone para emissão do relatório gerencial produzido no final da realização das tarefas. Usar as metáforas adequadas de acordo com a tarefa a ser realizada e o perfil do usuário; Considerar o uso de ícones e símbolos de referência internacional; Evitar o uso de textos dentro de ícones e símbolos. Teclado; Mouse; Monitor. Principal: Conceitual. Seleção do ícone do tutorial e/ou help; Seleção de menus; Janelas. Visualizando Informações; Não percepção do ícone desejado. Metáfora; Help; Ícone; Barra de Tarefas; Nível Conceitual. Verificar se existe um tutorial e/ou help e analisar como está estabelecida a metáfora; Utilizar a metáfora mais apropriada para identificar o help do sistema, ao invés de usar um símbolo próprio que não é conhecido pelos usuários. Tabela 1 Situação com uso inadequado de Metáfora Definimos este cadastro com informações que consideramos relevantes, dentro do processo de contextualização dos problemas nas situações-modelo. Desta forma, haverá diversas formas de busca das situações-modelo durante o processo de aprendizagem das recomendações ergonômicas. Finalmente, os casos de uso são relacionados com cenários gráficos (passo 4 do procedimento para a contextualização das recomendações ergonômicas). Os cenários servirão para que os usuários do ambiente, ou seja, os projetistas de interface, visualizem a aplicação ou violação de recomendações ergonômicas em situações de interação. Vejamos o exemplo do caso de uso relacionado com a interação do usuário, no momento da avaliação de um sistema interativo. A figura 5 ilustra o cenário Visualizando Informações relacionado ao caso de uso de mesmo nome.

211 Figura 5 Cenário Visualizando Informações Alguns componentes gráficos poderão ser adicionados a este cenário ilustrando com mais clareza o problema identificado nesta situação-modelo, tais como: variações nas condições ambientais, expressões facial e corporal do usuário, etc A Aprendizagem das Recomendações Ergonômicas usando o TeleCADI A definição da metodologia proposta foi motivada pela reflexão sobre as seguintes questões: Como estes usuários irão utilizar o ambiente? Qual a forma de interação entre projetistas aprendizes e o especialista? Como o aprendiz é levado a refletir sozinho e em grupo e ter uma postura reflexiva na solução de problemas? Como poderá o projetista utilizar um curso concebido pelo especialista usando a ferramenta CADInet de educação a distância? Estas questões poderão ser respondidas através da interpretação da figura 6.

212 Figura 6 Metodologia de Utilização do TeleCADI pelo Projetista de IHC De acordo com a metodologia proposta, inicialmente há o cadastro de novos projetistas que poderão usar o ambiente para o aprendizado das recomendações ergonômicas em IHC. Em seguida, podemos identificar as seguintes possibilidades de uso do TeleCADI pelo projetista de interface: i) participando de um curso e, ii) avaliando um problema de IHC. Para a primeira opção, propomos a utilização do ambiente CADInet. No exemplo da figura 7, o projetista escolhe o tema Projeto Lógico de Interface e visualiza o trabalho que o professor passou para ele. Neste trabalho, o professor sugere a reflexão de um problema de IHC, que pode ter sido manifestado por um usuário ou observado por um projetista. Isto implicaria na utilização do ambiente CADI para avaliar este problema.

213 Figura 7 Participando de um curso usando o CADInet Representamos na figura 8, as fases de um processo de resolução de problema pelos quais o projetista desempenha durante a realização da atividade Avaliando um Problema de IHC. O projetista inicialmente deve definir qual o seu problema. Em seguida, ele busca compreender as causas ou motivos do problema apresentado, ou seja, a identificação do mesmo. A última fase consiste na busca da solução deste problema considerando as recomendações ergonômicas de IHC. Definição Identificação Solução Consulta às Situações-Modelo Análise / Reflexão Figura 8 Fases do Processo de Aprendizagem Avaliando um Problema de IHC Durante as fases de identificação do problema e da busca de sua solução, o projetista tem a possibilidade de recuperação/consulta às situações-modelo previamente cadastradas pelo especialista em IHC. Para a escolha da forma mais adequada para a busca das recomendações ergonômicas, e que estão diretamente relacionadas com a contextualização dos casos, ele possui as seguintes opções: recomendação ergonômica; componentes de interface; nível de recomendação ergonômica; casos / cenários; e palavra-chave, conforme apresentado na estrutura da tabela 1. Durante o estado de reflexão e análise, várias perguntas sobre a aplicação das recomendações ergonômicas devem ser levantadas pelo projetista no intuito de verificar

214 as hipóteses existentes e viáveis para o problema em questão. Esta atitude é importante para a construção do conhecimento, através do pensamento prático-reflexivo em busca de soluções para o problema. Também existe a possibilidade de encerrar o ambiente de aprendizagem sem a obtenção de nenhuma sugestão ou solução para o problema. Quando o projetista concluir suas tarefas e tiver obtido algum resultado, o mesmo poderá reiniciar o processo para avaliação de outro problema ou encerrará o uso do ambiente TeleCADI. Podemos visualizar a etapa da busca da solução do problema na figura 9. Figura 9 Diagrama de Transição de Estados Avaliando um Problema de IHC A busca de uma solução através da reflexão e análise pelo projetista, poderá ocorrer individualmente, ou em grupo através da colaboração com outros projetistas. Ilustramos esta possibilidade através do uso do componente TELE, onde há o compartilhamento de um gerador de interface. 5. Conclusão Em virtude dos problemas apresentados neste trabalho, definirmos uma metodologia usando um ambiente interativo de aprendizagem para ajudar projetistas a aprenderem, refletindo sobre a aplicação, as recomendações ergonômicas na concepção e avaliação de interfaces. O projetista reflete sobre seu problema desenvolvendo sua própria solução seja colaborando com outros projetistas, seja consultando soluções já adotadas para problemas similares. Para isso, o cadastro de situações de problemas clássicos e comuns já apresentados na literatura da área em uma base de dados proporciona uma forma de aprendizagem reflexiva. Estas situações permitem ao projetista identificar e refletir sobre um problema usando analogia entre as situações problemas cadastradas e o problema do usuário. Apresentamos uma forma original para representar estas situações. Usamos um padrão na forma de tabelas com informações sobre o problema e as possíveis soluções envolvendo diversos componentes de interface e dando várias opções para o projetista identificar e contextualizar seu problema.também usamos uma representação gráfica através de cenários que permite abranger as recomendações ergonômicas no nível conceitual. Outra questão original do nosso trabalho é a associação das recomendações ergonômicas às ocorrências reais vividas pelos usuários usando os casos de uso e

215 cenários. Cenários ilustram as recomendações ergonômicas contextualizadas no ambiente de utilização de sistemas interativos pelos usuários. Finalmente, salientamos que a metodologia de aprendizagem de IHC usando o ambiente TeleCADI, proposta neste trabalho e ainda em fase de implementação, poderá ser utilizada por outras áreas de pesquisa. Referências Bibliográficas Bastien J..M.C., Scapin, D.L. (1993) Ergonomic criteria for the evaluation of user interfaces. INRIA, No.156. Borges Neto, H., Holanda, R., Silva, W., Braga, O. (2000) Especificando o Tele- Ambiente no Contexto da Educação a Distância. Simpósio Brasileiro de Informática na Educação - SBIE. (pp ). Dewey, J., (1959) Como Pensamos. São Paulo: Companhia Editora Nacional. Furtado, E., Furtado V., Silva, W., Rodrigues, D., Taddeo, L., Limbourg Q., and Vanderdonckt J. (2002) An Ontology-Based Method for Universal Design of User Interfaces. Chapter of the Book about Multiple User Interfaces over the Internet: Engineering and applications Trends. Quatrini, T., Booch, G. (1998) Visual Modeling With Rational Rose and Uml. Addison- Wesley Object Technology Series. Reiterer, H. (2001) Tools for Working with Guidelines in Different Interface Design Approaches. In Tools For Working With Guidelines (pp ). Schank, R., Dynamic Memory: a Theory of Learning in Computers and People. Cambridge University Press. (1994). Schön, D. (1987) Educating the Reflective Practitioner. New York. Jossey-Bass. Stephanidis, C. (2001) User Interfaces for All. Concepts, Methods and Tools. Mahwah, NJ: Lawrence Erlbaum Associates, Inc. Vanderdonckt, J. (1999) Developing Milestones toward a Tool For Working With Guidelines. Interacting with Computers 12, 2. (pp ). Vieira, F. (2002) Uma Metodologia de Aprendizagem de Recomendações Ergonômicas Contextualizadas em Casos de Uso. Dissertação de Mestrado (Mestrado em Informática Aplicada). Universidade de Fortaleza.

216 Desenvolvimento de Material Instrucional de Qualidade para EAD Segundo Princípios Cognitivos Rafael Godoi Orbolato, Vânia Paula da Almeida, Júnia C. Anacleto Silva Departamento de Computação Universidade Federal de São Carlos (UFSCar) Caixa Postal 676 CEP São Carlos SP Brasil {orbolato, vania, Abstract. This paper, partially sponsored by FAPESP, presents questions related to quality associated to the process of use and generation of instructional material to Distance Learning and its treatment by the adoption of cognitive strategies to the promotion of learning. In this context, it is presented a tool, that is being developed, that offers a group of cognitive strategies to show the viability of this approach. Resumo. Este trabalho, parcialmente financiado pela FAPESP, apresenta questões de qualidade associadas ao processo de geração e uso de material instrucional para Educação a Distância, e seu tratamento através da adoção de estratégias cognitivas para promoção do aprendizado. Nesse contexto, é apresentada uma ferramenta de edição, em fase de desenvolvimento, que oferece um conjunto de estratégias cognitivas, para mostrar a viabilidade dessa abordagem. 1. Introdução Qualidade é a totalidade das características de um produto ou serviço que lhe confere a capacidade de satisfazer as necessidades implícitas de seus usuários. Portanto, a qualidade está diretamente relacionada à satisfação do usuário ou do cliente e é percebida de maneiras diferentes [Rocha et al. 2001]. O modelo de qualidade para características externas e internas definido na norma ISO/IEC classifica os atributos de qualidade de software em seis características: usabilidade, funcionalidade, confiabilidade, eficiência, manutenibilidade e portabilidade. No contexto de desenvolvimento de interfaces, a questão da qualidade tem como objetivo: ter o foco de atenção centralizado na intenção do usuário; a não necessidade de conhecer o sistema como um todo; e, preocupação central neste trabalho, proporcionar usabilidade. Segundo Nielsen em [Nielsen 1993], usabilidade concerne a todas as características que permitem ao usuário interagir com o computador satisfatoriamente. Enquadra-se, ainda, dentro do conceito de aceitabilidade do sistema pelo usuário, ou seja, o sistema ser bom o suficiente para satisfazer as necessidades e requisitos do usuário e de outras pessoas relacionadas à utilização do sistema.

217 Com esse enfoque, percebe-se atualmente que a busca crescente pelo aprendizado apoiado pela internet, explorado na área de Educação a Distância (EAD), tem levado seus usuários a questionar a qualidade em ambientes para EAD, considerando seus mais diversos aspectos. Visando colaborar com essa discussão, este trabalho, parcialmente financiado pela FAPESP, defende que se há uma preocupação com aspectos de usabilidade na geração de material instrucional a ser utilizado em ambientes de EAD, pode-se garantir uma maior facilidade no processo de aprendizagem. Os aspectos de usabilidade são considerados em duas vertentes: em relação ao instrutor e a edição de material, e em relação ao aprendiz e o uso do material gerado. Para isso, é apresentado um conjunto de princípios cognitivos, expressos em estratégias cognitivas implementadas computacionalmente em uma ferramenta de edição para material instrucional, que visa facilitar o trabalho do instrutor na geração de um material de qualidade, facilitando também o processo de absorção de conhecimento pelo aprendiz. Este artigo está organizado da seguinte maneira: na seção 2 discute-se o uso de estratégias que facilitem a absorção de conhecimento para o aumento da qualidade em materiais para EAD apresentando também as estratégias cognitivas; na seção 3 apresenta-se a ferramenta de edição que está sendo desenvolvida baseada nas estratégias cognitivas; e na seção 4 são traçadas algumas considerações finais. 2. Estratégias Cognitivas e Aspectos de Usabilidade O sucesso do processo de ensino e aprendizagem utilizando ambientes de EAD se deve principalmente ao acesso ao material disponibilizado e às facilidades de comunicação entre aprendizes e instrutores. A comunicação entre as partes interessadas no processo, normalmente, é gerenciada por um ambiente de EAD e, assim, está fora do escopo deste trabalho, cuja principal preocupação é com a qualidade do material instrucional gerado. O instrutor deve se preocupar com a qualidade do material gerado não só porque a qualidade é um fator de avaliação, mas porque, em EAD, muitas vezes, o aprendiz entende que o material visualizado é a própria interface do sistema. Apesar da necessidade do uso de um browser para a visualização do material gerado, se o material for produzido adequadamente, o aprendiz pode navegar através de links inseridos pelo instrutor, no próprio material, tornando a navegação independente do browser e mais eficiente, pois o aprendiz é guiado pelo caminho sugerido pelo instrutor. É preciso que o instrutor se conscientize, primeiro, que ele passa a ter responsabilidades de um desenvolvedor, pois está gerando uma interface de transmissão de conhecimento, e segundo, que existe a necessidade de adequação do material que está sendo gerado, pois se o desenvolvedor entende, nas fases iniciais do desenvolvimento, a forma como o sistema é percebido pelo usuário, então o projeto e sua implementação serão executados gerando um sistema mais intuitivo ao usuário [Preece et al. 1994]. Sendo a usabilidade uma medida do esforço necessário para o uso do software e se considerarmos o material como a interface para o aprendiz, então facilitando o uso do

218 material, através de estratégias que facilitem a absorção de conhecimento, está-se diminuindo o esforço do usuário (aprendiz) e, portanto, aumentando a usabilidade desse material. Para tal se faz necessário apoiar o instrutor no desenvolvimento do material, tanto na estrutura da aula, bem como no uso de itens que facilitem a absorção do conhecimento. Estudos preliminares, analisando alguns dos ambientes computacionais de EAD como [BlackBoard 2001], [TopClass 2001], [WebCT 2001] e etc, indicam a pouca disponibilidade de recursos pedagógicos para o apoio ao instrutor em sua tarefa de elaboração de material [Orbolato et al., 2002]. Este estudo sobre uma metodologia de apoio ao instrutor levou a Gagné [Gagné 1974], que aborda os processos internos de aprendizagem através de itens que foram denominados domínios. Um desses domínios é constituído pelas estratégias cognitivas, que segundo ele são capacidades internamente organizadas que o aprendiz usa para guiar seus próprios processos de atenção, aprendizagem, memória e pensamento. O aprendiz usa uma estratégia cognitiva, por exemplo, ao prestar atenção nas diversas características daquilo que está lendo. O leitor usa certas estratégias cognitivas para selecionar e codificar o que aprende, valendo-se de outras estratégias para recuperar posteriormente essas informações. As estratégias cognitivas são, portanto, os meios que o aprendiz dispõe para administrar seus próprios processos de aprendizagem. Gagné relaciona tais estratégias com os conceitos de "aprender a aprender" e "aprender a pensar". Segundo Liebman [Liebman 1998], o aprendizado ativo vem ao encontro dos problemas descritos por professores universitários a respeito da efetividade de aulas expositivas no ensino. O aprendizado ativo é descrito da seguinte maneira: se a informação é processada ativamente no cérebro, antes de ser armazenada na memória de longa duração, tal informação é mais facilmente compreendida e retida (West et al 1 apud [Liebman, 1998]). Portanto, aumentando o aprendizado ativo na sala de aula, aumentam as chances dos estudantes compreenderem, lembrarem e usarem o conhecimento que se acredita deveriam ter. Liebman, em [Liebman 1998], sugere uma série de estratégias cognitivas para promover o aprendizado ativo, citadas a seguir: Organização: na literatura sobre psicologia cognitiva é chamada de particionamento, inclui a aplicação de taxonomias, listagens de semelhanças e diferenças, análise de forma e função e levantamento das vantagens e desvantagens. Estruturação: são organizações visuais da estrutura básica da informação em questão. Um exemplo de estruturação é a elaboração de uma tabela. Mapas de conceito: diagramas usados para expressar relacionamentos temporais, por categoria, causais, hierárquicos, etc. 1 West, C. K.; Farmer, J. A.; and Wolff, P. M. Instrucional Design: Implications from Cognitive Science. Allyn and Bacon, Boston, Massachusetts, 1991.

219 Uso de metáforas e analogias. Ensaios: são estratégias que visam manter a informação na memória de trabalho, tempo suficiente, para que seja mais bem estabelecida na memória de longa duração. Incluem repetição, perguntas e respostas, suposição e afirmação, redefinição ou parafraseamento da informação, revisão e resumo, seleção de informações importantes, anotações e grifos. Organizadores de avanços: são observações feitas pelo instrutor para ajudar o estudante a passar para um novo tópico, podendo ser entendidos como conectores ou ainda pontes, apontando semelhanças, diferenças e associações entre os temas envolvidos. Baseando-se nessas estratégias propostas por Liebman e sabendo da dificuldade inerente ao processo de elaboração e organização do material instrucional, está sendo desenvolvida uma ferramenta de edição que visa através da implementação do que chamamos, atividades (interpretações factíveis das estratégias propostas por Liebman) e de estruturas previamente definidas, que chamamos organização de documento, auxiliar o instrutor nessa tarefa de edição de material com qualidade e assim facilitar a transmissão do conhecimento. 3- Ferramenta de Edição de Material Instrucional Baseada em Estratégias Cognitivas Com base nas estratégias cognitivas vistas no intuito de apresentar uma solução para a questão da falta de apoio ao instrutor na sua atividade de criação de material instrucional para EAD, considerando aspectos de qualidade, está sendo desenvolvida uma ferramenta de edição de material instrucional para mostrar a viabilidade desta solução. As estratégias cognitivas, mostradas a seguir, foram implementadas em módulos, separados da ferramenta de edição. As características de sua interface ainda não são as definitivas, pois o objetivo era mostrar a viabilidade da utilização e implementação de tais estratégias. A Figura 1 mostra a edição de uma taxonomia, atividade da estratégia organização, sendo expressa graficamente em um mapa de conceito. O módulo pode ser utilizado para edição de outros diagramas que representam a estratégia mapa de conceito.

220 Figura 1 Tela do Módulo de Edição de Taxonomias A Figura 2 mostra uma outra estratégia cognitiva já implementada, a de criação de metáforas e analogias. Essa estratégia pode ser usada para enriquecer e exemplificar conceitos apresentados. No exemplo da figura, pode-se observar a edição de uma metáfora associada ao termo memória de longa duração na qual se digitou um texto e inseriu uma imagem para representá-la. Figura 2 Tela do Módulo de Edição de Metáforas Na Figura 3 pode-se observar o resultado final da edição de um texto no qual foi inserida essa metáfora. Quando o leitor clica sobre o link em questão, a janela explicativa contendo a metáfora é apresentada. Um segundo clique fecha a janela da metáfora.

221 Figura 3 Visualização de uma metáfora no material Outros módulos estão sendo implementados e serão posteriormente inseridos na ferramenta de edição, levando em consideração critérios de usabilidade para os instrutores. Pretende-se atingir tais critérios dando ênfase na interface da ferramenta e também através de explicações, exemplos e wizards guiando os passos dos instrutores na aplicação das estratégias e utilização da ferramenta, sem que esses recursos venham atrapalhar ou causar incômodo a usuários mais experientes, permitindo, por exemplo, que estes desabilitem as explicações e exemplos ou ainda tenham a sua disposição teclas de atalho. Considera-se que a disponibilização das estratégias cognitivas para os instrutores fornece uma grande ajuda na obtenção de um material instrucional de qualidade. Porém, pode-se facilitar ainda mais a utilização das estratégias cognitivas fornecendo ao instrutor estruturas organizacionais, que são seqüências pré-definidas de estratégias cognitivas, que formarão o corpo do material que está sendo criado. Com o uso dessas organizações de documento espera-se apoiar o instrutor na confecção de material instrucional a ser usado em ambientes de EAD, permitindo que ele comece a estruturação do documento com um apoio organizacional, ou seja, fornecendo uma espécie de roteiro a ser seguido. A organização de documento escolhida pelo instrutor fornecerá uma estrutura seqüencial a ser seguida, formada por estratégias cognitivas, que quando preenchidas podem vir a proporcionar um resultado com qualidade para o aprendiz que venha a utilizá-lo.

222 Para a criação do material, o instrutor pode escolher uma organização de documento previamente definida, pode modificar uma organização de documento existente ou ainda, pode criar uma nova organização de documento a ser utilizada no material. As organizações de documentos são divididas em três partes: bloco de estratégias inicial, corpo do texto e bloco de estratégias final. O corpo do texto é a única parte obrigatória das organizações. A Tabela 1 mostra dois exemplos de organizações de documentos disponíveis para os instrutores, onde a primeira coluna mostra a parte do documento, a segunda coluna mostra a estratégia aplicada e a terceira coluna mostra a atividade utilizada, ou seja, o resultado no material. Várias organizações serão oferecidas ao instrutor, seguindo as estratégias propostas. Partes do Documento Estratégia Atividade Bloco Inicial Ensaio Resumo Organização 1 Corpo do Texto Conteúdo Bloco Final Organização/Ensaio Pontos Importantes Organizador de avanço Link próximo assunto Bloco Inicial Ensaio Perguntas Organização/Ensaio Pontos importantes Organização 2 Corpo do Texto Conteúdo Bloco Final Ensaio Perguntas e Respostas Ensaio Resumo Tabela 1 Exemplos de organização de documento No corpo do texto, o instrutor tem liberdade para criar o material da maneira que desejar, podendo utilizar-se das estratégias cognitivas que achar mais pertinente para dar forma e estrutura ao material. A Figura 4 a seguir mostra um mock-up 2 da interface principal da ferramenta de edição. 2 Esboço

223 # Ferramenta de Edição Documento Organização Editar Ajuda Organização A Resumo Corpo do Texto Pontos Importantes Link Próximo Assunto D Nova A ferramenta de edição permitirá que o professor escolha a estratégia cognitiva que deseja usar e consiga aplicá-la de maneira organizada e simples em seu material. Opções de Edição Link Tabela Imagem Divisor Taxonomia Metáfora Semelhanças B C Figura 1 - Imagem inserida que pode ser usada como metáfora O resultado da edição das estratégias escolhidas vai sendo inserido na página que irá compor o material sendo editado. Estruturas Perguntas Resumo Tabela 1 - Tabela de propriedades e valores Figura 4 Mockup da tela principal da ferramenta de edição No bloco selecionado por A na Figura 4 aparecem as estratégias cognitivas que compõem a organização de documento escolhida para esse documento. Clicando duas vezes sobre uma dessas estratégias, dispara-se o módulo correspondente a essa estratégia que pode então ser editada antes de ser inserida no bloco a que corresponde (inicial ou final). Esses blocos irão compor a primeira e a última página do documento, sendo que o corpo do texto fica entre essas duas páginas. Selecionando o corpo do texto em A, é habilitada a edição no bloco C, onde o instrutor edita o corpo do texto, podendo digitar o conteúdo que deseja, ou ainda utilizar alguma das opções disponíveis no bloco B. Essas opções vão desde a inserção de uma imagem, de um link, de uma tabela, até a inserção de estratégias cognitivas, sendo que ao selecionar uma estratégia cognitiva, o instrutor dispara o módulo de edição dessa estratégia, que após ser preenchida é inserida no bloco C. No bloco marcado por D estão os controles das páginas que formam o corpo do texto do documento, ficando habilitados somente quando o corpo do texto está selecionado no bloco A. Com esse controle, pode-se mover por entre as diversas páginas que compõem o corpo do texto, sendo que o instrutor pode também inserir novas páginas. Selecionando a opção Abrir no item de menu Documento da Figura 4, é mostrada então uma janela de diálogo contendo os documentos criados e salvos anteriormente, permitindo agora que o instrutor continue a sua edição.

224 Selecionando a opção Criar ainda no item de menu Documento, é mostrada a janela de seleção da organização de documento a ser adotada, onde ele pode escolher uma organização pré-definida, modificar uma das organizações existentes, ou ainda criar uma nova organização. Essa janela pode ser vista na Figura 5 a seguir. # Seleção de Organização de Documento Escolher Modificar Criar Voltar Figura 5 Janela de Diálogo para a seleção de organização de documento a ser utilizada Ao selecionar a opção Escolher na janela da Figura 5 é mostrada a janela da Figura 6, na qual o instrutor seleciona a organização de documento que deseja utilizar em seu material. Nessa janela, ao mover entre as organizações de documento disponíveis, é mostrada uma descrição dessa organização, com as estratégias cognitivas que a compõem. # Seleção de Organização Organizações Descrição Organização 1 Organização 2 Organização 3 Organização 4 Estratégia 1 Estratégia 2 Estratégia 3 Corpo do Texto Estratégia 5 Estratégia 6 Voltar Utilizar Figura 6 Janela de Diálogo para a seleção de uma organização de documento existente

225 Selecionando a opção Modificar na janela de diálogo da Figura 5, é mostrada então uma janela de seleção de organização de documento semelhante à Figura 6, com um botão modificar no lugar do botão de aplicar. Ao selecionar uma organização de documento para ser modificada, é mostrada então a janela para modificação de organização ao instrutor. Essa janela é vista na Figura 7 onde ela aparece com os blocos inicial e final preenchidos com as estratégias cognitivas dessa organização de documento. O instrutor pode então inserir ou remover estratégias cognitivas nos blocos que desejar. Ao selecionar a opção Criar na janela da Figura 5 é mostrada também a janela da Figura 7, porém sem os blocos inicial e final preenchidos, sendo que o instrutor pode criar uma nova organização de documento para ser utilizada. # Criação/Modificação de Organização Estratégias Cognitivas Estratégia 1 Estratégia 2 Estratégia 3 Estratégia 4 Estratégia 5 Estratégia 6 Estratégia 7 Estratégia 8 - Início: - Corpo do Texto - Fim: Estratégia 2 Estratégia 6 Estratégia 5 Estratégia 3 Inserir Item => Remover Item Voltar OK Figura 7 Janela para a criação e modificação de Organizações de Documento Nessa janela, o instrutor seleciona quais estratégias cognitivas irão compor os blocos inicial e final da organização, sendo que a organização de documento final tem o corpo do texto inserido automaticamente entre esses blocos. Ao terminar a edição de seu material na ferramenta, o professor pode selecionar o item Gerar Material no menu Editar da Figura 4, fazendo com que um hiperdocumento seja gerado com o uso de HTML e Javascript. Nesse material, os blocos inicial e final tornam-se uma página HTML cada, sendo que a ligação entre essas páginas e as páginas do corpo do texto é feita através de links inseridos automaticamente pela ferramenta.

226 Para facilitar o entendimento dos instrutores com relação à ferramenta e a teoria que serve de base para a geração de material, será desenvolvido um tutorial explicando as idéias de Liebman, o conceito de aprendizado ativo, as estratégias cognitivas, as atividades derivadas dessas estratégias cognitivas, as organizações de documento e sua utilidade, bem como exemplos de uso de atividades e organizações. Supõe-se que os instrutores interessados em melhorar sua atuação em EAD estariam interessados ao menos a conhecer a ferramenta e sua base teórica, seguir seu tutorial e experimentá-la na criação de material. Essas explicações e exemplos contidos no tutorial também estarão na Ajuda da ferramenta e nos wizards das atividades, sendo que nesse caso, podem ser desabilitadas pelos instrutores para não causar nenhum incômodo quando estes já estiverem familiarizados com a ferramenta, podendo ser habilitadas novamente caso desejem. Foram discutidas aqui algumas das opções de edição oferecidas pela ferramenta, porém outros aspectos deverão ser tratados até a finalização deste trabalho, tendo como foco a qualidade e seus critérios de usabilidade, relacionados principalmente, à geração de hiperdocumentos, como, por exemplo, a quantidade de texto em cada página gerada, o tipo de fonte a ser utilizada e as cores empregadas. Esses critérios de usabilidade, como por exemplo os encontrados em [Alertbox 2002], estão sendo estudados, na tentativa de tornálos factíveis na implementação. 4- Conclusões As estratégias cognitivas apresentadas neste trabalho foram escolhidas como uma base de apoio a instrutores para criação de material instrucional, visando melhorar a usabilidade e garantir qualidade ao material e sua geração. Embora essas estratégias cognitivas sugiram ser apropriadas para esse fim, isso só poderá ser confirmado com a realização de testes com aprendizes utilizando o material gerado pela ferramenta quando esta estiver funcionando. Essa preocupação com a qualidade, fazendo um paralelo com a Engenharia de Software, se estende ao processo de criação do material (processo do software), através do oferecimento de uma ferramenta de edição ao autor do material instrucional, pautado por critérios de usabilidade convencionais ao desenvolvimento de interfaces. Além disso, existe a preocupação com a qualidade do material instrucional gerado (produto do software), oferecendo ao aprendiz um documento gerado baseado nas estratégias cognitivas apresentadas, para promoção de um aprendizado efetivo. É importante que pesquisadores e desenvolvedores envolvidos com EAD tenham em mente que os ambientes de EAD devem ser adaptáveis a instrutores e aprendizes dos mais diversos campos, e que há necessidade de um apoio pedagógico na edição do material, visando, principalmente, as questões relacionadas à qualidade do material instrucional gerado. Espera-se que este trabalho venha contribuir para esse objetivo. Referências [Alertbox 2002] Nielsen, J. The Alertbox: Current Issues in Web Usability, Documentação online, Disponível em Consultado em junho de 2002

227 [BlackBoard 2001] BlackBoard Release 5.5, Documentação online, Disponível em Consultado em outubro de 2001 [Gagné 1974] Gagné, R. M. "The Conditions of Learning". 3 rd editon. Holt, Rinehart e Winston, Versão Brasileira: Como se realiza a aprendizagem. [Liebman 1998] Liebman, J. Teaching Operations Research: Lessons from Cognitive Psychology. Interfaces, 28(2), 1998, p [Nielsen 1993] Nielsen, J. Usability Engineering, Estados Unidos: AP Professional, [Orbolato et al., 2002] Orbolato, R. G.; Almeida, V. P.; Silva, J. C. A. An Edition Tool Based on Cognitivism Theory to Support Distance Learning. In: IFIP World Computer Congress, 17., Montreal, Canadá, 2002 (a ser publicado em agosto de 2002). [Preece et al. 1994] Preece, J. et al. Human-Computer Interaction. Inglaterra: Addison- Wesley, [Rocha et al. 2001] Rocha, A. R. C.; Maldonado, J. C.; Weber, K.C. Qualidade de Software Teoria e Prática.1 a. edição. São Paulo. Prentice Hall, [TopClass 2001] TopClass, Documentação online, Disponível em Consultado em outubro de 2001 [WebCT 2001] WebCT, Documentação online, Disponível em Consultado em outubro de 2001

228 Desenvolvimento da Interface de um Software Educacional com base em Interfaces de Jogos André Luiz Battaiola 1, Nassim Chamel Elias 1, Rodrigo de Godoy Domingues 1, Rodrigo Assaf 1, Geber Lisboa Ramalho 2 1 Depart. de Computação Universidade Federal de São Carlos (UFSCar) Caixa Postal São Carlos SP Brasil 2 Centro de Informática - Universidade Federal de Pernambuco (UFPE) Caixa Postal Recife - PE {andre,nassim,rodrigod,rodassaf}@dc.ufscar.br, glr@cin.ufpe.br Abstract. The computer games interfaces have changed from 2D environments based on textures to sophisticated 3D environments that use polygonal objects, graphical animations, video and audio. The challenge offered by the plot, the compatibility between plot and interface, the sophistication of the scenes, the performance and the facility of interaction are the critical features for the success of any recent game. These criteria can also be considered for the development of successful educational software. This article shows the development of the Edugraph interface, software to teach computer graphics concepts, considering criterion on computer games interfaces. Resumo. As interfaces de jogos de computador evoluíram de ambientes 2D baseados em texturas para ambientes 3D sofisticados que contam com objetos poligonais, animações gráficas, vídeos e áudio. O desafio proporcionado pela trama, a compatibilização da interface com a trama, a sofisticação das cenas, a performance e a facilidade de interação são fatores críticos para o sucesso de um jogo atual. Estes critérios também podem ser considerados para o desenvolvimento de um software educacional de sucesso. Este artigo discute o desenvolvimento da interface do Edugraph, software de ensino de conceitos de computação gráfica, com base em critérios de interfaces de jogos de computador. 1. Introdução O esquema tradicional de ensino ignora, em geral, um fator importante para o aprendizado: a motivação. As pessoas preferem, usualmente, realizar atividades que lhes tragam prazer e divertimento. Assim, não se pode ignorar um parâmetro como este na determinação de critérios eficientes para o ensino de massa, especialmente, quando se considera o uso de software educacionais. Jogos de computador são exemplos de software para entretenimento que atraem milhões de pessoas e movimentam bilhões de dólares por ano. A empresa de consultoria americana Datamonitor ( divulgou que as vendas de software de jogos para computador e consoles no mercado americano e europeu alcançara a cifra de US$ 10,9 bilhões em Em seu relatório Wireless Gaming, a Datamonitor informa

229 que quatro em cinco usuários de celulares estarão jogando jogos em celulares em 2005, o que representa um universo de 200 milhões de consumidores na Europa Ocidental e Estados Unidos. Além da questão comercial, um outro aspecto pode ser considerado em relação à atração exercida pelos jogos. Papert, o inventor da linguagem Logo, destaca [1] que, atualmente, no mercado, encontram-se jogos sofisticados que envolvem conceitos complexos até para um adulto. Apesar disto, adolescentes com faixa de idade entre 10 e 15 anos, motivados pela possibilidade de competirem com seus colegas, não só são capazes de aprenderem estes conceitos, bem como de desenvolverem métodos para otimizar este aprendizado, tendo em vista que quem mais rápido aprende, mais rápido atinge as melhores marcas em competições. Por outro lado, é interessante notar que é nesta faixa de idade que os jovens começam a perder o interesse por temas escolares. Estes fatos apontam para a seguinte consideração: por que não utilizar alguns dos princípios que norteiam o desenvolvimento de jogos para a implementação de software educacional, de forma a torná-los tão atrativos quanto os jogos? Neste contexto, este artigo discute no item 2 o que são jogos de computador, no sub-item 2.1 como se classificam a suas interfaces, no sub-item 2.2 critérios de navegação em ambientes de jogos e no item 3 critérios cognitivos a serem considerados em sistemas multimídia para ensino. Com base nesses conceitos, no item 4, é descrita a criação do software de ensino de computação gráfica Edugraph, com considerações sobre a sua implementação nos sub-itens 4.1 e Jogos de Computador Ao contrário do produto, as características técnicas dos jogos de computador são pouco conhecidas. Um jogo de computador é um produto composto de três partes principais: enredo ou trama, motor e interface interativa [2]. O enredo define os objetivos do jogo e a sua definição pode requerer a participação de diferentes especialistas, tais como, escritores, psicólogos, historiadores, etc. O motor controla a interação entre o usuário e a sua interface. A implementação do motor pode envolver conceitos presentes em diversas áreas da computação, tais como, computação gráfica, inteligência artificial, redes de computadores, engenharia de software, etc. A interface interativa apresenta o estado corrente do jogo e viabiliza a interação entre o jogo e o usuário. A sua implementação pode envolver aspectos artísticos, cognitivos e técnicos. 2.1 Interface dos Jogos de Computador As características relevantes da interface de um jogo são o atrativo visual, a compatibilidade com a trama e o alto nível de jogabilidade, o qual representa a capacidade do usuário de fácil e rapidamente movimentar-se pelo ambiente do jogo e acionar os recursos necessários para realizar uma nova jogada. Critérios para medir o nível de compatibilidade de uma interface à trama de um jogo envolvem a definição dos diversos tipos de jogos e de ambientes que eles usualmente requerem. Os principais tipos de jogos são os de: estratégia, simulação, aventura, esporte, RPG, passatempo, educação/treinamento e infantil [2].

230 Jogos de passatempo (cartas, xadres, damas, etc) usualmente requerem interfaces 2D simples baseadas em sprites (texturas que se movimentam sobre a tela sem deixar marcas sobre o plano de fundo) [2]. Jogos de simulação (corrida de carro ou moto, pilotagem de avião, etc) usualmente requerem realismo, por isto utilizam interfaces baseadas em ambientes 3D e objetos poligonais sofisticados. A sofisticação visual, o nível de realismo e a flexibilidade de interação baseada em diversas formas de navegação no ambiente fazem das interfaces 3D as preferidas para o desenvolvimento dos jogos modernos. Apesar de diversas características de um jogo serem imprevisíveis, analisando-se as peculiaridades dos títulos mais famosos [3], [4], é possível estabelecer os seguintes critérios gerais para a classificação de suas interfaces 3D: 1) visão do jogador, 2) ambiente e 3) projeção. Dependendo da trama do jogo, a visão do jogador pode ser em 1 a (primeira) ou 3 a (terceira) pessoa. A visão em 1 a pessoa torna a tela do computador o olho do usuário, ou seja, o jogador tem a mesma visão do personagem do jogo, o que cria uma grande sensação de imersão. Jogos de combate em ambientes 3D fechados usualmente utilizam este tipo de visão. Note-se que a característica visual dos jogos em 1 a pessoa requer interfaces 3D. A visão em 3 a pessoa permite que o jogador se enxergue no cenário do jogo, sendo ele, por exemplo, apenas um soldado, um exército ou um veículo. Esta visão é também conhecida como God s eyes pois o usuário tem uma visão completa do mundo e do(s) objeto(s) que cercam o(s) personagem(s). Note-se que jogos 2D com personagens e ambientes limitados apresentam interfaces com visão em 3 a pessoa, porque, neste caso, o usuário tem visão total de sua localização no ambiente do jogo, para onde e como ele pode ir e de qualquer alteração na área de interesse do ambiente. Todas estas características tornam a interface do jogo atrativa e facilitam a interação. Outras considerações são mencionadas no sub-item 2.2. Os ambientes dos jogos podem ser classificados como: a) internos, b) externos e c) siderais, sendo que podem ser criados ambientes mistos formados pelo uso alternado dos tipos básicos. Os ambientes internos [Figura 1] são fechados, constituídos de salas e suas interconexões, tais como corredores e portas, de forma similar à planta de uma casa. Normalmente, estes ambientes são conhecidos como dungeons (masmorras) e são freqüentemente encontrados em jogos em 1 a pessoa, tais como o Quake e o Doom, da ID Entertainment. A iluminação é nitidamente artificial e geralmente estática porque provêm de fontes de luz como tochas ou spotlights. Os ambientes abertos [Figura 2] são criados a partir de geradores de terreno ou por um mapa de altitude (malha triangular ou quadrangular, na qual a coordenada z dos vértices representa altura). Usualmente, a iluminação é natural, mas pode haver outras fontes de luz. Geralmente, os ambientes externos simulam o céu através de uma caixa mapeada com texturas denominada de SkyBox. Esse tipo de recurso é muito utilizado em jogos de simulação, em especial, naqueles que operam com aviões, tal como o F1 World Grand Prix da Eidos Interactive. Os ambientes siderais [Figura 3] simulam o espaço sideral através da exibição de estrelas, planetas, nebulosas e outros objetos espaciais. Geralmente, possuem iluminação variável de acordo com as fontes de iluminações (sóis) disponíveis no sistema sideral em que o jogo se desenrola. Exemplos de jogos que se caracterizam por essa ambientação são Privateer I e II da Origin Systems.

231 Ambientes tridimensionais são visualizados no computador através de projeções. Em jogos, destacam-se dois tipos de projeções: 1) a perspectiva e 2) a axonométrica [5]. A projeção perspectiva é natural ao sistema ótico humano e é gerada através de raios projetores que partem de um centro de projeção localizado no finito, o que acarreta a perda de paralelismo entre linhas e é essencial para transmitir a noção de profundidade. Por exemplo, ao entrar em um túnel longo, uma pessoa vê a porta de saída com dimensão menor que a porta de entrada e, conseqüentemente, observa uma perda de paralelismo das linhas laterais do túnel. A projeção perspectiva é praticamente uma exigência em jogos em 1 a pessoa, pois a visualização do ambiente tem de ser compatível com o que é natural ao olho humano. Alguns jogos em 3 a pessoa com projeção perspectiva, como os da série Tomb Raider da Eidos Interactive, posicionam a câmera atrás do personagem de forma a aumentar o campo de visão do jogador e transmitir a sensação de um jogo em 1 a pessoa. A projeção paralela ortográfica axonométrica apresenta raios projetores que partem de um centro de projeção no infinito e incidem paralelamente ao plano de projeção. Os objetos são rotacionados antes da sua projeção no plano de forma a assegurar que se tenha uma visão tridimensional do mesmo. Como este tipo de projeção não acarreta a perda de paralelismo entre linhas, a noção de profundidade natural ao ser humano não existe. Jogos baseados em texturas e conhecidos como jogos 2 1/2 D utilizam a projeção axonométrica para simular a tridimensionalidade. Jogos 3D reais utilizam usualmente este tipo de projeção quando a trama do jogo se desenrola sobre planos onde mapas cartográficos ou vias são traçados. Neste caso, o plano é visualizado de forma inclinada e de uma certa altura, não havendo, assim, a necessidade da noção de profundidade. Entre os jogos nessa categoria encontram-se jogos recentes de estratégia em tempo real, tais como Emperor - Battle for Dune, da Westwood e Star Trek Armada, da Interplay. Note-se que bibliotecas gráficas 3D, como a OpenGL e o Direct3D da Microsoft, permitem trabalhar tanto com projeções perspectivas quanto com paralelas ortográficas, bem como movimentar e posicionar a câmera para obter o tipo de visualização desejado. Figura 1: Ambiente Interno Figura 2: Ambiente Aberto Figura 3: Ambiente Sideral 2.2 Critérios de navegação em ambientes de jogos A incorporação de ambientes 3D aos jogos por computador levou a uma série de questionamentos que se aplicam usualmente a ambientes virtuais. A causa principal deste questionamento é o fato de que dispor de um ambiente 3D não significa aumentar a sensação de imersão do usuário no ambiente. Um bom jogo 2D pode oferecer uma sensação maior de imersão que um 3D, no sentido de que ele é capaz de envolver mais o jogador em seu ambiente. Assim, faz-se preciso discutir os fatores chaves para a

232 implementação de interfaces 2D e 3D de jogos (critérios a-i), bem como aqueles específicos para jogos 3D (critérios j-m) [6]. a) Exploração e descoberta: A maioria dos usuários de jogos não lê os manuais quando começam a jogar. Eles esperam que a interface do jogo possibilite uma navegação intuitiva que o capacite a descobrir e explorar recursos e funções. b) Controles ao Alcance do Usuário: Em um ambiente virtual é desejável que o usuário tenha controle sobre a cena, com total compreensão sobre o lugar ao qual ele está se dirigindo e porque. Quando o ponto de vista é em 3º pessoa, o usuário é capaz de se ver na cena e determinar como ele se move em relação a outros objetos, o que aumenta a sua sensação de controle. e) Guias: As guias são necessárias para conduzir o personagem para lugares específicos do ambiente. O ambiente virtual 3D requer bons pontos de referência para tornar a navegação fácil sem o auxílio de recursos adicionais como os mapas presentes em determinados jogos de corrida, onde uma janela exibe a visão do motorista e outra a posição do carro na pista. f) Limites do Ambiente: Em jogos em ambientes abertos é importante que todos os lugares visitáveis sejam interessantes e que os não-visitáveis fiquem fora dos limites do mundo. g) Reforço Positivo e Negativo: Uma ação correta realizada pelo usuário pode ser notificada e resultar em algum tipo de recompensa, o que o incentiva a aprender como realizar uma ação correta. Outra possibilidade é reportar uma ação incorreta, entretanto, em muitos casos, é mais fácil reportar as ações corretas. Além disso, o usuário poderá se sentir desafiado a sempre realizar uma ação errada. h) Movimentação versus Animação: Um ambiente virtual pode dispor de um grande conjunto de objetos, mas os objetos de relevância na cena são aqueles que têm significado para a ação que o usuário deve realizar. Assim, não compensa associar visual sofisticado e animações complexas a objetos sem significado para a movimentação do personagem. i) Nível de Complexidade da Reação: Um erro comum e grave ao se definir um jogo é exigir uma reação do usuário a cada objeto que surge na cena. Muitos jogos de computador impõem limites ao número de objetos ativos na cena por razões de performance, mas estes estão sendo superados pela evolução do hardware. Assim, o número de objetos na cena deve ser limitado por razões psicológicas porque o usuário pode se sentir inundado de informações se houver muitos objetos ativos simultaneamente na cena de um jogo, não importando quão lentos e irrelevantes eles sejam. j) Visão do Jogador: A maioria dos jogos adota o ponto de vista em 1º pessoa devido a dois fatores principais: facilidade de implementação e maior nível de incorporação. Implementar é mais fácil porque o gerenciamento da percepção de profundidade é bastante simples, pois associa tamanho à profundidade, ou seja, se está perto, é grande, se está longe, é pequeno. O nível de incorporação é maior porque a visão em 1º pessoa é natural ao ser humano. Em um jogo em 3º pessoa,

233 a experiência é mais complexa. A relação entre o usuário, o personagem e o mundo permite mais oportunidades de interação. k) Falta de Percepção de Profundidade: A estereoscopia é um processo de percepção de profundidade baseado no fato do ser humano ter dois olhos separados por uma pequena distância. Este método é mais eficiente para se determinar a profundidade de objetos próximos ao observador. Para objetos distantes, as pessoas usualmente determinam a profundidade com base em outras referências, como, por exemplo, a linha de horizonte, nuvens, etc. No entanto, se um observador subir e abaixar a cabeça suavemente, ele poderá distinguir melhor o posicionamento relativo de objetos distantes. Um recurso do jogo Doom permite que o personagem se mova levantando e abaixando a cabeça, de forma a aumentar o senso de profundidade. l) Gerenciamento do Ponto de Vista do Jogador: Em um mundo virtual 3D, o usuário pode tentar ver a parte de trás da cena. Para uma apresentação em 3º pessoa, pode-se considerar a possibilidade de travar a câmera, mas os usuários logo desejarão movê-la. Assim, ao se construir a cena, o recomendado é posicionar e apontar a câmera para lugares passíveis de visualização e adicionar algumas restrições. m) Suporte à Navegação e ao Direcionamento: Em mundos virtuais com liberdade total ou parcial de movimentação, uma questão importante a ser considerada é como especificar a ação: quero ir até lá. Outra é: se o usuário aponta para um lugar e diz vá para aquele local, o sistema deve levá-lo até o local e deixá-lo virado de frente para um objeto daquele local? Se sim, corre-se o risco do usuário ficar boa parte do tempo olhando paredes. Uma solução para estes problemas é a criação de um sistema de navegação com alvo que, quando ativado, direciona o personagem para um local, mas que, durante o deslocamento, permita que ele realize alguns outros movimentos, rotação em torno do seu eixo, por exemplo. Neste caso, dosa-se a liberdade com facilidade de movimentação. Adicionalmente, alvos secundários ou um esquema alternativo podem ser utilizados para movimentar rapidamente o personagem para um local específico. 3. Conceitos cognitivos em sistemas multimídia de ensino Os jogos modernos utilizam diversas mídias integradas, como texto, animação, vídeo, áudio, etc. Logo, o desenvolvimento de um jogo ou de um software educacional deve considerar conceitos cognitivos que orientem a combinação destas várias mídias. A relevância de apresentações multimodais é baseada no fato de que o uso de símbolos com explicações verbais mostrou-se mais efetivo do que apresentações visuais (gráficos e/ou texto) ou explicações verbais separadamente. Este efeito é justificado em termos de um modelo para a memória humana que indica que ela é capaz de processar paralelamente informações apresentadas em dois modos diferentes: visual e sonoro [7], [8]. Apresentações multimídia transmitem um conjunto de informações que variam em termos de importância para o aprendizado [9]. Um conjunto de regras cognitivas que

234 envolvem, por exemplo, formas, tamanhos e cores, pode ser considerado na classificação da informação em uma escala de prioridades de assimilação. Mayer e Moreno [10] têm examinado a integração de som, texto e animação em um sistema multimídia de aprendizado. Eles concluíram que animação com som (informação visual e sonora) têm se apresentado mais eficiente do que animação com texto (informação visual apenas). Lowe [11] estabelece quatro pontos importantes a serem considerados na mudança de sistema educacional baseado em figuras estáticas para outro baseado em animação: (1) animações apresentam um maior conteúdo de informações; (2) durante a animação, o observador tem pouco tempo para observar e processar informações; (3) animações complexas requerem mais atenção para integrar informações refletidas em muitas mudanças em diferentes partes de cada quadro da animação; e (4) o observador necessita armazenar informações dos quadros anteriores e posteriores em uma memória de trabalho limitada durante um intervalo de tempo substancial, o que divide a sua atenção entre diferentes partes da transmissão. 4. Edugraph Edugraph [12] é um software em desenvolvimento para o ensino de computação gráfica. O foco de interesse é computação gráfica devido aos seguintes fatores: 1) o grande uso de recursos gráficos em diversos programas populares e 2) o aprendizado de conceitos referentes a esses recursos se baseia na filosofia a necessidade faz o aprendizado, o que não garante o aprendizado e torna o usuário dependente de pacotes. Uma análise dos principais conceitos abordados em um curso introdutório de computação gráfica indica que um sistema de ensino destes conceitos deve considerar os seguintes fatores: a. a possibilidade de estender os conceitos abordados de forma mais simples no espaço 2D para o 3D; b. propiciar alto nível de experimentação e interatividade, ou seja, o processo de aprendizagem de rotação é facilitado pelo uso de rotações; c. criar um ambiente que permita ao aluno correlacionar conceitos adquiridos empiricamente no mundo real com aqueles aprendidos formalmente, por exemplo, transladar um carrinho de plástico no chão é operacionalmente similar a transladar um carro no mundo virtual; d. explorar o potencial lúdico envolvido neste tipo de ensino e no seu ambiente de trabalho para otimizar o processo de aprendizado; e. expor os conceitos neste ambiente através de uma série de mídias integradas de acordo com critérios cognitivos, descritos no item 3; f. possibilitar trabalho colaborativo entre os estudantes. A menos da questão educacional, jogos de computador satisfazem muitos destes critérios, ou seja, jogos usualmente fornecem um ambiente lúdico dotado de interface com alta interatividade e visual sofisticado, composto por várias mídias integradas e, em alguns casos, esquema multiusuário de interação, envolvendo colaboração entre

235 jogadores. Logo, programas educacionais podem referenciar técnicas envolvidas no desenvolvimento de jogos e, assim, a definição do Edugraph seguiu a concepção de unir métodos educacionais com técnicas de jogos de computador. O Edugraph opera com uma interface interativa com acesso a diferentes mídias (vídeo, hipertexto, áudio, animação) e imersão em um ambiente 3D. Para garantir que este sistema tenha o almejado valor pedagógico, a sua interface foi definida considerando-se os tópicos abordados nos itens 2.1, 2.2 e 3. O Edugraph opera com um ambiente 3D com visão em 3 a pessoa, no qual um personagem representa o aluno. O objetivo com este tipo de ambiente é aumentar o nível de interação do aluno, favorecer a navegação e permitir que o aluno contraponha gráficos 2D com 3D, o que é um fato relevante em cursos de computação gráfica. Além disso, este tipo de ambiente propicia treino em navegação em ambientes 3D, fato importante quando o aluno tiver que trabalhar com objetos 3D. O processo de navegação considera as questões mencionadas no item 2.2, e utiliza, por exemplo, guias sonoras e visuais para orientar o aluno no ambiente. O ambiente do Edugraph foi definido como uma espécie de túnel 3D formado por paredes angulares que mudam de direção, simulando um zigue-zague [Figura 4]. A idéia é associar alterações de ângulos de parede a níveis de um jogo, no qual o jogador só passa para o próximo nível se completar o anterior. Em uma das paredes de cada nível do túnel há uma porta com um botão [Figura 5]. O acionamento deste botão abre uma porta e transporta o aluno para um outro mundo. Uma determinada tarefa realizada com sucesso neste novo mundo faz com que o aluno volte para o nível do túnel no qual ele se encontrava e o capacita a prosseguir para o próximo nível. Assim, a concepção do túnel serve para orientar o aluno sobre o estágio no qual ele se encontra, não permitindo que ele misture o nível de aprendizado com as tarefas a serem realizadas, bem como para desafiá-lo e incentivá-lo a progredir no estudo. Ao ativar o procedimento associado a uma porta, há um enquadramento na tela da área interna da porta, a qual se abre e ativa uma nova tela, de forma a dar a sensação ao aluno de que está entrando em um novo ambiente. Este outro mundo significa a ativação de programas que exibem hipertextos, vídeos e animações gráficas, ou então a inserção do aluno em ambientes 2D ou 3D, nos quais ele poderá exercitar os conceitos aprendidos. O ambiente 3D de teste irá permitir, por exemplo, que o aluno modele sólidos e o 2D que ele resolva questões em hipertexto.

236 Figura 4: Túnel Figura 5: Portal O vídeo será utilizado basicamente para introduzir conceitos [13]. Sua produção será baseada na técnica de cromaqui, que consiste em filmar um palestrante apresentando conceitos em um cenário com fundo azul e, em seguida, substituir o fundo por gráficos, imagens ou animações relacionadas ao conceito apresentado [Figuras 6a e 6b]. O áudio, além do uso na exposição de conceitos, será também utilizado em conjunto com informações visuais para notificar a realização de operação correta ou errônea. Áudio 3D [14] será utilizado de forma simples nos ambientes 3D de teste para, por exemplo, simular som de colisão ou reforçar a percepção de profundidade. Áudio interativo [15] só deverá ser utilizado em uma futura versão multiusuário. Figuras 6a e 6b: Produção de vídeo usando cromaqui. 4.1 Implementação do Edugraph A implementação do Edugraph está baseada na biblioteca gráfica OpenGL [16] e em módulos do DirectX da Microsoft [17], tais como o DirectSound para a reprodução de áudio e o DirectShow para a reprodução de vídeo. Programas de modelagem são utilizados para a geração e exportação do ambiente tridimensional. Como a OpenGL e o DirectX têm suas rotinas escritas em C, a linguagem de desenvolvimento escolhida foi a C++. A escolha deste ambiente de implementação foi baseada em uma análise de motores de jogos, frameworks que disponibilizam uma estrutura mínima para a implementação de jogos [18]. Tamanho, confiabilidade, performance e documentação de código, além de restrições como o uso de placas gráficas, foram fatores que induziram a implementação do Edugraph a partir do zero. A implementação ficou dividida em duas partes: 1) funções (recursos básicos que o sistema necessita para se tornar operacional) e 2) conteúdo (informações sobre os conceitos a serem ensinados). Atualmente, a maior parte do esforço se concentra no desenvolvimento das funções do sistema. Ele já conta com o túnel 3D, deslocamento de personagem com detecção de colisão, exibição de vídeo, acionamento de navegador para a exibição de hipertexto e recursos mínimos de áudio. Ainda faltam implementar o deslocamento do personagem com animação hierárquica (o personagem movimenta braços e pernas) e os cenários de trabalho em 2D e 3D, no qual o aluno realiza atividades de modelagem de sólidos. Em termos de conteúdo, a descrição dos conceitos em páginas HTML já está pronto, no entanto, ainda falta complementar o material com

237 animações, produzidas em GIF animado e/ou em Flash, vídeo e áudio. A produção de vídeo fará uso extensivo da técnica de cromaqui. Os cenários de trabalho 2D e 3D serão implementados em OpenGL. O cenário 3D permitirá que o estudante exercite conceitos de modelagem de sólidos através de malhas poligonais e operações pré-definidas [Figura 7]. A intenção não é implementar um modelador de sólidos, logo, malhas pré-definidas serão armazenadas de forma que o aluno possa manipular objetos em um esquema de posicionamentos e operações que resultem em um novo objeto, cuja malha também já esteja armazenada. Técnicas específicas permitem que as malhas sejam definidas e armazenadas de maneira otimizada [19], permitindo alta interatividade. Uma versão do Edugraph deverá estar disponível para teste até o segundo semestre de Versão Web do Edugraph No meio do segundo semestre de 2001, após o começo da implementação do Edugraph, foi lançado o Macromedia Director 8.5 [20], um poderoso software para a criação multimídia integrada em ambientes 2D ou 3D e passível de publicação na WWW (World Wide Web) com interação mono ou multiusuário. Levando-se em consideração os aspectos do Director 8.5, uma equipe começou a implementar o Edugraph nesse pacote. Nas experimentações feitas até o momento é possível visualizar o ambiente 3D do Edugraph (túnel com as texturas), o personagem 3D com animação (importada do 3D Studio Max) e movimentação de câmera através do ambiente [Figura 8]. Futuramente, será possível migrar todo o sistema para a WWW, o que amplia o público usuário e facilita o acesso ao software, bem como possibilita que algumas tarefas, como aquelas desenvolvidas nos cenários de trabalho 3D, possam ser realizadas de forma colaborativa. Além disso, o esforço de desenvolvimento fica concentrado em recursos específicos do aplicativo, ao invés de recursos básicos. Figura 7: Área de trabalho. Figura 8: Ambiente Edugraph em Director. 5. Conclusão Até o presente momento, não foi detectado nenhum software educacional com os aspectos e objetivos do Edugraph, o que o torna pioneiro na área, mas dificulta avaliações. Uma comparação com outro software baseado em jogos e voltado para o ensino de conceitos da área de biologia [21] resultou na seguinte constatação: o Edugraph não incorporou ao seu ambiente uma trama (enredo), o que é um componente

238 crucial para tornar um jogo desafiador. O aspecto lúdico e desafiador do Edugraph ficou centrado em sua interface, o que não é uma garantia de estímulo ao usuário. Estudos estão sendo realizados no sentido de se corrigir este problema [22]. Outra tarefa é elaborar um processo detalhado de avaliação do aprendizado baseado no desempenho de seus usuários. A indústria de jogos tem usado métodos para avaliar esse tipo de software [23], entretanto, no caso de software educacional, certamente o correto é recorrer aos métodos de avaliação recomendados por psicólogos e pedagogos. Assim, a avaliação do Edugraph será feita com o auxílio desses profissionais. Referências 1 Papert, S. Does Easy, Do It? Children, Games, Learning. Game Developer, junho de Feijó, B., Battaiola, A. et al. Jogos em Computador e Celular. Revista de Informática Teórica e Aplicada, Vol. 8, outubro de Historia dos Consoles: outerspace.terra.com.br/retrospace/materias/consoles/historiadosconsoles1.htm, Acessado em 24 de julho de Historia dos Videogames: acessado em 24 de julho de Battaiola, A., Erthal, G. Projeções e o seu Uso em Computação Gráfica. Anais do JAI98/SBC, agosto de Clarke-Willson, S. Digital Illusion: Entertaining the Future with High Technology. ACM Press, Mousavi, S.; Low, R.; Sweller, J. Reducing cognitive load by mixing auditory and visual presentation modes. Journal of Educational Psychology, 87(2), Tindall-Ford, S.; Chandler, P. & Sweller, J. When two sensory modes are better than one. Journal of experimental psychology: Applied, 3(4), Tuovinen, J. E. Cognition Research Basis for Instructional Multimedia. Design and Management of Multimedia Information Systems: Opportunities and Challenges, Idea Group Publishing, Mayer, R. E.; Moreno, R. A split-attention effect in multimedia learning: evidence for dual processing systems in working memory. Journal of Educational Psychology, 90(2), Lowe, R. K. Extracting information from an animation during complex visual learning. European Journal of Psychology of Education, 14, Battaiola, A., Elias, N., Domingues, R. Edugraph: Software to Teach Computer Graphics Concepts. IFIP-GI-Conference - Social, Ethical and Cognitive Issues of Informatics and ICT, julho de 2002, Dortmund, Alemanha. A ser publicado.

239 13 Waggoner, B.; York, H. Video in Games: The State of Industry. Game Developer, março de Graham, G. Exploring Surround Sound Using DirectSound3D. Game Developer, janeiro, Miller, M. S. Producing Interactive Audio: Thoughts, Tools, & Techniques. Game Developer, outubro, Wright, R., Sweet, M. OpenGL SuperBible. Waite Group Press, Parberrry, I. "Learn Computer Game Programming with DirectX". Wordware Publishing, Charles, A. FORGE V8: Um framework para o desenvolvimento de jogos de computador e aplicações multimedia. Dissertação de Mestrado, Cin/UFPE, Recife, Battaiola, A. Otimização do Processo de Geração de Malhas Triangulares a partir de Polígonos. XXIV Latin-American Conference of Informatics CLEI, 1998, Quito, Ecuador. 20 Robbins, C. et al. Director 8.5 Studio: with 3D, Xtras, Flash and Sound. Friendsof, agosto de Amory A. Building an educational adventure game: theory, design and lessons. Journal of Interactive Learning Research, 2001, 12 (2/3) Littlejohn, R. The Need to Adapt the Tools of Drama to Interactive Storytelling. Gamasutra, setembro de Geiger, B. Psychological Research Methods for Game Design. Game Developer, maio de 1998.

240 Aprendizagem Online: ferramentas de comunicação para colaboração Janne Yukiko Yoshikawa Oeiras 1, Heloísa Vieira da Rocha 1 1 Instituto de Computação Universidade Estadual de Campinas (UNICAMP) Caixa Postal Campinas SP Brasil {janne, heloisa}@ic.unicamp.br Abstract. This paper presents an analysis on the redesign of TelEduc, a webbased distance education environment, which has been done in order to improve its tools. In this process, priority has been given to evidence the social aspects present in any distance course. These aspects are important to promote collaboration among the participants what leads to community building. Resumo. Este trabalho apresenta uma análise sobre o redesign do ambiente TelEduc que vem sendo realizado a fim de aprimorar suas funcionalidades. Nesse processo, a prioridade é evidenciar aspectos sociais no decorrer de um curso, tendo em vista a importância destes no sentido de favorecer a colaboração entre os participantes e o conseqüente desenvolvimento de comunidades de aprendizagem online. 1. Introdução De forma análoga ao presencial, durante o oferecimento de cursos a distância também se busca incentivar a colaboração entre os participantes para que seja formado um grupo de aprendizagem que possibilite a troca de experiências e conhecimentos, sem os quais qualquer curso se aproxima do fracasso. Apesar da rede ter a propriedade de encurtar distâncias e dispor de recursos tecnológicos que permitem o agrupamento dos participantes, experiências descritas na literatura (Harasim, 1996; Romani et al., 2000) mostraram que esse objetivo não é tão simples e fácil de ser alcançado. Muitos cursos a distância são oferecidos com o apoio de algum ambiente computacional que é composto de várias ferramentas para gerenciá-los, possibilitar a comunicação entre seus participantes e facilitar a tarefa de organizar conteúdos. Um exemplo de ambiente é o TelEduc ( que vem sendo desenvolvido desde 1997 de maneira participativa, na qual seus usuários, em cursos semi-presenciais ou totalmente a distância, fazem sugestões de novas ferramentas ou de redesign das existentes, permitindo assim uma melhor adequação do ambiente à tarefa de ensinar e aprender a distância. Ultimamente, as principais modificações têm ocorrido na interface do sistema (cores, menu, forma de apresentação de conteúdos, etc.) e pela inclusão de novas ferramentas que buscam dar maior visibilidade aos participantes e prover outras formas de comunicação entre eles.

241 A possibilidade de visualizar quem está presente no ambiente tem se mostrado uma característica necessária para minimizar a sensação de solidão que os alunos sentem ao entrar nesses ambientes (Romani et al., 2000; Rocha et al., 2001) e também uma forma de promover o estabelecimento de relações pessoais que são fundamentais para o sucesso de qualquer atividade em grupo. Essas relações, que são criadas ao longo do tempo, facilitam relacionamentos de trabalho, auxiliando os membros de um grupo a conhecerem a personalidade dos demais, bem como seus estilos de trabalho. Dessa maneira, pode ser criada uma atmosfera de confiança entre as pessoas que encoraja o levantamento de questões e a troca de idéias; comunicação dinâmica associada com satisfação; aprendizagem e cooperação (Haythornthwaite, 1998). Após um primeiro momento, em que os ambientes de suporte para Educação a Distância (EaD) via Web tinham seu foco centrado basicamente no design de tecnologias para criar, apresentar e dispor de forma cada vez melhor o conteúdo de um curso (Romani et al., 2000), o redesign desses ambientes tem considerado aspectos sociais que visam principalmente incentivar a formação de novas relações sociais pelas quais os alunos possam aprender uns com os outros e saber como trabalhar em grupo (Valente, 1999), visando a construção de uma comunidade de aprendizagem. Em algumas experiências em cursos semi-presenciais e a distância de uso do TelEduc, pôde-se notar a dificuldade em utilizar principalmente suas ferramentas de comunicação que, em suas primeiras versões, foram incorporadas sem considerar o propósito original de seus desenvolvimentos e suas interfaces. Dessa forma, notou-se que algumas atividades que poderiam desencadear a troca de experiências são difíceis de serem realizadas por meio delas (Oeiras e Rocha, 2000). Por essa razão, acredita-se que seja necessário fornecer novas ferramentas pelas quais as pessoas possam se comunicar de forma adequada para que a colaboração entre elas possa crescer significativamente (Kollock, 1998a). Com isso, uma questão a ser estudada é quão importantes são as diferenças entre as formas de comunicação e como utilizar uma determinada modalidade de comunicação. Este trabalho apresenta o redesign do ambiente TelEduc a fim de aprimorar suas funcionalidades para apoiar principalmente aspectos sociais que são importantes para o desenvolvimento de comunidades de aprendizagem. Assim, na seção 2 são apresentados alguns princípios derivados de estudos da área de Sociologia para o desenvolvimento de comunidades online. A seção 3 apresenta uma análise sobre o uso do comunicador instantâneo ICQ durante o oferecimento de um curso totalmente à distância e, por fim, a seção 4 apresenta as considerações finais deste trabalho. 2. Comunidades online: identidade e continuidade de interação Kollock (1998b) afirma que não existe uma receita para formar comunidades, mas sugere alguns princípios que podem auxiliar no desenvolvimento de comunidades online. Os membros de uma comunidade permanecerão ativos e estimulados, principalmente, pelas relações que serão formadas ao longo do tempo. Assim, é preciso que haja um espaço para que as pessoas se conheçam e estabeleçam sua identidade e reputação dentro do grupo. A definição de identidade pode ajudar a construir um sentimento de confiança entre os

242 participantes, favorecer novos relacionamentos e criar uma infra-estrutura rica e significativa para o desenvolvimento de cooperação dentro daquela comunidade (Kim, 2000). Nas primeiras versões do TelEduc não havia ferramentas que permitiam saber informações sobre os participantes. Em outros ambientes, como o WebCT 1, havia um espaço para um participante incluir sua página pessoal (home page), muitas vezes já construída e que nem sempre continha as informações pertinentes ao contexto de um curso. A necessidade de identificar e conhecer um pouco a respeito do outro foi sentida durante um curso da área de Educação e ocasionou a inclusão da ferramenta Perfil no ambiente TelEduc. Essa ferramenta apresenta informações pessoais distribuídas em um texto elaborado por cada pessoa e que pode seguir orientações previamente estabelecidas pelo(s) professor(es) de acordo com o contexto de um curso. Após a introdução dessa ferramenta no TelEduc, foi feito um novo redesign do ambiente, pois no início de um curso, momento em que os participantes estão se conhecendo, era necessário, principalmente para os professores, retornar ao Perfil para lembrar características de um determinado participante sempre que houvesse uma nova mensagem, atividade ou comentário. Assim, tinha-se que sair da ferramenta ativa 2 naquele momento para verificar o perfil de uma pessoa. A interface do ambiente foi então reformulada de maneira que em todas as ferramentas o nome de um participante é um link de acesso ao seu perfil, o que possibilita uma rápida verificação de sua identidade naquele grupo. Em cursos a distância, além de conhecer características dos demais participantes, tem-se notado que é necessário também saber quem está conectado ao mesmo tempo no ambiente. A literatura (Harasim et. al., 1996; Romani et al., 2000) mostra que uma das queixas mais freqüentes de alunos é quanto ao sentimento de isolamento, solidão. É comum, ao entrar em um ambiente de curso a distância, encontrar uma seqüência de páginas e não saber se há alguém conectado naquele momento. Essa sensação também foi relatada por uma usuária que comentou ser interessante descobrir quem entra nos mesmos horários, pois isto facilitaria, por exemplo, a tarefa de encontrar pessoas para discutir, em tempo-real, alguma atividade ou leitura do curso. O TelEduc, em sua versão atual, não possui uma ferramenta para identificar os participantes que estão online. Para minimizar esse problema de visibilidade, alguns usuários têm explorado e utilizado algumas ferramentas do TelEduc de maneira diferente do propósito original para o qual elas foram criadas. Essa forma particular de utilizar uma determinada ferramenta foi denominada (re)significação (Rocha et al., 2001). Em outras palavras, cada ferramenta é concebida com uma determinada funcionalidade dentro de uma visão específica do que vem a ser a tarefa de educar, mas o modo de utilizá-la em um dado contexto pode gerar outras funções de acordo com a significação a ela atribuída pelo usuário A página de entrada de um curso oferecido via TelEduc é dividida em duas partes. Na parte esquerda são dispostas as ferramentas que serão utilizadas; na parte direita é apresentado o conteúdo correspondente à ferramenta selecionada.

243 Um exemplo de (re)significação para perceber participantes online, foi o uso combinado de duas ferramentas: Acessos e Correio. Acessos é uma ferramenta que permite um professor saber, por meio de relatórios, quão freqüente é o acesso dos participantes ao curso (diário, semanal, mensal), enquanto o Correio consiste em um sistema de correio eletrônico interno ao ambiente. Em um curso, alguns participantes estimavam, por meio do horário fornecido nos relatórios fornecidos por Acessos, que colegas estariam conectados ao ambiente e utilizavam o Correio como forma de iniciar um contato quase síncrono com o outro. E este procedimento, tem se repetido em inúmeros cursos, das mais diversas naturezas. Este dado torna evidente a necessidade que os usuários têm em manter relações de proximidade mesmo em ambientes a distância e revela a forma criativa que os usuários desenvolvem para utilizar duas ferramentas familiares a fim de resolver um determinado problema (Preece, 2000). Isto também remete ao design de uma nova ferramenta que possa assegurar a continuidade de interação (Kollock, 1998b) de forma síncrona entre os participantes. A ferramenta Acessos é bastante proveitosa quando utilizada em sua concepção original (acompanhamento de cursos) e, apesar da possibilidade de (re)significá-la, não é simples detectar os usuários conectados ao TelEduc, pois é preciso varrer visualmente todo o relatório, atentando para os horários e datas, até encontrar as pessoas cujo último horário de acesso esteja próximo da hora atual (Figura 1). Figura 1: Relatório de acessos Na Web pode-se obter gratuitamente comunicadores instantâneos, programas muito utilizados por usuários de Internet para identificar pessoas que também estejam online. Geralmente os comunicadores possuem interfaces e funcionalidades semelhantes e, na maioria deles, a identificação do usuário online é feita por meio de uma lista de pessoas cadastradas que cada usuário possui na sua cópia do programa.

244 Revelada essa necessidade de comunicação síncrona entre os participantes de vários cursos a distância, buscou-se utilizar o comunicador instantâneo ICQ 3 para se observar como a introdução dessa nova ferramenta influenciaria a comunicação entre os participantes (Preece, 2000). A escolha por essa ferramenta se deu pelo fato de ser um programa amplamente conhecido entre os usuários de Internet. Na figura 2, tem-se a janela principal do ICQ na qual é apresentada a lista de contato, uma espécie de agenda na qual pode-se adicionar as pessoas que se tornam conhecidas. As cores dos nomes na lista diferenciam as pessoas conectadas (azul) das que estão offline (vermelho). Cada usuário pode escolher uma variação de flor que indicará para os demais o seu estado em um determinado momento (ocupado, afastado, disponível, não perturbe, etc.). Figura 2: Janela Principal do ICQ A próxima seção apresenta a análise realizada sobre a utilização do ICQ em um curso oferecido totalmente a distância que revela as diferentes formas de interação entre seus participantes. A introdução desse programa no curso permitiu a realização de algumas ações colaborativas, bem como o estabelecimento de novas relações sociais entre as pessoas. 3. Ações Colaborativas a Distância via Comunicadores Instantâneos O ICQ foi utilizado como um recurso adicional para prover uma forma de comunicação instantânea entre os participantes de um curso de capacitação de professores em Informática na Educação Especial. Esse curso foi realizado totalmente a distância via ambiente TelEduc e teve a duração de 120 horas, distribuídas ao longo de 14 semanas, com a participação de 3 formadores e 25 alunos. Após um período inicial de familiarização com o curso e com o TelEduc, na terceira semana os formadores enviaram uma mensagem pelo Correio do ambiente para todos os participantes com orientações sobre como obter um material de apoio para instalação do ICQ e como iniciar as primeiras trocas de mensagens. Como a turma envolvia pessoas inexperientes com o uso de computadores (principalmente instalação e configuração de 3

245 programas), foi deixado a critério de cada participante utilizar ou não o ICQ. Na mensagem comentou-se a respeito de como este programa poderia ser utilizado para iniciar um contato síncrono com os formadores e colegas. Aqueles que já o utilizavam foram os primeiros a atualizar o conteúdo da ferramenta Perfil com o seu número de identificação do ICQ. Entre os formadores foi adotada a política de usar o programa sempre que estivessem conectados no ambiente do curso (comentando atividades, atualizando conteúdos, etc.). Assim, geralmente havia pelo menos um formador online no período da manhã, à tarde e à noite. A análise apresentada a seguir foi realizada com base no registro das conversas via ICQ mantidas entre formadores e formadores-alunos. A maneira como os alunos utilizaram o programa entre si foi conhecida por meio de entrevistas informais realizadas por ICQ e correio eletrônico Um espaço reservado O curso foi realizado em forma de vários módulos com conteúdos diferentes. Para cada módulo era aberto um Fórum de Discussão visando o compartilhamento das dúvidas que surgissem entre a turma. A tentativa de canalizar as dúvidas para um espaço público, não era confortável para muitos alunos que as remetiam aos formadores de maneira privada via Correio interno do TelEduc. Com o decorrer do curso, o grande número de mensagens trocadas via Correio sobrecarregou o servidor do TelEduc o que causava lentidão no acesso ao curso e em qualquer operação que precisasse ser realizada (envio de atividades, atualização de conteúdos, etc.). Assim, foi enviada uma mensagem para os alunos avisando que seria criado um fórum especial, denominado Comunicados Gerais, para divulgar qualquer informação importante a respeito do curso. Dessa maneira, implicitamente, também foi reforçada a idéia de que as mensagens de dúvidas deveriam ser remetidas aos respectivos fóruns. Assim, foi "reprimido" nesse curso, o canal para falar em particular com os formadores. Alguns alunos então passaram a utilizar o ICQ como uma alternativa para tirar dúvidas de maneira privada. Ao longo do curso era realizada uma sessão de Bate-papo semanal, durante a qual geralmente os formadores deixavam seus ICQs ativos. As sessões eram um encontro para falar sobre o andamento do curso, discutir as atividades propostas e, com o tempo, passou a ser um espaço para compartilhar dúvidas que tivessem surgido até o momento. A turma de maneira geral se esforçava e tinha grande interesse em participar e aproveitar o momento síncrono proporcionado pelo Bate-papo. Certamente isto se deve à competência pragmática dos usuários de bate-papos (Maingueneau, 1998) que o consideram um espaço informal e descontraído que os deixa mais à vontade para interagir (Suguri et al., 2002). Porém, como não havia a opção reservado (falar em particular para um determinado interlocutor), alguns alunos aproveitavam e faziam algumas perguntas em particular via ICQ ou desabafos sobre problemas com trabalho em grupo para os quais eram buscadas orientações sobre como proceder. O aspecto de ter um espaço reservado para troca de mensagens parece ser um ponto relevante para os alunos. Uma participante, numa entrevista por correio eletrônico, levanta o fato do Bate-papo não permitir conversas privadas que para ela eram importantes principalmente quando da discussão e elaboração de alguma tarefa do curso:

246 (...) tb [também] preferia ele ao chat do TelEduc, pq [porque] nele poderia conversar sobre coisas pessoais q ficaria sempre entre eu e a pessoa, o bate papo do curso ñ tinha a ferramenta reservado, além das conversas ficarem gravadas, qdo [quando] era só coisa do curso referente a dúvidas ñ tinha problema, mas qdo era outra coisa ñ dava (ex trocar tarefas). Esta forma de utilizar o ICQ revelou a mudança na interação entre os participantes e na realização de suas tarefas, que antes ocorriam somente pelo TelEduc, e passaram a ser realizadas por uma ferramenta externa como forma de estabelecer novamente um canal síncrono e privado de comunicação Aproximação entre participantes O ICQ também foi usado como um meio de aproximação entre os participantes. Diferentemente do Bate-papo que tinha horário pré-estabelecido, essa comunicação se dava de maneira ocasional, espontânea e informal sobre assuntos variados como no exemplo abaixo em que uma participante encontra uma formadora online no início do curso: A : é a formadora do curso da TelEduc, né? F : sou eu sim, tudo bem? (...) A : faz pedagogia, né? F : (...) Estou no 3º ano de pedagogia. (...) A : me formei em Pedag em 98 (hab supervisão escolar e magistério), só naum fiz a pós em supervisão escolar, preferi psicopedagogia A interação informal e sobre assuntos variados aconteceu em diversos momentos via ICQ. Conversar sobre trivialidades do dia-a-dia pode parecer, num primeiro momento, atrapalhar o desempenho das pessoas durante um curso. No entanto, na literatura (Bickmore e Cassel, 2001) essa atitude é apontada como uma estratégia importante para o desenvolvimento de qualquer relacionamento colaborativo. Por meio dessas interações podese obter informações sobre os indivíduos de um grupo e desenvolver um sentimento de confiança entre eles. Timms et al. (2001) também apontam experiências em que foi benéfico mudar o foco de atenção de questões puramente ligadas ao curso para aspectos mais simples da boa convivência social como trocas irrelevantes, humor, etc. a fim de promover relações efetivamente colaborativas. Esse tipo de "encontro" ocasional, a medida em que acontecia, também promovia a colaboração entre os participantes da turma como será mostrado a seguir. 3.3 Realizando Trabalho em Grupo Ao longo do curso foram propostas algumas atividades que buscavam incentivar a colaboração e a troca de experiências entre todos os participantes. Uma delas era elaborar um seminário virtual - uma discussão sobre um tema que aconteceria pela postagem de mensagens no Fórum de Discussão. Os responsáveis precisavam, a partir de um tema proposto pelos formadores, escolher tópicos para discussão; elaborar uma mensagem para a turma explicando como seriam as regras do seminário; moderar e avaliar a participação dos colegas. Preece (2000) afirma que a teoria de Common Ground pode ser utilizada para determinar como duas pessoas ou um pequeno grupo validam que se entenderam. Essa teoria

247 enfoca como são coordenados o conteúdo abordado e o processo de comunicação. A todo momento as pessoas têm que atualizar sua base comum e esse processo é influenciado pelo meio e pela tarefa de comunicação. Essa atualização constante de conhecimentos certamente influenciou os responsáveis pelo seminário a utilizar meios síncronos para comunicação, entre eles o ICQ e telefone, pois esse tipo de atividade envolvia tomadas de decisão que deveriam ser efetuadas em um curto espaço de tempo e que requeriam argumentação que, quase sempre, se constitui no decorrer de uma conversação. Apesar de disporem do Bate-papo como ferramenta síncrona, a elaboração desta atividade foi feita pelo ICQ por questões de privacidade (no Bate-Papo, a discussão sobre a elaboração do seminário ficaria registrada), de velocidade na transmissão de mensagens e pela facilidade na troca de arquivos como mostra o depoimento a seguir: C icq, pudemos montar o fórum, cada uma faia um pouco e depois enviava p a outra em forma de arquivo, assim ia sofrendo mudanças, tb [também] utilizamos ele numa madrugada c a T. p fazer esse mesmo trabalho. Ao final do fórum qdo [quando] tivemos de montar o relatório, uma outra colega (R.) entrou em contato comigo pelo ICQ p decidirmos as notas dos participantes, c ele pudemos tocar idéias até altas horas. Os encontros para elaborar o seminário eram previamente agendados entre os participantes. Porém outros alunos relataram que também muitas vezes havia encontros ocasionais em que eram trocadas experiências e compartilhadas soluções, como no depoimento abaixo em que um participante faz comentários sobre uma atividade que ele deveria realizar com os alunos que ele atendia em sua instituição: toda solução, na minha parte principalmente vinha através da troca de experiência. Por exemplo: As vezes eu sentia dificuldade de iniciar um trabalho com um certo aluno. Essa experiência era relatada e então a outra pessoa, me dizia como ela começou, se fosse válido eu ia tentar aplicar aqui também. Muitos encontros ocasionais também passaram a se tornar freqüentes entre alguns participantes, principalmente entre aqueles que costumavam acessar a rede nos mesmos horários. O uso do ICQ então parece ter sido um meio de prover a interação continuada entre eles (Kollock, 1998b) o que auxiliava a compartilhar conhecimentos: Eu e a V. continuamos mantendo contato por icq diariamente, ñ só p/ trabalhos, mas p bater papo, é uma forma de continuarmos amigas e nos encontramos sempre. Só q o icq nos auxiliou muito na realização de todas as atividades, pq [porque] antes de anexarmos as atividades ao portfólio, uma analisava a tarefa da outra, dava palpite e mudava as coisa (enviávamos em forma de arquivo), por isso, algumas de nossas tarefas eram tão parecidas, pq mesmo sendo um trabalho individual, fazíamos em dupla e qdo o trabalho era em grupo, continuávamos fazendo em dupla, acho q nos ajudou muito, pois aprendemos a fazer as coisas e tiramos boas notas, além de nos deixar muito amigas. Outro ponto a ser notado é que esse programa proporcionou momentos extensivos de contato (Haythornthwaite, 2000) entre essas participantes o que parece ter propiciado o estabelecimento de relações pessoais não somente de trabalho, mas também de amizade que forneceram suporte mútuo, companheirismo, bem como o senso de pertencer à uma comunidade de aprendizagem a distância.

248 3.4 Feedback mais rápido O tempo de resposta dos formadores a uma mensagem era um aspecto muito importante para os alunos, principalmente no início do curso em que houve várias dificuldades operacionais (sobrecarga do servidor, inexperiência em aprender a distância e em utilizar o TelEduc, etc.). Dada a pequena duração do curso e dos prazos para entrega de atividades, alguns participantes chegavam a enviar várias mensagens num curto intervalo de tempo ou mesmo telefonar em busca de seus formadores. Na maioria dos casos os recados eram transmitidos por correio eletrônico, mas em outros foi possível atender mais rapidamente um grupo, pela interação entre formadores via comunicador: F1: estou falando [no telefone] com cuiaba F2: pestalozzi ou APAE? F1: pestalozzi F2: é minha! se quiser, pede pra ligar aqui em casa! 3289**** F1: estou passando F2: obrigada! Com o tempo, alguns alunos sabiam em qual horário poderiam encontrar um formador online e dessa maneira aproveitavam para tentar receber uma resposta a uma questão em aberto: A: blz. Vcs receberam o recado da pest de Itap hj? F: qual recado, dependendo da hora eu não estava no curso. Da mesma forma, apesar de solicitado que todas as dúvidas fossem compartilhadas nos Fóruns, alguns alunos encontravam os formadores online para tirar dúvidas por preferirem a interação síncrona: Preferia (e prefiro) ele ao fórum e correio pq nele podia estar em contato, tinha resposta imediata as minhas dúvidas O contato via ICQ também foi útil para os formadores conseguirem algumas informações que não eram obtidas por outras formas de comunicação (por exemplo, mensagens não respondidas no Correio) e que eram importantes para direcionar novas etapas do curso. Um exemplo foi a interação com uma participante que fornecia informações sobre as demais colegas de grupo que pouco interagiam no curso. Estas tinham pouca familiaridade com computadores e, ao mesmo tempo em que realizavam o curso a distância, estavam participando de um curso presencial de Introdução à Informática. Por meio das conversas pelo ICQ era possível averiguar como prosseguia o desenvolvimento daquelas pessoas. Essas informações eram importantes para delinear o perfil dos participantes que estavam realizando o curso e tomar providências para uma nova versão do mesmo. 4. Considerações Finais Este estudo foi desenvolvido a partir de reflexões sobre o oferecimento de cursos via Web, principalmente sobre a comunicação entre participantes, já que é por meio dela que haverá interação, trocas de experiências e compartilhamento de conhecimentos. A experiência com EaD até o momento tem mostrado que há pouca interação entre os alunos que ainda interagem na maioria das vezes apenas com os formadores. Isto leva a um questionamento sobre como escolher, integrar e para quê utilizar cada ferramenta de comunicação em um curso a distância (Moran, 2000). Certamente o desenvolvimento de um software para apoiar

249 as atividades de uma comunidade de aprendizagem influenciará na comunicação e interação dos participantes de um curso (Preece, 2000). Assim, o TelEduc tem passado por redesigns que buscam aprimorar suas funcionalidades a fim de prover recursos que possibilitem as tarefas a serem realizadas em cursos a distância, bem como a interação social que ocorre entre seus participantes. Pôde-se notar que a possibilidade de ver as pessoas que estavam online pelo ICQ pareceu estimular o contato entre as pessoas. Sem dúvida este foi um meio que assegurou, em muitos casos, outro espaço de encontro virtual, favorecendo o surgimento de novas relações e elos sociais (Haythornthwaite, 1998) que resultaram em ações colaborativas. Em cursos via Web, cada vez mais se propõe atividades em grupo como uma forma de estimular a interação entre todos. E dependendo do perfil dos participantes, tem-se notado que é importante dispor de ferramentas síncronas de comunicação, principalmente porque a realização de atividades desse tipo requer, geralmente, argumentação que se constitui ao longo de uma conversação (Rocha et al., 2001). Para isto, alguns aspectos importantes são privacidade, velocidade na troca de mensagens e possibilidade de trocar arquivos. No curso observado, grande parte das pessoas que utilizaram o ICQ era formada por aqueles que tinham conhecimento prévio dessa ferramenta, sendo que muitos não chegaram a se cadastrar no servidor do programa. Para estes houve várias dificuldades: inexperiência com instalação e configuração de programas, ser uma ferramenta em idioma Inglês e também aprender a utilizá-la num curto período de tempo. Para minimizar essas dificuldades, já está em desenvolvimento uma nova ferramenta para o TelEduc que será ativada sem muitos conhecimentos técnicos, com um clique do mouse de maneira semelhante as demais. Nessa ferramenta pretende-se fazer ligação direta entre a representação do usuário e o seu respectivo Perfil, o que eliminará o cadastro no ICQ e facilitará bastante a decisão de iniciar ou não um contato. Isto será útil principalmente no início de um curso, momento em que todos ainda estão se conhecendo. Uma característica que precisa ser pensada cuidadosamente é a manutenção ou não dos registros da interação que acontecerá por essa ferramenta. Na concepção de design do TelEduc toda interação que ocorre pelas ferramentas de comunicação é registrada e pode ser analisada com o auxílio da ferramenta InterMap, que auxilia os formadores no acompanhamento dos alunos, dando-lhes subsídios para decidir a melhor hora e forma de intervir (Romani, 2000). Se o registro é mantido, mantemos o design do TelEduc consistente. Por outro lado, apesar da ferramenta InterMap não apresentar o conteúdo de mensagens particulares como do Correio, não se sabe como isto afetará a interação dos participantes nesta ferramenta, já que eles estarão cientes de que o registro é mantido e há meios computacionais de recuperá-lo. Nesse caso o usuário perderia a confiança no sistema e não utilizaria suas ferramentas para comunicar com seus colegas aquilo que lhe é de caráter reservado. Esta será uma questão de análise relevante ao trabalho. A intenção de oferecer uma ferramenta de comunicação instantânea no TelEduc não é reproduzir as mesmas funcionalidades de um ICQ, principalmente porque se constatou que a nova ferramenta deve ter um conjunto reduzido de funcionalidades para que estas possam ser usadas por pessoas inexperientes em recursos computacionais. Assim, por exemplo, a

250 troca de arquivo de maneira privada por essa ferramenta, em um primeiro momento, não fará parte desse conjunto de funcionalidades. No entanto, a necessidade verificada desta funcionalidade está remetendo a outras mudanças no ambiente de forma a atender a necessidade que grupos ou pares formados espontaneamente no decorrer de um curso têm de elaborar suas atividades de maneira privada. Nesse caso o Portfólio, que atualmente possibilita o não compartilhamento de um conteúdo, ou compartilhá-lo com Todos ou somente com Formadores, deveria possibilitar a escolha de com quem especificamente se deseja compartilhar um item. Isto por conseqüência, e por razões de consistência, tenderia a modificar as demais ferramentas que utilizam opções de compartilhamento. Nota-se portanto, que a inclusão dessa nova ferramenta trará implicações de design das demais e da concepção do espaço TelEduc como um todo. Por fim, o desenvolvimento dessa ferramenta aponta para outra questão mais abrangente a respeito da presença de pessoas em um ambiente de EaD. Além de saber quem está online em um determinado momento e qual seu perfil, que atividades essa pessoa está realizando? Isto leva ao conceito de awareness que, apesar de não possuir definição única, de maneira geral se refere à habilidade do usuário manter algum conhecimento sobre a situação e atividades dos demais (Liechti e Sumi, 2002). Nessa direção, existem alguns ambientes (Tapped in, 2002) que configuram o espaço virtual de aprendizagem de maneira gráfica e o usuário navega, por exemplo, da sala de café para a biblioteca e dessa forma vai encontrando outras pessoas que estão nesses "locais". Referências Bickmore, T. e Cassel, J. (2001) Relational Agents: A Model and Implementation of Building User Trust. ACM CHI 2001 Conference Proceedings, Seattle, Washington, 2001 Harasim, L.; Hiltz, S. T.; Teles, T.; Turoff, M. (1996) Learning networks: a field guide to teaching and learning online. Cambridge: MIT Press, 329p. Haythornthwaite, C. A (1998) Social Network Study of the Growth of Community Among Distance Learners. In: IRISS, Bristol, UK. Em rede: [Consulta: 25/04/2001] Haythornthwaite, C. A (2000) Online personal networks: seize, composition and media use among distance learners. New media and Society (2) 2 p Em rede: [Consulta: 03/05/2002] Kim, A. J. (2000) Community building on the Web - Secret for successful online communities. Berkeley: Peachpit Press. 360 p. Kollock, P. (1998a) Social Dilemmas: The Anatomy of Cooperation. Annual Review of Sociology. n. 24, p Kollock, P. (1998b) Design Principles for Online Communities. Annual Review of Sociology. PC Update 15(5): June 1998 Em rede:

251 Liechti, O. e Sumi, Y. Editorial: Awareness and the WWW. International Journal of Human Computer Studies. Vol. 56, No. 1, January 1, Em rede: [Consulta em: 09/05/2002] Maingueneau, D. (1998) Termos-chave da Análise do Discurso. Belo Horizonte, MG: Editora da UFMG, 155 p. Moran, J. M. (2000) Ensino e Aprendizagem Inovadores com Tecnologias. Em rede: [Consulta em: 30/06/2001] Oeiras, J. Y. Y. e Rocha, H. V. (2000) Uma modalidade de comunicação mediada por computador e suas várias interfaces. In: WORKSHOP SOBRE FATORES HUMANOS EM SISTEMAS COMPUTACIONAIS, 3, 2000, Gramado. Anais... Porto Alegre: Instituto de Informática da UFRGS, p Preece, J. (2000) Online Communities - Designing Usability, supporting sociability. Chichester: John Wiley & Sons, 439 p. Rocha, H. V.; Oeiras, J. Y. Y.; Freire, F. M. P.; Romani, L. A. S. (2001) Design de ambientes para EaD: (re)significações do usuário, In: WORKSHOP DE INTERFACE HUMANO-COMPUTADOR, 4, 2001, Florianópolis. Anais... Florianópolis: UFSC, SBC, p Romani, L. A. S.; Rocha, H. V.; Silva, C. G. (2000) Ambientes para educação a distância: onde estão as pessoas? In: WORKSHOP DE INTERFACE HUMANO- COMPUTADOR, 3, 2000, Gramado. Anais... Porto Alegre: Instituto de Informática da UFRGS, p Romani, L. A. S. (2000) InterMap: Ferramenta para visualização da Interação em Ambientes de Educação a Distância na Web. Campinas: Instituto de Computação da UNICAMP. 120 p. (Dissertação, Mestrado em Ciência da Computação). Suguri, V.; Matos, L.; Castro, N.; Castro, I.; Jung, L. M.; Rusten, E. (2002) Pedagogical uses of web-based chat - A pilot Activity in Brazil. TechKnowLogia, January - March em rede: www. TechKnowLogia.org [Consulta em: 04/03/02] Tapped in (2002) Online workplace of an international community of education professionals. Em rede: [Consulta em: 09/05/2002] Timms, D.; Ferlander, S.; Timms, L. (2001) Building Communities: Online Education and Social Capital. In: SZUCS, A.; WAGNER, E. & HOLMBERG, C. (Org.) Learning Without Limits: Developing the Next generation of Education. Proceedings of the EDEN 10 th. Anniversary Conference held in Stockholm. Budapest: EDEN. P Em rede: [Consulta em: 04/03/02]. Valente, J. A. (1999) Mudanças na Sociedade, Mudanças na Educação: O Fazer e o Compreender. In: VALENTE, J. A. (Org.) O computador na sociedade do conhecimento. Campinas: UNICAMP/NIED, cap. 2, p

252 Uso de agentes de interface para adequação de bate-papos ao contexto de educação a distância José Cláudio Vahl Júnior 1, Janne Yukiko Yoshikawa Oeiras 1, Heloísa Vieira da Rocha 1 1 Instituto de Computação Universidade Estadual de Campinas (UNICAMP) Caixa Postal Campinas SP Brasil {jose.junior, janne, heloisa}@ic.unicamp.br Abstract. During a lot of experiences about TelEduc in distance courses in many areas we could notice that there is a comum environment but a lot of diferents contexts and objectives about a specific course, and because of this, their tools must be redesigns to end up in a personalized task about each user. This article describes how the technology of interface agents have been used to offer flexibility on tools of chat in these environment Resumo. Ao longo de várias experiências de uso do TelEduc em cursos a distância das mais diversas áreas, nota-se que apesar desse ambiente ser geral, existem contextos e objetivos que são específicos de cada curso e por essa razão suas ferramentas têm sido redesenhadas a fim de permitir que o usuário as personalize de acordo com a tarefa que deseja realizar. Este artigo descreve como a tecnologia de agentes de interface tem sido usada para dar flexibilidade a ferramenta de Bate-papo desse ambiente. 1. Introdução O desenvolvimento de ambientes computacionais de apoio às atividades de Educação a Distância (EaD) via Web, em um primeiro momento, basicamente tinham seu foco centrado no design de tecnologias para criar, apresentar e dispor de forma cada vez melhor o conteúdo de um curso (Romani et al., 2000). Ao longo do tempo, nota-se que o redesign desses ambientes tem sido necessário para mediar e suportar a interação social entre os participantes de um curso. A interação social é importante para o desenvolvimento de uma comunidade de aprendizagem, e para apoiar as tarefas que serão realizadas pelos participantes. Em muitos cursos via Web são propostas atividades que envolvem a discussão sobre algum tema como uma forma de estimular o levantamento de questões e a troca de idéias, a comunicação dinâmica, a aprendizagem e a cooperação entre todos. Algumas experiências em cursos semi-presenciais e a distância usando o ambiente TelEduc 1, mostraram a dificuldade dos usuários em utilizar principalmente as ferramentas de comunicação desse ambiente que, em suas primeiras versões, foram incorporadas sem considerar o novo contexto, o educacional, ao qual elas iriam pertencer. 1

253 Na literatura, um estudo sobre a interface de cinco programas de Bate-papo (Oeiras e Rocha, 2000) conclui que não se pode consagrar um formato para um determinado tipo de comunicação e passar a usá-lo em todos os contextos, pois novas interfaces precisam ser propostas de acordo com a tarefa e a sua população de usuários. Certamente, o design de um software para apoiar as atividades de uma comunidade de aprendizagem influenciará a comunicação e a interação de seus membros (Preece, 2000). Assim, um dos desafios no (re)design de ambientes para EaD tem sido o desenvolvimento de ferramentas de comunicação adequadas para situações de ensinoaprendizagem. Portanto, novas funcionalidades vêm sendo adicionadas ao TelEduc para prover recursos que possibilitem a realização de algumas tarefas em cursos a distância, bem como a interação social que ocorre entre seus participantes. Neste trabalho é apresentado o (re)design de uma das ferramentas de comunicação do ambiente TelEduc: o Bate-papo. Para isso está sendo utilizada a tecnologia de agentes para recriar a interface dessa ferramenta, bem como suas funcionalidades. Na seção 2 é descrito o Bate-papo atual do TelEduc. A seção 3, define conceitos da tecnologia de agentes e na seção 4 são apresentadas as propostas de novas modalidades para esta ferramenta. Por fim, a seção 5 apresenta as considerações finais deste trabalho. 2. A ferramenta atual de Bate-papo Como será visto a seguir, o Bate-papo, como está atualmente implementado no ambiente TelEduc, é semelhante a outros programas de bate-papo comumente encontrados na Web (por exemplo, Essa ferramenta permite conversas síncronas e textuais em um curso, sendo executada diretamente pelo próprio navegador (browser). Geralmente no contexto educacional uma sessão é agendada previamente como uma forma de convidar todos participantes e estabelecer o melhor horário para esse encontro. Dessa forma, o TelEduc permite que os formadores agendem uma sessão de Bate-papo de acordo com as necessidades da turma (Figura 1). Figura 1: Agendamento de uma sessão de Bate-papo

254 Para entrar no Bate-papo, o usuário deve se identificar fornecendo seu nome ou apelido em uma nova janela. Ainda, nessa janela, tem-se a informação sobre quantos participantes já estão presentes em uma sessão de conversa (Figura 2). Figura 2: Página de entrada do Bate-papo Ao clicar no botão "Entrar" o usuário é levado ao espaço para conversas. As mensagens enviadas são visualizadas na forma de uma seqüência de frases, uma após a outra, na vertical e as mais recentes aparecem na parte inferior da tela. Ao enviar uma mensagem, pode-se escolher o destinatário e a entonação que será dada à mensagem como se ela fosse comunicada oralmente: fala para, pergunta para, concorda com, desculpa-se com, etc. (Figura 3). Figura 3: Sessão de Bate-papo As conversas que ocorrem pelo Bate-papo são registradas na base de dados do TelEduc e qualquer participante do curso tem acesso a esses registros que podem ser impressos ou salvos como arquivos HTML. Isso tem se mostrado bastante proveitoso

255 para posterior análise ou conhecimento do conteúdo da discussão quando não se pôde participar de uma sessão (Figura 4). Figura 4: Escolha de um registro de sessão A utilização do Bate-papo em cursos a distância tem revelado algumas dificuldades para a realização de muitas atividades, principalmente as atividades que envolvem discussão de algum tema específico. A representação seqüencial de mensagens propicia o aparecimento de diversos problemas relacionados à administração de discurso como, por exemplo, o controle de turno (Oeiras e Rocha, 2000). Vários participantes podem enviar mensagens simultaneamente, ocasionando o rompimento de controle de turno e resultando em tópicos paralelos. Assim, torna-se complexo acompanhar uma discussão, pois surgem diversos "fios de conversa" e é necessário que o usuário faça, mentalmente, as ligações coesivas entre os enunciados de um mesmo fio (McCleary, 1996). No formato atual do Bate-papo, como foi visto, é necessário o controle explícito do usuário quanto à escolha da entonação e do destinatário das mensagens. Em versões anteriores, uma pessoa podia escolher uma entonação e o nome do destinatário que estes ficavam selecionados até que o usuário decidisse mudá-los. Isso potencializava o envio errado de mensagens para um interlocutor que as recebia sem compreender o contexto. O remetente então deveria corrigir esse erro enviando uma nova mensagem comentando que esta se destinava a outra pessoa. Esse problema foi atenuado na versão atual do TelEduc fazendo com que as opções de entonação e destinatário sempre voltem ao padrão "falar para" e "Todos", respectivamente, após o envio de uma mensagem. Tal fato pôde ser constatado em alguns cursos em que os usuários mostraram-se menos preocupados com a entonação e também passaram a utilizar a estratégia de citar o

256 interlocutor na sua mensagem mesmo que tivessem, ou não, escolhido o seu nome na lista: (10:19:53) Francisca fala para Todos: Gislane, tudo bem? como você está realizando essas tarefas? Aqui nós estamos com muita dificuldade. (...) (10:21:51) socorro alves fala para Raquel: Oi Raquel ontem conseguimos bater um papo gostoso. Foi legal. Conversamos com a Helena e outra pessoa que não lembro o nome. A palavra "Todos" associada a um nome no corpo da mensagem parece ter reduzido esse problema porque assim todas pessoas lêem tal mensagem e tanto o destinatário quanto os demais participantes saberão a quem se destina. Isto é diferente da maneira anterior quando uma mensagem era enviada a um destinatário específico e por essa razão, apesar da mensagem ser pública, nem todos atentavam para ela. As mensagens trocadas pelo programa são totalmente públicas e isso decorre da concepção de design adotada em que a sala de bate-papo seria um ambiente similar ao da sala de aula presencial: todos "ouvem" o que se fala, não existindo salas reservadas e cochichos devem ser evitados. Além dessas alterações, a nova versão do Bate-papo utiliza cores para diminuir o esforço cognitivo do usuário em reconhecer, dentre tantas mensagens que são enviadas simultaneamente, aquelas que lhe são destinadas. Sempre que um destinatário é selecionado, o programa apresenta a mensagem na cor azul para este e na cor verde para quem a enviou. As demais são representadas na cor preta. A implementação dessas características têm facilitado a utilização da ferramenta em cursos a distância. Porém, ao tentar realizar uma atividade discursiva sobre algum tema de interesse de um curso, a conversa acaba tomando rumos diferentes em que os participantes se distraem e perdem o contexto da discussão. Portanto, tem sido um fato mais que constatado que, quando se quer realizar atividades síncronas para discussão o design atual da ferramenta de Bate-papo não é adequado. Devido principalmente aos diversos "fios de conversa" que se formam pela possibilidade de envio simultâneo de várias mensagens pelos participantes, o esforço mental do usuário é alto ao tentar acompanhar uma discussão pelo Bate-papo. Assim, utilizando a tecnologia de agentes, que descrevemos brevemente na próxima seção deste artigo, um (re)design dessa ferramenta tem sido realizado a fim de poder adaptá-la para a realização de atividades educacionais. 3. Agentes de Interface Na literatura computacional ainda não há uma definição formal para o termo agente. Segundo Franklin e Graesser (1996), mesmo entre os pesquisadores envolvidos com trabalhos referentes a agentes existem diversas definições desse termo. Essas definições estão normalmente associadas a diferentes pontos de vista e dependem muito da funcionalidade fornecida pelo agente em questão (Costa, 1999). No contexto deste trabalho a palavra agente será utilizada para referenciar um componente de software capaz de agir e realizar tarefas autonomamente para o usuário, buscando alcançar um conjunto de metas. Algumas propriedades (Wooldridge e Jennings, 1994) que um sistema deve possuir para ser considerado um agente são:

257 Autonomia: funcionar sem intervenção humana, baseando suas ações em seu conhecimento armazenado sobre o ambiente em que atua (ex. Internet). Habilidade Social: interagir com outros por meio de uma linguagem comum. Reatividade: ser capaz de perceber mudanças em seu ambiente e atuar de acordo com essas mudanças. Pró-Atividade: não deve apenas atuar por percepção, mas deve procurar alcançar uma meta apresentando iniciativa. Existem também outros atributos menos relevantes que poderíamos considerar relacionados de alguma forma aos já citados como: Mobilidade, relacionada principalmente com agentes que buscam informações na Internet; Cooperação, ligada à habilidade social do agente; Comunicabilidade, comunicação com outros agentes ou humanos; Aprendizagem, principal característica dos agentes inteligentes, etc. Embora um agente não precise possuir todas essas características ou atributos, suas habilidades e capacidades estão diretamente associadas a elas. De acordo com Nwana (1996) podemos identificar os seguintes tipos de agentes: Agentes Colaborativos: cooperam com outros agentes para realizar as tarefas para seus donos. São utilizados, por exemplo, em problemas muito grandes para um único agente centralizado resolver e para prover soluções para problemas inerentemente distribuídos. Agentes de Interface: aprendem para realizar tarefas para seus donos. Ajudam o usuário observando suas ações e imitando-as; ou recebendo um feedback positivo ou negativo sobre essa reprodução; ou aprendem por meio de instruções explícitas do usuário; ou ainda pedindo conselho a outros agentes. Agentes Móveis: são capazes de percorrer WANs (Wide Area Networks) como a Web, interagindo com diferentes hosts, capturando informações em benefício de seu usuário e voltando assim que realizaram as suas tarefas. Alguns benefícios do uso deste tipo de agente são redução dos custos de comunicação, computação assíncrona, coordenação simples e uma arquitetura flexível e distribuída. Agentes de Informação/Internet: surgiram devido à demanda por ferramentas que auxiliassem a gerenciar o crescimento explosivo de informações na Web. Realizam a gerência, manipulação e coleta de informações de várias fontes distribuídas. A grande quantidade de atributos relacionados a agentes ajuda a perceber que seria muito difícil implementar um agente que incorporasse todos aqueles atributos. Até porque essas características são dependentes do tipo de aplicação a que ele se propõe (Costa, 1999). Neste trabalho serão destacados os Agentes de Interface, também conhecidos como assistentes pessoais. Esse tipo de agente exerce uma missão (busca um objetivo) bem definida e endossada pelo humano. Costa (1999) afirma que os Agentes de

258 Interface enfatizam a autonomia e o aprendizado para executarem tarefas para seus donos, atuando normalmente em background. Os Agentes de Interface descritos neste artigo estão sendo usados para atuar da forma que um ser humano agiria na coordenação de um bate-papo em um contexto educacional. Sabemos como funcionam diferentes mecanismos de coordenação de discussões síncronas de acordo com a categoria (seminário, assembléia, painel, etc.). E novas formas podem ser inventadas ou surgirem de uma mistura de outros mecanismos. Sem dúvida, isso é passível de ser ensinado a um agente. A idéia de usar agentes para essa tarefa de coordenação é tentar ver a viabilidade do uso dessa tecnologia, advinda da área de Inteligência Artificial, como forma de facilitar e personalizar, devido a flexibilidade que sua utilização dá a um componente de software, muitas das ações de um ambiente de EaD. Na próxima seção estaremos descrevendo os novos formatos do ambiente de Bate-papo que estamos implementando. 4. Novos modelos para bate-papos educacionais Como já afirmado anteriormente, era clara a necessidade de se implementar formas de coordenação no sistema de Bate-papo. A partir dessa constatação e da escolha justificada da tecnologia de agentes para implementar os mecanismos, foi iniciado o processo de coleta de formatos adequadas de coordenação. E a partir de sugestões de usuários e uma análise da literatura (Harasim, 1996) foram escolhidos três formatos iniciais que, como poderá ser observado, são a transposição de esquemas geralmente adotados em ambientes presenciais. 4.1 Seminário Este tipo de atividade é previamente agendada (hora, data e duração) e existe um assunto pré-definido, do qual todos os participantes devem estar a par (Figura 5). Normalmente a discussão é baseada em algum material disponibilizado para leitura e conduzida por um grupo responsável. Figura 5: Tela de agendamento de uma sessão

259 A Figura 6 apresenta a interface deste modelo. A tela é dividida em 3 partes: a parte superior identifica a pauta do seminário; a parte do meio é dividida em duas sendo uma a que apresenta as mensagens e a outra a fila de espera; por fim a parte inferior, também dividida em duas, apresenta no lado esquerdo as funções para escolher a entonação, destinatário e escrever a mensagem e no lado direito o link para o material auxiliar (caso haja) e o nome dos responsáveis pelo seminário (com um link para o seu Perfil 2 ). Figura 6: Interface do modelo Seminário Neste modelo, como em seminários reais, apenas os responsáveis pelo seminário podem enviar mensagens para todos os participantes. As perguntas feitas pelo público geral para esses responsáveis serão submetidas aos seguintes critérios definidos para a moderação: Tempo: aquele que está há mais tempo sem falar tem maior prioridade; Quantidade de frases: quem falou menos até o momento tem maior prioridade; Réplica: aquele que estiver respondendo para alguém recentemente terá maior prioridade. Esses critérios definem as diretrizes que o Agente seguirá para gerenciar a fila de espera e publicar as mensagens enviadas inicialmente em todos os modelos propostos. O agente reconhece as mensagens submetidas pelos responsáveis pelo seminário e as publica imediatamente (privilégio deste tipo de participante). 2 O Perfil é uma ferramenta do TelEduc usada por um participante de um curso para fazer sua apresentação aos demais colegas de maneira bastante pessoal, colocando sua foto, dizendo quem é, do que gosta, o que faz, etc.

260 4.2 Assembléia Neste modelo, o número de participantes normalmente é maior que no seminário e a pauta mais abrangente, envolvendo a tomada de alguma decisão. Em uma assembléia, todos os participantes tem os mesmos privilégios. É usada uma metáfora de levantar a mão, que eqüivale a clicar em um outro botão próximo ao de Enviar na interface (Figura 7). Nesse momento o nome do usuário é inserido na fila de espera de acordo com os critérios definidos para o Agente. Enquanto estiver esperando por sua vez de falar, o participante poderá escrever a mensagem que deseja comunicar. Quando estiver na primeira posição da fila este participante terá um tempo pré-definido para escrever sua mensagem ou enviar sua mensagem previamente elaborada. Há também a possibilidade de clicar no botão Sair da fila para desistir de falar. Seguindo a metáfora de uma assembléia real, neste modelo, a princípio, todos os participantes sempre falam para todos, não havendo a possibilidade da troca de entonação e destinatário através da interface. 4.3 Painel É semelhante ao modelo de assembléia referido anteriormente, porém com menor número de participantes e vários responsáveis pelo painel. As mensagens são do público para os responsáveis, sendo possível a escolha de um específico ou "Todos". Também é usada a metáfora de levantar a mão para pedir a palavra, porém, os responsáveis pelo painel possuem privilégios de prioridade e suas mensagens são avaliadas pelo Agente de forma diferenciada e publicadas imediatamente. A parte direita da tela mostra, na parte superior, a fila de espera pela vez de falar e na parte inferior um link para o material auxiliar (quando houver) e para a lista de responsáveis pelo painel, também com referências para seus respectivos Perfis (Figura 7). Figura 7: Interface do modelo Painel

261 O modelo de Bate-papo atual não será eliminado do TelEduc, podendo sofrer um redesign para permitir que seja configurado o número de participantes em cada sessão. Essa mudança é necessária em função de não haver nenhum tipo de estruturação ou coordenação neste programa, e percebe-se que com um grande número de participantes torna-se difícil acompanhar a conversa de forma produtiva. Isto poderia auxiliar o encontro de pequenos grupos de trabalho, por exemplo. Os modelos apresentados nesta seção foram definidos previamente e o uso de agentes se deu para que esses modelos possam ser (re)inventados dando a ferramenta a flexibilidade desejada em um ambiente educacional. O usuário pode personalizar um desses modelos a fim de escolher quais critérios o agente aplicará às mensagens e qual peso será atribuído. O peso é utilizado como uma forma de desempate. Por exemplo, dois participantes enviam suas mensagens ao mesmo tempo. O "participante A" falou mais vezes e está há mais tempo sem falar que o "participante B". Então se o agente estiver configurado para que o peso da quantidade de frases seja superior ao peso do tempo sem falar, o participante B terá prioridade pois falou menos vezes. 5. Considerações finais A área de EaD tem sido foco de inúmeras pesquisas. Com o surgimento de novas tecnologias, muito se tem avançado no aspecto do desenvolvimento de materiais pela ampla e diversificada utilização de diferentes mídias (Oliveira, 2001). O benefício que se obtém dessas mídias depende, entre diversos fatores, do quão interativas e adaptáveis elas serão. A tendência, portanto, é tornar as ferramentas mais adaptáveis e adequadas a usos diferenciados. Para isso, os novos desenvolvimentos têm buscado o apoio de conhecimentos gerados em outras áreas de pesquisa como o campo da Inteligência Artificial. A teoria de Agentes vem sendo utilizada em outros projetos (Johnson e Shaw, 1997; Jacques, 2000) como uma forma de criar ferramentas que sejam adaptáveis às necessidades dos participantes, apoiar a interação entre eles e facilitar a autoria de cursos. Em relação ao ambiente TelEduc, além do uso de agentes na implementação de novos modelos de Bate-papo, há outras linhas de pesquisa que buscam usá-los no desenvolvimento de ferramentas que auxiliem formadores no processo de avaliação contínua (Otsuka e Rocha, 2002), que é realizada por meio do acompanhamento das contribuições do aluno no curso. Nessa linha, as pesquisas concentram-se no estudo de ferramentas que facilitem o acompanhamento e análise do grande volume de dados gerado pelas ações dos alunos nos cursos. Os agentes de software atuarão observando e aprendendo com os professores, procurando fornecer auxílio flexível e personalizado às necessidades de cada professor. Ainda no escopo de apoio à avaliação contínua, está sendo desenvolvido um sistema baseado em agentes de interface para o suporte à análise e seleção de mensagens relevantes em sessões de bate-papo. Outras ferramentas do TelEduc deverão sofrer redesign em função das novas formas de coordenação. Entre essas está a Intermap, uma ferramenta de visualização que usa os registros do Bate-papo para mostrar graficamente as interações ocorridas durante uma sessão. Dados extras precisarão ser avaliados pela Intermap para espelhar as modificações no Bate-papo, como quem foram os participantes especiais (responsáveis pelo painel ou pelo seminário, etc.), como foi conduzida a coordenação em determinado modelo, em qual modelo a participação é maior, dentre outros.

262 Ao longo de várias experiências de uso do TelEduc em cursos a distância das mais diversas áreas, conclui-se que apesar desse ambiente ser geral, existem contextos e objetivos que são específicos de cada curso e por essa razão suas ferramentas têm sido redesenhadas a fim de permitir que o usuário as personalize de acordo com a tarefa que deseja realizar. Isso é que nos leva a experimentar agentes de interface. Referências Costa, M. T. (1999) Uma Arquitetura Baseada em Agentes para Suporte ao Ensino à Distância. Em rede: [Consulta: 03/05/2002] Franklin S. e Graesser, A. (1996) Is it an Agent, or just a Program? A Taxonomy for Autonomous Agents. In: Proceedings of the Third International Workshop on Agent Theories, Springer-Verlag. Em rede: AgentProg.html [Consulta: 01/05/02] Harasim, Linda (1996) Learning Networks: A Field Guide to Teaching and Learning Online. The MIT Press - Cambridge, Massachusetts - London, England. Haythornthwaite, C. A (1998) Social Network Study of the Growth of Community Among Distance Learners. In: IRISS, Bristol, UK. Em rede: [Consulta: 25/04/2001] Jacques, P. (2000) Um Experimento com Agentes de Software para Monitorar a Colaboração em Aulas Virtuais. Workshop de Informática na Escola. Johnson, W. L. e Shaw, E. (1997) Using Agents to Overcome Difficulties in Web-Based Courseware. AI-ED'97 Workshop on Intelligent Educational Systems on the World Wide Web, August. Em rede: [Consulta: 01/05/02] McCleary, L. E. (1996) Aspectos de uma modalidade mediada por computador. São Paulo: Faculdade de Filosofia, Letras e Ciências Humanas USP. (Tese, Doutorado em Semiótica e Lingüística Geral). Nwana, H. (1996) Software Agents: An Overview. Knowledge Engineering Review, Vol. 11, N. 3, pp e , September. Em rede: agents/introduction/ao.ps [Consulta: 01/05/02] Oeiras, J. Y. Y. e Rocha, H. V. (2000) Uma modalidade de comunicação mediada por computador e suas várias interfaces. In: WORKSHOP SOBRE FATORES HUMANOS EM SISTEMAS COMPUTACIONAIS, 3, 2000, Gramado. Anais... Porto Alegre: Instituto de Informática da UFRGS, p Oliveira, José Palazzo M. (2001) AdaptWeb Ambiente de Ensino-Aprendizagem Adaptativo na Web. Em rede: [Consulta: 01/05/02] Otsuka, J. L; Rocha, H.V. (2002) Análise do processo de avaliação contínua em um curso totalmente a distância. In: Virtual Educa 2002 (a ser publicado), Valença, Espanha. Preece, J. (2000) Online Communities - Designing Usability, supporting sociability. Chichester: John Wiley & Sons, 439 p.

263 Romani, L. A. S.; Rocha, H. V.; Silva, C. G. (2000) Ambientes para educação a distância: onde estão as pessoas? In: WORKSHOP DE INTERFACE HUMANO- COMPUTADOR, 3, 2000, Gramado. Anais... Porto Alegre: Instituto de Informática da UFRGS, p Valente, J. A. (1999) Mudanças na Sociedade, Mudanças na Educação: O Fazer e o Compreender. In: VALENTE, J. A. (Org.) O computador na sociedade do conhecimento. Campinas: UNICAMP/NIED, cap. 2, p Wooldridge, M. e Jennings, N. R. (1994) Intelligent Agents: Theory and Practice. Submitted to the Knowledge Engineering Review. Em rede: [Consulta: 01/05/02]

264 Uso de Agentes de Interface no Suporte à Análise de Sessões de Bate-Papo Ricardo Luís Lachi, Joice Lee Otsuka, Heloisa Vieira da Rocha Instituto de Computação Universidade Estadual de Campinas (Unicamp) Caixa Postal 6176 CEP: Campinas SP Brasil {ricardo.lachi, joice, Abstract. This paper presents the researches that have been developed in order to provide a new design to TelEduc, a supporting environment for distance education, focusing on adaptive support to formative assessment. It presents the initial results obtained in this research line by means of constructing a tool based on agent s interface technology. This tool helps selection of commentaries in chats log of TelEduc according to interests of every teacher in each teaching and learning context. Resumo. Neste artigo são apresentadas as direções das pesquisas desenvolvidas para prover um (re)design no ambiente de suporte à Educação à Distância TelEduc, com enfoque no apoio adaptativo à avaliação formativa. São apresentados os primeiros resultados obtidos nesta linha de pesquisa, por meio do desenvolvimento de uma ferramenta baseada em agentes de interface, que auxilia a seleção de comentários de registros de sessões de bate-papo do TelEduc, de acordo com os interesses de cada professor. 1. Introdução Atualmente existe uma busca por mudanças no paradigma de avaliação, a fim de que a avaliação deixe de ser um instrumento de verificação da aprendizagem para atuar diretamente no processo de ensino-aprendizagem, de forma contínua, ao longo de todo o processo. Segundo Cerny (2001), o grande avanço que se coloca hoje para a avaliação é constituirse como parte do processo de ensino-aprendizagem, permeando e auxiliando todo este processo, não mais como uma atividade em momentos estanques e pontuais. É uma busca por uma avaliação formativa, que segundo Perrenoud (1999), pode ser entendida como toda prática de avaliação contínua que pretenda melhorar as aprendizagens em curso, contribuindo para o acompanhamento e orientação dos alunos durante todo seu processo de formação. É formativa toda a avaliação que ajuda o aluno a aprender e a se desenvolver, que participa da regulação das aprendizagens e do desenvolvimento no sentido de um projeto educativo. Nos cursos à distância também existe uma busca por métodos de avaliação on-line que possibilitem a avaliação formativa do aluno. E no contexto da EaD esta forma de avaliação ganha relevância ainda maior por possibilitar a percepção do comportamento do aluno e favorecer a identificação de problemas. Por ser contínua, a avaliação formativa

265 permite também alguma forma de autenticação da identidade do aluno, pela familiarização com o estilo e habilidades do mesmo. Com os ambientes de suporte à EaD baseados na web foram introduzidas novas possibilidades à EaD e à avaliação a distância. Ambientes de Ead como o TelEduc 1, possuem ferramentas de comunicação projetadas para facilitar tanto a interação como a posterior análise de registros destas interações. Dessa forma, todo o processo de aprendizagem do aluno é continuamente registrado, gerando uma massa de informações passível de análise, de onde podem ser obtidos dados relevantes para a avaliação formativa. No entanto, apenas o registro das interações não é suficiente para prover suporte efetivo à avaliação formativa. Esse processo de avaliação demanda muito trabalho e tempo do professor no acompanhamento, análise e orientação das atividades desenvolvidas ao longo do curso, o que consiste num dos principais problemas da avaliação formativa, seja ela presencial ou à distância. Novas tecnologias computacionais (tais como os agentes de software, a mineração de dados e a visualização de informações) vêm sendo pesquisadas, a fim de explorar melhor os registros das interações dos alunos em ambientes de EaD e prover suporte para o professor na coleta, identificação, seleção e análise de dados relevantes à avaliação formativa. Neste artigo são apresentados os primeiros resultados das pesquisas que vêm sendo desenvolvidas para prover um (re)design no TelEduc, com enfoque no suporte à avaliação formativa. Dessa forma, a seção 2 apresenta a direção dessas pesquisas e uma visão dos principais projetos em andamento nesta linha de pesquisa. Na seção 3 é apresentada uma ferramenta baseada em agentes de interface, desenvolvida para diminuir a sobrecarga do professor na análise de registros de sessões bate-papo do TelEduc. Finalizando, na seção 4 são apresentadas algumas considerações finais e a seção 5 contém as referências bibliográficas. 2. A caminho de soluções para apoiar a avaliação formativa no TelEduc Atualmente, a avaliação formativa no TelEduc pode ser realizada por meio do acompanhamento dos registros das ferramentas de comunicação do ambiente (Fórum de Discussões, Bate-Papo, Correio, Mural, Portfólio e Diário de Bordo). No entanto, apesar do TelEduc possibilitar o registro de todas interações dos alunos ao longo do curso, essas informações ainda são pouco exploradas no auxílio à avaliação formativa. A fim de facilitar a análise de dados quantitativos das participações do aluno no curso, foram desenvolvidas duas ferramentas: Acessos e InterMap. A ferramenta Acessos permite a geração de relatórios sobre os acessos dos alunos ao curso ou às ferramentas do mesmo, e a ferramenta InterMap utiliza técnicas de visualização de informações para mapear 1 O Teleduc é um ambiente de EaD que vem sendo desenvolvido desde 1997 por pesquisadores do Instituto de Computação da Unicamp, em parceria com o NIED. O TelEduc é um software livre e está disponível em

266 as interações realizadas, facilitando a visualização das participações dos alunos (Romani, 2000). As pesquisas que vêm sendo desenvolvidas no Projeto TelEduc 2 no escopo de avaliação, têm como foco principal facilitar a análise de dados qualitativos das participações dos alunos. Dessa forma, estão sendo desenvolvidos três projetos: um projeto de (re)design das ferramentas do Teleduc, que visa facilitar o registro das avaliações realizadas ao longo do curso, bem como a posterior recuperação, consolidação e análise dos dados destas avaliações; um sistema baseado em agentes de interface para o suporte à análise e seleção de mensagens relevantes em sessões de bate-papo; e um projeto que engloba os dois projetos anteriores, na tentativa de prover suporte efetivo às principais funções desempenhadas pelo professor no processo de avaliação online formativa (Otsuka e Rocha, 2002 ; Otsuka, Lachi, Ferreira e Rocha 2002 ). Espera-se, com estes trabalhos, prover auxílio ao professor extraindo das interações registradas, as informações relevantes à sua avaliação. É importante notar que a relevância de uma informação pode variar de acordo com o professor e também com o contexto e os objetivos específicos de cada curso. Portanto é necessária a adoção de uma solução flexível, que possibilite um apoio adaptável às necessidades e interesses de cada professor nos mais variados contextos. A fim de prover uma solução flexível, estamos desenvolvendo pesquisas de suporte à avaliação formativa empregando a tecnologia de agentes de software. Agentes são entidades de software que atuam de forma contínua e autônoma em um determinado ambiente, sendo capazes de intervir no seu ambiente, de forma flexível e inteligente, sem necessidade da constante orientação humana (Bradshaw, 1997). Mais especificamente, estão sendo usados agentes de interface, que são aqueles que aprendem observando e monitorando as ações dos usuários em uma interface, e atuam como assistentes pessoais, colaborando com o usuário e com outros agentes na realização de determinadas tarefas (Maes, 1994). Na próxima seção é apresentado um dos primeiros resultados obtidos nessa linha de pesquisa, uma ferramenta baseada em agentes de interface, desenvolvida para diminuir a sobrecarga do professor na análise de registros de sessões bate-papo do TelEduc. 3. Agente de seleção de comentários em sessões de bate-papo A ferramenta de Bate-papo, como concebida originalmente, é uma ferramenta de comunicação síncrona informal, isto é, não tem grande estruturação 3 nem restrições nos comentários enviados por meio dela. Essa característica faz com que a interação se dê de forma natural e informal, tendo em vista que é relativamente não-planejada, ou seja, a construção da interação vai sendo planejada e re-planejada a cada novo lance do jogo A única estruturação presente nos comentários dos bate-papos é com relação a existência do nome da pessoa que enviou o comentário (remetente), da pessoa que recebeu o comentário (destinatário) e à da entonação da fala ( pergunta para, fala para, etc), além do próprio texto do comentário. Ex.: José pergunta para Maria: Que dia é hoje?

267 da linguagem (Dionísio, 2001), diferentemente do que, provavelmente, aconteceria se a opinião do participante fosse postada via uma ferramenta de comunicação como o Correio ou Fórum de Discussões. Essa naturalidade e informalidade na conversação permitem aos participantes de uma sessão de bate-papo dar uma vazão maior às suas idéias o que, conseqüentemente, se reproduz em um número enorme de comentários. Quando usada no contexto da EaD, a ferramenta de bate-papo acaba originando uma grande sobrecarga para o professor, uma vez que ele tem que analisar todos os comentários realizados em uma sessão de bate-papo para poder avaliar adequadamente as contribuições dos alunos. A fim de diminuir a sobrecarga do professor na análise de sessões de bate-papo realizadas no ambiente TelEduc, foi desenvolvida uma ferramenta baseada na tecnologia de agentes de interface, que possibilita a seleção automática de comentários de acordo com os interesses do professor. Nas subseções seguintes são apresentadas as principais características da ferramenta em questão. A subseção 3.1 apresenta o re(design) do registro das sessões de bate-papo, realizado a fim de possibilitar que um usuário selecione os comentários de seu interesse e justifique a seleção. A subseção 3.2 apresenta as formas de aprendizagem do agente de interface e a seção 3.3 mostra algumas opções de configuração do agente Interface para seleção de comentários A ferramenta de Bate-Papo do TelEduc, como dito anteriormente, gera um registro com todos os comentários de uma sessão de bate-papo realizada. A interface original desse registro (Figura 1) possibilita apenas a visualização do conjunto de comentários de uma sessão, não sendo possível a seleção de comentários pelo usuário. Figura 1 -Visualização do registro de uma sessão de bate-papo

268 Dessa forma, foi realizado um (re)design do registro das sessões (Figura 2), a fim de possibilitar a seleção de comentários pelo usuário e indicação dos critérios da seleção. Na nova interface é apresentada uma tabela com duas colunas onde, na primeira coluna aparecem os comentários enviados pelos participantes e, na segunda, o estado de cada um deles: Sim para os comentários selecionados e Não para os não-selecionados. Além disso, foi colocado um cabeçalho na primeira linha da tabela indicando o conteúdo das duas colunas evitando que o usuário tenha que memorizar os seus significados. Na primeira vez em que se visualiza o registro de uma sessão de bate-papo, todos os comentários estão no estado Não (não selecionado). Nesse momento, o usuário pode começar a selecionar os comentários que considerar importante, clicando sobre o link de status Não. Figura 2 Interface que possibilita a seleção de comentários do registro de uma sessão de bate-papo Ao clicar no link de status Não, é aberta uma janela de seleção de comentário (Figura 3), contendo o comentário que está sendo selecionado e os critérios (seleção pelo nome do remetente, pela entonação da fala, pelo nome do destinatário e/ou pelas palavraschave presentes no comentário) passíveis de serem indicados como causa da seleção. Esses critérios foram levantados a partir da observação de análises de sessões de bate-papo efetuadas por diversos professores, em situação real de cursos. Durante essa observação foram coletados os principais motivos indicados por esses professores na seleção dos comentários. A partir dos dados coletados foram definidos os critérios mencionados. Nessa janela de seleção de comentário, a caixa de edição das palavras já é preenchida com o texto do comentário no intuito de diminuir o trabalho do usuário. Além disso, é possível indicar como o agente deve entender o relacionamento entre as palavras. Se o agente deve selecionar comentários que apresentem exatamente as mesmas palavras indicadas marca-se a opção contém exatamente ou, se o agente deve procurar por comentários que possuam

269 qualquer uma das palavras indicadas, marca-se a opção contém. Essa característica é análoga a existente nas ferramentas tradicionais de busca. Figura 3 Janela de indicação dos critérios de seleção de um comentário O feedback da seleção de um comentário é dado pela mudança do estado do comentário para Sim. Se o usuário clicar sobre o status Sim de um comentário, é aberta uma janela contendo informações sobre o autor da seleção e os motivos da sua seleção. Nesta mesma janela são apresentadas as opções de cancelamento da seleção e de edição dos critérios da seleção (Figura 4). Figura 4 Janela de indicação dos critérios de seleção de um comentário

270 A partir da observação da interação do usuário com a interface apresentada, o agente de interface aprende os critérios de seleção do usuário. A qualquer momento o usuário pode solicitar que o agente analise uma sessão, selecionando a opção Analisar (Figura 2). Na subseção seguinte são apresentados os métodos de aprendizagem do agente Aprendizagem do Agente O agente de interface desenvolvido possui duas formas de aprender os interesses do usuário na seleção dos comentários de uma sessão de bate-papo: pela observação e pelo feedback do usuário. Nas próximas subseções são apresentadas essas duas formas de aprendizagem Aprendizagem por observação Esta forma de aprendizagem ocorre antes do agente efetuar qualquer análise dos comentários de uma sessão. Nessa fase, o usuário seleciona um certo conjunto de comentários e indica, para cada comentário, os critérios que o levaram a fazer a seleção. Durante o processo de seleção do usuário, o agente vai observando os critérios indicados para cada comentário selecionado. A cada seleção do usuário, o agente atribui um peso a cada um dos critérios indicados na seleção, em função da freqüência com que aparecem nos comentários já selecionados pelo usuário. Esse conjunto de critérios e seus respectivos pesos são usados, pelo agente, na construção do perfil do usuário. O perfil do usuário é usado na análise dos comentários de uma sessão pelo agente. Nessa análise, o agente calcula o peso de cada comentário para decidir se este deve ser ou não selecionado. Esse peso é calculado pela soma dos pesos de todos os critérios presentes na sua base de conhecimentos que também constem do comentário analisado. Vale ressaltar que é possível pedir para o agente analisar uma sessão a qualquer momento, mesmo antes do usuário selecionar algum comentário da sessão para o agente observar. No entanto, nas primeiras sessões analisadas, o agente não terá muitos subsídios para poder decidir sobre a seleção ou não de algum comentário da sessão. A medida que o agente vai observando o usuário em análises de várias sessões de bate-papo de um mesmo contexto de curso, o agente consegue refinar o perfil do usuário e torna-se capaz de fornecer resultados mais efetivos na seleção de comentários relevantes ao usuário Aprendizagem via feedback do usuário Esta forma de aprendizagem ocorre após a análise de uma sessão de bate-papo pelo agente. Ao finalizar a seleção dos comentários de uma sessão de bate-papo o agente apresenta os resultados para o usuário (Figura 5). Nesse momento, o usuário pode começar a revisar a seleção feita pelo agente, ou seja, o usuário pode marcar comentários não selecionados pelo agente e/ou cancelar seleções realizadas pelo agente. Por meio desse processo, o agente aprende quais os comentários que selecionou de forma errada, refinando o perfil do usuário. Dessa forma, o resultado final da análise de uma sessão de bate-papo é um conjunto de comentários selecionados tanto pelo usuário quanto pelo agente (Figura 5). A fim de facilitar a identificação da procedência de cada seleção, os comentários selecionados foram destacados com dois tons de cinza (um cinza claro identificando comentários do agente e um

271 cinza escuro identificando comentários do usuário). Uma legenda é acrescida para evitar a necessidade de memorização dessa associação. Também são apresentados o número total de comentários da sessão, o número de comentários selecionados e o de comentários não selecionados (Figura 5). E, a fim de facilitar a visualização de sessões com muitos comentários, foi criada uma opção onde o usuário pode optar pela apresentação de todos os comentários ou somente os comentários selecionados. Figura 5 Design final da visualização do registro de uma sessão de bate-papo analisada pelo agente Na próxima seção são apresentadas algumas opções de configuração do agente, oferecidas para possibilitar a apresentação de resultados efetivos de forma mais rápida Configuração direta do agente Como se pôde constatar na subseção anterior é necessário que o agente possua em sua base de conhecimentos um certo número de comentários corretamente selecionados para poder começar a ser efetivo na seleção dos mesmos. Passar esse conjunto inicial de comentários para o agente implica em esforço direto para o usuário. Visando diminuir um pouco esse esforço foi criada uma interface que permite a configuração de três características do agente: autonomia, seleção rápida e múltiplas visões (Figura 6). Nas próximas subseções essas características são descritas e explicadas detalhadamente.

272 Figura 6 Configurando o comportamento do agente Seleção rápida A partir da análise de sessões de bate-papo realizadas via TelEduc em situações reais de curso, pôde-se observar que a maioria das mensagens postadas é direcionada para os professores dos cursos a distância. Isso decorre do fato de que, apesar de todas as tentativas no sentido de diminuir o papel do professor de ser um centralizador do conhecimento, este ainda se faz sentir de forma marcante nos cursos presenciais ou ministrados à distância. Com base nisso, surgiu a idéia de dar ao participante a possibilidade de selecionar rapidamente todos os comentários de uma sessão que fossem relacionadas diretamente com um professor (mensagens recebidas e enviadas por ele). Uma extensão direta da idéia anterior foi a implementação da possibilidade de seleção também dos comentários enviados e recebidos por algum participante do curso e não só de um professor. Outra extensão implantada foi a da seleção de todos os comentários que apresentem uma determinada entonação de fala, por exemplo: Selecionar todos os comentários que tem a entonação de fala pergunta para. Neste caso, comentários do seguinte tipo são selecionados: Autonomia José pergunta para Maria: Como vai? Outra possibilidade de configuração do agente é na forma como ele utilizará os dados armazenados na sua base de conhecimentos para efetuar a seleção dos comentários relevantes para cada participante. Há duas opções disponíveis: configurar o agente para agir de forma autônoma ou não-autônoma (Figura 6). Essas opções permitem configurar que informações da sua base de conhecimentos o agente levará em consideração para decidir sobre a seleção ou não de um comentário.

273 Se estiver marcada a opção não autônomo, o agente somente levará em consideração os critérios presentes na sua base de conhecimentos que tiverem sido indicados pelo usuário quando da seleção, por este, de um comentário. Caso contrário (opção autônomo), o agente também utilizará na sua análise os critérios que ele próprio adicionou à base de conhecimentos como decorrência de análises de sessões de bate-papo realizadas anteriormente. Há vantagens e desvantagens nas duas opções. Na opção não autônomo o agente apresenta um comportamento mais preciso na hora de selecionar um comentário, uma vez que, somente seleciona os comentários baseado em critérios extraídos a partir de comentários selecionados pelo próprio usuário. No entanto, isso acaba fazendo com que o usuário tenha que alimentar o agente com um grande número de palavras (necessário um grande treinamento do agente) até que ele possa começar a apresentar resultados satisfatórios. Já a segunda opção, embora leve menos tempo (menor esforço para treinar o agente), ela pode levar a resultados menos precisos pois o agente utilizará na sua análise palavras armazenadas na sua base de conhecimentos que foram adicionadas por conta própria e que, portanto, podem não representar exatamente o perfil do usuário Múltiplas visões Uma outra característica implementada no agente é a possibilidade de compartilhá-lo com outros participantes, isto é, permitir que um outro participante do curso possa ver com a visão de um agente que não seja o seu. Esquematicamente essa opção poderia ser representada da forma como é mostrada na Figura 7. Nessa figura, o agente do participante A está olhando o conjunto de comentário selecionados de uma sessão de bate-papo cuja seleção foi efetuada pelo agente do participante B. Sessão Agente do participante A Agente do participante B de bate-papo Figura 7 - Esquema de visões Para permitir que a visão de seu agente seja compartilhada, um usuário deve selecionar a opção compartilhar agente com (Figura 6). Nesta opção é possível indicar com quais participantes do curso deseja-se compartilhar a visão do agente. Uma vez que define-se o compartilhamento do agente com algum outro participante, este passa a ter a possibilidade de visualizar a visão do seu agente 4. 4 É permitido visualizar, simultaneamente, as visões de diferentes usuários ( múltiplas visões ).

274 Na visualização de análises compartilhadas o nome do dono da visão é apresentado no canto superior da janela, a fim de facilitar a sua identificação (Figura 8). A característica de múltiplas visões abre algumas possibilidades interessantes, como por exemplo, o compartilhamento da visão do agente do professor com os alunos do curso. Isso permite que os alunos observem os comentários selecionados pelo professor, dando um feedback do que está sendo observado e avaliado. 4. Considerações Finais Figura 8 Visão do participante Formador Atualmente existe uma grande busca pela avaliação formativa, no entanto, o uso deste paradigma de avaliação ainda esbarra em problemas, como a sobrecarga de tarefas para os professores e, conseqüentemente, um alto custo de implantação. Nesse contexto, o grupo de pesquisas do projeto TelEduc tem desenvolvido trabalhos que visam explorar melhor os dados das interações dos alunos, que são totalmente registrados no ambiente e dessa forma prover suporte ao professor na identificação, seleção e análise de dados relevantes à avaliação formativa. A fim de se ter uma solução flexível, que possibilite um apoio adaptável às necessidades e interesses de cada professor em cada contexto, estão sendo desenvolvidas pesquisas de suporte à avaliação formativa empregando a tecnologia de agentes de software. Neste artigo foram apresentados os primeiros resultados obtidos nessa linha de pesquisa, a partir do desenvolvimento de uma ferramenta de auxílio à análise de sessões de bate-papo. A solução adotada baseia-se na tecnologia de agentes de interface, que atuam observando a interação de cada usuário com a interface de seleção de comentários, e a partir desta observação, aprendem os critérios de seleção de cada usuário.

275 Testes preliminares com a ferramenta, realizados fora da situação real de curso, apontam bons resultados quanto à filtragem de informações relevantes e à adaptação destas aos objetivos específicos de cada contexto e usuário. Alguns destes resultados são apresentados em (Otsuka, Lachi, Ferreira e Rocha, 2002) e mostram que a tecnologia de agentes de interface se aplicou bem ao problema da seleção de comentários de sessões de bate-papos em ambientes de EaD. Isso ocorreu mesmo sendo o bate-papo, a ferramenta de comunicação menos estruturada do TelEduc. O desafio da análise de uma sessão de bate-papo é, justamente, o fato desta ferramenta não apresentar estruturas que auxiliem na seleção de comentários relevantes, tais como, as encontradas em outras ferramentas (por exemplo, na ferramenta Correio, o conteúdo do campo assunto normalmente dá uma dica sobre o teor do conteúdo da mensagem). Por isso, os resultados positivos obtidos com esta ferramenta apontam para a extensão da aplicação do agente para as outras ferramentas do ambiente. A próxima fase deste trabalho é a integração da ferramenta ao ambiente TelEduc e a realização de testes em situação real de curso. 5. Referências Bibliográficas Bradshaw, J. M. An Introduction to software Agents. In: Bradshaw, J. M. (Ed.). Software Agents. Massachussetts: MIT Press Cerny, R.Z. Uma reflexão sobre a avaliação formativa na educação a distância. UFSC, Dionísio, A. P. (2001) Análise da Conversação. In: MUSSALIM F. e BENTES, A. C. (Org.) Introdução à Lingüística: Domínios e Fronteiras. São Paulo, SP: Cortez. V.2, cap.3, p Maes, P. Agents that Reduce Work and Information Overload. Communications of the ACM. 37(7), Otsuka, J. L.; Lachi, R. ; Ferreira, T.; Rocha, H. V. Suporte à Avaliação Formativa no Ambiente de Educação à Distância TelEduc. In: VI Congresso Iberoamericano de Informática Educativa ( a ser publicado), Vigo, Espanha, Otsuka, J. L; Rocha, H.V. A caminho de um modelo de apoio à avaliação contínua. In: VIII Workshop de Informática na Escola 2002, XXII Congresso da SBC, Florianópolis,2002. Perrenoud, P. Avaliação: da excelência à regulação das aprendizagens entre duas lógicas. Porto Alegre: Artes Médicas, Rocha, H. O ambiente TelEduc para Educação à Distância baseada na Web: Princípios, Funcionalidades e Perspectivas de desenvolvimento. In: Moraes, M.C. (Org). Educação à Distância: Fundamentos e Práticas. Campinas, SP:Unicamp/Nied, 2002, pp Romani, L. Intermap: Ferramenta para Visualização da Interação em Ambientes de Educação a Distância na Web. Dissertação de Metrado, IC/Unicamp, dez 2000.

276 Software Educacional e Diálogo Entre Usuários: Um Modelo De Avaliação Flávia Peres¹, Luciano Meira² ¹Departamento de Psicologia e Orientação Educacional - CE - UFPE ²Pós-Graduação em Psicologia Cognitiva UFPE Recife-PE flaviapr@npd.ufpe.br, lrlmeira@npd.ufpe.br Abstract. This study focuses the collaborative actions created by users during the symbolic mediation of the educational software. We suggest that an interpretative primary unit based on conversational analysis indicates the mechanisms of the interaction between software and user, and some strategies to elaborate a dialogue-based educational software evaluation. These strategies integrate the characteristics of the interface design (principles and guidelines) as well as the process of the learning among students. Resumo. Este estudo focaliza suas atenções nas ações colaborativas construídas pelos usuários durante a mediação de um software educacional. Sugerimos que uma unidade de análise baseada na análise da conversação indica os mecanismos da interação usuário-software, e possibilita algumas estratégias para a elaboração de uma avaliação de software educacional centrada no diálogo, a qual possibilita integrar características do design da interface (princípios e guidelines) com o processo da aprendizagem dos alunos. 1. Fundamentação Teórica Muitas pesquisas sobre tecnologias da informação aplicadas à educação apontam para novos métodos e possibilidades para a aplicação de recursos informatizados que aparecem como importantes mediadores entre a criança e o conhecimento (Schuartz, 1997; Snir, Smith & Grosslaine, 1997; Noss, 1997). Kaput (1994), por exemplo, discute várias possibilidades de utilização do software educacional como mídia singular no uso de múltiplas representações para o desenvolvimento de conceitos científicos em crianças. Assim, as escolas, em suas atividades pedagógicas com a utilização de mediadores como esse, vêm apropriando-se dos softwares com o objetivo de favorecer o processo de aprendizagem. Definimos software educacional como uma classe de ferramentas computacionais cujo enfoque está nos conceitos específicos e nas situações locais para o ensino, que cada vez mais ganha espaço na escola para a construção de significados. Mas, decorrente desta prática, uma preocupação crescente e que tem motivado vários estudos centraliza suas atenções no aperfeiçoamento da avaliação de software educativo (Caftori e Paprzycki, 1999; Schuartz, 1997; Valente, 1998) e geralmente guia-se a partir de um conjunto compreensivo de parâmetros e questões destinadas à verificação da qualidade "educacional" do mesmo. Muitos dos critérios utilizados por essas propostas advém da teoria do processamento da informação e dos estudos sobre o design, priorizando o olhar sobre as

277 características da interface dos ambientes informatizados. Em sentido restrito, podemos considerar interface como o ponto de mediação entre as duas partes - usuário e computador -, capaz de tornar uma sensível à outra. É portanto uma relação semântica, caracterizada pela possibilidade de fazer com que a máquina represente a si mesma para o usuário, numa linguagem compreensível. A interface "traduz" a linguagem da computação (estabelecida em código binário, composta de zeros e uns) a fim de tornar possível a comunicação com o universo humano através de imagens, palavras, sons e associações. 1.1 O lugar da interface na comunicação homem-máquina Shneiderman (1997) aponta para algumas medidas centrais a serem levadas em conta e dizem respeito aos fatores humanos implicados no processo de uso de um ambiente informático: tempo para aprendizagem; rapidez no desempenho; razão de erros; retenção ao longo do tempo; satisfação subjetiva. É fundamental considerar para qualquer aplicação a grande diversidade de habilidades humanas, as diferentes formações, motivações, personalidades e estilos que requerem portanto alterações no design de programas interativos. Considerar esses aspectos é respeitar o desenvolvimento sócio-histórico e cultural dos usuários e reconhecer que as habilidades perceptuais e cognitivas para interpretar os símbolos e as representações, bem como para desempenhar complexas ações frente a um sistema informático, depende da inserção daqueles em um dado contexto (Werstch, 1985; Vygotsky, 1991; Valsiner, 2000). Reconhecer essa diversidade de indivíduos possibilita o entendimento sobre o usuário "pretendido" ou destinatário superior - apenas para mencionar Bakhtin (1997) - permitindo a inclusão do mesmo em um quadro global que deve levar em conta: nacionalidade, idade, gênero, habilidades físicas, educação, formação ética e cultural, motivação, personalidade, etc. Bakhtin nos aponta que "o autor de um enunciado, de modo mais ou menos consciente, pressupõe um superdestinatário superior (o terceiro), cuja compreensão responsiva absolutamente exata é pressuposta seja num espaço metafísico, seja num tempo histórico afastado" (p. 356). De qualquer forma, alguns teóricos indicam regras gerais - Golden rules of interface design (Shneiderman, 1997) - a serem respeitadas para o design de interfaces, as quais são aplicáveis a muitos sistemas interativos, podendo ser cada uma interpretada, refinada e estendida para variados ambientes. Essas regras são abarcadas por alguns princípios e guidelines sugeridos por Mandel (1997). Os princípios de design de interface referem-se aos conceitos, idéias e crenças que guiam e/ou orientam o design de software. Escolhe-se quais são os princípios mais adequados para aplicação em determinado sistema, com um objetivo específico, e também para o estabelecimento dos guidelines. Os guidelines recomendam os cursos específicos da ação, baseados em um grupo de princípios. São mais específicos que os princípios e também menos abstratos, requerendo menos conhecimento em design e experiência para interpretá-los. As grandes operadoras de sistema como a Apple, a Microsoft, a IBM, entre outras, têm seus guidelines, seus princípios e materiais de referência publicados, de modo a exemplificar e especificar sua perspectiva em design de interface, o que nos indica o quanto esses fatores são importantes para a área. Embora existam especificidades relacionadas a cada uma dessas operadoras - como pudemos observar

278 através da leitura dessa publicação da IBM (2001) - seus princípios e guidelines encontram-se dentro das três grandes áreas de princípios descritas por Mandel (1997): Controle sobre o sistema pelo usuário; Redução da carga de memória do usuário; Consistência. Estes estudos vão estabelecer que apenas os princípios de design não garantem uma interface de software amigável e interativa satisfatoriamente. São os guidelines que permititem a criação de elementos, o estabelecimento de suas aparências e características adequadas a uma boa interação. São eles que definem o modelo da apresentação, comportamento e interação possíveis através dos elementos e objetos presentes na interface. Os guidelines podem ser físicos, sintáticos e semânticos. Os físicos são aqueles aplicados à porção do hardware como teclado, mouse, etc. Por exemplo: No IBM (2001) encontramos que o botão 1 do mouse é o botão para seleção enquanto que o botão 2 serve para manipulação. Os guidelines sintáticos referem-se às regras sobre a apresentação da informação na tela e a seqüência e ordem de execução das ações do usuário. Por exemplo, para sair de um determinado programa o usuário deve seguir alguns passos pré-estabelecidos numa ordem lógica. Os guidelines semânticos referem-se ao significado dos elementos, objetos e ações na interface. Por exemplo o botão iniciar tem uma ação esperada pelo usuário, de acordo com o próprio significado da palavra usada, que remete o usuário à idéia de início para disparar um determinado evento. Estes são pontos de extrema relevância a serem considerados numa observação de ambientes computacionais, que ganham peso maior quando cuidadosamente ponderados em relação ao contexto de utilização. No entanto, as práticas em si merecem tornar-se objetos da análise cognitiva, visto que toda ação possui um conteúdo semântico, e que as ações têm influência devido ao significado que adquirem em contextos sócio-culturais diversos (Meira, 1996). Em relação à educação, segundo podemos perceber, a atenção a esses pontos é então ainda mais urgente uma vez que é através da interface que acontecerá a mediação entre a criança e o conhecimento, dizendo respeito não apenas aos signos próprios ao design do ambiente, mas também à representação do conceito na mesma. 1.2 Avaliando interfaces educativas Verificando estudos mais recentes na área educacional, encontramos alguns como os desenvolvidos pelos pesquisadores da TERC (Murray, Mokros e Rubin, 1998; Corwin e Storeygard, 1995), que revisam vários jogos eletrônicos interessados em como as crianças interagem com tais jogos e que matemática elas aprendem a partir dos mesmos. Estas pesquisas buscam desenvolver alguns critérios para avaliação de software, enfatizando um olhar ao diálogo das duplas durante o uso, influenciando portanto a idéia que direciona a nossa proposta. Pesquisas como estas evidenciam a necessidade de analisar os softwares durante o uso, em contextos específicos, sendo somente a partir de uma análise desse tipo que as sutilezas referentes à aplicabilidade de um software tornam-se nítidas. Analisando a usabilidade - enquanto processo de uso de determinados ambientes - os fatores relevantes relacionados ao indivíduo, suas estratégias de ação e os processos cognitivos de que se valem em tal aplicação tornam-se também passíveis de verificação e análise. Com um outro enfoque, mas considerando também o artefato em seu momento de uso, alguns estudos têm centrado sua atenção na forma como as pessoas interagem

279 com os artefatos culturais na vida diária, em situações sociais significativas, onde ao lidarem com os mesmos demonstram competência funcional, resolvendo problemas e mobilizando conceitos e esquemas. A parte da ergonomia que se ocupa do desenvolvimento de tais padrões, ambientes e interfaces homem-máquina, de modo a tornar tais interações mais "amigáveis" (no sentido de proporcionarem uma maior facilidade no seu uso), é a Ergonomia Cognitiva. Trabalhos como os de Brown e Duguid (1996) destacam a importância de "pistas periféricas" aos artefatos, as quais dão auxílio direto aos usuários pela evocação de conteúdos socioculturais. Trabalhos semelhantes são realizados desde 1970 por antropólogos e cientistas da computação na Xerox Palo Alto Research Center (PARC) que desenvolvem um programa de pesquisa interdisciplinar concentrado no design de tecnologias digitais etnograficamente baseadas. Defendem que para o entendimento de tecnologias é necessário um olhar etnográfico, requerendo a localização de artefatos dentro de ambientes específicos e considerando as suas relações de uso diário (Suchman, Bolmberg, Orr et All, 1999). Dentro desse campo, portanto, percebemos que já existe o início de uma psicologia de "objetos" e "materiais" (Norman, 1988), a qual centraliza seu foco de análise na affordance dos objetos. Materializado nesse sentido, o termo affordance refere-se às qualidades próprias e atuais dos objetos, ou seja, aquelas características fundamentais que determinam como as coisas podem ser usadas. Dessa forma, o usuário vem ganhando mais evidência e atenção no instante da elaboração dos aparatos tecnológicos, onde podemos conectar essas idéias com os estudos desenvolvidos na área de design, influenciando a elaboração dos princípios e guidelines já descritos. Buscando uma ligação entre a estruturação de um conceito na interface de um programa e os processos cognitivos que se formam e ganham significado durante a ação mediada pelos instrumentos culturais e pela linguagem, algumas pesquisas têm dado um passo a mais nessa direção e influenciaram ainda mais diretamente o nosso trabalho, como é o caso de uma pesquisa desenvolvida por Roschelle (1995). Naquela pesquisa, o autor tratou da questão das trocas conceituais convergentes através da análise microgenética de um caso onde duas estudantes estavam engajadas no uso de um software. O software usado foi o Envisioning Machine, apresentado como um ambiente de simulação voltado aos conteúdos da física, diretamente aos conceitos de velocidade e aceleração. Como a análise de Roschelle vai mostrar, as alunas realizaram troca conceitual de seus conhecimentos prévios, compartilharam significado e construíram cooperativamente o entendimento do conceito de aceleração. A idéia central nos estudos de Roschelle é que a interação conversacional possibilita que os estudantes construam colaborativamente aproximações entre conceitos científicos. Baseia-se na Análise da Conversação, a qual tem identificado as estruturas conversacionais para a interação face-a-face, e que habilitam os participantes a construírem, monitorarem e repararem o conhecimento compartilhado. Em suma, Roschelle argumenta que o principal fator da aprendizagem por colaboração é a convergência, sugerindo que estudantes desenvolvem seus conceitos, no curso da aprendizagem, por participarem de práticas conversacionais que os próprios cientistas necessitam para desenvolver conceitos científicos (Latour e Woolgar, 1997). Em relação ao nosso trabalho, vemos que dois artefatos se sobressaem: o sistema informático (interface) e o conhecimento específico implementado no software (representação do conceito). O relacionamento do usuário com o software(sistema informático e conceito científico) dá-se através da ação ou, melhor ainda, da

280 comunicação (para sublinhar a fundamental mediação da linguagem), que acontece de forma situada. Então propomos que, para verificar a qualidade dessa interação, uma outra contribuição pode ser dada pelos estudos do discurso, como será melhor desenvolvido na seção seguinte, onde a análise da conversação, através de alguns de seus pontos chaves, permitirá apontarmos para uma nova forma de avaliar softwares educativos, de modo a abarcar características da interface que aparecem pontuadas na própria fala dos alunos, interferindo na condução do processo de aprendizagem. 2. Metodologia e Estudo Empírico Estamos fundamentados na concepção de que a ação é mediada e situada, não podendo ser desvinculada do contexto onde emerge. Portanto, levamos em conta os diversos mediadores do processo em estudo para compreender as ações dos sujeitos, idéia que, por sua vez, fundamenta-se na teoria sócio-histórica e nos leva a considerar a dimensão semiótica da atividade humana, sendo mesmo esta dimensão o que está em jogo na presente pesquisa, uma vez que nossos objetivos foram: investigar a construção de significados mediada por um software educacional específico; verificar as ações construídas colaborativamente durante o seu uso; identificar os mecanismos orientadores dos diálogos nessa interação. Focalizamos nossa "lente" para os microprocessos de mudança ocorridos na construção dos diálogos através de um software, que levaram os alunos a discutirem diversos tópicos conversacionais durante o uso daquela mídia. Portanto o foco foram as ações realizadas durante a situação, no sentido de que são estas ações que alimentam o "futuro próximo" do usuário no processo. Para efeito dos objetivos almejados e mantendo-se coerente com a abordagem teórica geral, usamos o registro videográfico e a perspectiva microgenética (Meira, 1994) sobre o fenômeno como estratégias satisfatórias por possibilitarem em conjunto interpretar o processo dinâmico de significação. 2.1 Software usado Calcule! é o nome do software usado ( Luciano Meira & Mundi Kids, 2000), um programa planejado para a escola, com o objetivo de dar apoio principalmente do ponto de vista institucional a um certo número de conceitos, idéias e noções de matemática. Está voltado para a realização de atividades com aritmética por crianças de 4 a a 8 a série do ensino fundamental e pode-se dizer, anterior a uma análise mais apurada, que o software trabalha com formas de representações tradicionalmente usadas na educação escolar, centralizado-se nos conceitos de adição, subtração, multiplicação e divisão. Ao dar início ao programa, automaticamente aparece na tela um personagem que "disponibiliza" um bilhete de identificação (passaporte) onde o nome (login) do usuário deve ser cadastrado. Preenchendo esse cadastro, o usuário já pode escolher, a partir da tela inicial, por qual dos três ambientes deseja começar: Descalculadora, Cripto ou Estima. A) Descalculadora Uma máquina de calcular que requer a construção de estratégias alternativas de resoluções de expressões aritméticas, pois suas teclas são quebradas a cada expressão;

281 B) Cripto - Requer a construção de hipóteses para a descoberta de incógnitas em operações de adição e subtração; C) Estima Ambiente que pretende trabalhar com quantidades numéricas através da estimação do valor de expressões aritméticas. 2.3 Participantes Sendo o programa Calcule! destinado a crianças de 4a a 8a série do ensino fundamental, foi válido verificar como crianças 6a série (média de destinação do software) vieram a construir conhecimento a partir do mesmo, e nos possibilitou verificar a geração de discussões colaborativas na construção de estratégias e hipóteses que particularmente nos interessaram no presente estudo. 4 duplas foram criteriosamente analisadas, constituindo portanto estudos de casos que nos permitiram verificar o que de particular aconteceuna interação das duplas com o Calcule!. 3. Análises e Discussões Seguimos o modelo de análise conversacional detalhado por Marcuschi (1991), segundo o qual a conversação, estruturalmente, consiste numa série de turnos alternados que compõem seqüências a partir de movimentos coordenados e cooperativos. Desse modo, as sentenças são entendidas contextualmente por seu lugar e participação nas seqüências das ações. São essas seqüências e os turnos de fala, mais do que as sentenças isoladas, que interessam à análise da conversação, que vem mostrar que algumas ações conversacionais situam a ação a tal ponto de orientar a fala subseqüente. Ou seja, um turno corrente projeta a próxima ação relevante, ou as futuras trocas de ações a serem complementadas pelo outro, podendo haver rompimento, por parte de um dos falantes, com uma das máximas de Grice (fenômenos denominados implicaturas conversacionais). Portanto, o contexto interacional organiza e orienta as seqüências na estrutura da atividade e as variações seqüenciais referem-se aos caminhos pelos quais os participantes demonstram sensibilidade a esse contexto (Atkinson e Heritage, 1984). Esta visão traz conseqüências metodológicas significativas, pois de acordo com este modelo, a troca de turnos (marcada pela alternância de falantes) e a coerência são os organizadores mais importantes da conversação. Logo esses organizadores nos interessam aqui enquanto processo global que implica interpretação mútua, local e coordenada, uma vez que sem coerência não há interação colaborativa durante o uso do software. Para tanto, temos não no ato da fala nosso foco, mas na localização de uma seqüência de ações dentro da atividade geral, marcada pelas seqüências de turnos e pares adjacentes como pergunta-resposta, ordem-execução, convite-aceitação/recusa, entre outros desses pares que estruturam uma seqüência entre dois turnos co-ocorrentes e servem para a organização local da conversação.no tratamento da coerência entram considerações referentes ao tópico desenvolvido, e embora a variedade de conteúdos possa dificultar o estabelecimento de padrões para a exploração de cada tópico na conversação, é possível descrever a organização dos mesmos, pois eles seguem uma estrutura: para cada conversação há um fio condutor que centraliza a interação em

282 torno de um ponto e que permite, numa conversação fluente, uma certa naturalidade na passagem de um tópico a outro. Há uma convergência da atenção dos participantes para os aspectos relevantes que devem ser falados, constituindo tópicos específicos na seqüência da fala compartilhada. Dentro do paradigma dialógico, há uma responsabilidade mútua na construção de sentido durante a conversação. Na presente pesquisa, portanto, iremos verificar os mecanismos orientadores do diálogo dos usuários e identificar os processos da atividade que estão orientando essa convergência. Logo, verificaremos em que medida a interface está participando dessa interação com vistas a construção de significados específicos. Quando dois parceiros se engajam numa conversação sobre um interesse compartilhado, a negociação de significados tem que acontecer para que ambos façam sentido do tópico. Portanto o que é expresso em uma sentença (seu conteúdo proposicional) somente poderá ser compreendido relacionando-se ao que é conjuntamente pressuposto pelos interlocutores. Então numa colaboração com vistas à construção de significados, parece-nos crucial não apenas a diferença entre Mudança de Tópico e Quebra de Tópico, mas os momentos onde ocorreram e por quê ocorreram tais redirecionamentos. A Mudança de Tópico acontece quando o tópico chegou ao seu final, delimitando seu término. A Quebra, por outro lado, indica a interrupção do tópico, podendo o mesmo retornar em momentos seguintes. Esse ponto foi de fundamental importância para atingir nossos objetivos, pois as quebras e mudanças de tópico percebidas na conversação dos alunos em atividade com o software apontarão para as características da interação mediada, sendo possível indicar as causas e conseqüências da construção dos diálogos com fins educacionais. Para uma melhor categorização desses momentos, achamos adequado considerar dois tipos de organização em relação à Quebra: Subseqüências Encaixadas e Seqüências Alternadas (Stech, 1982, citado em Marcuschi, 1991). Subseqüências Encaixadas ocorrem quando um tópico é introduzido como conseqüência de uma quebra do tópico anterior, podendo então ceder espaço ao retorno para a conclusão do tópico original; Seqüências Alternadas ocorrem quando um tópico é introduzido e gera uma quebra no anterior, havendo uma quebra seguinte de novo tópico, voltando ao anterior sem concluir o segundo, podendo acontecer sucessivas quebras de tópico, sugerindo que os participantes não estão coordenando suficientemente suas contribuições, ou indicando que cada um interessa-se por debater algo diverso. Sendo estabelecida essa distinção, três tipos de Subseqüências Encaixadas são percebidas pelo autor: 1) Subseqüência Encaixada Subordinada: O tópico inserido é parte ou está relacionado com o tópico em andamento; 2) Subseqüência Encaixada Associativa: O tópico encaixado está associado apenas acidentalmente, não contribuindo propriamente ao desenvolvimento do tema geral; 3) Subseqüência Encaixada Formulativa: Os tópicos são introduzidos para indicar como tratar o tema em pauta, especificando-se em como e sobre o que se deve falar em relação àquele ponto. Para capturar a continuidade através das transformações e/ou progressivas diferenciações dos tópicos durante qualquer trecho coerente de análise, temos que examinar as contribuições das ligações dos componentes individuais tanto

283 retrospectivamente quanto prospectivamente: como co-operam e como um tópico proposto é compartilhado e apoiado pelos interlocutores. Tudo isso por entendermos, baseados nesses pressupostos, que a conversação é organizada contribuição por contribuição, mais do que sentença por sentença. Nesse sentido, queremos verificar neste trabalho as ações construídas colaborativamente durante as atividades com um software educacional e as possíveis contribuições de tal mediador para o processo de construção de conhecimento. Considerando essas idéias, podemos já partir de um pressuposto: a forma de estruturar o conceito e representá-lo, de modo a permitir a interação do usuário com o software, pode orientar o desenvolvimento do conceito por determinados caminhos e restringir outros. Caminhos estes que serão reconstruídos quando os significados representados na interface entrarem em contato com as idéias e os significados dos usuários, durante a atividade. Quais os mecanismos que orientam essa construção de significados durante o uso do software? Como se estruturam os diálogos durante essa interação? A análise da linguagem em ação com o uso do software nos permitiu verificar que existem algumas características específicas capazes de favorecer, mais que outras, uma particular interação conversacional com vistas a construção de significados em matemática. Para chegarmos a tais características, centralizamos o olhar para os limites entre as seqüências tópicas na conversação mediada pela representação e estruturação de determinados conceitos matemáticos na interface daquele ambiente informatizado. Isso nos permititu elaborar algumas idéias para a construção de um modelo de avaliação de software educacional fundamentado nos seguintes parâmetros: As subseqüências encaixadas formulativas podem ser momentos necessários do ponto de vista estrutural da tarefa, porque embora não estejam vinculadas ao conceito, dizem respeito a como tratar o tópico e como desenvolver a atividade. Portanto podem servir para organizar as futuras ações e podemos dizer que acontecem principalmente após mudança de ambiente dentro do software ou reconfiguração do nível do usuário e da atividade, indicando uma adaptação do usuário ao novo ambiente. No entanto, se essas quebras são decorrentes da interpretação dos usuários para as características do design da interface, elas não se mostram positivas, pois interferem na fluidez da conversação durante o uso, podendo interromper um processo de trocas conceituais. Por outro lado, caso os momentos de quebra, como percebemos, gerem subseqüências encaixadas subordinadas, de forma que as mesmas se vinculem ao tópico anterior (relativo ao conceito propriamente dito) vemos que estes são os momentos mais ricos para o desenvolvimento conceitual, podendo levar a colaborações advindas das digressões, fundamentais para a construção de sentido. Essas subseqüências subordinadas e as causas que as motivam indicam-nos as características presentes no ambiente computacional que mais interessam aos objetivos da aprendizagem, pois o campo para a convergência de significados é ampliado, podendo gerar intensos momentos de compartilhamento e troca conceitual. Já os momentos de ocorrência de subseqüências encaixadas associativas devem ser cuidadosamente verificados, pois vinculam-se apenas acidentalmente ao tópico em andamento, tanto podendo favorecer como não favorecendo à construção de significados. Se as causas forem decorrentes de princípios de design de interface e guidelines, não as vemos como positivas, porque assim como contribuíram com o desenvolvimento conceitual entre uma dupla específica, poderiam não contribuir com uma outra e, ao contrário, interromper o processo. Porém, se dizem respeito a outras

284 causas: intervenção da pesquisadora, insights dos participantes, etc. estas são positivas, ampliando o espaço simbólico para a introdução de novos significados e convergência conceitual. Seqüências alternadas revelam uma dificuldade de engajamento na tarefa proposta pelo ambiente. Embora possamos admitir que o ambiente de laboratório (e não uma situação em contexto próprio de sala de aula) possa ter desempenhado uma influência para a pouca incidência deste tipo de subseqüência, preferimos fechar o modelo (respaldados pelas considerações advindas das observações sobre os outros tipos de quebra): caso tais seqüências alternadas sejam decorrentes de características do design da interface (princípios e guidelines), indicam-nos que o processo de uso está sendo bastante interrompido por motivos próprios ao software, pois a conversação entre os usuários não está acontecendo de forma fluida e, logo, a interação do usuário com os ambientes está demasiadamente truncada, não sendo a interface do mesmo suficientemente amigável para o desenvolvimento de uma conversação com vista a convergência de significados. Também reforçamos o fato de que se as constantes quebras forem decorrentes de adaptações dos usuários às tarefas, dispersões, falta de concentração ou outras que digam respeito muito mais ao usuário do que ao software, essas causas devem ser ponderadas e analisadas em uma aplicação futura do modelo. Todos esses aspectos reforçam as idéias já discutidas na fundamentação teórica (baseados nos estudos de ergonomia cognitiva e nos princípios e guidelines desenvolvidos) de que algumas regras são fundamentais para uma boa interação sujeitomáquina, mas que é principalmente durante a observação de usuários em atividade que essas características entram em evidência e podem ser identificadas em relação às contribuições das mesmas ao processo de aprendizagem com um software. Se na cena comunicativa o outro é o limite, temos o software como um outro constituinte da interrelação que acontece mediante seu uso, estabelecendo portanto alguns limites à interação. Essas considerações puderam ser verificadas na presente pesquisa, apontando para as conseqüências que cada subseqüência encaixada trouxe para a aprendizagem através de um software educacional e portanto quais os caminhos da conversação mediados pelo software, quais os tópicos desenvolvidos e os vínculos com os conceitos objetivados e a aprendizagem possibilitada por tais ambiente. 4. Considerações Finais Defendemos que os pontos fortes da avaliação baseada no diálogo dizem respeito principalmente à consideração do processo de aprendizagem que tanto leva em conta o sujeito (aluno) quanto o objeto (software), priorizando a relação entre ambos. Esta é uma visão fundamentada em nossa perspectiva teórica, que vai tomar o software enquanto objeto de mediação entre o aluno e o conhecimento. Os estudos em design nos fornecem uma grande quantidade de princípios e guidelines usados como critérios de avaliação de software. No entanto, muitas destas avaliações não verificam as contribuições de cada princípio e guideline para o uso de softwares educacionais pois apenas permitem olhar para o artefato. Tais critérios nos fornecem uma base para tratarmos da interface, base esta já bastante firme dado o nível de desenvolvimento que as interfaces interativas adquiriram, os campos de usos possíveis e as conexões práticas que possibilitaram ao usuário. Porém, vimos que ao

285 analisarmos esses critérios a partir do diálogo, e mais especificamente, das quebras na conversação durante o uso, e dos caminhos tomados pelas seqüências conversacionais, podemos estabelecer as diferenças qualitativas entre os mesmos para diferentes softwares educacionais e suas contribuições para a construção de significados nos determinados campos de conhecimentos visados. Por isso encontramos nos estudos sobre colaboração a possibilidade para o tratamento desses critérios dentro do espaço simbólico gerado na situação de uso, para avaliarmos em que medida tal espaço poderá propiciar a convergência e a troca conceitual. Ou seja, as "forças" dos critérios baseados nos estudos sobre design de interface variam de software para software e a análise da conversação nos permite qualificar tais critérios em relação a suas contribuições educacionais. Vimos que as crianças, enquanto usavam o programa, estavam motivadas por uma atividade altamente complexa que exigia competências específicas tanto ao uso da informática quanto ao domínio de conhecimento ao qual o ambiente estava relacionado (aritmética). Assim, em seus diálogos, os tópicos conversacionais fundamentalmente vinculavam-se ora aos conceitos propriamente pretendidos pelo ambiente, ora às características do design da interface, permitindo avaliar o software sob um duplo olhar que focaliza tanto a colaboração com vistas a construção de conceitos, quanto as características da interface, e, mais ainda, cruza esses dois focos para capturar a relação entre eles. De uma forma geral, o que podemos afirmar a partir desta pesquisa é que o conceito e suas representações em uma determinada tecnologia como o computador - orientam a fala e a colaboração da dupla de usuários em um determinado caminho. Assim, os princípios seguidos na implementação dos conceitos na interface do software devem ter em foco sempre a idéia de que a aplicação volta-se à aprendizagem e portanto o desenvolvimento dos conceitos visados deve ser favorecido ao máximo. Como exemplo desse favorecimento, podemos exemplificar o feedback para acertos e erros do ambiente Estima Aproximação verificado no software Calcule!. Apenas para ilustrar, relembramos que nesse ambiente as respostas dos usuários à tarefa matemática não eram apontadas (como nos outros ambientes) como certas ou erradas, com símbolos específicos para isso em um quadro. À elas, um percentual relativo à margem de erro aparecia naquele quadro, exigindo dos alunos, para compreendê-lo, a necessidade de estabelecer cálculos aproximados, desenvolvendo portanto o conceito de estimação de quantidades objetivado no ambiente, vinculando-o ao conceito de porcentagem e ainda favorecendo a construção de sentido para o que estava sendo trabalhado. Consideramos que os conceitos vinculam-se sempre a outros e não podem ser pensados isoladamente. A metáfora do hipertexto pode mesmo ser usada aqui em relação a tais ligações entre conceitos, uma vez que significações estão em jogo. Ou seja, no hipertexto uma cadeia de significações vai sendo montada, permitindo que o sentido seja remodelado ou reparado a cada novo turno, fruto da interação entre interlocutores. Os nós vão sendo ligados por várias conexões e podem, eles próprios, constituírem hipertextos, levando em conta a rede de conexões semióticas pela qual a mensagem será lançada e capturada. Defendemos, portanto, que os softwares assumem um lugar próprio nessa cadeia de significações pois, no espaço interativo no qual está a atividade situada, a imagem e o som contidos em sua interface adquirem um lugar de quase texto. No entanto, percebemos que um software como o Calcule! não consegue "participar"

286 completamente de alguns momentos de trocas entre os sujeitos (ainda que as orientasse), abrindo lacunas que chamavam por uma terceira participação. Ou seja, mesmo não havendo um professor no local, o modelo aplicado revelou momentos em que, durante o diálogo, as duplas sentiam a necessidade de um Outro, presente no mesmo contexto de fala em que se encontravam. Momentos em que havia a necessidade da presença do professor (se pensarmos na aplicação do software em sala de aula), ou o adulto da relação, que pudesse participar como o outro da conversação e cuja contribuição possibilitasse retornos para reparações, reconstruções e convergência conceitual que o software, por si, não estava conseguindo emitir. As causas dos erros dos alunos muitas vezes se auto-acusavam em suas próprias falas ao resolverem as tarefas. Portanto essas falas apontavam para o raciocínio desenvolvido pelos alunos e para o que necessitavam, durante a ação colaborativa, que colaborasse para que os mesmos contornassem suas dúvidas ou desenvolvessem novos significados compartilhados. Essas evidências eram denunciadas nos atos de fala propriamente ditos (Searle, 1995), indicando o quanto fazemos coisas com as palavras, apenas para mencionar Austin (1965) em seu clássico How to do things with words. Em alguns instantes as duplas sentiam a necessidade de uma participação mais direta e eficiente, do ponto de vista educacional, que favorecesse a colaboração. Na presente pesquisa, alguns desses momentos foram evidenciados quando a pesquisadora assumiu o papel desse outro na relação, na tentativa de desenvolver ações colaborativas ao processo. Em suma, houve demandas comunicativas específicas dos interlocutores que não foram supridas pela interação (face-a-face)-objeto e abriu espaço para um outro, sensível ao contexto de fala dos participantes. Isso no entanto é uma característica que decorre da análise do Calcule!, especificamente, que aparece como um software escolar justamente por abrir espaços como estes. Existem variações na forma como diferentes softwares suprem essas demandas, e percebemos que essas variações remetem às "regras da interface". Reconhecemos que essas idéias permitem pensar em um modelo para avaliação de aplicações educativas, por fornecerem subsídios para focalizarmos a interação usuário-software, relacionando-os não apenas frente ao conceito, mas também ao modo como esse conceito foi implementado na interface. Através da fala dos alunos em conversação durante o uso, pôde-se estabelecer as características da interface que estavam levando ao desenvolvimento conceitual e como estava sendo estruturado esse desenvolvimento. 5. Bibliografia AUSTIN, J. L.(1965) How to do things with words New York, Oxford University Press ATKINSON, J. e HERITAGE, J. (Eds) (1984) Structures of social action: Studies in conversation analysis. Cambridge, UK: Cambridge University Press BAKHTIN, M. (1997) Estética da criação verbal. São Paulo: Martins Fontes BROWN, J. S. and DUGUID, P. (1996) Keeping it simple. In: Terry Winograd (Ed) Bringing design to software ACM Press CAFTORI, N. and PAPRZYCKI, M. (1997) Technology and education annual (Cd- Rom edition), Association for the advanced of computing in education, Charlottesville, V. A. CORWIN, R. B. e STOREYGARD, J. (1995) Talking mathematics In: Hands On! Vol. 18 (

287 IBM Corporation (2001) Object oriented interface design: IBM commom user acess: Basic interface design guide. New York, QUE LATOUR, B. e WOOLGAR, S. (1997) A vida de laboratório - a produção dos fatos científicos Rio de Janeiro: Relume Dumará MARCUSCHI, L. A. (1991) Análise da Conversação São Paulo: Ed. Ática MANDEL, T. (1997) The elements of user interface design John Wiley & sons MEIRA, L. (1994) Análise microgenética e videografia: Ferramentas de pesquisa em psicologia cognitiva In: Temas em Psicologia, 3 (pp 59-71) MEIRA, L. (1996) Atividade algébrica e produção de significados em matemática: um estudo de caso Em: DIAS, MG e SPINILLO, A. Tópicos especiais em psicologia cognitiva, Recife, Ed Universitária UFPE. MURRAY, M., MOKROS, J. and RUBIN, A. (1998) Where's the math in the computer games? In: Hands Oh!, 21 ( NORMAN, D. A. (1988) The Psychology of every day things New York: Basic books NOSS,, R. (1997) Meaning mathematically with computers In: Bryant, P. and NUNES, T. Learning and teaching mathematics na international perspective, Psychology Press Ltda ROSCHELLE, J. (1995) Learning by collaborating: convergent conceptual change In: KOSCHMANN, T. (ed) CSLC: Theory and practice of emerging paradigm. Lawrence Elbaum associates, Inc SCHARTZ, J.L (1997) The rigth size byte: reflections of na educational software designer In: PERKINS, D. N. et al. Software goes to school: teaching for understanding with new technologies, New York: University Press SEARLE, J. (1995) Expressão e significado: estudos dos atos de fala São Paulo: Martins Fontes SHNEIDERMAN, B. (1997) Designing the user interface: strategies for effective human-computer-interation. Addison Wesley Pub Co SNIR, J. SMITH, c AND GROSSLIGHT, L. (1997) Conceptually enhaced simulations: a computer tool for science teaching In: PERKINS, D. N. ET ALL. Software goes to school: teaching for understanding with new technologies, New York: University Press STECH, E. L. (1982) The Analysis of Conversational Topic Sequence Structure. Semiotica, XVII: SUCHMAN, L., BOLMBERG, J., ORR, J., TRIGG, R.(1999) Reconstructing technologies as social practice In: The American Behavioral scientist; Thousand Oaks; Nov/Dec, 43, pp VALENTE, J. A (1998) Análise dos diferentes tipos de software usados na educação In: Salto para o futuro: TV e informática na educação Sec de Educação à distância. Brasília, Ministério da educação e desporto, SEED VALSINER, Y. (2000) Culture and Human Development London: SAGE Publications Ltd VYGOTSKY, L. S. (1991) A formação social da mente São Paulo: Martins Fontes WERTSCH, J. V. (Ed.) (1985) Culture, Communication and cognition. New York: Cambridge, MA: Harvard University Press

288 Construindo Significados para o Espaço Infantil na Internet: a Criança como Parceira M. Cecília C. Baranauskas, Amanda Meincke Melo Instituto de Computação (IC) & NIED Universidade Estadual de Campinas UNICAMP Caixa Postal Campinas SP Brasil {cecilia, amanda.melo}@ic.unicamp.br Abstract. HCI literature has shown the importance of bringing the user to the process of software design and several methodological proposals have been discussed. While we acknowledge the relevance of bringing children to the design process, we are equally interested in understanding the child s process of signification for design elements, and in reflecting this understanding in the system. In this paper we extend the use of participatory practices with the Semantic Analysis method from Organizational Semiotics, aiming to reflect in ontology charts the child s signification to elements of design. The proposed approach is illustrated in a case study towards the design of a Portal for children. Resumo. A literatura em IHC tem mostrado a importância de trazer o usuário para o processo de design de software e diversas propostas metodológicas têm sido discutidas. Enquanto reconhecemos a importância de trazer a criança ao processo de design, estamos igualmente interessadas em entender o processo de significação da criança para os elementos de design e refletir no sistema esse entendimento. Neste trabalho estendemos o uso de práticas participativas com o método da Análise Semântica da Semiótica Organizacional, objetivando refletir a significação da criança para elementos de design em diagramas ontológicos. A abordagem proposta é ilustrada em um estudo de caso objetivando o design de um portal para crianças. Palavras-chave. Criança, Internet, Design Participativo, Semiótica Organizacional. 1. Introdução Acreditamos, como Resnick (1996), que a Internet possibilita discutir, colaborar e compartilhar conhecimento e, dessa forma, é um artefato da nossa cultura que potencializa processos de construção de conhecimento e aprendizagem. A análise mais cuidadosa de portais para crianças, tem mostrado que ainda há uma carência de ambientes na Web que tornem essas ações possíveis e que façam sentido às crianças. A maioria dos sites e ferramentas disponíveis hoje na Internet foi projetada por profissionais das áreas de computação e mídia, e é principalmente direcionada para adultos, jovens e adolescentes. Ambientes na Internet voltados ao público infantil e que

289 valorizem a interação social nessa faixa etária têm sido criados como extensões de padrões que se aplicam aos ambientes para adultos. A importância de trazer o usuário da tecnologia para o processo de design de software tem sido largamente reconhecida. Áreas do conhecimento como a Engenharia de Software, Sistemas de Informação e principalmente a área de Interação Humano- Computador mostram diferentes maneiras de envolver o usuário no processo de criação de artefatos computacionais: em atividades de avaliação e testes (Nielsen e Mack, 1994); em observações e/ou entrevistas (Beyer e Holtzblatt, 1998); como parceiros nas atividades de design (Schuler e Namioka, 1993). Esse envolvimento não tem ocorrido da mesma maneira quando o usuário é uma criança. No máximo as crianças são chamadas a participar de atividades de teste de novos produtos, em geral em cenário escolar. Entretanto, trabalhos de pesquisa como os de Druin (1999), Barcellos e Baranauskas (1999a), Barcellos (2000), Baranauskas e Barcellos (2001) mostram que, assim como o adulto, a criança como uma categoria de usuário, tem muito a contribuir no processo de design de tecnologia para seu uso. Como bem coloca Druin (1999), as crianças são capazes de dizer do que gostam ou não gostam, têm curiosidades e necessidades que não são as mesmas dos designers de software, de seus pais ou professores. Em conseqüência disso, o design de tecnologia para a criança, deveria respeitá-la como usuário e, da mesma forma que com o adulto, possibilitar seu envolvimento no processo de criação. Acreditamos que, ao mesmo tempo, essa também é uma maneira de entendermos melhor a relação da criança com a tecnologia sendo desenvolvida para seu uso. Neste trabalho investigamos o uso de práticas do Design Participativo (DP) com crianças, combinadas a métodos da Semiótica Organizacional (SO), na fase inicial de criação de um portal infantil. A abordagem participativa propõe dar voz à criança na criação de tecnologia para seu universo de ações. Isso significa ir muito além de observar a criança no uso da tecnologia que o adulto inventa para ela. Essa proposta traz desafios importantes uma vez que dependendo da fase de desenvolvimento em que se encontra, a criança pode ter mais dificuldade em verbalizar pensamentos especialmente relacionados a conceitos abstratos (Piaget, 1971). Por outro lado, as crianças são extremamente honestas e francas em seus comentários e participação. Do ponto de vista dos designers, aceitar o papel da criança como co-autora exige um desprendimento em relação ao controle do processo de design e um aprendizado contínuo sobre o contexto da criança. A participação da criança em atividades de design deve ser interpretada no contexto de suas experiências concretas com elementos de design. Neste trabalho complementamos as técnicas de DP com a Análise Semântica da SO objetivando capturar a significação que elas constróem para os elementos de design. O artigo está organizado da seguinte maneira: na Seção 2 apresentamos o referencial teórico para o trabalho e discutimos o processo de participação e significação proposto como base do processo de design. Na Seção 3 apresentamos um estudo de caso onde mostramos a proposta metodológica, os principais resultados das atividades participativas com as crianças e discutimos resultados preliminares da Análise Semântica derivada das atividades de DP. Na Seção 5 concluímos o trabalho. 2. Design Participativo e o Contexto da Criança O Design Participativo (DP) (Muller et al, 1997; Bodker et al, 1995; Ehn, 1992) teve

290 início na Escandinávia na década de 70, com suas bases fundamentadas no princípio da democracia no ambiente de trabalho. Nesta abordagem os sistemas computacionais são desenhados pelos designers e usuários em conjunto, contrapondo a abordagem tradicional ao desenvolvimento de sistemas computacionais, onde muitas vezes os interesses dos usuários do sistema não são considerados, ou não são captados de maneira satisfatória. Na abordagem tradicional, em geral, prevalece somente o interesse de quem contrata o sistema e a vontade dos próprios designers do sistema. O DP surge como uma abordagem capaz de aprimorar a qualidade de design e do sistema resultante, através da melhor compreensão da atividade do usuário e da combinação das experiências dos diversos participantes do processo de design (Braa, 1996). Druin (1999) observa que essa abordagem ao design, que tenta capturar a complexidade e aspectos do contexto do trabalhador pela sua própria perspectiva, poderia ser útil também para capturar aspectos do contexto da criança. A criança como parceira de designers e educadores no design de tecnologia tem sido apresentada nos trabalhos pioneiros de Druin (1996), que propõe como equipe de design um grupo que a autora denomina intergenerational. Essa equipe inclui membros de diversas idades, disciplinas e experiências, sendo que algumas crianças têm feito parte da equipe juntamente com educadores, cientistas da computação e artistas. Ao longo de práticas participativas realizadas pela equipe foi desenvolvida a cooperative inquiry: uma abordagem à criação de tecnologia para crianças realizada em parceria com crianças. Essa metodologia é derivada de uma combinação de outras metodologias que objetivam trazer o usuário adulto ao processo de design, como por exemplo: cooperative design, participatory design e contextual inquiry. Enquanto reconhecemos a importância de trazer a criança ao processo de design, estamos igualmente interessadas em entender o processo de significação da criança a partir da atuação delas com os elementos de design e refletir no sistema, através de sua interface, esse entendimento. Conforme mencionado anteriormente, em função do estágio de desenvolvimento cognitivo em que se encontra, a criança nem sempre consegue expressar, da mesma maneira que o adulto, idéias abstratas. Assim, o designer deve interpretar as ações da criança com os objetos concretos e simbólicos utilizados e gerados nas atividades participativas. Neste trabalho estendemos a abordagem participativa ao design de tecnologia com o método de Análise Semântica da Semiótica Organizacional, objetivando refletir em diagramas ontológicos a significação da criança para o espaço infantil na Internet a partir da sua atuação com os elementos de design. Nossa proposta é ilustrada em um estudo de caso objetivando o design de um portal infantil. 2.1 Participação e Significação como Base do Processo de Design O entendimento do contexto capturado em atividades participativas, deve ser representado de maneira a informar a modelagem do sistema. Argumentamos que métodos da Semiótica Organizacional, em especial a Análise Semântica, podem facilitar essa transição do que resulta de atividades participativas para o design do sistema. Dessa maneira o significado é construído como resultado da cooperação entre os designers e as crianças, usuários prospectivos da tecnologia. A Semiótica Organizacional é uma disciplina que explora o uso de signos e seu

291 efeito em práticas sociais. Baseada nas escolas de Peirce ( ) e Morris (1938), a SO propõe um conjunto de métodos para design de Sistemas de Informação. Organização é entendida num sentido amplo como um grupo de pessoas, uma sociedade, uma cultura, que não somente compartilham regras de linguagem, costumes e hábitos, mas também participam da construção social dessas regras. A Análise Semântica é um método utilizado para produzir modelos semânticos ou diagramas de ontologia do domínio do problema. A Análise Semântica apoia-se em dois conceitos principais: agente e affordance. Agentes possuem affordances manifestadas por padrões de comportamento e, ao mesmo tempo, estão sujeitos a affordances dos objetos e agentes com os quais interagem. O conceito de affordance foi proposto por Gibson (1979) e utilizado pelos estudiosos da abordagem ecológica à percepção visual, para designar o comportamento de um organismo possibilitado por alguma estrutura combinada do organismo e seu ambiente. Por exemplo, se uma superfície terrestre é horizontal, plana, rígida, relativa a um determinado animal, então essa superfície affords suporte. Da mesma maneira, artefatos da nossa cultura afford um tipo de utilização. O formato da maçaneta da porta affords o tipo de movimento necessário para abrir a porta. O que percebemos quando olhamos para objetos são suas affordances, não suas qualidades. Affordances não são propriedades físicas ou fenomenológicas; são propriedades tomadas relativas a um observador (Gibson, 1979: 143). O conceito de affordance tem sido mencionado por autores influentes da área de IHC (Norman, 1988; Winograd, 1996; Preece, 2002; Shneiderman, 1998) em geral referindo-se ao design de ambientes do cotidiano ou estendendo o conceito a objetos de interface. Um botão na interface carrega o affordance clicar sobre, percebido do objeto do ambiente físico; a diferença é que o botão na interface não é realmente um botão, mas está para um: ele é um signo. Conforme apresenta Gibson, entretanto, o conjunto mais elaborado de affordances do ambiente é fornecido pelas outras pessoas que interagem com o observador, umas com as outras e com os objetos do mundo. Comportamento affords comportamento. A definição dos conceitos de agente e affordance em SO é sensível ao contexto; um agente pode ser simplesmente uma pessoa e ser ontologicamente dependente de algum agente mais complexo, por exemplo, a sociedade. Nesse caso o agente pessoa é, ele próprio, uma affordance de sociedade (Liu, 2000). O método de Análise Semântica possibilita modelar um sistema computacional com o foco em agentes e affordances. O método pode ser sumarizado em quatro fases principais: definição do problema, geração de affordances candidatas, agrupamento de affordances e criação do diagrama ontológico. A Figura 1, a seguir, ilustra a abordagem proposta, envolvendo atividades participativas de design e Análise Semântica. A definição do problema é a primeira fase da Análise Semântica, onde o problema a ser modelado é introduzido basicamente através de um enunciado. Esse enunciado pode servir como uma fonte inicial de agentes e affordances. Mas em geral o enunciado do problema é muito vago, e atividades de design participativo podem colaborar na descoberta das atribuições do sistema e de seus usuários. Na fase de geração de affordances, o enunciado do problema é investigado e toda a documentação que colabora para a definição do problema, na busca de unidades semânticas que podem indicar agentes, affordances e suas relações.

292 Figura 1. Design Participativo Combinado à Análise Semântica. O agrupamento de affordances e o diagrama de ontologias construído pelo designer como resultado de seu entendimento da significação, por sua vez, podem realimentar novas práticas participativas e refinar esse processo de entendimento do problema e significação dos participantes a partir dos elementos de design. 3. Trazendo a Criança para o Processo de Design de um Portal: Um Estudo de Caso Nesta seção apresentamos as atividades de design participativo realizadas com crianças, visando à construção de um portal na Internet adequado ao público infantil, denominado Caleidoscópio Júnior. O portal Caleidoscópio Júnior é uma extensão do projeto Caleidoscópio, que visa à promoção de princípios educacionais inclusivos em um espaço dinâmico, caracterizado pela diversidade de seus elementos (Mantoan et al, 1999). Neste sentido, o design do portal Caleidoscópio Júnior está comprometido com a construção de um espaço virtual colaborativo na Internet voltado ao público infantil, que seja adequado às necessidades e às especificidades das crianças. As primeiras idéias para o portal foram concretizadas, através de protótipos de ambientes propostos para promover a comunicação e a troca de idéias entre crianças. Entre esses ambientes estão o Papo-Mania, uma ferramenta de chat para crianças (Barcellos, 2000; Barcellos e Baranauskas, 1999b), o Jornal On-line (Aoki e Baranauskas, 2001) e ferramentas baseadas na estrutura de fórum para possibilitar a colaboração (Lai e Baranauskas, 2001). Para participar do processo design do portal, dez crianças entre 6 e 10 anos meninos e meninas com diferentes níveis de acesso à tecnologia foram convidadas a participar de uma diversidade de atividades de criação de protótipos, exploração de uma ferramenta de comunicação para crianças, exploração de sites infantis e conversas que colaboraram para a troca de idéias sobre o espaço infantil na Internet. Os encontros com as crianças ocorreram durante 4 sessões de 2 horas cada, nos meses de outubro e novembro de Para registrá-los, foram utilizadas máquinas fotográficas, câmeras de vídeo e gravadores de som. De forma geral, as atividades realizas com as crianças estão sintetizadas na tabela a seguir.