23 Avaliao Heurstica

Avaliao Heurstica
Even finding some problems is of course much better than finding no problems... Jakob Nielsen and Rolf Molich

1.

A avaliao

Existem basicamente 4 maneiras para se avaliar uma interface com usurio: formalmente, atravs de uma tcnica de anlise; automaticamente, por um procedimento computadorizado; empiricamente, por experimentos com testes de usurios; e heuristicamente, simplesmente percorrendo a interface e julgando-a de acordo com sua prpria opinio. Os princpios bsicos de usabilidade envolvem trs categorias principais: facilidade com que novos usurios podem efetivamente comear a interagir e alcanar mxima performance; multiplicidade de maneiras com que o usurio e o sistema trocam informao; e o nvel de suporte que o usurio tem para determinar seu sucesso e a avaliao de suas metas [Romani & Baranauskas, 1998]. A inteno bsica da avaliao identificar elementos que possam causar dificuldades ao usurio, porque violam princpios cognitivos conhecidos ou ignoram os resultados empricos j bem aceitos. So 3 as metas principais da avaliao: examinar a funcionalidade do sistema, o efeito da interface no usurio e identificar problemas especficos de design. O mtodo de avaliao heurstica foca na terceira meta, que relaciona tanto funcionalidade quanto usabilidade da interface. Trata-se de identificar os aspectos negativos do design: elementos que, quando usados em seu contexto intencional, causam resultados inesperados ou confuso entre os usurios [Romani & Baranauskas, 1998]. A avaliao heurstica envolve especialistas avaliando um design com base em um conjunto de critrios de usabilidade ou heursticas. O design examinado em busca de instncias nas quais esses critrios so violados. Um conjunto de critrios proposto originalmente por [Molich & Nielsen, 1990] inclui: Dilogo simples e natural; Falar a lngua do usurio; Minimizar a carga de memria do usurio; Consistncia; FeedBack; Sadas marcadas claramente; Atalhos; Mensagens de erro precisas e construtivas; Prevenir erros.

1.1

O custo-benefcio

Testes de usabilidade podem geralmente requerer custos muito altos. O mtodo descrito aqui tenta diminuir os custos da avaliao apenas prevendo aspectos de uso ao invs de observ-los diretamente. Esse mtodo no envolve usurios, mas sim, certa forma de

inspeo. Como no envolve usurios, a avaliao heurstica se torna um mtodo rpido e barato. Alm disso, no so necessrios equipamentos especiais. Molic e Nielsen [Molich & Nielsen, 1990] planejaram esse mtodo conhecido como avaliao heurstica, em resposta necessidade de mtodos de baixo custo que pudessem ser utilizados por pequenas empresas que no possuem facilidades, tempo, dinheiro ou pessoal treinado para a engenharia de usabilidade. Na avaliao heurstica, so utilizados avaliadores, no lugar dos usurios, que examinam o sistema ou prottipo, guiados por um conjunto de heursticas de alto nvel [Nielsen, 1992]. A avaliao heurstica uma tcnica analtica e informal, que faz parte da chamada discount usability engineering, um mtodo barato, rpido e fcil de usar. Alm disso, a literatura tem mostrado, em estudos experimentais comparativos com outras tcnicas de avaliao, que a avaliao heurstica tem apresentado melhores resultados, encontrando problemas mais srios com menos esforo despendido [Jeffries et. al., 1991] [Nielsen, 1994] [Romani & Baranauskas, 1998].

Figura 1 A curva mostra a razo custo-benefcio, i.e., quantas vezes os benefcios so maiores do que os custos. Por exemplo, a razo igual a 50 provavelmente corresponder para um custo de R$ 1.000, um benefcio de R$ 50.000.

1.2

Os avaliadores

Testes empricos realizados com diversos avaliadores em vrios estudos da literatura envolvendo o mtodo de avaliao heurstica induzem seguinte corrente de pensamento, na qual validaremos no nosso estudo de caso na Seo 3 adiante. Estudos iniciais em [Nielsen, 1989], [Molich & Nielsen, 1990] e [Nielsen & Molich, 1990] mostram que alguns avaliadores obtm resultados melhores do que outros, mas no se engane achando que os avaliadores ditos bons (mais qualificados, com mais experincia e maior conhecimento do domnio especfico) obtiveram melhores resultados que os ruins (iniciantes na engenharia de usabilidade). Esse o grande mrito do mtodo de avaliao heurstica, rpido, prtico, fcil de aprender e barato (por no despender de especialistas). Estudos mostraram que os bons avaliadores so mais eficientes, mas isso no indica que esses avaliadores conseguem descobrir todos os problemas dos avaliadores novatos. Em [Nielsen & Molich, 1990] e [Baker et. al., 2002] foram demonstrados que mesmo os avaliadores inexperientes conseguem descobrir problemas graves na interface, alm claro dos problemas mais fceis que os avaliadores mais experientes acabam s vezes passando

despercebidos. Estudos em diversas interfaces mostram que pessoas diferentes encontram diferentes problemas de usabilidade. A Figura 2 extrada de [Nielsen, 1994] e [Baker et. al., 2002] relacionadas a problemas em interfaces diferentes, comprovam a hiptese levantada anteriormente:

Figura 2 Cada linha representa um avaliador e cada coluna representa um problema de usabilidade. O quadrado preto representa se o problema foi encontrado pelo avaliador. Esses grficos mostram que mesmo avaliadores ruins conseguem encontrar os problemas mais graves, que so os mais importantes e o real objetivo de uma boa avaliao. Dessa forma, Nielsen conclui que a melhor forma de se realizar uma avaliao heurstica seria com um agregado de avaliadores escolhidos aleatoriamente, no importando o grau de conhecimento de cada avaliador. Ao final da avaliao individual, as listas de problemas de usabilidade devem ser reunidas e discutidas pelo grupo de avaliadores ou por um perito, para que seja feita uma nica lista com todos os problemas de usabilidade encontrados. Bom, descobrimos que no necessariamente precisamos de peritos para avaliar uma interface, mas quantos avaliadores devem ser usados para que obtenhamos um bom resultado? Essa pergunta foi bastante explorada na literatura, e podemos encontrar diversas respostas que entram em consenso [Nielsen & Molich, 1990] [Baker et. al., 2002]. De acordo com a Figura 3, conclui-se que so necessrios de 3 a 5 avaliadores para que sejam encontrados uma mdia de 60-80% dos problemas da interface avaliada. Pode parecer insuficiente, porm se voc considerar que se trata de um mtodo barato, intuitivo, de fcil motivao para faz-lo, no requer um plano avanado e, alm disso, possui rpida aplicao podemos concluir que um resultado muito bom. importante observar que, se desejar uma soluo melhor basta seguir a curva do grfico, ou seja, aumente o nmero de avaliadores, utilize tambm alguns avaliadores mais experientes e com maior conhecimento do domnio, mas tudo isso tem um preo, voc est disposto a pagar e ter tempo para isso? Lembre-se que achar algum problema melhor do que nenhum.

