Winckler, M. A. A.; Nemetz, F.; Lima, J. V. de. Interao entre aprendiz e computador: mtodos para desenvolvimento e avaliao de interfaces.

In: Tarouco, Liane (Org.). Tecnologia Digital na Educao. PGIE/UFRGS, Porto Alegre, Brazil. 2000. p.7-33. 113 pginas.

INTERAO ENTRE APRENDIZ E COMPUTADOR

Mtodos para Desenvolvimento e Avaliao de Interfaces
Marco Antnio Alba Winckler, Fbio Nemetz, Jos Valdeni de Lima
winckler@inf.ufrgs.br, mapfn@bath.ac.uk, valdeni@inf.ufrgs.br

RESUMO
Interfaces fceis de utilizar so essenciais para uma boa interao entre os usurios e seus computadores. Em software educacional, estas so ainda mais importantes para evitar que alunos gastem seu tempo aprendendo a usar a interface ao invs de aprender novos conhecimentos atravs da interface. Como soluo identificao de problemas com a interface ainda durante o seu desenvolvimento, tm-se preconizado o Projeto Centrado no Usurio (PCU). Nesta abordagem, o usurio o foco principal do processo de desenvolvimento e considerado parte da equipe de projeto do software. Aprendizes e alunos, porm, tem requisitos diferentes de usurios tradicionais e, por isso, requer um tratamento especial dentro do ciclo de vida PCU. Neste captulo apresentado uma proposta de extenso de PCU que considera tais diferenas caracterizando uma nova forma de projetar e desenvolver software educacional.

1. INTRODUO
O projeto e construo de interface de um software ainda uma tarefa to artesanal quanto escrever um livro ou pintar um quadro, para as quais nenhuma tcnica garante sucesso [2]. Em parte isto se justifica porque a interface reflexo direto do domnio do conhecimento envolvido pelo software (tais como biologia, matemtica etc.) e o contexto no qual ele ser utilizado. A identificao do contexto uma tarefa complexa que envolve o conhecimento dos usurios reais do software e suas tarefas especficas. Apesar de muitos esforos realizados nos ltimos anos em pesquisas na rea de Interao Homem Computador (IHC), no existem solues padronizadas para produzir interfaces eficientes para qualquer tipo de aplicao. Por exemplo, solues para interfaces mdicas no funcionam para aplicaes administrativas, e mesmo duas aplicaes mdicas semelhantes podem ter requisitos de interface diferentes em funo de necessidades especficas de seus usurios. Assim, somente conhecendo os usurios e suas tarefas que se consegue ter sucesso na construo de interfaces que se adaptem a eles e preencham suas necessidades. Os problemas de interao do usurio com a interface, denominados problemas de usabilidade [1], tm agravantes quando ocorrem com software educacional. Eles podem levar o aluno a concluses equivocadas ou errneas, tornar o uso do computador uma experincia frustrante e mesmo causar desinteresse pelo estudo. Alm disso, existem outros requisitos especficos como, por exemplo, interfaces devem ser atrativas para chamar a ateno do usurio, estimulantes para lhes prender a ateno, ter uma linguagem compreensvel a alunos no especializados e com diferentes necessidades de aprendizado, manter coerncia de representao visual e computacional com o domnio

do conhecimento que est sendo abordado. A fcil interao um requisito importante porque o aluno deve utilizar a interface para aprender algo novo e no simplesmente aprender a usar a interface. Como forma de identificar as reais necessidades dos usurios, tem sido desenvolvido nos ltimos anos um conjunto de tcnicas e mtodos que atendem a denominao de Projeto Centrado no Usurio (PCU). O objetivo desta abordagem de projeto focalizar o desenvolvimento da interface sobre necessidades e capacidades dos usurios, atendendo seus requisitos e apoiando suas atividades. Para tanto, PCU agrega mtodos que permitem envolver usurios reais durante este processo. A participao efetiva de usurios durante o projeto tem por objetivo a construo de softwares que reduzam sua sobrecarga cognitiva, sendo, ao mesmo tempo, fceis de aprender e eficientes de operar. A tarefa, ou o objetivo, principal de um software educacional apoiar/suportar/estimular o processo de aprendizagem do aluno com o uso do computador. Esta tarefa geral porm vaga e, em alguns casos, ambgua porque no existe uma nica maneira de ser alcanada. Alm disso, pessoas ou contedos podem no se adaptar a padres rgidos de aprendizagem. Diversas estratgias tm sido propostas como solues para alcanar aquele objetivo global, tais como tutores que auxiliam e/ou dirigem a aprendizagem, hiperhistrias, interfaces que apenas suportam exerccios, simuladores que permitem a experimentao, entre outros. Entretanto, nenhuma destas estratgias pode ser considerada como uma metodologia de projeto de interfaces. Em outros casos a metodologia de projeto da interface se confunde com estratgia de ensino adotada como no caso do Projeto Centrado no Aprendiz (PCA) Jackson et al.[4]. PCA pode ser adequada para algumas situaes mas desejvel uma estrutura maior que guie o projeto da interface em si, no importando qual a estratgia de ensino escolhida. Assim, o tema central deste captulo o projeto e desenvolvimento de interfaces como uma metodologia mais do que como suporte a uma abordagem pedaggica ou estratgia de ensino. Embora eficaz no desenvolvimento de interfaces tradicionais, PCU limitado quando aplicado em projetos de software educacionais. Na ausncia de outras metodologias, propem-se aqui sua extenso para contemplar requisitos de interfaces educacionais. Assim, inicialmente apresentado (seo 2) o Projeto Centrado no Usurios tradicional, seguido pela Projeto Centrado no Aprendiz na seo 3 que apresentado aqui como um exemplo de metodologia rgida de desenvolvimento de interfaces para software educacional. Segue-se a proposta de extenso do PCU (seo 4) e algumas concluses.

2. PROJETO CENTRADO NO USURIO

Trs aspectos caracterizam PCU segundo Lewis e Gould [23]: processo cclico de desenvolvimento, nfase nos usurios e suas tarefas e avaliao emprica da interface. O processo cclico de desenvolvimento pode ser resumido como a contnua construo de prottipos a partir de requisitos conhecidos, avaliao da sua usabilidade e reprojeto dos mesmos. A cada ciclo so anexadas novas funes e solucionados os problemas encontrados durante a avaliao, criando-se assim verses que evoluem at o produto

final. O nmero de etapas deste processo pode variar1 na literatura [5, 6, 17], mas o funcionamento bsico, apresentado na figura 1, semelhante em todas as variantes.

