A aplicação da Engenharia Semiótica no design da interface de usuário do software ASK2000

A aplicação da Engenharia Semiótica no design da interface de usuário do software ASK2000 Jair Cavalcanti Leite Universidade Federal do Rio Grande do Norte Campus Universitário, Lagoa Nova 59072-970 Natal, RN, Brasil +55 +84 215 3814 jair@dimap.ufrn.br Salerno F. de S. Silva Universidade Federal do Rio Grande do Norte Campus Universitário, Lagoa Nova 59072-970 Natal, RN, Brasil +55 +84 215 3814 salerno@lcc.ufrn.br RESUMO Este trabalho relata a aplicação da abordagem da Engenharia Semiótica e de um formalismo (a LEMD) para design de interfaces de usuário para o ASK2000, um software de apoio ao telemarketing. Nosso objetivo é verificar aplicação da abordagem e de seus fundamentos como um método prático de design. Foram desenvolvidas duas versões. A primeira foi desenvolvida sem a utilização de qualquer fundamentação teórica, modelo ou formalismo. O único recurso utilizado foi uma ferramenta de programação de interfaces. A segunda versão segue a abordagem da Engenharia Semiótica, incluindo modelos teóricos e utilização de formalismos de especificação. A ferramenta de programação utilizada foi a mesma para os dois casos. Neste relato descrevemos a aplicação do método, os diversos diagramas de especificação gerados e apresentamos algumas telas do protótipo da interface. Palavras-chave Design de Interfaces de Usuário, Engenharia Semiótica, Usabilidade. 1. INTRODUÇÃO Os processos de desenvolvimento de software em empresas muitas vezes utilizam metodologias da engenharia de software cujo foco é quase sempre o sistema. O design de sistemas centrado no usuário muitas vezes utiliza-se apenas de princípios ou diretrizes de design que são bastante fáceis de aplicar. Por outro lado eles não possuem qualquer fundamentação teórica que possibilitem previsões e explicações para o sucesso ou fracasso da usabilidade dos sistemas. Alguns métodos baseados em ciência cognitiva têm preenchido parte desta lacuna. Entretanto, eles são insuficientes para o desafio de usabilidade por não articularem o papel do projetista e da interface na aquisição do modelo de usabilidade pelo usuário. Nosso trabalho aplica a perspectiva da Engenharia Semiótica para o design de interfaces de usuário na qual sistemas são considerados como artefatos de metacomunicação (de Souza 1993). Nesta perspectiva a interface é vista como uma mensagem unidirecional e indireta de designers para usuários. A abordagem da Engenharia Semiótica considera o sistema como um artefato de metacomunicação (de Souza, 1993). A interface de usuário é o instrumento que permite ao designer comunicar ao usuário o que o sistema faz (a sua funcionalidade) e como interagir com ele (o modelo de interação). A interface é vista como uma mensagem do designer. A abordagem da Engenharia Semiótica está fundamentada nos conceitos de comunicação e significação das teorias de Charles Peirce (Peirce, 1931) e Umberto Eco (Eco, 1976). A teoria de Peirce nos mostra que o processo de utilização de sistemas computacionais envolve processos de interpretação de signos que são ilimitados e imprevisíveis. Eco descreve que processo de produção de signos pode ser realizado pela articulação de signos provenientes de diferentes códigos. Nesta perspectiva, o processo de design de interfaces envolve determinar os signos que possibilitem interpretações pelo usuário em torno do significado pretendido pelos designers.