Figura 3

Proporo de problemas de usabilidade encontrados utilizando avaliao heurstica pela mdia de 6 estudos de caso [Nielsen, 1994].

Nielsen em [Nielsen, 1994] recomenda que sejam usados cinco avaliadores. Dessa forma, com a economia realizada, podem-se realizar outros mtodos de avaliao para que outros problemas sejam detectados ou mesmo para afirmar a eficincia do mtodo de avaliao heurstica [Nielsen & Molich, 1990], j que existe certa crtica em relao ao uso de mtodos no estatsticos, comprovado por [Lieberman, 2003] que teve um artigo rejeitado por no ser emprico o bastante.

2.

Mtodo de Avaliao Heurstica

De acordo com [Nielsen, 1993], cada avaliador normalmente faz duas ou mais iteraes sobre a interface para: Inspecionar o fluxo da interface de uma tela para outra, Inspecionar cada tela por vez contra as heursticas, examinando caractersticas como mensagens do sistema, dilogos e assim por diante dentro do escopo das heursticas. Uma sesso tpica ir durar entre uma e duas horas, mas se a interface for grande pode ser necessrio um tempo maior. Nas sesses de avaliao, cada avaliador conduz sua avaliao individualmente e independentemente dos outros avaliadores, ele no deve discutir com os outros at que todas as avaliaes estejam prontas. Quando todos os avaliadores terminarem, eles devem juntar seus problemas em apenas uma nica lista de problemas de usabilidade [Preece et. al., 1994]. O mtodo de avaliao heurstica deve ser visto como parte do processo de design interativo de uma interface. Ele envolve um pequeno conjunto de avaliadores examinando a interface e julgando suas caractersticas em face de reconhecidos princpios de usabilidade, as heursticas [Rocha & Baranauskas, 2000]. De modo geral, difcil de ser feita por um nico avaliador, porque uma nica pessoa nunca capaz de encontrar todos os problemas de usabilidade de uma interface. A literatura tem mostrado que diferentes pessoas encontram diferentes problemas, e, portanto se melhora significativamente os resultados da avaliao heurstica utilizando mltiplos avaliadores. A recomendao que se use de trs a cinco avaliadores (Seo 1.2) [Nielsen, 1992].

2.1

Heursticas revisadas

A avaliao heurstica feita em um primeiro momento individualmente. Durante a sesso de avaliao cada avaliador percorre a interface diversas vezes (pelo menos duas) inspecionando os diferentes componentes do dilogo e ao detectar problemas os relata associando-os claramente com as heursticas de usabilidade que foram violadas. As heursticas so regras gerais que objetivam descrever propriedades comuns de interfaces usveis e foram revisadas em [Nielsen, 1994]:

1. Esttica e design minimalista: dilogos no devem conter informao irrelevante ou

raramente necessria. Qualquer unidade de informao extra no dilogo ir competir com unidades relevantes de informao e diminuir sua visibilidade relativa. 2. Coerncia do sistema com o mundo real: o sistema precisa falar a linguagem do usurio, com palavras, frases, expresses e conceitos similares ao usurio, ao invs de termos orientados ao sistema. Seguir convenes do mundo real, fazendo com que a informao aparea numa ordem natural e lgica. 3. Reconhecimento ao invs de relembrana: tornar objetos, aes e opes visveis. O usurio no deve ter que lembrar informao de uma para outra parte do dilogo. Instrues para uso do sistema devem estar visveis e facilmente recuperveis quando necessrio. 4. Consistncia e padres: usurios no precisam adivinhar que diferentes palavras, situaes ou aes significam a mesma coisa. Seguir convenes de plataforma computacional. 5. Visibilidade do status do sistema: o sistema precisa manter os usurios informados sobre o que est acontecendo, fornecendo um feedback adequado dentro de um tempo razovel. 6. Controle do usurio e liberdade de opes: usurios frequentemente escolhem por engano funes do sistema e precisam ter claras sadas de emergncia para sair do estado indesejado sem ter que percorrer um extenso dilogo. Prover funes undo e redo. 7. Flexibilidade e eficincia de uso: usurios novatos se tornam peritos com o uso. Prover aceleradores de forma a aumentar a velocidade da interao. Permitir a usurios experientes atalhos em aes freqentes. 8. Ajudar usurios a reconhecer, diagnosticar e corrigir erros: mensagens de erro devem ser expressas em linguagem clara (sem cdigos) indicando precisamente o problema e construtivamente sugerindo uma soluo. 9. Preveno de erros: melhor que uma boa mensagem de erro um design cuidadoso o qual previne o erro antes dele acontecer. 10. Ajuda e documentao: embora seja melhor um sistema que possa ser usado sem documentao, necessrio prover uma Ajuda (Help) e uma documentao. Essas informaes devem ser fceis de encontrar, focalizadas na tarefa do usurio, listando os passos para se realizar a tarefa e no serem muito extensas.

2.2

Etapas da avaliao
Com base nestes princpios, os avaliadores passam a percorrer a interface e descrevem em formulrios os problemas nela encontrados. Nestes formulrios devem constar os problemas encontrados (descrio), seus tipos (princpios infringidos), como foram descobertos (aes executadas que levaram identificao dos problemas), grau de severidade e possvel soluo (opcional, pois no objetivo da avaliao). Etapas da avaliao heurstica:

1. Definio dos requisitos da avaliao: objeto, avaliadores, objetivos, escopo, aspecto,

recursos necessrios, etc.

2. Introduo: apresentao de informao aos avaliadores, incluindo objetivos,

princpios (heursticas) e material de apoio (formulrios, exemplos, manuais, etc.).

3. Avaliao da Interface: avaliadores testam a interface em busca de problemas de

usabilidade. Os problemas encontrados devem ser registrados.

4. Discusso: avaliadores e desenvolvedores (opcional) renem-se para discutir os

problemas detectados e atribuir um grau de severidade aos mesmos.

5. Apresentao dos resultados: divulgao dos problemas e determinao dos mais