FIGURA 1: Ciclo de vida de desenvolvimento de uma interface no PCU. Este ciclo de vida, tambm conhecido como ciclo de prototipao, possibilita o desenvolvimento e a avaliao de diferentes estratgias de projeto de maneira rpida, fcil e com um baixo custo. Ao longo de todo processo, usurios participam na definio de seus requisitos e na identificao de problemas com a interface. Em alguns casos, usurios tambm tomam parte das reunies da equipe e auxiliam na construo de prottipos. As prximas sees apresentam estas etapas em detalhe. 2.1 Conhecer os usurios reais e suas tarefas O primeiro passo para o projeto de software na abordagem PCU definir (a) quem sero os usurios e (b) o que eles faro com o software (quais as suas tarefas). O produto desta etapa a criao de um perfil que identifica o grupo de usurios e a relao de todas as tarefas que devero ser suportadas pela interface. No caso de software educacional, o perfil do aluno deve incluir informaes como faixa etria, escolaridade, conhecimentos prvios sobre o contedo, experincias anteriores com computador e outros software educacionais. Informaes tais como o tipo de nomenclatura e formas de representao que os alunos conhecem so teis, mas a compreenso de como se processa o aprendizado dos alunos essencial. Sugere-se que durante a observao de alunos em sala de aula sejam identificadas principalmente aquelas tarefas que de fato levam assimilao do conhecimento que est sendo ensinado, muito embora os alunos possam estar realizando uma srie de outras tarefas que no lhes proporcionam o mesmo insight. Considerando o aspecto evolutivo que ocorre no processo de aprendizagem, importante observar que o software dever suportar o contnuo crescimento do aluno. Se o software deve contemplar diferentes alunos em diferentes nveis ou durante um longo processo de aprendizado de algum conhecimento especfico, perfis com as necessidades dos seus usurios devem ser elaborados para cada nvel e ao longo do processo. Conhecer os usurios reais e suas tarefas, na abordagem PCU, tm um significado mais abrangente que o encontrado na tradicional elicitao de requisitos. A participao de
O processo de desenvolvimento de interface segue o modelo de ciclo de vida de prototipao conforme apresentado na figura 1, embora existam inmeras variaes. Este ciclo de vida deve ser encarado como algo flexvel, de modo a permitir sua adaptao s necessidades especficas de cada projeto. Assim, optou-se por apresentar um modelo simplificado que suficiente para exemplificar a abordagem PCU.
1

usurios em vrios ciclos de avaliao, acaba adaptando a interface a eles e, por isso, importante escolher usurios reais ou representativos do pblico alvo. Um erro comum construir o software sobre um perfil hipottico de usurios que acaba falhando com usurios reais. Assim, alm de pesquisas e entrevistas como fonte de informaes sobre usurios, recomenda-se que estes sejam observados diretamente durante a realizao de suas tarefas dirias em seu ambiente natural de trabalho. Observar usurios uma tarefa que costuma revelar requisitos essenciais que passam desapercebidos em entrevistas, alm do que, aproxima a equipe de desenvolvimento da realidade na qual a interface ser inserida. Sees de observao tambm proporcionam a identificao de quais so as tarefas dos usurios, como eles as realizam e por qu eles agem desta forma. O estudo em detalhe das tarefas dos usurios, geralmente, resulta na descoberta de formas mais eficientes de realizar o mesmo trabalho. Aps o estudo inicial sobre usurios e suas tarefas deve ser conduzida uma reunio com a equipe de projeto para discutir o projeto da interface. Reunies do tipo brainstorming so adequadas ao projeto da interface para permitir que solues criativas para a interface sejam encontradas pelo grupo. o momento de se fazer um balano do projeto e discutir quais tarefas sero implementadas. Algumas, por questes econmicas ou tcnicas, podem ser descartadas do projeto ou deixadas para verses futuras. Deve-se discutir a ocorrncia de problemas encontrados at o momento, suas possveis solues e quais so as alternativas de projeto. Quando no for possvel determinar uma nica melhor soluo, deve-se considerar a hiptese de construir um prottipo para cada soluo que devero ser avaliados quanto aos seus desempenhos. 2.2 Prototipao Nesta etapa, as idias so implementadas em um prottipo. Um prottipo uma verso simplificada de todo o projeto que se deseja construir, utilizado para experimentar e avaliar solues. No incio eles podem ser bem simples, construdos utilizando-se apenas papel e caneta. Estes prottipos, conhecidos como mockups, tem baixssimo custo e so ideais para discutir as primeiras idias. Para criar uma impresso realstica da interface, utiliza-se seqncias de cartes (cada um representando um tela) na simulao da interao do usurio com a interface. Os prottipos podem evoluir a partir de cenrios de uso, que so descries da interao de um usurio na realizao de uma nica tarefa mediante certas condies especficas. A vantagem de cenrios que eles permitem estudar situaes especficas de uso em detalhe. A anlise de vrios cenrios diferentes pode produzir solues globais para a realizao de tarefas na interface. Por exemplo, um possvel cenrio de uso de um terminal bancrio poderia ser: "Usurio chega ao terminal; passa o carto magntico; digita a sua
senha; a senha e a identificao no conferem; o terminal recusa o acesso e volta ao estado inicial; o usurio passa o carto novamente e informa a senha correta; o usurio escolhe uma das opes de saque (R$10, 50, 100); Por questes de segurana, a mquina solicita ao usurio que passe o carto novamente; a mquina conta o dinheiro e lhe paga.

medida que as idias iniciais so definidas como padro para o projeto, pode-se criar prottipo funcionais utilizando-se ferramentas de programao visual que permitam a

rpida prototipao tais como, ferramentas para multimdia (ex.: Macromedia Director2, HyperCard3, ToolBook4) ou mesmo ambientes de programao visual (ex.: Borland Delphi5, Microsoft Visual Basic6). Usando este tipo de ferramenta possvel agregar funcionalidades at que este se torne o produto final. 2.3 Avaliao da usabilidade A avaliao da usabilidade de interfaces uma das etapas mais importantes dentro do ciclo de desenvolvimento. O seu objetivo identificar problemas que possam comprometer a interao do usurio com a interface. Inicialmente necessrio escolher qual ou quais mtodos sero utilizados dentre um grande nmero de mtodos disponveis. Estes mtodos podem ser classificados como mtodos de inspeo de usabilidade e testes empricos com usurios. Mtodos de inspeo caracterizam-se por empregarem especialistas em interface que usam o software em busca de possveis problemas de usabilidade. Como exemplos cita-se a avaliao heurstica [8], reviso cognitiva [9] e inspeo formal de usabilidade [10]. Os mtodos com a participao de usurios caracterizam-se pela utilizao de questionrios ou observao direta ou indireta de usurios durante a utilizao da interface, como fonte de informaes que possam levar identificao de problemas. Como exemplos destes mtodos podem ser citados ensaios de interao (ou teste com usurio) [5], questionrios [10] e anlise de arquivos de log [11], entre outros. Outros mtodos que envolvem usurios como, por exemplo, focus group [12] e classificao de cartes [13, 14], tambm so utilizadas para descobrir como os usurios organizam as informaes do domnio de problema, quais suas expectativas e necessidades com relao interface do software.
Mtodos de inspeo
Avaliao heurstica Reviso cognitiva Inspeo formal de usabilidade Ensaios de interao Questionrios Anlise de arquivos de log Focus group Classificao de cartes

Testes com usurios

TABELA 1: Mtodos de avaliao de usabilidade Como os problemas de usabilidade podem ocorrer de diferentes formas e em diferentes situaes, com freqncia as tcnicas de avaliao precisam ser adaptadas ao contexto do projeto onde sero empregadas [15]. Algumas tcnicas so mais eficientes para capturar alguns tipos de problemas do que outras e, por esta razo, recomenda-se a aplicao de duas ou mais tcnicas a uma mesma interface para descobrir um nmero maior de problemas [16]. A escolha do mtodo de avaliao depende de vrios fatores,
2 3

Macromedia Director - http://www.macromedia.com/ Apple HyperCard - http://www.apple.com/hypercard/ 4 Asymetrix ToolBook - http://www.asymetrix.com/ 5 Borland Delphi - http://netserv.borland.com/delphi/ 6 Microsoft Visual Basic - http://msdn.microsoft.com/vbasic/