Com base nestes fundamentos procuramos desenvolver um método prático para o design de interfaces que guia o usuário neste processo comunicativo de design. Nosso método consiste de um processo iterativo que envolve análise, especificação, prototipagem e avaliação (de Souza e al., 1999). A especificação e a prototipação são conduzidas como um processo de produção dos signos que formam a mensagem que o designer envia aos usuários através da utilização do sistema computacional. Nosso objetivo é mostrar que as idéias fundamentais da engenharia semiótica podem ser facilmente aplicadas por designers de interfaces e que a utilização dos modelos e formalismos possibilitam melhorias no produto e no processo. 2. O ASK 2000 Telemarketing é a venda ou divulgação de produtos e serviços por intermédio de ferramentas de telecomunicações. O ASK2000 é um sistema de gerenciamento de telemarketing que tem por objetivo facilitar, dinamizar e orientar estas operações. O sistema é utilizado por dois tipos de usuários. Os operadores fazem ou recebem ligações dos clientes e aplicam o questionário da campanha na qual estão inseridos. Os supervisores são responsáveis pelo cadastramento das tabelas, operadores, campanhas, clientes e questionários. Eles fazem também a distribuição dos operadores com as campanhas e diversas outras tarefas. Uma campanha é uma ação do telemarketing que aplica um questionário a clientes pré-definidos. Por cliente consideramos todas as pessoas que fazem parte do público alvo definido na campanha. Um questionário envolve um conjunto de perguntas e observações feitas ao cliente. Cada questionário está associado a uma campanha. O processo de desenvolvimento da primeira versão do software, o ASK 2000 V1, foi conduzido por dois programadores em realização de estágio na empresa que o desenvolveu. Os estagiários eram estudantes de Ciência da Computação com conhecimentos de programação, engenharia de software, banco de dados, dentre outros assuntos. O tempo de desenvolvimento desta versão inicial do software foi de cinco meses. Para esta versão, o desenvolvimento da interface se resumiu apenas à implementação das telas e dos comandos, sem que fossem aplicados conhecimentos teóricos, modelos, técnicas ou formalismos. A interface gráfica foi implementada com o auxílio de uma ferramenta de Geração Automática de Sistemas (GAS) e do MS Visual Basic. Esta atividade foi realizada conjuntamente com o restante da implementação. Neste relato vamos exemplificar as diferenças entre as duas versões utilizando uma pequena parte da aplicação que auxilia o operador na realização de uma pesquisa de campanha. Os detalhes de todo o processo de desenvolvimento estão descritos em (Silva, 2000). 3. O PROCESSO DE DESIGN NA ENGENHARIA SEMIÓTICA Na abordagem da Engenharia Semiótica o processo de design é uma atividade de produção de uma mensagem complexa, dinâmica e interativa, formada por vários signos, provenientes de diferentes códigos. Nosso modelo de design prevê um processo iterativo envolvendo especificação, prototipação e avaliação (Leite, 1998). Estas atividades pressupõem inicialmente que sejam realizadas as atividades de análise do domínio, dos usuários e das tarefas. No processo comunicativo da abordagem da Engenharia Semiótica a especificação consiste na formulação do conteúdo da mensagem do designer e na especificação abstrata da mensagem. O conteúdo da mensagem do designer determina aquilo que ele quer comunicar ao usuário, isto é, a funcionalidade e o modelo de interação que denominamos de modelo conceitual da aplicação. Para a especificação deste modelo conceitual elaboramos um meta-modelo básico para uma aplicação. A especificação abstrata descreve a expressão da mensagem independente da sua forma final que é a interface composta pelos diversos widgets. A forma abstrata da linguagem é descrita utilizando um formalismo denominado de Linguagem de Especificação da Mensagem do Designer (LEMD). Na especificação abstrata da interface através da LEMD o designer concentra-se apenas nas suas intenções de design, isto é, nos diferentes tipos de interações