graves, que devem ser corrigidos. Embora represente um aumento no custo, realizar uma avaliao heurstica sem especialistas em usabilidade impossvel. Ao menos um indivduo (orientador) necessrio para apresentar os princpios aos no-especialistas e realizar uma discusso para determinar a gravidade dos problemas. Tais discusses ocorrem aps as sesses de interao e correspondem exposio de problemas encontrados e atribuio consensual de graus de severidade aos mesmos. Independentemente do perfil e experincia dos avaliadores escolhidos, este mtodo exige que a interface esteja funcionalmente disponvel, ou seja, implementada, ao menos parcialmente ou como prottipo para que os avaliadores possam utiliz-la. Isto limita a aplicabilidade do mtodo em fases iniciais de um ciclo de desenvolvimento de interface, retardando a descoberta de problemas [Chan & Rocha, 1996].

2.3

Exemplos

A seguir, so apresentados alguns problemas detectados em avaliaes heursticas extrados de [Rocha & Baranauskas, 2000]: Exemplo 1 O antivrus Norton 2000 para NT Server um software projetado para proteger servidores de rede Windows NT de arquivos infectados por vrus. O software executado no servidor NT e sempre que se tenta gravar/abrir algum arquivo infectado no servidor, o programa apresenta uma mensagem na tela do servidor avisando que o arquivo est infectado, mas os usurios em estaes cliente NT no recebem esse aviso. Tem-se, portanto, a heurstica visibilidade do status do sistema violada. Consequentemente, quando o usurio trabalhando em uma estao cliente tenta gravar um arquivo infectado no servidor o antivrus impede a gravao e no emite nenhuma mensagem para a estao cliente e o usurio pode ento perder seu trabalho sem saber que isso est ocorrendo. O resultado a perda do arquivo, o que teria sido facilmente prevenido se alguma mensagem de alerta fosse exibida estao cliente. Claramente a heurstica ajudar usurios a reconhecer, diagnosticar e corrigir erros tambm violada. Pode-se dizer que a heurstica preveno de erros tambm no respeitada. Exemplo 2 No sistema Windows quando se quer instalar um novo componente de hardware iniciado um processo de busca e o indicador de deteco pode ficar parado por muito tempo, como indicado na janela de dilogo na Figura 4. O usurio fica perdido na maioria das vezes por no saber o que significa esse muito tempo e no sabe se deve ou no reiniciar o computador, mesmo porque usurios de sistemas semelhantes sabem quo pouco confivel a relao da barra de deteco com o real andamento da operao (visibilidade do status do sistema; ajudar usurios a reconhecer, diagnosticar e corrigir erros).

Figura 4 Exemplo 3

Deteco de hardware do sistema Windows 98.

O software Winzip em uma mesma verso gratuita (no registrada) tem uma tela de abertura onde os botes aparecem em ordem aleatria a cada execuo (Figura 5). Arbitrariamente os botes I Agree e Quit aparecem em ordem trocada levando o usurio a errar sem saber por que (consistncia e padres; preveno de erros).

Figura 5 Exemplo 4

Tela de abertura da cpia para avaliao do software Winzip.

No Windows Explorer, ao tentarmos excluir um arquivo que est em uso, uma caixa de dilogo aberta (Figura 6). Nessa caixa aparece a mensagem de que no foi possvel acessar o arquivo, e recomenda ao usurio que verifique se o disco est cheio ou protegido, e finalmente se o arquivo no est sendo usado. No h usurio que no se confunda: o que tem a ver disco cheio com excluir um arquivo (ajudar usurios a reconhecer, diagnosticar e corrigir erros)!

Figura 6 Exemplo 5

Mensagem de erro do Windows Explorer.

No Adobes ImageReady a mensagem de erro da Figura 7 apresentada para o usurio. A mensagem diz que a aplicao no pde ser iniciada porque um ponteiro estava nil.

Qualquer usurio que no tenha experincia com programao no consegue entender o real motivo do erro e nem corrigi-lo (coerncia do sistema com o mundo real; ajudar usurios a reconhecer, diagnosticar e corrigir erros).

Figura 7 Exemplo 6

Mensagem de erro do Adobes ImageReady.

No dilogo da Figura 8, a ferramenta Oracles SQL*Net Easy Configuration apresenta um problema de usabilidade, pois existe uma redundncia de funes (Cancel e Exit SQL*Net...). O usurio acaba ficando confuso, quando na verdade todas conduzem ao mesmo resultado (esttica e design minimalista).

Figura 8

Oracles SQL*Net Easy Configuration utility.

Com esses exemplos, podemos, de forma mais clara, perceber que o diagnstico de um problema associado com as heursticas que foram consideradas traz possibilidades concretas de redesign, embora esse no seja o principal objetivo desse mtodo.

2.4

Graus de severidade

O uso efetivo de uma lista de problemas de usabilidade ir requerer que esses problemas sejam priorizados com relao gravidade de cada problema. Prioridades so necessrias para no se despender esforos desproporcionais corrigindo problemas que no iro alterar em muito a interao do usurio com a interface. Graus de severidade so geralmente derivados do impacto gerado pelo problema tanto no usurio quanto no mercado. Por serem muitas vezes critrios dependentes da aplicao, a definio de graus de severidade no muito bem estabelecida na literatura, mas alguns autores do exemplos de como atribuir graus de severidade problemas de usabilidade [Nielsen, 1994]. Precisa ser estimado o custo associado implementao das sugestes de redesign. Certamente, problemas de usabilidade com alto grau de severidade devem ser corrigidos no interessando o quanto custe. Freqentemente, muitos dos problemas no muito graves podem ser corrigidos com alteraes mnimas de cdigo. Esse compromisso no pode ser considerado como parte do mtodo de inspeo de usabilidade, pois prefervel ter uma relao completa de todos os problemas sem o pr julgamento da viabilidade ou no da sua correo. Esta informao importante no momento em que forem alocados recursos para corrigir os problemas mais srios e se necessrio deixar os menos graves para uma nova verso. A gravidade de um problema a combinao de trs fatores:

A freqncia com que ele ocorre: se comum ou raro;