mas principalmente da experincia do avaliador com o mtodo escolhido. Nas sees seguintes ser descrita a avaliao heurstica - representando os mtodos de inspeo - e ensaio de interaes como exemplo de testes empricos. Estes mtodos exigem um certo treinamento que pode ser facilmente alcanado mesmo por avaliadores no especialistas em IHC (Interface Homem-Computador). 2.3.1 AVALIAO HEURSTICA A avaliao heurstica um mtodo de inspeo sistemtica da interface do usurio com relao sua usabilidade. Basicamente um avaliador interage com a interface e julga a sua adequao comparando-a com princpios de usabilidade reconhecidos, as heursticas. Nielsen [6] sugere um conjunto com apenas 10 regras heursticas para guiar a avaliao: 1. Dilogos Simples e Naturais: as interfaces de usurios devem ser o mximo simples possvel. Interfaces devem combinar as tarefas do usurio de tal forma que o mapeamento entre os conceitos computacionais e os do usurio seja simples. Devese apresentar exatamente a informao que o usurio precisa nem mais nem menos - na hora e lugar exatos onde necessria. Informao que ser usada em conjunto deve ser exibida em conjunto, ao menos na mesma tela. Tanto os objetos de informao quanto as operaes devem ser acessados em uma seqncia que casa com o modo como os usurios iro realizar suas tarefas efetiva e produtivamente. Muitas vezes tais seqncias so foradas pela interface, mas normalmente melhor permitir que o usurio controle o dilogo o mximo possvel, de tal forma que a seqncia possa se ajustar s preferncias do usurio individual. 2. Falar a Linguagem do Usurio: a terminologia da interface deve ser baseada na linguagem do usurio, e no orientada ao sistema. Para tanto, deve-se verificar quais termos so utilizados com maior freqncia pelos usurios. As informaes tambm devem ser organizadas conforme o modelo mental que o usurio possui do domnio. 3. Minimizar a Sobrecarga de Memria do Usurio: o software deve exibir elementos de dilogo para o usurio e permitir que o mesmo faa suas escolhas, sem a necessidade de lembrar deste ou daquele comando especfico. Para facilitar a utilizao da interface, deve ser apresentado ao usurio um pequeno nmero de regras que se aplicam por toda a interface. Se o nmero de regras grande o usurio ter de aprender/lembrar todas as regras, o que pode no ser to simples. Por outro lado, se o software no tiver regra alguma, ento o usurio dever lembrar de cada elemento de dilogo. O uso de comandos genricos uma maneira de se ter um pequeno conjunto de regras. Comandos genricos fazem com que coisas similares ocorram em diferentes circunstncias, sendo suficiente ao usurio aprender poucos comandos para trabalhar com vrios tipos de dados. 4. Consistncia: consistncia um dos princpios bsicos de usabilidade. Se os usurios souberem que um mesmo comando ou uma mesma ao ter sempre o mesmo efeito, eles ficaro mais confiantes no uso do software, e sero encorajados a fazerem novas descobertas. A mesma operao dever ser apresentada na mesma localizao em todas as telas e dever ser formatada da mesma maneira para facilitar o reconhecimento.