básicas que o usuário irá realizar e como elas devem ser estruturadas, independentes de quais widgets de interface e qual será o layout final da interface. Um protótipo consiste na implementação de uma versão inicial e simplificada da interface. Durante a prototipação a especificação abstrata será concretizada em um protótipo de interface que define a forma final da mensagem. Esta atividade é realizada com base em regras de correlação semântica que possibilitam o mapeamento entre construções da LEMD e widgets de interfaces. Estas regras são definidas com base na cultura e no conhecimento dos usuários que foram definidos durante a etapa de análise. A etapa de avaliação no design de interfaces de usuário tradicionalmente considera fatores como facilidade de uso e de aprendizado, produtividade, flexibilidade, satisfação do usuário, dentre outras. Nosso objetivo é avaliar se a LEMD possibilita construir interfaces que sejam, principalmente, comunicativas, fáceis de usar e de aprender. O fator comunicabilidade é introduzido para verificarmos se o processo e a LEMD possibilita uma interface que comunique melhor as intenções do designer (de Souza, 1999). O modelo do processo de design adotado e os formalismos e ferramentas utilizados estão descritos na figura 1. especificação dos dos modelos protótipos designer Especificação Prototipação Análise Avaliação Figura 1: O modelo do processo para a Engenharia Semiótica 4. O PROCESSO DE RE-DESIGN DO ASK2000 O re-design da interface foi realizado durante dois meses. Nossa equipe foi formada por um dos programadores que participou da versão e por um especialista em design de interfaces de usuário e na abordagem adotada. O ponto de partida para o design é a análise de requisitos. Nesta etapa são analisados o domínio, os usuários e a as tarefas que elas realizam. A análise do domínio possibilita uma visão geral do contexto onde será inserido o sistema, incluindo os usuários, tarefas e a aplicação. Na análise de usuários são conhecidos quem são os potenciais usuários, seus papeis e suas características, como linguagem, cultura, conhecimento do domínio e de produtos de computação, e algumas outras que sejam convenientes para o produto desenvolvido. Na análise de tarefas são descritas as principais atividades que os usuários devem realizar em termos de metas e planos. A análise de tarefas indicou quais as funções que o ASK2000 deve oferecer. Como o nosso objetivo com este trabalho é avaliar a aplicação da abordagem da Engenharia Semiótica, optamos por trabalhar com as funções necessárias para cinco tarefas dentre todas as analisadas. Elas são Cadastrar Campanha, Cadastrar Questionário, Converter Banco de Dados, Distribuir Clientes para Operadores e Realizar Pesquisa com Clientes. As tarefas foram modeladas utilizando o formalismo GOMS (Card, Moran & Newell, 1983). A figura 2 apresenta uma versão simplificada do modelo de tarefas para Realizar Pesquisa com Cliente.

5: Realizar pesquisa 5.1 definir clientes 5.1A: se (campanha for do tipo receptivo) então 5.1A.1: se (não houver campanha cadastrada) então (cadastrar campanha) 5.1A.2: se (não houver questionário relacionado à campanha cadastrado) então (cadastrar questionário) 5.1A.3: se (não tiver sido convertido o banco de dados para a campanha escolhida) então (converter banco de dados) 5.1A.4: escolher clientes 5.1A.5: selecionar a campanha que utilizará o banco de dados convertido 5.1B: se (campanha for do tipo ativo) então ver lista de clientes distribuídas 5.2: selecionar o cliente com o qual se deseja fazer a pesquisa 5.3: aplicar o questionário ao cliente 5.3.1: se (houver comentário para o operador) então (ler o comentário para ajudá-lo no desenvolvimento da pergunta) 5.3.2 ler as perguntas e anotar as respostas 5.3.3: após cada pergunta decidir 5.3.3A: ir para a próxima pergunta 5.3.3B: voltar para a pergunta anterior 5.3.3C: encerrar o questionário 5.4: escolher próxima tarefa 5.4A: selecionar novo cliente 5.4B: finalizar Figura 2: o modelo GOMS para a tarefa Realizar Pesquisa com Cliente A análise de usuário revelou dois papeis de usuário. O Supervisor é o responsável pela maioria das tarefas. O outro papel é o do Operador que é o responsável por realizar a pesquisa durante a campanha. Com relação ao perfil dos usuários sabíamos que eles eram especialistas no domínio e iriam trabalhar com alta freqüência de uso. Aplicamos um questionário para avaliar qual interpretação eles davam para a maioria dos widgets de interfaces. Esta informação foi aplicada durante a construção do protótipo da interface. 5. O MODELO CONCEITUAL DA APLICAÇÃO O objetivo do modelo conceitual é permitir ao designer definir os elementos que compõem a aplicação do ponto de vista do usuário. A nossa abordagem da Engenharia Semiótica propõe um modelo básico, um meta-modelo conceitual, que define as principais categorias de elementos de uma aplicação. Estes elementos são os objetos da aplicação, as funções da aplicação, os comandos de função, os comandos de controle e a estrutura de aperesentação das tarefas. Os objetos da aplicação definem os elementos da aplicação sobre os quais o usuário realiza operações. São exemplos de objetos, os dados que representam conceitos do domínio, os recipientes que armazenam dados, os visualizações que apresentam os dados. Sabendo as principais tarefas que o usuário necessita realizar o designer deve determinar quais funções e objetos serão necessários para cada uma delas. Os objetos e funções determinam o modelo do núcleo funcional da aplicação. Os objetos possuem propriedades e estão relacionados entre si. As funções modificam propriedades de objetos ou relacionamentos entre eles. Para que o usuário possa interagir com a aplicação é necessário que o designer especifique o modelo de interação. O modelo de interação define as regras que os usuários utilizarão para interagir. Os comandos de função definem a forma como os usuários controlam a execução das funções. Um comando contém principalmente os controles de execução e campos para se definir os operandos necessários à função. As visualizações de objetos definem quais objetos da aplicação poderão ser visualizados pelo usuário. Além de comandos e visualizações o modelo de interação deve definir como eles vão ser apresentados e como o usuário pode controlar esta apresentação. O modelo de apresentação é definido por um grafo (semelhante a um hipertexto) onde cada nó representa um elemento de apresentação (visualização ou comando) e os elos representam o processo de controle dos elementos de apresentação. O