Impacto do problema quando ele ocorre: se fcil ou difcil para o usurio super-lo; A persistncia do problema: problema que ocorre uma nica vez e que o usurio pode superar desde que saiba que ele existe, ou se os usurios sero repetidamente incomodados por ele. Finalmente, claro que preciso considerar o impacto do problema no mercado, pois muitos problemas simples de serem superados tm um efeito importante na popularidade de um produto [Rocha & Baranauskas, 2000]. difcil conseguir uma boa estimativa de severidade por parte dos avaliadores durante uma sesso de avaliao heurstica, pois os avaliadores esto concentrados em encontrar novos problemas de usabilidade. Tambm, cada avaliador ir apenas encontrar um pequeno nmero de problemas, ento a classificao dos problemas do usurio estar incompleta em relao lista de problemas detectados. Ao invs disso, graus de severidade podem ser coletados atravs de questionrios entregues aos avaliadores depois das sesses de avaliao, listando todos os problemas de usabilidade descobertos, e pedindo a classificao de cada problema. Visto que cada avaliador s identificar um pequeno conjunto de problemas includos na lista, os problemas precisam estar bem descritos. As descries podem ser resumos das descries dos problemas encontrados pelos outros avaliadores. Essas descries permitem que os avaliadores avaliem os diversos problemas mesmo que eles no os tenham encontrado. Tipicamente, os avaliadores gastam apenas 30 minutos para fornecer seus graus de severidade. importante notar que cada avaliador deve fornecer seus prprios graus de severidade independentemente dos outros avaliadores. Geralmente, os avaliadores no tero acesso ao sistema enquanto eles esto considerando a severidade dos vrios problemas de usabilidade. possvel que os avaliadores consigam ganhar uma percepo adicional re-visitando partes da interface em execuo do que apenas contando com suas memrias e com as descries dos problemas. Ao mesmo tempo, no h dvida de que os avaliadores sero mais lentos se recorrerem a mais uma interao com o sistema. Alm disso, problemas de agenda iro certas vezes tornar difcil fornecer equipamentos para todos os avaliadores em uma hora conveniente se recursos especiais so necessrios para executar um sistema prottipo ou se a distribuio do software est limitada devido a certas restries (e.g. um projeto confidencial). Nielsen ressalta que graus de severidade fornecidos de apenas um avaliador no so confiveis. Quanto mais avaliadores fizerem o julgamento da severidade dos problemas de usabilidade, maior ser a qualidade da mdia de classificao de severidade, e o uso da mdia de classificao feita por trs avaliadores satisfatria para muitos propsitos prticos.

2.5

Extenso das heursticas originais

Alm das heursticas propostas originalmente por Molich e Nielsen em considerao a todos os elementos do dilogo, o avaliador, obviamente, pode considerar qualquer princpio de usabilidade adicional ou resultados relacionados que possam ser pertinentes a elementos de dilogo especfico. Alm disso, possvel desenvolver heursticas especficas de categoria que so aplicadas a uma classe especfica de produtos como complemento s heursticas gerais. Uma forma de construir uma lista suplementar de heursticas especficas de um domnio, executar uma anlise competitiva, testes com usurios em produtos existentes no domnio desejado e tentar abstrair princpios que explicam os problemas de usabilidade encontrados.

Diversos trabalhos foram realizados com o objetivo de estender as heursticas gerais [Romani & Baranauskas, 1998], [Baker et. al., 2001] e [Baker et. al., 2002]. Neles, foram discutidos princpios que visavam um escopo especfico de um determinado domnio para uma dada interface. Por exemplo, as heursticas utilizadas para avaliao de uma interface ditavam o escopo da avaliao, ou seja, em [Baker et. al., 2001] o alvo de avaliao era o quanto o seu ambiente de groupware motivava a colaborao entre os usurios. Para isso, so necessrias heursticas especficas para trabalho em equipe, ou seja, heursticas projetadas para identificar problemas de usabilidade especficos para trabalho em grupo, entre equipes separadas por uma grande distncia para trabalharem sobre uma interface de trabalho visual compartilhada. Uma das heursticas criadas era: Facilitar o descobrimento de colaboradores e estabelecer contato: a maioria dos encontros so informais, no programados, espontneos ou iniciados por uma pessoa. No dia-a-dia, estes encontros so facilitados pela proximidade fsica, onde indivduos prximos podem manter conscincia sobre quem est por perto. Pessoas freqentemente entram em contato com outra atravs de interaes casuais (e.g. se encontrando casualmente em um corredor) e so capazes de iniciar e conduzir a conversa sem esforo. No pouco tempo durante a conversa, muito pode acontecer, como a troca de informaes e coordenao de aes. Em comunidades eletrnicas, a falta de proximidade fsica significa que outros mecanismos so necessrios para suportar a conscincia e o encontro informal. Note que a heurstica acima no se encaixa nas heursticas gerais definidas anteriormente, esta avalia um domnio especfico. Veja que os avaliadores esto interessados em avaliar esta caracterstica da interface, o que impede uma perda de tempo e dinheiro avaliando aspectos da interface que no interessam aos usurios especficos da aplicao. Isso significa que as heursticas podem ser usadas para avaliao de um aspecto especfico da interface, elas mesmas ditam o escopo da avaliao. Da a importncia de uma escolha de bons princpios de avaliao. Em [Romani & Baranauskas, 1998] foram definidas heursticas para outro contexto. A interface sendo avaliada era um Sistema de Acompanhamento e Avaliao de Rebanhos Leiteiros (ProLeite), que usado na organizao das informaes de desempenho produtivo e reprodutivo dos animais de rebanhos leiteiros. O sistema possui grande quantidade de formulrios para entrada de dados, possibilita consultas e emisso de relatrios. Para atender a categoria de usurios no domnio considerado, que possuem pouca preciso para movimentos leves e precisos, pois so usurios acostumados a equipamentos pesados e rudes como a enxada, [Romani & Baranauskas, 1998] propuseram diversas heursticas que complementam as heursticas gerais. Uma das heursticas propostas era: Permitir opes de configurao: para facilitar o uso do mouse para usurios com dificuldade de manipulao deste perifrico, o sistema deve permitir alterar o tamanho dos botes para tamanhos maiores. Alm disso, o sistema deve permitir a alterao das cores dos rtulos e cor dos campos de entrada, para facilitar a leitura e prever a possibilidade de execuo do sistema em qualquer tipo de configurao de tela (por exemplo, 640X480, 800X600, fontes grandes e pequenas, etc) sem perda de qualidade dos dilogos. Mas nem tudo perfeito. A extenso das heursticas gerais tambm pode causar problemas. [Baker et. al., 2002] mostrou que a avaliao com as heursticas especficas para um domnio obteve um desempenho inferior s avaliaes realizadas com as heursticas gerais. Baker atribuiu esse resultado ao fato de que os avaliadores podem ter achado as heursticas especficas mais difceis de aprender e aplicar do que as heursticas de Nielsen. Mesmo assim, as heursticas especficas obtiveram um resultado satisfatrio considerando o custobenefcio da avaliao.

3.

Estudo de caso: OriOn