5. Feedback: O sistema dever informar continuamente ao usurio sobre o que ele est fazendo. O tempo de resposta influi no tipo de feedback que deve ser dado ao usurio. Um dcimo de segundo (0,1s) o limite para o usurio pensar que o sistema est reagindo instantaneamente, o que significa que nenhum feedback especial necessrio; um segundo (1,0s) o limite para que o fluxo de pensamento do usurio no seja interrompido, mesmo que o usurio perceba uma certa demora; e dez segundos (10s) o limite para manter a ateno do usurio focalizada no dilogo. As vezes feedbacks especiais so necessrios para contextualizar uma navegao mais demorada do usurio. 6. Sadas Claramente Marcadas: De modo a fazer com que o usurio sinta que pode controlar o software, dever ser fcil sair das situaes mais variadas possveis. Por exemplo, todas as caixas de dilogo devem possuir um boto de cancelar para trazer o usurio para a situao anterior. Muitas vezes, as sadas podem ser fornecidas por meio de uma facilidade de desfazer (undo) a ltima operao para retornar ao estado anterior. Os usurios rapidamente aprendem a confiar neste mecanismo, logo deve estar disponvel como um comando genrico por todo o software. Neste caso, o usurio poder confiar no aprendizado por explorao, pois saber desfazer eventuais erros. 7. Atalhos: embora deva ser possvel operar a interface conhecendo-se apenas algumas regras gerais, deveria tambm ser possvel para o usurio experiente executar mais rapidamente operaes freqentemente utilizadas, atravs de atalhos. Aceleradores tpicos incluem abreviaes, teclas de funo, clique duplo do mouse, ou botes especiais para funes freqentes. Tambm podem ser apresentados atravs da exibio dos ltimos comandos executados, ou da funo de volta (backtrack) em sistemas de hipertexto. Atalhos so tambm necessrios quando por uma poltica de uma empresa ou organizao a informao que se encontra em uma maior profundidade da rvore navegacional tenha que ser recuperada diretamente pela interface principal. Por exemplo, na pgina do II (http://www.inf.ufrgs.br) na poca de publicar o resultado do processo de seleo do Ps-Graduao em Computao deveria ter um elo na primeira pgina em vez de obrigar ao usurio a navegao pelo caminho cursos ->ps-graduao->resultado seleo, muitas vezes no muito fcil de deduzir. 8. Boas mensagens de erro: as mensagens de erro devem seguir algumas regras: linguagem clara e sem cdigos. Devem ser precisas. Devem ajudar o usurio a resolver o problema. No devem intimidar ou culpar o usurio. 9. Prevenir Erros: melhor do que possuir boas mensagens, evitar situaes de erro. Conhecendo-se as situaes que mais provocam erro, sempre possvel modificar a interface a tornar muito difcil que este erro ocorra. 10. Ajuda e Documentao: o melhor se ter um software que seja to fcil de usar que no necessite de ajuda ou documentao para complementar a interface do usurio. Alm disto, sabidamente usurios raramente lem a documentao Como certamente um s avaliador no ir encontrar todos os problemas de uma interface, idealmente so utilizados vrios. Nielsen [6] sugere que a melhor relao custo/benefcio alcanada quando se utilizam entre 3 e 5 avaliadores. Cada avaliador deve realizar a sua inspeo individualmente e somente depois de todas avaliaes terem sido concludas, os avaliadores podem se comunicar. Este cuidado importante para

garantir avaliaes independentes e sem influncias. Os resultados tanto podem ser registrados por cada avaliador como por um observador presente durante as sesses, onde os avaliadores verbalizam seus comentrios. Ao final de todas as sesses o observador dever reunir todas as avaliaes feitas em um nico documento. Alm disto, o observador poder auxiliar o avaliador em caso de problemas com o prottipo, se este for o caso. Tipicamente, uma sesso de avaliao heurstica dura entre uma e duas horas. Normalmente, o avaliador determina o ritmo da procura por problemas mas recomendase que o mesmo utilize pelo menos duas vezes o software; na primeira vez para ter uma viso geral da interface e do sistema, na segunda ele deve focalizar elementos especficos, j tendo uma idia do funcionamento geral. O resultado da avaliao uma lista de problemas de usabilidade, indicando qual ou quais princpios foram violados e a gravidade do problema. Na tabela 2 so apresentados alguns dos problemas encontrado durante a avaliao do CD-ROM Literatura Gacha7 (veja figura 2), assim como comentrios que ilustram com os avaliadores utilizaram as heursticas para identificar problemas.
Descrio do Problema Severidade [ 0 5] Heurstica violada e Comentrios Fornecer sadas claramente marcadas e Prevenir erros. Os avaliadores consideraram o problema muito grave (5) porque ele obriga o usurio a ver todo o vdeo mesmo que a sua ativao tenha sido ocasionada por um click acidental. Esta uma situao de erro que poderia ser minimizada com a opo para interromper o vdeo. Observa-se aqui um problema que foi classificado por mais de uma heurstica, o que aceitvel na identificao de problemas complexos como este. Fornecer Mensagens de Retorno Adequada. Sabendo que mensagens adequadas so necessrias para a eficiente utilizao da interface, o avaliador inspeciona a interface em busca de todas as situaes onde boas mensagens de retorno no so fornecidas. Assim, o avaliador identificou este problema e atribuiu severidade moderada (3) supondo que os usurios ficariam desorientado sobre a funo de crtica. Fornecer atalhos. O avaliador usou esta heurstica para procurar situaes que necessitassem de atalhos. Contudo, foi considerado que atalhos no so necessrios nesta aplicao e por isto uma severidade baixa (1) foi atribuda. Esta heurstica lembra o avaliador de considerar as situaes onde atalhos so necessrios.

Na pgina rico Verssimo h a opo de visualizar um vdeo sobre o autor, que disponvel pelo cone de uma cmera filmadora (figura autor). Ao iniciar o vdeo no h como interromp-lo. Na obra O tempo e o Vento o boto [crtica] (base da figura Obra) aparece disponvel mas, quando selecionado, no apresenta o texto correspondente crtica do livro, como esperado.

No existem atalho.

opes

de

TABELA 2. Exemplos de Problemas de Usabilidade.

CD-ROM multimdia com os principais escritores e livros da literatura produzida no Rio Grande do Sul (disponvel na biblioteca do II). Ganhou Prmio de Segundo Lugar na Categoria de Melhor Pacote Multimdia no 1 Concurso Nacional de Software Universitrio promovido pelo Softex 2000, CTI e UFMG em dezembro de 1996.

Autor - rico Verssimo.

Obra O Tempo e o Vento.

FIGURA 2. CD-ROM Literatura Gacha. O mtodo de avaliao heurstica tem sido empregado com sucesso pelo nosso grupo de trabalho, em alguns caso com algumas adaptaes para atender a necessidades especficas de cada projeto. Na avaliao do software para ensino da teoria dos intervalos musicais - STI, por exemplo, professores de msica foram treinados no mtodo para realizar a avaliao da interface [19]. Os professores assimilaram rapidamente o funcionamento do mtodo e foram capazes de identificar tantos problemas de usabilidade da interface (como esperado) como tambm problemas que envolviam a correo do contedo e a abordagem pedaggica do software. Como forma de obter melhores resultados com o mtodo, sugere-se a realizao de uma reunio final com todos os avaliadores na qual devem estar presentes tambm o observador e representantes da equipe de projetistas. Deve-se discutir os problemas mais freqentes, possveis solues e levantar os pontos positivos que no devem ser alterados na interface. 2.3.2 ENSAIOS DE INTERAO Neste tipo de avaliao, usurios participam realizando algumas tarefas com a interface enquanto so observados por avaliadores em um laboratrio de usabilidade [5]. Os laboratrios de usabilidade so salas equipadas com cmeras para filmagem do teste e espelhos falsos que permitem aos avaliadores observar os usurios sem serem visto. Contudo, tais testes tambm podem ser realizados sem a necessidade de laboratrios sofisticados, utilizando-se apenas uma cmera filmadora convencional ou mesmo um gravador. Se duas cmeras so disponveis, uma deve focalizar o rosto do usurio enquanto a segundo registra a tela do computador. Com uma nica cmera prefervel focalizar a tela do computador para registrar o que o usurio est fazendo. A reviso da gravao ao mesmo tempo uma forma de registro e um meio para a equipe discutir os problemas de usabilidade. Porm, estes equipamentos podem ser dispensados se o avaliador dispem de outro meio de registro dos problemas (por exemplo, papel e caneta). Sesses de testes simplificadas tem sido utilizadas com sucesso na identificao

de problemas de usabilidade em software educacional. A Figura 3 apresenta um ensaio de interao no laboratrio de usabilidade da UFSC, o LabUtil8.

FIGURA 3. Ensaio de Interao em um laboratrio de usabilidade. Inicialmente deve-se selecionar um grupo de usurios para o teste que represente os usurios reais do software. Se os usurios escolhidos no forem representativos, todo o teste pode falhar na identificao de problemas de usabilidade para o contexto em que ele ser utilizado. Um grande nmero de usurios desejvel mas, por questes de custo e tempo, tem se adotado um nmero reduzido em cada ciclo como forma de viabilizar a avaliao. Nielsen [6] sugere que com 5 usurios pode-se identificar aproximadamente 70% dos problemas mais crticos da interface. Isto caracteriza uma situao adequada para a maioria dos projetos. Durante o teste os usurios podero ser solicitados a realizar tarefas que so predefinidas pelo avaliador, respondero algumas perguntas ou simplesmente utilizaro livremente a interface. Se utilizado, o conjunto de tarefas deve ser previamente definido e passado ao usurio no incio do teste. Como exemplos de tarefas, citam-se: Qual o autor do livro o Tempo e o Vento? e Identifique o intervalo musical apresentado na pauta., que foram utilizadas nas avaliaes do CD da Literatura gacha e do STI, respectivamente. Durante a sesso, o usurio deve ser instrudo para dizer tudo o que est pensando e fazendo. Como esta no uma atitude muito natural para a maioria das pessoas, o avaliador precisa estimular o usurio com perguntas como, por exemplo, "O que voc est pensando?" ou "Tem alguma coisa na interface que voc no gosta?". Esta forma de dilogo conhecida como "Thinking Aloud Protocol", ou pensamento em voz alta, induz o usurio a verbalizar seus pensamentos de modo a captar suas opinies. Algum treinamento necessrio para conduzir tais testes satisfatoriamente, contudo, mesmo profissionais da rea de computao que no so necessariamente especialistas em IHC, conseguem resultados satisfatrios com esta tcnica [NIE97a, HEU97]. Basicamente, problemas de usabilidade so identificados quando se observa usurios com dificuldades para completar suas tarefas.

Imagem reproduzida com a permisso do Labtil, disponvel por http em http://labiutil.inf.ufsc.br/ Universidade Federal de Santa Catarina UFSC.

Existem algumas questes ticas em torno de teste com usurios. Primeiramente, quem est sendo testado a interface e no o usurio. Isto deve ser norma de conduta do avaliador e tambm ser informada claramente ao usurio. Ainda que o usurio saiba disto, a sesso de teste geralmente estressante para ele e dever do avaliador criar um clima o mais agradvel possvel para deix-lo vontade. A idia de participar de um teste pode amedrontar algumas pessoas e, por isto, usurios no devem ser obrigados a participar. Do mesmo modo, se um usurio desejar interromper o teste por qualquer motivo o avaliador no deve insistir no contrrio. Ensaios de interao costumam ter custo maior que o mtodo de avaliao heurstica e, por este motivo, recomenda-se que seja empregado a partir de prottipos funcionais. Este mtodo no substitui a avaliao heurstica e melhores resultados so obtidos quando ambas as tcnicas so empregadas em conjunto [16].

3. PROJETO DA INTERFACES CENTRADO NO APRENDIZ

O projeto da interface de um software educacional se confunde muito com a concepo do software como um todo. Isto porque um dos aspectos mais importante do software educacional a interao do aprendiz com o sistema e o dilogo que estabelecido entre as partes. Assim, a separao do que a interface do software e o que o software em si com freqncia no fcil. Um software educacional pode ser concebido considerando vrias estratgias de dilogo e de interao como, por exemplo, hiperhistrias, jogos educativos, ambientes de simulao, tutores inteligentes, exerccios ou questionrios eletrnicos, entre outras. A escolha da estratgia a ser adotada depende da abordagem pedaggica utilizada pelo professor para apresentar o contedo e qual o contexto de uso do software (ferramenta de apoio em sala de aula, em casa, ensino distncia, etc.). No cabe aqui discutir qual a melhor abordagem ou estratgia para a elaborao da interface do software educacional porque qualquer uma delas pode ser til dependendo da situao. Entretanto, argumentase que os parmetros como evoluo, diversidade e motivao, apresentados dentro da metodologia de Projeto Centrado no Aprendiz9 - PCA [3, 4, 18], podem ser utilizados como parmetros de sucesso de uma interface. O PCU foi desenvolvido como uma alternativa ao projeto centrado no usurio, cujo o foco principal garantir que as tarefas dos usurios sejam realizadas de maneira eficiente com o auxlio do computador. Esta porm uma viso limitada para software educacional porque no assegura que o usurio ir aprender com o software mesmo se sua interface de fcil interao. Enquanto esto utilizando uma interface de software educacional, alunos tambm so usurios e todos os princpios de PCU so vlidos. Porm, Soloway et al. [3] enfatizam que alunos tem necessidades especiais que devem ser consideradas na construo do software quanto a seu:
9

Crescimento (evoluo): aprendizagem um processo no qual o aluno desenvolve

sua experincia e seu conhecimento, o software educacional deve acompanhar o

PCA traduo para Learner-Centered Design LCD.

crescimento do conhecimento do usurio oferecendo novos desafios. O software deve no somente suportar a execuo de tarefas, como tambm, e principalmente, o aprendizado;
Diversidade: aprendizes constituem uma populao diversa, com diferentes graus de

conhecimento, habilidades, interesses, culturas e estilos de aprendizado. Estas diferenas constituem os maiores problemas na preparao de material didtico que, para ser til, deve oferecer ferramentas para suportar todos os tipos de aluno;
Motivao: os alunos precisam ser motivados a aprender com o software; a idia de

utilizar um computador pode tanto motivar os alunos como inibir aqueles menos afeitos a esta tecnologia. Em ambos casos, o aluno deve ser estimulado antes e durante a utilizao do software educacional, o que nem sempre uma tarefa facilmente alcanada. Estas necessidades especiais sugerem que o software educacional seja construdo com o uso de estruturas de apoio sobre as quais os alunos possam se envolver em atividades, que de outra forma, estariam alm de suas habilidades. Ambientes de modelagem e ferramenta de simulao que permitam aos alunos construir modelos a partir de situaes reais ou explorar diferentes representaes para um mesmo fenmeno, so exemplos de estratgias PCA na construo de software educacional [21]. A simulao de situaes reais desperta o interesse e envolve o aluno durante o processo de aprendizagem, o que pode ser exemplificado com o software Portugus para Estrangeiros [22] que utiliza-se deste artifcio no ensino da Lngua Portuguesa. A Figura 4 apresenta um dos exerccios de compreenso escrita do Portugus para Estrangeiros onde o aluno convidado a auxiliar o personagem principal na elaborao de uma festa de casamento (1 quadro). Para tanto, ele deve realizar um srie de tarefa (2 quadro) como, por exemplo, escolher os msicos para a festa (3 quadro). O resultado as aes do aluno sobre a interface determinam o final da histria (4 quadro). O resultado publicado em um jornal da cidade como feedback para que o aluno compreenda o que ele no fez corretamente e assim ele possa retomar o exerccio. Esta estratgia considerada conveniente ao aprendiz pelo fato dela permitir uma anlise a posteriori pelo aluno do seu erro, permitindo ao mesmo tempo conscientizao e reforo do exerccio.

FIGURA 4 Quadros do exerccio de compreenso escrita do Portugus para Estrangeiros, onde o aluno deve auxiliar nos preparativos de uma festa de casamento. Em todos os casos, observa-se que o desafio no desenvolvimento das ferramentas est na identificao de atividades que motivem e conduzam o aluno aquisio do seu conhecimento. Neste sentido, Soloway et. Al [3] sugerem um roteiro para desenvolver o software que comea com a definio do contexto, tarefas, ferramentas e interface do software, onde: contexto: descreve o ambiente onde o software educacional ser inserido, como ser utilizado e por quem; tarefas: identifica quais as tarefas que o software ir suportar; ferramentas: descreve quais ferramentas auxiliaro a realizao das tarefas; interface: define qual a interface para as ferramentas; Jackson [4] exemplifica a importncia destes componentes no desenvolvimento de uma ferramenta para suportar a construo e simulao de ambientes dinmicos chamada Model it. O objetivo desta ferramenta proporcionar ao aluno uma experincia prtica a partir da construo e observao de modelos, permitindo que eles possam construir modelos mentais prprios para explicar e compreender fenmenos observados. O Model it pode ser utilizado para descrever uma srie de modelos de fluxo de processo. A seguir, so descritos os componentes da ferramenta para um domnio especfico em ecologia : contexto: a ferramenta enfatiza a construo e o teste de modelos por alunos no final do curso bsico (stima e oitava sries). Os alunos devem estar envolvidos na investigao de questes como, por exemplo, "Qual a qualidade da nossa gua?" Para tanto, eles so envolvidos na coleta de dados sobre a qualidade da gua em um rio prximo. Aps a coleta de material, os dados so inseridos na ferramenta e analisados. Eles devem criar um modelo para o ecossistema em questo (um rio) considerando questes como o impacto de construes feitas pelo homem sobre o

curso do rio e a qualidade da gua com o aumento de resduos. A criao de tais modelos oferece desafios intelectuais e permite aos alunos decidir como planejar, projetar e trabalhar em seus modelos enquanto esto aprendendo. tarefas: a tarefa principal dos alunos nesta aplicao estabelecer relaes entre os dados coletados, criando um modelo. A ferramenta oferece alguns objetos grficos predefinidos como curso da gua, animais aquticos e plantas que podem ser utilizados para representar os dados coletados sobre o rio, tais como "fosfato", nmero de plantas e "qualidade da gua". A seguir, deve-se definir o relacionamento entre os fatores. ferramentas: as ferramentas devem ser adaptadas ao conhecimento do aluno sobre a tarefa. Assim, a tarefa "criar relacionamento entre fatores" pode ser realizada de diferentes maneiras, por exemplo, criando sentenas do tipo "...O aumento do componente fosfato diminui a qualidade do componente gua..." ou atravs de tabelas de valores que podem ser representados em um grfico. Os usurios podem ento escolher com quais ferramentas eles desejam trabalhar na construo do modelo. interface: este componente descreve como as ferramentas sero apresentadas visualmente na tela do computador ao aluno. Atravs da disposio, cores, e uso de elementos grficos os alunos devem ser conduzidos e estimulados a realizao da tarefa. Para criar um contexto que motive os alunos, foi adicionado como tela de fundo do programa uma foto do rio sobre o qual os alunos estavam estudando a qualidade da gua. importante ressaltar que o PCA ainda muito mais um conceito de concepo do software que uma metodologia de projeto. Neste sentido, o grupo de pesquisa de Soloway [3] tem trabalhado no desenvolvimento de regras e recomendaes para facilitar a concepo e a implementao de software educacional. Contudo, at o momento, a maior contribuio de PCA a criao de um conceito de projeto no qual a tarefa aprendizagem colocada em primeiro plano a partir de situaes/tarefas de apoio no software que permitam a aquisio de conhecimento.

4. EXTENSO AO CICLO DE VIDA DE PROJETO DE INTERFACES

Durante a avaliao de usabilidade e projeto de algumas interfaces para software educacional, verificou-se que a metodologia de projeto centrado no usurio precisava de algumas adaptaes para se utilizada com sucesso. A abordagem PCA descreve alguns dos requisitos de avaliao mas no fornece mtodos para o acompanhamento do projeto. Assim, os mtodos que auxiliam o projeto e avaliao de interfaces na abordagem PCU foram estendidos, como apresentado na Figura 5 para contemplar tambm requisitos da abordagem PCA. A extenso proposta aqui sugere modificaes na primeira etapa (conhecer usurios, alunos e suas tarefas) e na etapa de avaliao (avaliao multidisciplinar).

FIGURA 5 Ciclo de vida de PCU modificado. Considera-se que alunos so usurios com necessidades especiais que devem receber um tratamento diferenciado de usurios em geral. Estas necessidades dizem respeito a definio de contedos e abordagens pedaggicas utilizadas na construo da interface. Uma interface educacional, pode ter vrios tipos de usurios, alguns podem ser alunos e outros no, como por exemplo professores. Assim, nesta primeira etapa, devem ser identificados os diferentes grupos de usurios e quais suas necessidades. A diversidade de papis que as pessoas podem assumir dentro do contexto de uso de um software educacional pode ser grande. Os papis se modificam drasticamente se um mesmo software utilizado como ferramenta de suporte em sala de aula em um momento, e como ferramenta ldica em casa onde no h a superviso do professor. As necessidades do aprendiz com relao a interface nos dois casos acima so distintas; no primeiro o professor pode intervir e auxiliar nas dvidas do aprendiz guiando-o durante o aprendizado; no segundo a mesma interface deve suprir a ausncia do professor. Existem tambm casos de aprendizes que no fazem parte de um sistema formal de ensino, ou seja, no esto na escola. Neste caso, a figura de um professor ou facilitador pode no existir. Para estes aprendizes a aquisio do conhecimento no est diretamente relacionada a uma avaliao externa. Geralmente, estes usurios esto mais auto-motivados, porm, eles no conhecem, a priori, o assunto abordado. Alm disso, eles podem no saber quais tarefas so necessrias para facilitar o seu prprio processo de ensino-aprendizagem. De fato, mesmo muito difcil identificar quais tarefas despertam o processo de aprendizagem e esta, talvez seja a principal diferena entre software educacional e outros tipos de software, onde se tem tarefas bem conhecidas para a interface. Alunos so usurios para os quais devem-se prever subgrupos considerando a sua evoluo ou experincia. Numa escala simplificada pode-se delimitar grupos de alunos iniciante, intermedirio e avanado como ocorre com o CD-ROM Epilepsia10 (Figura 6), onde o contedo, linguagem e exemplos so diferenciados considerando o nvel do aprendiz. Em alguns casos a transio, ou evoluo, do aluno pode ser acompanhada pela interface que conduz um usurio iniciante at um nvel mais avanado. Em outros,
10

Ganhou Prmio de Primeiro Lugar na Categoria de Melhor Pacote Multimdia no 1 Concurso Nacional de Software Universitrio promovido pelo Softex 2000, CTI e UFMG em dezembro de 1996. Maiores informaes para a verso comercial com o Mdico Daniel Branco ou no endereo http://www.epilepsia.org.br/cd/index.htm

como no caso do CD-ROM Epilepsia, atende-se necessidades especficas de cada subgrupo de usurios identificados, muito embora a transio de um grupo para o outro no ocorra apenas com o auxlio da ferramenta.

FIGURA 6 CD-ROM Epilepsia. A diferenciao em subgrupos deve contemplar os requisitos para atender cada grupo individualmente, independentemente se a ferramenta acompanha a evoluo do aluno ou no. O importante identificar quais so as ferramentas mais adequadas para facilitar a aquisio de conhecimento de usurios com caractersticas comuns. Isto implica em definir requisitos tais como tarefas, contedo de informao, estilo de aprendizagem, linguagem para cada subgrupo de alunos ou perfil identificado. O contexto, tarefas, ferramentas e interface, conforme previsto na abordagem PCA, devem se utilizados para criar uma especificao detalhada da identificao do usurios e suas tarefas. Este grau de refinamento til especialmente durante a verificao de que tipo de tarefas e ferramentas so necessrios para contemplar a diversidade de alunos. No se pretende aqui fazer apologia personalizao de interface, mas sim considerar que, para contemplar a diversidade de usurios, ferramentas diferentes so necessrias. Em alguns casos, pode-se optar por disponibilizar vrias ferramentas numa mesma interface, considerando necessidades diferenciadas, e deixar os alunos escolherem quais dessas atendem melhor suas necessidades especficas. Em outros, tutores ou agentes da interface podem sugerir ou guiar o aprendiz considerando, por exemplo, suas respostas anteriores ou a sua navegao [22]. O problema como partida fria, ou seja a utilizao do software pela primeira vez por um novo aluno , evidentemente sem conhecimento do perfil do mesmo, pode ser atenuado com a introduo de esteretipos de alunos (iniciante, intermedirio e experiente) conforme foi feito no CD-ROM de Epilepsia.

Embora nossos trabalhos tenham envolvido principalmente avaliaes de usabilidade de interface, reconhece-se que no caso de interfaces para software educacional uma avaliao mais abrangente deve ser realizada. Deve-se avaliar, por exemplo, o interesse despertados nos alunos, adequao do contedo e abordagem pedaggica utilizada. Algumas experincias realizadas nos sugerem que os mtodos para a avaliao da usabilidade, descritos na seo 2, podem ser estendidos ou adaptados para avaliar outras aspectos da interfaces alm do contedo, como mencionado anteriormente. Um exemplo disto pode ser constatado durante a avaliao do STI, programa para ensino de teoria dos intervalos musicais [19]. Na avaliao do STI, foram empregados os mtodos de ensaio de interaes com 5 alunos da escola de msica Preldio e avaliao heurstica. A avaliao heurstica foi realizada por dois grupos de avaliadores, treinados previamente para realizar o teste: o primeiro especializado em msica e o segundo em interface. O objetivo daquele experimento foi verificar quais as diferenas entre os problemas identificados pelos dois grupos de avaliadores. Os resultados demonstraram que apenas os avaliadores especialistas em msica foram capazes de identificar alguns tipos de problemas, tais como o tamanho de algumas melodias muito grande para ser assimilado por alunos iniciantes e o intervalo tocado pelo programa no corresponde a informao apresentada na tela. Estes problemas foram classificados como sendo do domnio da aplicao e no de usabilidade da interface. Este estudo comprovou a nossa hiptese inicial de que o mtodo de avaliao heurstica poderia ser estendido para avaliar outros aspectos da interface. Alm disso, mostrou que professores podem ser facilmente treinados para a realizao do mtodo. Outros mtodos porm, podem ser necessrios para uma avaliao mais completa do software. No nos cabe discuti-los aqui, at porque os mtodos e metodologias de avaliao variam consideravelmente dependendo do tipo do domnio da aplicao. Mas o conjuntos destas avaliaes compem o que foi denominado no ciclo de vida de avaliao multidisciplinar. Nesta etapa, todos os mtodos devem ser utilizados em conjunto; isto porque a soluo de um problema de usabilidade pode alterar o projeto da ferramenta segundo a abordagem pedaggica escolhida, por exemplo. Ou o contrrio, a abordagem escolhida no pode ser implementada em funo da tecnologia sem que alguns problemas de usabilidade ocorram. Para resolver estes conflitos, todas as avaliaes devem ser realizadas em conjunto. Assim, uma equipe multidisciplinar (envolvendo especialistas em interface, professores, designers, etc.) pode discutir as alternativas para problemas visualizados de diferentes perspectivas. A etapa de avaliao continua a ser cclica como descrito no clico de vida de prototipao, ou seja, solues encontradas devem ser implementadas, avaliadas por diferentes mtodos e refeitas em um novo prottipo. Pode-se prever um escalonamento de modo que alguns mtodos de avaliao sejam utilizados nas primeiras avaliaes e outros apenas no final, considerando a adequao do mtodo fase de desenvolvimento em que empregado. Porm, a ateno deve ser redobrada para evitar situaes de conflito como descrito anteriormente.

Cabe ressaltar que o projeto de uma interface de software uma tarefa inerentemente multidisciplinar. No caso de software educacional, esta condio reforada pela presena de consultores do domnio de conhecimento especfico e de especialistas em educao. A abordagem PCU estimula a participao dos usurios tanto em reunies de projeto como na concepo e avaliao dos prottipos, sendo que o grau de participao dos usurios depende de cada projeto. A participao de especialistas de domnio na equipe deve ser acolhida de uma forma natural mas esta integrao nem sempre uma tarefa fcil. Geralmente, os projetistas de software no conhecem bem o domnio da aplicao e consideram que as sugestes dos professores so excessivas ou desnecessrias. Por outro lado, professores costumam esperar muito mais do que a tecnologia pode proporcionar. Os conflitos so reduzidos medida que ambos os grupos conheam as limitaes do outro, ou seja, quando os projetistas tornam-se dedicados estudantes do domnio de conhecimento e os professores participam de todas as etapas de desenvolvimento do software. Durante a etapa de avaliao, os dois grupos podem discutir sobre situaes reais e identificar seus requisitos e limitaes.

5. CONSIDERAES FINAIS
As lies mais importantes, extradas durante o desenvolvimento e avaliao de interfaces para software educacional pelo nosso grupo de pesquisas, so resumidas aqui. 5.1 Alunos como Usurios Na abordagem PCU tradicional, parte-se do pressuposto que o usurio conhece o domnio do software que est sendo construdo ou, pelo menos, tem uma idia de como o software lhe pode ser til. Como exemplos, pode-se citar um mdico que conhece o domnio da aplicao para um software de monitoramento cardaco, ou outro mdico que tem requisitos especiais para a organizao do seu programa de agenda de consultas. Porm, alunos no se encaixam em nenhuma das definies acima, pois eles no conhecem o domnio da aplicao (o contedo eles ainda esto aprendendo) e raramente conseguem expressar requisitos para a interface (eles, geralmente, no sabem o que lhes agrada ou no e por isso necessrio que a interface motive a utilizao). Alguns alunos podem fazer algumas sugestes positivas ou crticas que reflitam exatamente os problemas que esto ocorrendo durante a utilizao do software, mas isto deve ser esperado como exceo e no como regra. Num senso prtico, no suficiente perguntar ao aluno o que ele deseja na interface, mas sim extrair os requisitos por meio indireto observando a atividade de aprendizagem em sala de aula, por exemplo. Durante testes de usabilidade com usurios, normal esperar que os alunos apresentem um estresse maior, considerando que a avaliao de conhecimentos faz parte do atual processo de ensino/aprendizagem. Temos observado a preocupao dos alunos que participaram de algumas avaliaes de usabilidade. O temor de ser avaliado pode refletir negativamente sobre os resultados da avaliao e dever do experimentador, que organiza e conduz o teste, deixar os usurios o mais relaxados possvel. Para diminuir os riscos, pode-se adotar algumas medidas para o convite de alunos em testes de usabilidade: a) evitar alunos com vnculo aos membros da equipe projeto, especialmente