modelo de apresentação define o ambiente de tarefas no qual o usuário pode desempenhar suas atividades. Resumindo, o modelo de interação e o modelo do núcleo funcional definem o modelo conceitual da aplicação. Os objetos, funções, comandos, visualização, controles e apresentação da aplicação são os tipos de elementos básicos de um modelo da aplicação. A especificação do modelo conceitual envolve definir os objetos com suas propriedades e relacionamentos, funções que modificam os objetos, os comandos que controlam as funções, as visualizações de objetos, e a estrutura de apresentação e seus controles. No ASK2000 os principais tipos de objetos são registros de dados, arquivos de registros e formulários para fornecimento e visualização dos dados de registro. Um formulário apresenta um registro. Um arquivo armazena registros. Os principais registros do ASK2000 são registro de campanhas, de clientes, de questionário, de resposta, de operadores. Para cada um destes registros foram definidos os formulários e os arquivos nos quais eles serão armazenados. Utilizamos os diagramas de classes da Unified Modeling Language (UML) como forma de representar como os diferentes objetos da aplicação relacionam-se entre si (Booch et al., 1999). Os diagrama de classe permitem abstrair detalhes específicos de cada objeto e mostram relações válidas entre os objetos que pertencem a mesma classe. A figura 3 mostra as algumas das principais classes de objetos da aplicação. A funções da aplicação foram definidas utilizando-se diagramas de atividades da UML. Um diagrama de atividades diagramas permite representar as atividades realizadas pelo sistema e pelo usuário. Ele também descreve o processo de interação entre o sistema e o usuário. A figura 3 descreve o diagrama de atividades para a Realizar pesquisa. Neste diagrama participam o sistema, o operador e o cliente que responde as perguntas do operador. Formulário de Clientes a Formulário de C h Formulário Pesquisar 1 1 a a Registro de Cliente Está Vinculado à Está Vinculado à Está Vinculado Registro de Resposta Registro de Está 1 Campanha 1 1 a Está a Registro de Q ti á i Formulário de Q ti ái Registro de Operadores Formulário Converter Formulário de Operadores Formulário Distribuir Figura 3: O diagrama de classes UML generalizando os elementos do modelo conceitual 6. A ESPECIFICAÇÃO COM A LEMD A Linguagem de Especificação da Mensagem do Designer (LEMD) tem como objetivo apoiar a formulação da mensagem sobre o modelo conceitual da aplicação (Leite, 1998). Ela permite ao designer especificar os objetos da aplicação, as funções da aplicação e os comandos de função, os comandos de controle e o modelo de apresentação como sendo mensagens enviadas pelo designer. As sentenças da linguagem descrevem cada uma destas mensagens que juntas compõem a mensagem global do designer. Estas mensagens são descritas de maneira abstrata e independente dos signos de interfaces que serão utilizados. A LEMD define alguns tipos básicos de mensagens. As mensagens de tarefas têm por objetivo organizar todas as outras mensagens. As mensagens de controle da leitura comunicam como o usuário pode controlar a apresentação das mensagens. As mensagens de comandos de função indicam como o usuário pode controlar a execução de cada uma das funções da aplicação. As mensagens de interações básicas definem ações que o usuário deve desempenhar durante a Está Vinculado à a