OriOn[1] um grupo de discusso utilizado na Universidade Federal de Ouro Preto para ensino e pesquisa da disciplina Sistemas Interativos. Um grupo de discusso uma localizao online onde as pessoas interagem com outras atravs da colocao e leitura de mensagens sobre tpicos de interesse pessoal e para a comunidade. O OriOn foi escolhido para realizar a avaliao heurstica justamente para explorar o poder da extenso das heursticas, pois para fazer esse estudo seria interessante definir heursticas especficas para o domnio em questo: comunidades online. Definida a interface que ser avaliada, seguiremos o processo de avaliao heurstica atravs das etapas de avaliao (Seo 3.1). Definidas as etapas do processo, devemos determinar o nmero de avaliadores que sero utilizados (Seo 3.2). Aps a realizao da avaliao e coleta dos dados, faremos a anlise dos resultados (Seo 3.4) comparando com trabalhos relacionados da rea [Nielsen & Molich, 1990] [Baker et. al., 2002].

3.1

Etapas da avaliao

As etapas para a avaliao heurstica sobre a interface do OriOn so as mesmas definidas na Seo 2.2, porm existe uma etapa adicional inicial para definir as heursticas especficas para comunidades online (discutidas na Seo 3.3). Os resultados de cada etapa do processo de avaliao heurstica sero discutidos na Seo 3.4. As etapas so:

1. Definio das heursticas: especficas para comunidades online, ditando o escopo da

avaliao;

2. Definio dos requisitos da avaliao: objeto de avaliao (OriOn), avaliadores (Seo

3.2);

3. Introduo: apresentao de informao do mtodo aos avaliadores, incluindo as

heursticas para comunidades online (Seo 3.3);

4. Avaliao da interface: os avaliadores testam a interface em busca de problemas que

infrinjam as heursticas apresentadas. Os problemas devem ser registrados;

5. Discusso: um orientador reunir todos os problemas encontrados pelos avaliadores e

eliminar os problemas redundantes. Atribuio de graus de severidade no ser necessria j que o objetivo do nosso estudo no corrigir a interface avaliada; 6. Apresentao dos resultados: divulgao dos resultados obtidos comparados com trabalhos relacionados [Nielsen & Molich, 1990] [Baker et. al., 2002].

3.2

Avaliadores

O objetivo desse estudo de caso fazer um comparativo com outros trabalhos que utilizaram a avaliao heurstica. Para isso, acompanhando a curva da Figura 3, foram necessrios apenas quatro avaliadores para realizar toda a avaliao de forma satisfatria. Os avaliadores foram selecionados entre estudantes do curso de Cincia da Computao que j fizeram alguma disciplina da rea de IHC. Assim, todos os avaliadores tiveram alguma experincia em relao aos conceitos de sistemas iterativos.

3.3

Heursticas

Para que a avaliao da interface do OriOn seja feita sobre os aspectos relevantes de uma comunidade online, foram definidas algumas heursticas que levam em considerao princpios como sociabilidade e usabilidade para ambientes online. Para isso, devemos lembrar que: Comunidades so dinmicas; mudam e evoluem constantemente, influenciadas pela personalidade dos participantes, atividades do grupo, e por algumas influncias

externas. Por exemplo, o que pode ser importante no incio de uma comunidade pode no ser mais tarde. Tecnologia no o fator mais importante em comunidades online. Membros so. A partir de guias definidos em [Preece, 2000] e de um estudo sobre as expectativas de usurios potenciais a respeito de grupos de discusso virtuais [da Silva et. al., 2003], podemos definir algumas heursticas:

1. Definir um propsito claramente: uma comunidade deve possuir um nome claro e

significativo e conter uma descrio clara e concisa sobre o seu propsito.

2. Prover acesso: para que os usurios tenham acesso comunidade necessrio que
seja descrito claramente os requerimentos tcnicos e outras informaes adicionais essenciais para o acesso dos usurios. No utilizar URLs longos e com caracteres incomuns. Utilizar cores padres para os links (e.g. azul, para links no seguidos, e vermelho, para links j visitados), a mudana dos padres pode causar confuso. Prevenir perodos longos de download, limitando o uso desnecessrio de grficos e animaes que podem se tornar cansativos para os usurios em futuros acessos. Facilitar a comunicao: ajudar os participantes a fazerem suas intenes claras provendo emoticons e um menu de gestos auxiliam o processo de comunicao. Prover ferramentas de edio (e.g. fontes, smbolos, verificador ortogrfico, etc.) para a postagem de falas. Disponibilizar diferentes formas de visualizao e estruturao da discusso para que cada usurio se sinta confortvel com a de sua preferncia. Deve-se distinguir as mensagens que j foram lidas das que ainda no foram. Permitir que seja realizado um certo tipo de filtragem de informao e fornecer resumos sobre as discusses. Motivar a comunidade: as discusses em uma comunidade online devem ter um auxlio para que sejam efetivas para todo o grupo de discusso. Para isso, deve-se encorajar a confiana, empatia e cooperao dos participantes. Focar no propsito da comunidade aumenta a proximidade entre os membros. Estabelecer polticas, para encorajar o processo de comunicao, ajuda a conter agresses e outros tipos de comportamentos inapropriados. Definir uma poltica de registro: deve-se definir uma poltica de registro de novos usurios, bem como uma poltica que permita ou no a entrada de visitantes na comunidade. Os procedimentos de registro e login devem ser realizados com o menor nmero de passos possveis e descritos claramente. Incluir uma ajuda para essas atividades auxilia o processo, bem como uma forma de usurios recuperarem e modificarem suas senhas de maneira rpida, fcil e segura. Garantir segurana: uma comunidade deve proteger informao confidencial. Para isso, toda informao, das discusses realizadas, deve permanecer na comunidade e todos os membros devem concordar com uma poltica de privacidade. Navegao: deve-se prevenir a ocorrncia de pginas rfs, que no esto ligadas ao site da comunidade, levando os usurios a becos sem sada. Para que a navegao ocorra de forma satisfatria, deve-se fornecer um suporte, ou seja, um mapa de site claramente definido. Esse mapa deve aparecer em qualquer lugar que o usurio esteja no site, para que auxilie os usurios a criarem um modelo mental de como partes diferentes do site se inter-relacionam. Consistncia das informaes: manter as informaes atualizadas e completas. Manter a consistncia tambm muito importante (terminologias, fontes, nome de menus, navegao, etc.). Participao na gesto: lembre-se de que quem mantm a comunidade so os seus membros, por isso, deve existir algum mecanismo que delegue alguma forma de gesto para os membros da comunidade. Decises de acesso, por visitantes, s

3.

4.

5.

6. 7.

8. 9.

discusses do grupo; decises a respeito de membros que no contribuem nas discusses; decises sobre a aparncia do grupo, etc.

3.4

Resultados