professores; b) realizar testes fora do ambiente escolar; c) convidar alunos de turmas e escolas diferentes; d) e, se possvel, realizar os testes fora do calendrio escolar. Estas medidas, porm, limitam a avaliao a uma amostragem aleatria onde informaes teis sobre a evoluo dos alunos durante e aps a utilizao da interface no so consideradas. O acompanhamento do aluno em seu processo de aprendizagem com a utilizao da interface pode ser melhor avaliado quando o prottipo estiver em um estgio avanado de desenvolvimento e puder ser utilizado em salas de aula, por exemplo. Quando o experimentador consegue criar um ambiente agradvel, os alunos costumam expressar suas idias e concepes de uso do software de forma expontnea, geralmente atravs de perguntas. Estas perguntas devem ser exploradas como fonte de requisitos para o software e potenciais problemas de usabilidade. Deve-se ter o cuidado, porm, de no responder as perguntas dos alunos como se eles estivessem sendo treinados para utilizar o software. Por exemplo, se o aluno pergunta Como eu posso escrever um intervalo num pauta musical?, o experimentador deve question-lo sobre o motivo desta pergunta, verificando se ocorreu por ele no ter encontrado esta opo na interface ou por no ter conseguido utilizar esta funcionalidade. 5.2 Professores como Usurios Professores devem ser considerados como usurios da interface quando: a) monitoram as atividades dos alunos com o software; ou b) quando utilizam a interface para preparao do material de aula utilizado pelo aluno. No primeiro caso, o professor pode ser definido como um supervisor externo que inspeciona o resultado do trabalho, mas no interage diretamente com o software. No segundo caso, o professor pode ter uma parte especial, um mdulo, que lhe permita supervisionar diretamente o andamento do trabalhos, configurar a interface para aplicaes especficas, criar novos desafios/exerccios, etc. Contudo, professores so usurios especiais porque conhecem ambos os domnios do problema e tem uma concepo de como apresenta-lo a outros usurios (os alunos). Como professores so uma fonte valiosa de experincia e sugestes para o projeto da interface, estes devem ser integrados equipe de projeto, participando das reunies, auxiliando na concepo de prottipos e acompanhando avaliaes de usabilidade. 5.3 Contexto de utilizao do software O contexto de utilizao deve estar bem definido no incio da concepo da aplicao. Em alguns casos pode no haver a figura de um professor ou facilitador para acompanhar ou auxiliar o aluno. A maioria dos exemplos utilizados aqui consideram o uso da interface dentro de um ambiente de sala de aula. Entretanto deve-se considerar outra situaes e ambientes de uso para interface tais como atividades extra classe, quando o professor ou o facilitador no est presente, ou interface de suporte para atividades de educao continuada. Os requisitos mudam de acordo com os contextos utilizados. Num exemplo mais simples, pode-se imaginar um software projetado para