interação. As mensagens de objetos e funções da aplicação revelam quais os objetos e funções do sistema, bem como os seus estados correntes. As interações básicas previstas na LEMD são acionamento, fornecimento de caracteres alfanuméricos, visualização e seleção. Elas podem ser agrupadas em estruturas de articulação como seqüência, agrupamento, combinação, repetição e seleção. São elas que determinam o processo de interação usuário-sistema. No re-design do ASK2000 fizemos a especificação das mensagens de comandos para as funções Cadastrar Campanha, Cadastrar Questionário, Converter Banco de Dados, Distribuir Clientes para Operadores e Realizar Pesquisa com Clientes. A figura 4 mostra a especificação para a mensagem de comando Realizar Pesquisa. Nesta mensagem de comando definimos cada uma das interações básicas e a maneira como elas estão estruturadas de acordo com o modelo de tarefas (ver figura 2). Comparando a especificação da mensagem com o modelo de tarefas da figura 3 podemos identificar alguns relacionamentos entre eles. O modelo de tarefas define quatro sub-metas para a meta 5 realizar pesquisa. Esta tarefa é comunicada ao usuário pela mensagem de tarefa Realizar Pesquisa. A especificação desta mensagem de tarefa estrutura as ações dos usuários como uma seqüência na qual ele deve definir os clientes e em seguida aplicar o questionário. A definição do cliente é feita de forma diferente de acordo com o tipo da campanha. Isto é expresso na interface como duas mensagens de comandos diferentes: Definir Cliente de Campanha Receptivo e Definir Cliente de Campanha Ativo. As sub-metas 5.2, 5.3 e 5.4 foram estruturadas como uma nova tarefa que é comunicada ao usuário pela mensagem de tarefa Aplicar questionário. Esta tarefa, por sua vez, é estruturada como uma repetição que comunica ao usuário que em cada iteração ele pode escolher um cliente para obter as respostas ou finalizar a tarefa. A sub-meta 5.4 é definida como uma mensagem de comando que comunica ao usuário que ele deve repetidamente ler as perguntas para o cliente e fornecer as respostas através da interface (ver figura 5(b)). De forma semelhante foram definidas as mensagens para cada uma das metas descritas durante a análise de tarefas (Silva, 2000). 7. O PROTÓTIPO DO ASK 2000 2.0 O design do protótipo da interface é a etapa na qual a mensagem deve ser concretizada em sua forma final. As mensagens abstratas que foram descritas com a LEMD devem ser mapeadas em signos de interfaces (widgets) de acordo com a interpretação preferencial dos usuários. O conhecimento a respeito da interpretação preferencial foi obtido durante a análise do perfil dos usuários. O protótipo da interface da versão 2.0 foi implementado usando as mesmas ferramentas da versão 1.0. Nosso objetivo era mostrar que a interface melhoraria apenas pela introdução dos modelos e formalismos da Engenharia Semiótica, considerando-se as mesmas condições de implementação. As diferenças entre as duas versões podem ser percebidas pelos usuários desde a tela principal da interface. Ela apresenta ao usuário um menu com as principais tarefas que ele pode realizar como o sistema (figura 5(a)). A mensagem de comando para responder questionário cuja especificação em LEMD está na figura 3, pode ser visualizada em sua forma concreta na figura 5(b). 8. CONCLUSÃO Neste trabalho mostramos que a abordagem da Engenharia Semiótica pode ser aplicada em casos reais de design de interfaces de usuário. O método utilizado determinou várias mudanças na interface, mostrando que ele tem forte impacto no resultado final. A sua utilização foi bastante importante e valiosa para o processo de design, permitindo que os desenvolvedores pudessem planejar melhor cada uma das atividades do design. O modelo permitiu também que o processo de design da interface fosse realizado de forma independente da sua implementação e do desenvolvimento do restante do sistema.