Depois de realizada a avaliao e coletados os problemas encontrados pelos avaliadores, os problemas redundantes foram eliminados e o restante dos problemas foram contabilizados em um total de 17 infraes das heursticas para comunidades online: Problema 1. No existe como opo exibir o nome do grupo e muito menos uma descrio clara sobre o seu propsito. O usurio que est entrando no grupo, no tem como saber qual o seu propsito (Figura 9). Antes de logar ou de cadastrar, o usurio no tem nenhuma descrio sobre do que se trata o grupo, e nem em qual est cadastrado, mesmo depois de estar logado, ele no tem nenhuma descrio do grupo. Uma soluo seria para todos os grupos, colocar uma breve descrio do grupo, com os seus propsitos bem claros para o que o usurio possa saber se realmente o que ele esperava. (Definir um propsito claramente).

Figura 9

Tela inicial do OriOn.

Problema 2. O ambiente possui um nome claro (OriOn - Orientao Online), mas no possui uma descrio clara sobre o ambiente (Figura 9). Somente quem o conhece ou quem de inicio explora o OriOn, observando a disposio das informaes, sabe que se trata de um ambiente de discusso on-line. Poderia haver um link "Sobre" para uma tela com um pargrafo ou um pequeno texto descrevendo o OriOn. (Definir um propsito claramente). Problema 3. O OriOn no possui uma descrio dos requisitos mnimos de sistema para uma execuo adequada do ambiente (Figura 9). Deveria ser disponibilizado na tela de login um link para uma descrio dos requisitos mnimos do sistema. Caso este for pequeno (uma frase), talvez seja interessante disponibilizar na prpria tela de login (e.g. no rodap da tela). (Prover Acesso). Problema 4. H no Orion muitas imagens pesadas que so carregadas toda vez que se abre uma nova tela (Figura 10). Desta forma uma conexo lenta pode ter dificuldades para carregar as telas do OriOn e a interao com o ambiente se torna cansativa e desestimulante. Definir frames (HTML) para que certas partes do ambiente, com imagens pesadas, no sejam recarregadas novamente com a interao (e.g. a barra de ttulo e a barra de opes lateral direita) pode ajudar. (Prover Acesso).

Figura 10

Tela de Temas e Assuntos.

Problema 5. Na pgina inicial e em outras pginas do Orion, alguns links tm a cor vermelha mesmo que nunca tenham sido visitados. Ex.: na pgina inicial, o link cadastrese aqui vermelho, mesmo que o usurio nunca tenha tentado se cadastrar (Figura 9). Colocar os links com cores padres. Ex.: Azul para links nunca clicados, vermelho para links j visitados. (Prover Acesso). Problema 6. No existe um editor para a postagem de falas (Figura 11). Criar um editor completo com verificador ortogrfico, barra de ferramentas, emoticos e menu de gestos para facilitar a postagem de falas e tornando a discusso mais agradvel. (Facilitar a comunicao).

Figura 11

Tela para postar fala.

Problema 7. O OriOn possui uma nica maneira de visualizar as discusses (Figura 12). Esse layout de apresentao das discusses pode agradar alguns membros, mas outros podem se sentir incomodados ou no gostar do mesmo layout. Para aumentar a proximidade entre um membro e o ambiente, poderia haver outros layouts disponveis para personalizao do OriOn. O membro deveria escolher o que mais lhe agradaria na tela de

edio de perfil. Um tipo interessante de visualizao a visualizao em rvore que permite uma viso geral do andamento da discusso e facilita a identificao dos pontos onde a discusso est mais polmica. (Facilitar a comunicao).

Figura 12

Visualizao da discusso.

Problema 8. H um mecanismo que avisa a um membro que existem novas falas (i.e. no lidas) e atravs da interao na tela de Temas e Assuntos o mesmo descobre em qual discusso que elas ocorreram, mas dentro da discusso no existe uma forma de distinguir falas novas de falas j lidas (Figura 13). Para resolver este problema, as falas novas poderiam ser apresentadas com um fundo de cor diferente, ou at mesmo, o texto em cor diferente. Isto para que esta fala se destaque em relao s outras. (Facilitar a comunicao).

Figura 13

Visualizao da discusso, informao das novidades e sistema de busca.

Problema 9. Existe uma ferramenta para a filtragem da discusso, contudo, a ferramenta no d muitas opes para o usurio (Figura 13). Criar uma ferramenta completa, para filtragem, utilizando tcnicas mais especializadas, para esta funo, para facilitar a procura

do usurio por certos termos em determinado perodo de tempo e por usurios especficos. (Facilitar a comunicao). Problema 10. No existe no OriOn um mecanismo de gerao de resumo das discusses. Para que um novo membro obtenha uma leitura geral das discusses, este deve percorrer as discusses fazendo uma leitura das falas. Uma forma rpida de obter esta leitura geral seria muito interessante. Para uma soluo parcial, a criao de uma ferramenta que fornea uma interface para a impresso amigvel da discusso. (Facilitar a comunicao). Problema 11. No existe uma forma de motivao para que os usurios participem mais e melhor do Orion. A comunidade no tem uma pessoa que fica responsvel por ficar motivando, ficar sempre observando e continuando o assunto tentando fazer com que os membros tambm participem. Promover premiaes ou bonificaes para os usurios que mais e melhor participarem, serve de estmulo para que o usurio sempre participe veementemente de forma sria e respeitosa. Tambm pode-se escolher um motivador, ou sempre ir revezando entre os membros. (Motivar a comunidade). Problema 12. O usurio no consegue mudar sua senha, ou caso tenha esquecido no tem como recuperar, a no ser entrar em contato com o administrador, esperando at que ele possa passar uma nova senha. Fornecer uma opo segura para mudana e modificao de senha pelo usurio. (Definir uma poltica de registro). Problema 13. No existe no OriOn um mecanismo de registro on-line. Novos membros para obterem acesso devem procurar os gestores, administradores do ambiente para conseguir o acesso como membro. Definir um mecanismo de registro disponibilizado na tela de login do OriOn. Desta forma, novos usurios poderiam ser adicionados de forma mais dinmica, mas claro, somente com a liberao dos gestores e/ou administradores. (Definir uma poltica de registro). Problema 14. No existe uma poltica de privacidade. Os usurios no sabem quais so as polticas e regras quanto privacidade no grupo. Quando o usurio cadastrar, ele ter que aceitar a poltica de privacidade, para que esteja sabendo como funciona o grupo e da punio aos usurios que desrespeit-la. (Garantir segurana). Problema 15. No existe um mapa do site para facilitar a navegao dos usurios. Criar um mapa do site mostrando a estrutura do site para facilitar a navegao dos usurios. (Navegao). Problema 16. No existe nenhum mecanismo que delegue aos usurios uma participao na gesto do grupo. Os usurios simplesmente postam informaes. Possibilitar aos usurios uma participao na gesto, como polticas de acesso pelos visitantes e decises sobre membros que no contribuem nas discusses. Com a participao na gesto o usurio fica mais motivado a participar do grupo. Os usurios poderiam modificar a aparncia do grupo em conjunto e algumas funcionalidades, para o grupo ter a "cara" de seus usurios. (Participao na gesto). Problema 17. No OriOn, no existe um mecanismo explcito para definir quem est moderando ou gerindo as discusses. O simples fato de que um membro criou uma discusso, no impe que esta ir moderar esta discusso. No existe uma definio de papis no OriOn (e.g., moderador, membro, visitante). Na atual situao, todos que tem acesso no OriOn so todos membros de igual poderes. A definio de tipos de usurios diferentes poderia solucionar esta questo. Poderia haver: moderadores, membros e visitantes. Os moderadores poderiam ser eleitos atravs de uma votao entre os membros do OriOn, de forma rotativa. Estes teriam a responsabilidade de manter as discusses ativas, levantando questes, intimando os membros a participarem etc. Os membros poderiam: eleger os moderadores, tornar-se moderadores por um certo tempo e participar