auxiliar alunos em sala de aula com o acompanhamento de um professor que funcionara bem nesta situao mas pode falhar no uso individual em casa. Em alguns casos, como em interfaces WWW, o contexto pode ser dinmico. interessante observar que a utilizao da interface de um software educacional pode gerar expectativas nos usurios que estavam alm dos requisitos estabelecidos durante a sua concepo. Isto foi constatado com a interface WWW do ConVer11 [24], Figura 7, cujo objetivo auxiliar a aprendizagem da conjugao de verbos da Lngua Portuguesa.

FIGURA 7 Conjugao automtica do verbo preferir realizada pelo ConVer. Embora o objetivo inicial do ConVer fosse apresentar as formas e flexes verbais, com freqncia os usurios solicitavam auxlio, via correio eletrnico sobre como utiliz-las [25]. Cita-se o caso de um usurio que tinha dvidas sobre qual forma verbal do verbo preferir ele deveria utilizar, se preferisse, prefira ou preferiria. Isto demonstra que novos requisitos para o software podem aparecer apenas durante o uso e tornam-se fundamentais no processo de aprendizagem de alguns alunos. Em uma interface convencional esta situao no seria identificada facilmente pelos desenvolvedores e talvez no representasse um problema maior a sua utilizao. Uma interface WWW, porm, pode perder o seu significado ou utilidade para os usurios que enfrentam problemas que limitam o seu aprendizado. 5.4 Alunos como Participantes Sempre que possvel usurios reais devem participar do projeto da interface, no caso do software orientado ao aprendiz so os alunos este usurios. Esta participao pode ser mais abrangente do que apenas entrevistas para identificao de requisitos ou participao em testes de avaliao da interface. Usurios reais podem ser integrados equipe de projeto participando das reunies onde so discutidas as estratgias para
11