Task-Message Realizar Pesquisa for Goal Realizar Pesquisa Sequence { Select { Command-Message Definir Cliente de Campanha Receptivo Command-Message Definir Cliente de Campanha Ativo Task-Message Aplicar Questionário Command-Message Definir Cliente de Campanha Receptivo for Application-Function Obter Lista de Clientes para Receptivo <Especificação da mensagem omitida nesta figura> Command-Message Definir Cliente de Campanha Ativo for Application-Function Obter Lista de Clientes para Ativo <Especificação da mensagem omitida nesta figura> Task-Message Aplicar Questionário for Goal Aplicar questionário ao cliente Repeat { Sequence { Select Information-of Cliente Select { Activate Show Command-Message Responder Questionário Activate Discard Task-Message Aplicar Questionário Command-Message Responder Questionário for Application-Function Realizar Pesquisa Repeat { View Information-of Pergunta Enter Information-of Resposta Select { Activate Show Responder Questionário Activate Show Responder Questionário Activate Discard Responder Questionário Figura 4: A especificação da mensagem para a tarefa de realizar pesquisa Uma dificuldade encontrada pelos desenvolvedores foi com a descrição das mensagens com a LEMD. Identificamos que são necessários alguns ajustes para aumentar o seu poder expressivo. Outra dificuldade foi no entendimento da semântica da LEMD por parte da equipe de design. Foi necessário complementarmos a especificação do modelo conceitual utilizando diagramas da UML. Embora isto tenha facilitado o processo de especificação com a UML não foi possível estruturar o modelo de interação completo com a UML, pois uma vez que ela não permite estruturar a interação em termos de seqüência, repetição, combinação, agrupamento e seleção. Ela também não permite diferenciar os diversos tipos de mensagens. Neste caso a LEMD foi indispensável. Por outro lado, a LEMD teve um grande impacto positivo nas etapas de análise e avaliação. A LEMD estrutura a interface em mensagens que comunicam quais as funções que a aplicação deve oferecer ao usuário. Desta forma, as funções da aplicação são o foco principal para o design centrado no usuário (Norman, 1986). Por este motivo foi necessário realizarmos a análise de tarefas para identificarmos as metas dos usuários. Na versão inicial, a análise foi realizada a partir de entrevistas e os resultados foram descritos informalmente. Na análise realizada para a nova versão foi utilizado o modelo GOMS para que definíssemos as metas de cada papel de usuário. O GOMS facilitou bastante a especificação das mensagens com a LEMD, como mostramos neste artigo. Os modelo produzidos com o GOMS serão a base para a realização dos testes de avaliação.

O desenvolvimento do ASK2000 ainda está em andamento e a próxima etapa consiste em realizar testes de avaliação para comparar alguns fatores de usabilidade e a comunicabilidade das duas versões da interface. Os fatores de usabilidade que vamos avaliar são facilidade de uso e de aprendizado. A comunicabilidade visa avaliar se o designer conseguiu expressar bem as suas intenções de design (de Souza 1999). Outro objetivo que pretendemos atingir mais adiante é comparar o nosso método e seus modelos e formalismos com outros propostos na literatura. Figura 5: Telas do protótipo do ASK2000 v2.0 (a) principal (b) comando responder questionário 9. REFERÊNCIAS Booch, G., Rumbaugh, J. & Jacobson, I. The Unified Modeling Language User s Guide. Addison-Wesley, 1999. Card S.; Moran T. & Newell A. The Psychology of Human-Computer Interaction, Hillsdale, NJ: Lawrence Erlbaum Associates, 1983. De Souza, C.S. The Semiotic Engineering of User Interface Languages. International Journal of Man- Machine Studies 39. Academic Press. 1993. pp. 753-773. De Souza, C.S.; Leite, J.; Prates, R. & Barbosa, S. Projeto de Interfaces de Usuário: Perspectivas Cognitivas e Semióticas. Anais da Jornada de Atualização em Informática do Congresso da Sociedade Brasileira de Computação, Rio de Janeiro, julho de 1999. Eco, U. A Theory of Semiotics. Bloomington, IN. Indiana University Press. 1976. Edição brasileira: Tratado Geral de Semiótica, coleção estudos 73, ed. Perspectiva, 2a. Edição, São Paulo 1991. Leite, J. C. Modelos e Formalismos para a Engenharia Semiótica de Interfaces de Usuário. Tese de Doutorado. Departamento de Informática. PUC-Rio, 1998. Norman, D. Cognitive Engineering. in D. Norman & S. Draper (eds.) User Centered System Design. Hillsdale, NJ. Lawrence Erlbaum. 1986. Pp.31-61. Peirce, C.S. 31-58. Collected Papers (1931-1958). Edição brasileira: Semiótica. São Paulo, Ed. Perspectiva (coleção estudo, n.46) 1977. Silva, S. F. S. Uma avaliação para a Linguagem de Especificação para a Engenharia Semiótica de Interfaces de Usuário. Relatório de graduação. Dep. de Informática e Matemática Aplicada, UFRN, Natal, junho de 2000.