das discusses. Os visitantes somente poderiam visualizar as discusses, sem nenhum direito dentro do ambiente (e.g., postar falas, criar discusses etc). (Participao na gesto). Analisando o nmero de problemas encontrados por cada avaliador, podemos construir o seguinte grfico:

Figura 14

Proporo de problemas de usabilidade encontrados utilizando avaliao heurstica no OriOn.

A Figura 14 corresponde com a curva da Figura 3, demonstrando que a avaliao heurstica realmente necessita de poucos avaliadores (pelo menos trs) para achar uma mdia entre 60-80% dos problemas da interface avaliada. Alm disso, analisando de perto quais problemas cada avaliador encontrou, podemos construir outro grfico que tambm demonstra certa correspondncia com os resultados da literatura, validando certos aspectos da avaliao heurstica:

Figura 15 Cada linha representa um avaliador e cada coluna representa um problema de usabilidade. O quadrado preto representa se o problema foi encontrado pelo avaliador. A Figura 15 comprova a nossa hiptese levantada na Seo 1.2 de que pessoas diferentes encontram diferentes problemas de usabilidade. Os avaliadores ditos bem sucedidos acabam s vezes deixando os problemas fceis para trs, enquanto que os avaliadores ditos malsucedidos tambm conseguem encontrar os problemas difceis mesmo tendo encontrado menos problemas que os avaliadores em geral.

4.

Concluses

Os resultados de uma avaliao heurstica vo ser muito melhores se no for utilizado apenas um avaliador, e se os avaliadores utilizados no mantiverem nenhum contato entre si. O nmero de problemas de usabilidade encontrados por um agregado de avaliadores cresce rapidamente no intervalo entre um e cinco avaliadores, mas esse crescimento diminui prximo a dez avaliadores. A partir do estudo de caso feito e dos experimentos de outros autores, podemos concluir que a avaliao heurstica pode ser realizada de forma satisfatria utilizando-se de trs a cinco avaliadores.

As maiores vantagens da avaliao heurstica so: Mtodo de baixo custo; Mtodo rpido; Mtodo fcil de aplicar e de entender; Bom para descobrir que existem desfalques na interface; Bom para delimitar o escopo da avaliao.

As desvantagens da avaliao heurstica so: Dependncia das heursticas para se realizar a avaliao; Ainda no foram definidas heursticas para todos os tipos de interface; Heursticas ruins ou difceis levam a uma avaliao de baixa qualidade;

Os avaliadores, geralmente, se limitam aos exemplos de problemas apresentados nas heursticas, diminuindo o poder de alcance das mesmas; No existe a preocupao com a interpretao do avaliador, s existe o erro se a interface no respeitar a heurstica. Esse estudo realizado sobre o mtodo de avaliao heurstica comprovou a sua eficincia, mediante ao baixo custo e curto prazo de tempo para se realizar uma avaliao com um nmero pequeno de avaliadores e encontrando um nmero satisfatrio de problemas na interface. O mtodo simples e fcil de aprender, porm a avaliao fica altamente dependente da utilizao de boas heursticas. Sendo que essas mesmas heursticas podem prejudicar a qualidade da avaliao realizada pelos avaliadores, pois muitos avaliadores ficam presos apenas aos exemplos apresentados para uma determinada heurstica, no explorando o seu verdadeiro potencial. Isso s comprova que a avaliao fica restrita as heursticas e suas sugestes, o que pode tornar a avaliao um tanto quanto limitada, pois no levada em considerao a interpretao do avaliador em relao aos elementos da interface, levando erros ainda desconhecidos pela heurstica a nunca serem descobertos.