Disponvel por WWW em http://www.inf.ufrgs.br/~emiliano/conver/ .

soluo de problemas. Quando trata-se de usurios do tipo aluno esta participao deve ficar mais restrita porque eles no conhecem, a prior, o domnio do conhecimento envolvido. Em alguns casos o processo de construo do software pode fazer parte do processo de aprendizagem do aluno. Ferramentas para prototipao rpida como o HyperCard e o ToolBook podem ser facilmente aprendidas mesmo por usurios pouco experientes. Estas ferramentas so fontes de estmulo ao aluno, fornecendo estruturas de apoio (como sugere a abordagem PCA) para que o usurio desenvolva o seu prprio conhecimento. O estmulo despertado por este tipo de trabalho pode envolver mesmo outros alunos que no participaram diretamente da construo da interface, como ocorreu com o Atlas de Histologia12 desenvolvido por alunos de medicina da UFRGS (veja Figura 8).

FIGURA 8 ndice de contedos e exemplo de uma lmina do Atlas de Histologia. Com o Atlas de Histologia apresentado aqui, pretende-se argumentar o quanto usurios podem ser ativos na concepo e desenvolvimento de interfaces e, assim, poderiam perfeitamente participar como integrantes do grupo de projeto no desenvolvimento de novos sistemas. Contudo, isto nem sempre fcil devido a resistncia de alguns desenvolvedores participao de usurios. Por outro lado, dependendo do tipo de usurio podem haver algumas dificuldades inerentes falta de conhecimentos sobre o domnio da aplicao, como mencionado anteriormente. Tais situaes de conflito devem ser solucionadas caso a caso, no havendo regras gerais.