Exerccios
1. Um sistema de resposta por voz, um sistema computacional acessado atravs de um telefone. O sistema, chamado aqui de Sistema Bancrio, uma interface operada pelo telefone para acesso conta do usurio. A tarefa do usurio no dilogo de exemplo foi transferir R$ 1.000 da poupana para a conta corrente do prprio usurio. As nicas opes de entrada do usurio so 12 botes iguais aos de um telefone comum (os dgitos 0-9 e os caracteres especiais * e #). A nica resposta do sistema atravs de fala e algumas vezes efeitos sonoros. A tecla # significa o fim da entrada do usurio. Enquanto o usurio no pressionou a tecla #, possvel pressionar duas vezes a tecla * para corrigir a entrada. Um exemplo de dilogo entre um usurio (U) e o Sistema Bancrio (S) mostrado a seguir: (1) S: Entre um para informao sobre conta, trs para transferncias entre suas prprias contas, ... (2) U: 3# {o usurio interrompe o sistema} (3) S: Entre a conta de origem da transferncia (4) U: 1234567890# {nmero da poupana} (5) S: Entre a conta destino da transferncia

(6) U: # {uma abreviao para conta corrente} (7) S: Entre com o valor em centavos (8) U: 100000# (9) S: Do nmero de conta doze, trinta e quatro, cinqenta e seis, setenta e oito, noventa, para o nmero de conta, conta primria, uma transferncia de um mil reais est para ser feita. Pressione um para confirmar, zero para cancelar. (10) U: 1# (11) S: Voc no tem acesso para usar esta funo. Os nmeros dos enunciados no fazem parte do dilogo, apenas so usados para referenciar enunciados individuais. Tente encontrar problemas de usabilidade utilizando o mtodo de avaliao heurstica atravs das nove heursticas originais. Dica: conhecido um total de 16 problemas [Nielsen, 1992]. 2. Sua tarefa aconselhar uma companhia sobre a qualidade do dilogo humanocomputador de um de seus sistemas. A administrao da companhia quer ter certeza que usurios inexperientes conseguiro obter resultados rapidamente quando usarem o sistema. Com isso em mente, voc deve apontar o mximo de problemas de usabilidade no dilogo utilizando o mtodo de avaliao heurstica atravs das nove heursticas originais. A funcionalidade bsica do sistema pr-determinada. O propsito deste exerccio criticar o dilogo do sistema e no sua funcionalidade. Novas funes possivelmente elevaro a usabilidade do sistema mas sugestes para novas ou mudanas nas funes no fazem parte desse exerccio. Sua soluo deve consistir de uma lista com todos os problemas de usabilidade que voc pde encontrar no dilogo. Voc pode incluir sugestes de como aperfeioar o dilogo para evitar os problemas e at pode especificar um dilogo aprimorado. Seu objetivo principal articular os problemas de usabilidade identificados, do que meramente indicar para eles mudanas em um design alternativo. O Sistema de Catlogo Telefnico Este sistema parte de um servio da Manhattan Telephone (MANTEL) [2] para usurios domsticos. Usurios tpicos tm pouco conhecimento sobre processamento de dados. Eles podem discar para o sistema, que prover o nome e endereo de um assinante nos Estados Unidos, dado o nmero de telefone do assinante. Para simplificar o exerccio, ns fizemos as seguintes suposies. Para cada nmero de telefone, temos somente um assinante. Todos os nmeros de telefone consistem de exatamente dez dgitos (3 dgitos para cdigo de rea e os outros 7 dgitos para o nmero). O computador do usurio possui um monitor alfanumrico, monocromtico com 24 linhas de 80 caracteres cada e um teclado com teclas extras encontradas na maioria dos teclados, incluindo 10 teclas de funes marcadas como PF1-PF10. Uma tela mostrada na figura abaixo:

Especificao O usurio entra neste sistema selecionando Catlogo de Telefone a partir do menu principal do MANTEL. O sistema ento lana o seguinte prompt: ENTRE O N DE TELEFONE DESEJADO E ENTER Se o usurio entrar com qualquer coisa que no seja exatamente dez dgitos, o sistema responde: NMERO ILEGAL. TENTE NOVAMENTE! Se o usurio entra com um nmero de telefone que no est em uso, o sistema responde: NMERO DE TELEFONE DESCONHECIDO Se o cdigo de rea do telefone 212 (cdigo de rea de Manhattan), o sistema ir normalmente mostrar a tela correspondente a figura anterior em cinco segundos. Para outros cdigos de rea, o sistema precisa recuperar a informao necessria de bancos de dados externos; isto pode durar cerca de 30 segundos. Dica: so conhecidos 29 problemas. Para ajud-lo a iniciar a avaliao, aqui est um dos problemas de usabilidade, bem como uma sugesto de como melhorar o dilogo: O design da tela usa apenas letras maisculas, apesar de que ns sabemos que estudos sobre fatores humanos alertam que a mistura de letras maisculas e minsculas muito mais legvel. Est OK usar letras maisculas para um nmero limitado de palavras que voc queira enfatizar [Molich & Nielsen, 1990].

Referncias Bibliogrficas
[Baker et. al., 2001] Baker, K., Greenberg, S. e Gutwin, C. Heuristic Evaluation of Groupware Based on the Mechanics of Collaboration. Proceedings of the 8th IFIP Working Conference on Engineering for Human-Computer Interaction (EHCI01). (Maio 11-13, Toronto, Canada), 2001. [Baker et. al., 2002] Baker, K., Greenberg, S. e Gutwin, C. Empirical Development of a Heuristic Evaluation Methodology for Shared Workspace Groupware. Proceedings CSCW02. (Novembro 16-20, New Orleans, Louisiana, USA), 2002.

[Chan & Rocha, 1996] Chan, S. e Rocha, H. V. Estudo comparativo de mtodos para avaliao de interfaces homem-computador. Relatrio Tcnico IC-96-05, 1996. [da Silva et. al., 2003] da Silva, E. J., Nicolaci-da-Costa, A. M., de Souza, C. S., Prates, R. O. Expectativas de usurios potenciais a respeito de grupos virtuais de discusso. [Jeffries et. al., 1991] Jeffries, R., Miller, J. R., Wharton, C., Uyeda, K. M. User Interface Evaluation in the Real World: A Comparison of Four Techniques. Em ACM CHI Conference Proceedings, pp. 119-124, 1991. [Lieberman, 2003] Lieberman, H. The Tyranny of Evaluation. MIT Media Lab. Disponvel em: http://web.media.mit.edu/~lieber/Misc/Tyranny-Evaluation.html. Acessado em: 26 de Abril de 2005. [Molich & Nielsen, 1990] Molich, R. e Nielsen, J. Improving a human-computer dialogue. Communications of the ACM 33, 3 Maro, 338-348, 1990. [Nielsen & Molich, 1990] Nielsen, J. e Molich, R. Heuristic Evaluation of User Interfaces. Proceedings ACM CHI90 (Seattle, WA, 1-5 Abril): 249-256, 1990. [Nielsen, 1989] Nielsen, J. Usability engineering at a discount. Em G. Salvendy et.al. (eds.), Designing and Using Human-Computer Interfaces and Knowledge Based Systems. Amsterdan: Elsevier Science Publishers, 1989. [Nielsen, 1992] Nielsen, J. Finding usability problems through heuristic evaluation. Proceedings ACM CHI92 Conference (Monterey, CA, 3-7 Maio): 373-380, 1992. [Nielsen, 1993] Nielsen, J. Usability Engineering. Academic Press, Cambridge, MA, 1993. [Nielsen, 1994] Nielsen, J. Heuristic Evaluation. Em J. Nielsen (ed.) Usability Inspection Methods. John Wiley, New York, 1994. [Preece et. al., 1994] Preece, J., Sharp, H., Benyon, D., Holland, S., Carey, T. HumanComputer Interaction, Addison Wesley, 1994. [Preece, 2000] Preece, J. Online Communities: Designing usability, supporting sociability. John Wiley & Sons, Ltd. [Rocha & Baranauskas, 2000] Rocha, H. V. e Baranauskas, M. C. C. Design e Avaliao de Interfaces Humano-Computador. So Paulo, 2000. [Romani & Baranauskas, 1998] Romani, L. S. e Baranauskas, M. C. C. Avaliao heurstica de um sistema altamente dependente do domnio. Relatrio Tcnico IC-98-26, Julho, 1998.

[1] www.orion.iceb.ufop.br [2] O nome MANTEL e o sistema foram inventados somente para o propsito deste exerccio. Qualquer relao
com companhias ou servios de informaes existentes mera coincidncia.