AGRADECIMENTOS

12

O Atlas de Histologia foi construdo enquanto os alunos cursavam a disciplina de Histologia Humana I em 1995/1. Ele est disponvel por http em www.ufrgs.br/morfologicas/atlas.html. Atualmente utilizado por estudantes de medicina da UFRGS e de outras instituies.

Agradecemos a Walter Cybis por ter permitido a publicao da figura 3 neste trabalho. s professoras Magda Bercht e Cora Pinto Ribeiro por suas valiosas sugestes e correes do texto e Margarete Schlater na orientao do prottipo Portugus para Estrangeiro. Enfim, agradecemos a todos os bolsistas, sem citar seus nomes para no correr o risco de esquecer os muitos que testaram e implementaram os softwares educacionais aqui referidos.

REFERNCIAS
1. BEVAN, N. Usability is Quality of Use. In: Symbiosis of Human and Artifact. Elsevier, 1995. p.349254. 2. WROBLEWSKI, D. A. The construction of Human-Computer Interfaces Considered as a Craft. In: Taking Software design Seriously (Karat, J. editor) Academic Press, Boston, 1991. p. 1-20. 3. SOLOWAY, E. et Al. Learning Theory in Practice: Case Studies of Learner-Centered Design. Proceedings of CHI96. ACM Press, Nova Iorque, 1996, pp. 189-196. 4. Jackson, S. L. (1995). The ScienceWare Modeler: A Learner-Centered Tool for Students Building Models, demonstration, ACM CHI '95 Human Factors in Computer Systems, Conference Companion, Denver, CO. 5. RUBIN, J. HandBook of Usability Testing. John Wiley, New York. 1994. 330 p. 6. NIELSEN, J. Usability Engineering. AP Professional. Boston. 1993. 362 p. 7. GELDENRMAN, M. The Relation Between User Satisfaction, Usage of Information System and Performance. Information & Management, Amsterdan, [s.n.], v.34, p.11-18, 1998. 8. MOLICH, R.; NIELSEN, J. Improving a Human-Computer Dialogue. Communications of the ACM, New York, v.33, n.3, p.338-348, Mar. 1990. 9. WHARTON, C. et al. The Cognitive Walkthrough Method: A Practicioner's Guide. In: Usability Inspections Methods. (Nielsen, J. and Mack, eds.)New York : John Wiley, 1994. p. 105-139. 10. KAHN, M. and Prail, A. Formal Usability Inspections In: Usability Inspections methods. New York : John Wiley, 1994. p. 141-169. 11. Chin, J. P., Diehl, V. A. and Norman, K. L. (1988). Development of na instrument measuring user satisfaction of the human-computer interface. Proceedings of SIGCHI '88, (pp. 213-218),

New York: ACM/SIGCHI. Tambm disponvel http://lap.umd.edu/lapfolder/papers/cdn.html (jun. 1998).

por

WWW

em

12. SIOCHI, A. C.; Ehrich, R. W. Computer Analysis of Users Interfaces Based on Repetition in Transcripts of users Sessions. ACM Transaction on Information System, New York, v.9, n.4, p. 309-335, Oct. 1991. 12. NIELSEN, J. The Use and Misuse of Focus Groups. Disponvel por WWW em http://www.useit.com/papers/focusgroups.html (set. 1997). 13. NIELSEN, J.; SANO, D. Sun Web: User Interface Design for Sun Microsystem's Internal Web. In Proceeding of the Second World Wide Web Conference '94. Computer Networks and ISDN Systems. V.28, n. 182. December 1992. 14. LOKUGE, I.; GILBERT, S. A.; RICHARDS, W. Structuring Information with Mental Models: A Tour of Boston. . Proceedings of CHI96. ACM Press, Nova Iorque, 1996, pp. 413-419. Disponvel por WWW em http://www.acm.org/sigchi/chi96/proceedings/papers/Lokuge/sag_txt.htm (jan. 1997). 15. KARAT, C. A Comparison of User Interface Evaluation Methods. In: Usability Inspections methods. New York : John Wiley, 1994. p. 203-233. 16. NEMETZ, F.; WINCKLER, M. A. A.; Lima, J. V. de. Evaluating Methods for Hypermedia Applications. In: ED-MEDIA & ED-TELECOM, 1997, Calgary - CA. Proceedings [S.l.:s.n.], 1997. 17. LEWIS, C.; RIEMAN, J. Task-Centered User Interface Design: A pratical Introduction. Disponvel por ftp anonymous em: ftp.cs.colorado.edu (jan. 1997). 18. Jackson, S. L., Krajcik, J. S., Soloway, E. (1998) The Design of Guided Learner-Adaptable Scaffolding in Interactive Learning Environments, ACM CHI '98 Human Factors in Computer Systems, Proceedings, Los Angeles, CA, Addison-Wesley, 187-194.

19. WINCKLER, M.; Nemetz, F.; Lima, J. V. de. Estudo de caso da aplicao do mtodo de avaliao heurstica em um projeto multidisciplinar. In Proceedings IHC'98, Maring - PR, de 12 a 13 de Outubro, 1998 21. Communication of the ACM 1996 August , v.39 n.8(entire issue) p.82-102. 22. PROKOPETZ, K.; LIMA, Jos Valdeni de.Navegao Personalizada de Hiperdocumentos em Ambientes de Ensino-Aprendizagem. Congresso Internacional de Informtica Educativa. Buenos Aires - Argentina. Outubro 1997. 23. GOLD, J.; LEWIS, C. Designing for Usability: Key Princriples and What Designers Think. Communication of the ACM, v.2 March 1985, pp.300-311. 24. PADILHA, E. G.; WINCKLER, M. A. A.; VICCARI, R. ConVer: a Conjugao Verbal pela WWW. In Proceedings... RIBIE98 IV Congresso Ibero-Americano de Informtica na Educao. Braslia DF, Outubro de 1998. 25. WINCKLER, M. A. A.; PADILHA, E.; LIMA, J. V. de. O Uso de uma Interface WWW para o ConVer: uma Ferramenta de Apoio ao Ensino da Conjugao Verbal. In Proceedings... TISE97 Taller Internacional de Software Educativo. Santiago Chile, Dezembro de 1997.