Avaliao de Usabilidade de Sites Web

Marco Winckler
1
Marcelo Soares Pimenta
2
Resumo:
Desde a inveno da Web, a tecnologia para construo de interfaces Web vem sendo progressivamente
incrementada permitindo o desenvolvimento de aplicaes cada vez mais complexas que utilizam a Web
no apenas para troca de informaes, mas como plataforma para aplicaes distribudas tais como
comrcio eletrnico e intranets. Durante este processo evolutivo, o nmero de usurios e de sites Web
cresceram exponencialmente. A Web tornou-se acessvel a todas as pessoas, e conta com uma grande
variedade de aplicaes. Contudo, observa-se que tal popularidade no implica necessariamente em
satisfao dos usurios. Muitos sites Web so visitados uma nica vez no porque o contedo do site no
seja interessante mas sim porque eles foram incapazes de encontrar a informao desejada , um dos
problemas de usabilidade tpicos mais relatados por usurios.
Usabilidade o termo tcnico usado para descrever a qualidade de uso de uma interface. Quando a
usabilidade levada em conta durante o processo de desenvolvimento de interfaces Web, vrios
problemas podem ser eliminados como, por exemplo, pode-se reduzir o tempo de acesso informao,
tornar informaes facilmente disponveis aos usurios e evitar a frustrao de no encontrar informaes
no site.
A tendncia atual em avaliao tentar identificar os problemas de usabilidade to logo eles possam ser
detectados na interface. Uma vez identificado, o problema pode ser solucionado ou, ao menos, seus
efeitos podem ser minimizados. Existe uma srie de mtodos de avaliao que podem ser utilizados em
diferentes etapas do desenvolvimento de interfaces Web.
O objetivo principal deste trabalho descrever o processo de avaliao de usabilidade de interfaces Web
e alguns mtodos e ferramentas que podem ser utilizados neste processo. Para contextualizar este assunto,
na parte inicial do captulo so apresentados alguns tpicos importantes tais como a caracterizao de
problemas de usabilidade, as peculiaridades do ambiente Web e suas aplicaes assim como uma viso
panormica sobre concepo de interfaces Web, com a inteno de permitir uma compreenso melhor dos
objetivos e procedimentos envolvidos na avaliao.
1. Introduo
Desde que foi criada por Tim Berners-Lee em 1989, a World Wide Web, WWW
ou simplesmente Web, foi criada no final dos anos 90 por nos laboratrios CERN como
uma soluo para os problemas de intercmbio de informaes entre os pesquisadores.
Desde ento, a tecnologia para construo de interfaces Web vem sendo
progressivamente incrementada permitindo o desenvolvimento de aplicaes cada vez
mais complexas. No incio, a Web era apenas um ambiente para publicao de
documentos no formato texto e HTML (Hypertext Markup Language) e, portanto, a
interao dos usurios era limitada a ler/imprimir texto e a selecionar links para outros

1
e-mail: winckler@irit.fr
LIHS -IRIT (Institut de Recherche en Informatique de Toulouse)
118, route de Narbonne 31062 - Toulouse Cedex 4 - Frana
2
e-mail: mpimenta@inf.ufrgs.br, http://www.inf.ufrgs.br/~mpimenta
Instituto de Informtica - UFRGS
Av. Bento Gonalves, 9500 - Caixa Postal: 15064
CEP 91501-970 - Porto Alegre - RS -Brasil
documentos. Na sequncia, vieram os formulrios e programas CGIs (Common
Gateway Interface) que permitem a entrada de dados do usurio e a integrao com
aplicaes de banco de dados. Como conseqncia desta inovao, surgem aplicaes
complexas que utilizam a Web no apenas para troca de informaes, mas como
plataforma para aplicaes distribudas como, por exemplo, o comrcio eletrnico e
intranets (em que empresas usam a Web para gerenciar informaes internas).
Atualmente, outras tecnologias de interface como por exemplo, ActiveX, Java e
JavaScript, entre outras, permitem um tipo de interao do usurio prximo ao
encontrado nas tradicionais interfaces WIMP (Windows, Icons, Mouse and Pointers,
como MS Windows, por exemplo).
Durante este processo evolutivo, o nmero de usurios e de sites Web cresceram
exponencialmente. A Web tornou-se acessvel a todas as pessoas, e conta com uma
grande variedade de aplicaes. Contudo, observa-se que tal popularidade no implica
necessariamente em usurios satisfeitos. Muitos sites Web so visitados uma nica vez
pelos usurios. Em muitos casos, isso ocorre no porque o contedo do site no os
interessa mas sim porque eles foram incapazes de encontrar a informao desejada. A
dificuldade em encontrar informaes no site , sem dvida, o problema de usabilidade
mais relatado por usurios.
Usabilidade o termo tcnico usado para descrever a qualidade de uso de uma
interface (BEVAN, 1995). Essa uma qualidade importante pois interfaces com
usabilidade aumentam a produtividade dos usurios, diminuem a ocorrncia e erros (ou
as sua importncia) e, no menos importante, contribuem para a satisfao dos usurios.
A satisfao um critrio importante, embora no o nico, para determinao da
qualidade global da aplicao. De um modo geral, este um critrio final para que o
usurio adquira um software ou visite regularmente um site.
Quando a usabilidade levada em conta durante o processo de desenvolvimento
de interfaces Web, vrios problemas podem ser eliminados como, por exemplo, pode-se
reduzir o tempo de acesso informao, tornar informaes facilmente disponveis aos
usurios e evitar a frustrao de no encontrar informaes no site. Se o site em questo
for uma aplicao de comrcio eletrnico, por exemplo, tais problemas podem significar
reduo nas vendas ou mesmo venda nenhuma. Se o objetivo for, por exemplo, ensino
distncia, alunos podem se sentir frustados, desmotivados e apresentar baixo
desempenho devido a ocorrncia frequente de problemas de usabilidade.
necessrio reconhecer que a usabilidade est relacionada ao tipo de aplicao
em questo, perfil dos usurios, contextos de utilizao, etc., que so variveis. Alm
disso, tais valores podem se modificar em funo do tempo com o crescimento da
populao de visitantes, mudana dos requisitos e recursos da aplicao e mesmo
atualizao da tecnologia. Assim, a determinao da usabilidade pode variar em funo
destes critrios e, assim, no se pode garantir que um projeto ter 100% de usabilidade,
por exemplo.
A tendncia atual em avaliao tentar identificar os problemas de usabilidade
to cedo eles possam ser detectados na interface. Uma vez identificado, o problema
pode ser solucionado ou, ao menos, seus efeitos podem ser minimizados. Esta
abordagem utilizada tambm para o desenvolvimento de aplicaes tradicionais, no
apenas para Web. Contudo, observa-se que em aplicaes Web as atualizaes so
muito mais frequentes que em outros tipos de interface. Alm disso, o carter
distribudo das aplicaes Web distancia os usurios dos desenvolvedores e, por vezes,
torna-se difcil identificar quem so de fato os reais usurios da aplicao e quais so
suas expectativas.
Existe uma srie de mtodos de avaliao que podem ser utilizados em
diferentes etapas do desenvolvimento de interfaces Web. Alguns desses mtodos vm
sendo empregados durante vrios anos em outros tipos de interfaces como, por exemplo,
o mtodo de anlise de interao de usurios em laboratrios de usabilidade. Outros
mtodos so adaptaes de mtodos tradicionais para a Web, como por exemplo o uso
de questionrios para avaliar satisfao dos usurios (WAMMI). Outros ainda, so
mtodos especialmente desenvolvidos para a Web, como a anlise de arquivos de log.
Cada mtodo apresentado aqui auxilia na identicao de um gama especfica de
problemas de usabilidade. No existe um nico mtodo capaz de identificar todos os
problemas de usabilidade possveis em uma interface, embora o mtodo de anlise de
interao do usurio seja um dos mais completos e, algumas vezes, considerado um
mtodo de referncia. Em resumo, mais de um mtodo deve ser utilizado para cobrir um
espectro maior de problemas de usabilidade. Alm disso, devem ser aplicados
regularmente para que possam acompanhar as alteraes de contedo, mudanas na
populao de usurios e incluses de problemas de usabilidade s interfaces durante a
manuteno do site.
O objetivo principal deste trabalho descrever o processo de avaliao de usabilidade
de interfaces Web e alguns mtodos e ferramentas que podem ser utilizados neste
processo . Para contextualizar este assunto, so discutidos na parte inicial do captulo os
problemas de usabilidade mais frequentes em interfaces Web, como identific-los e
algumas solues possveis (seo 2), so apresentadas as caractersticas do ambiente
Web (seo 3) assim como uma viso panormica sobre concepo de interfaces Web
(seo 4) , de modo a permitir uma compreenso melhor dos objetivos e procedimentos
envolvidos na avaliao (seo 5) e as ferramentas existentes (seo 6). Finalmente, a
seo 7 contm as consideraes finais deste captulo incluindo um roteiro para
realizao de avaliaes de usabilidade e um guia para selecionar os mtodos mais
adequados, de acordo com a etapa de desenvolvimento do site e do oramento
disponvel.
2. Usabilidade
Nesta seo definiremos usabilidade, discutiremos suas caractersticas e apresentaremos
alguns exemplos de problemas de usabilidade. Abordaremos tambm o conceito de
acessibilidade, cada vez mais considerado devido universalizao da informao e
necessidade de incluso digital. Um ciclo de projeto que contemple usabilidade (e
tambm acessibilidade) tambm discutido.
2.1 O que usabilidade?
Usabilidade o termo usado para descrever a qualidade da interao dos usurio
com uma determinada interface (Bevan, 1995). Esta qualidade est associada, segundo
Nielsen (1993), aos seguintes princpios:
facilidade de aprendizado;
facilidade de lembrar como realizar uma tarefa aps algum tempo;
rapidez no desenvolvimento de tarefas;
baixa taxa de erros;
satisfao subjetiva do usurio.
Considera-se que a interface tem um problema de usabilidade se um
determinado usurio ou um grupo de usurios encontra dificuldades para realizar uma
tarefa com a interface. Tais dificuldades podem ter origens variadas e ocasionar perda
de dados, diminuio da produtividade e mesmo a total rejeio do software por parte
dos usurios.
Uma grande parte dos problemas relacionados interfaces Web diz respeito a
navegao, ou seja, os usurios tm dificuldade para encontrar a informao desejada no
site ou no sabem como retornar a uma pgina anteriormente visitada. Outros problemas
so ocasionados pelo uso de recursos multimdia de maneira inadequada como, por
exemplo o uso abusivo de muitas cores numa mesma pgina. A Figura 1 apresenta um
exemplo negativo (contra-exemplo) de interface que utiliza inadequadamente muitas
cores, frames e textos em destaque.
Figura 1 Exemplo negativo disponvel em: http://www.fooz.com/eric/bad/
Embora seja discutvel o gosto por cores, sabe-se que o uso excessivo delas em
uma mesma pgina causa fadiga visual, desvia a ateno do usurio do contedo e pode
tornar a pgina ilegvel se as cores de fundo e texto no so escolhidas adequadamente.
No entanto os problemas de usabilidade em interfaces Web no se resumem apenas
links no disponveis e uso de cores. Alguns problemas podem ocorrem apenas durante
a utilizao em contextos especiais de uso.

a) Ausncia de informao. b) Inadequao ao contexto.
Figura 2 Exemplos de problemas de usabilidade encontrados em
http://www.englishpractice.com/
A Figura 2 a apresenta um problema de usabilidade resultado de um
funcionamento inadequado de um componente da interface. A aplicao em questo tem
por objetivo ensinar ingls atravs de exerccios. No exemplo mostrado, o aluno deve
prencher o campo de formulrio com uma palavra que completa uma frase, usualmente
apresentada entre aspas duplas (). No entanto, a frase a ser completada no aparece
durante a realizao do exerccio e, portanto, o aluno no pode responder o teste e sua
avaliao ser prejudicada por este problema de usabilidade.
Alguns problemas de usabilidade ocorrem apenas quando fatores culturais esto
envolvidos. Considere, por exemplo, um site Web visitado por usurios do mundo
inteiro. possvel que algumas pessoas encontrem dificuldades para usar o site
simplesmente porque as referncias culturais utilizadas no so as mesmas.
Considerando o exemplo da figura 2.b que apresenta um outro exerccio do site
englishpractice.com. A questo apresentada Qual a cor de um limo? e a resposta
bvia para uma criana no Brasil verde (green) simplesmente porque esta a cor
mais frequente dos limes no pas. Este um problema de usabilidade apenas para
usurios que no esto habituados a comprar limes amarelos (yellow) na feira. O
problema maior est no fato de que nenhuma informao adicional fornecida ao aluno,
que fica sem saber porque a resposta correta amarelo.
A interpretao do que um problema de usabilidade pode variar, e portanto o
qu representa um problema para um usurio pode no ser um problema para outro. Por
exemplo, considere dois usurios sendo que o primeiro tem uma conexo internet de
rpido acesso (tipo ISDN) e o segundo usa uma conexo modem de 56 kb;
provavelmente eles tem opinies diferentes sobre a velocidade de apresentao de uma
pgina Web que contm muitas imagens. Outro exemplo de origem de problemas a
incompatibilidade entre browsers que no suportam da mesma maneira as diferentes
tecnologias para construo de interfaces Web; assim, um usurio pode visualizar sem
problemas uma interface com o browser Internet Explorer enquanto a mesma interface
pode apresentar uma srie de problemas sobre o browser Netscape, e vice-versa. De
uma maneira geral, espera-se contentar e eliminar os problemas de usabilidades graves,
frequentes durante a utilizao da aplicao e que ocorrem com a maior parte do seu
pblico-alvo. Sendo assim, um dos aspectos mais importantes para determinao do que
um problema de usabilidade conhecer bem os usurios da aplicao.
Embora alguns problemas de usabilidade possam ser especficos um grupo de
usurios, outros podem ser reconhecidos como problemas comuns grande maioria.
Um dos problemas de usabilidade mais frequentes em interfaces Web a ocorrncia de
links que contm URLs (Uniform Resource Locator) invlidas. Outro problema comum
a todos os usurios a dificuldade de encontrar a informao desejada dentro de um
site, embora as razes pelas quais isso ocorre possam ser diversas. difcil generalizar e
descrever todos os tipos possveis de problemas de usabilidade que podem ser
encontrados. Contudo, pode-se identificar algumas mtricas ou fatores a serem
observados para a determinao de um problema de usabilidade tais como:
Desempenho do usurio durante a realizao de tarefas: a observao (direta ou
indireta) da realizao de tarefas por usurios permite a verificao das seguintes
mtricas:
o Concluso de tarefas (com sucesso, parcialmente concluda, no-concluda):
tarefas que no so concludas ou o so apenas parcialmente so um forte
indcio de que existe algum problema de usabilidade;
o Tempo de realizao da tarefa: mesmo se concluda com sucesso, um tempo
excessivamente longo pode indicar um esforo desnecessrio sendo exigido
do usurio;
o Ocorrncia de erros: vrios tipos de erros podem ocorrer durante a
realizao de uma tarefa. Se o erro causado por uma operao do usurio
por exemplo, deve-se investigar se a interface no induz ao erro atravs de
comandos complexos ou ausncia de mensagem adequadas. Se o erro
produzido por uma atividade do sistema, deve-se verificar como o usurio
advertido da ocorrncia e que suporte oferecido pela interface para efetuar
a recuperao deste erro;
Satisfao subjetiva do usurio: a usabilidade tambm uma qualidade subjetiva
que compreende a opinio do usurio da interface; se o usurios esto satisfeitos
com a interface, o efeito de eventuais problemas minimizado;
Correspondncia com os objetivos do usurio: independente das tarefas
suportadas pelo sistema, verifica-se se os objetivos do usurios foram alcanados.
Esta uma mtrica que pode ser quantitativa ou qualitativa, de acordo com o que
considerado como objetivo final dos usurios;
Adequao padres (normas, recomendaes ergonmicas, etc.): Grande parte do
conhecimento sobre usabilidade organizado na forma de normas e recomendaes
ergonmicas tais como as definidas pela ISO9241. Tais recomendaes descrevem
padres conhecidos de problemas e, em alguns casos, propem solues ou
alternativas para evit-los. A aplicao de tais recomendaes durante o
desenvolvimento da interface pode realmente evitar ou reduzir vrios problemas de
usabilidade. Pode-se verificar a usabilidade inspecionando uma interface em relao
a tais recomendaes. Se a interface as segue pode-se estimar que os problemas de
usabilidade foram evitados.
2.2 Acessibilidade
Acessibilidade (accessibility) o termo usado para descrever problemas de
usabilidade encontrados por usurios com necessidades especiais como, por exemplo,
usurios que tem algum tipo de dificuldade auditiva ou visual. Acessibilidade implica
em tornar utilizvel a interface por qualquer pessoa, independente de alguma deficincia
fsica, sensorial, cognitiva, condio de trabalho ou barreiras tecnolgicas.
A maioria das recomendaes ergonmicas e recomendao para acessibilidade
no limita a utilizao da interaface apenas pessoas com necessidades especiais. Na
verdade, algumas das recomendaes podem ser mesmo teis por qualquer usurio,
como os exemplos a seguir
2
:
Imagens e animaes: use o atributo alt para descrever a funo de cada imagem;
Mapas clicveis: use mapas clicveis do tipo map e texto nos pontos com links;
Multimdia: incluir transcrio de udio e descrio de vdeos;
Links hipertexto: use texto com significado quando lidos fora do contexto e evite
clique aqui, por exemplo;
Organizao das pginas: use cabealho, listas e estruturas consistentes. Use CSS
(Casdade Style Sheets) se possvel;
Frames: use elementos noframe e ttulos com significado;
Tabelas: faa linha por linha regvel. Resuma a tabela.
Accessibilidade e usabilidade so conceitos fortemente relacionadas pois ambos
buscam melhora a satisfao e eficincia de uso da interface. Contudo acessibilidade diz
respeito a uma populao muito mais ampla e genrica. Neste documento a usabilidade
ser o tema principal e recomenda-se aos interessados em acessibilidade que visitem os
sites http://www.hcibib.org/accessibility/ e http://www.w3.org/WAI/ para maiores
informaes. Existem vrias organizaes que se preocupam com a acessibilidade de
sites Web, aqui porm, sero feitas referncias apenas a iniciativa WAI da W3C.
2.3 Ciclo de vida do projeto com usabilidade

2
As regras acima so apenas um resumo de regras para acessibilidade. Para um conjunto completo de regras
ergonmicas para acessibilidade verifique o site http://www.w3.org/WAI/
Na maioria dos casos, problemas de usabilidade somente so identificados
durante a utilizao da interface, em situaes e contextos de utilizao especiais. A
maioria dos autores concorda que o processo de desenvolvimento de interfaces com
usabilidade, Web ou no, um ciclo contnuo de design e avaliaes de usabilidade,
como o representado na figura 3. Neste ciclo, inicia-se com a identificao de usurios,
tarefas e requisitos para a aplicao. Tais requisitos so utilizados como entrada para a
construo de um prottipo que, em seguida, avaliado com relao a sua usabilidade.
Os problemas de usabilidade identificados na avaliao so solucionados na verso
seguinte e uma nova avaliao de usabilidade se segue. O ciclo termina quando nenhum
problema de usabilidade for identificado ou, pelo menos, os problemas mais graves
tenham sido solucionados na interface.
Figura 3 Ciclo de vida do projeto com usabilidade.
O ciclo de vida acima uma representao simplificada. Outros autores
propem etapas intermedirias de design e especificao. Contudo, o processo cclico
apresentado aqui suficiente para descrever o princpio.
O grau de desenvolvimento de um projeto pode ser avaliado em funo da
complexida dos prottipos utilizados. Prottipos nada mais so do que verses
simplificadas da interface mas que descrevem algumas funes de maneira que possa
ser possvel analisar a futura interface. Os primeiros prottipos podem ser simples
croquis ou desenhos feitos sobre papel. Este tipo de prottipos tm um baixo custo de
realizao e so ideais para testar diferentes possibilidades de organizao da
informao em um site. Na seqncia pode-se construir prottipos em HTML que
descrevem a estrutura de apresentao, embora o contedo esteja incompleto.
Cada prottipo deve ser avaliado no sentido de tentar identificar problemas de
usabilidade, pois o custo da soluo de problemas inversamente proporcional ao
estgio de desenvolvimento da aplicao. Deve-se observar que, dependendo do estgio
de desenvolvimento, pode-se empregar um mtodo de avaliao de usabilidade
diferente. Por exemplo, pode-se utilizar o mtodo de avalio heurstica mesmo com
prottipos em papel, mas nesta etapa de desenvolvimento, a anlise de arquivos de log
invivel sendo este mtodo mais adequado quando a interface encontra-se em uso.
Deve-se considerar que, devido s frequentes atualizaes necessrias
manuteno de um site Web, uma interface Web ser sempre um prottipo avanado
dentro do ciclo de vida de projeto acima. As modificaes no site podem incluir, e com
freqncia incluem, problemas de usabilidade devidos a remoo de links ou incluso
de URLs invlidas, modificaes na estrutura do site que alteram profundamente a
navegao, entre outras. Assim, a cada modificao no site, deve-se considerar a sua
avaliao para assegurar que a modificao no alterou a usabilidade do site.
Uma vez identificado um problema de usabilidade, o passo seguinte procurar
uma soluo. O custo da soluo de um problema pode ser apenas algumas linhas de
cdigo corrigidas em alguns minutos ou transformaes profundas na estrutura do site,
o que podem levar semanas. Alm disso, com freqncia, identifica-se no um
problema de cada vez mas vrios em uma mesma avaliao. necessrio dar prioridade
para aqueles que so mais importantes e que exigem uma soluo imediata. Por isto,
extremamente importante atribuir a cada problema de usabilidade um grau de
severidade.
O grau de severidade pode ser avaliado como relao ao impacto (grave,
importante ou impacto menor) sobre a realizao de tarefas e freqncia com o qual o
problema ocorre. Embora outras escalas para avaliar severidade possam ser utilizadas,
sugere-se a escala de severidade proposta por Woolrych e Cockton (2001). Assim, com
relao ao impacto, os problemas podem ser classificados como:
Grave: usurios precisam de mais de 2 minutos sem progresso na realizao da
tarefa. Usurios abandonam a tarefa ou demonstram stress na realizao da mesma.
Usurios no conluem a tarefa.
Importante: usurios gastam at 2 minutos e obtem xito na realizao da tarefa.
Usurios podem demonstrar stress visvel ou perda de qualidade de interao.
Impacto menor: usurios encontram o problema mas conseguem contorn-lo sem
prejuzo importante para a qualidade de realizao da tarefa.
A segunda dimenso para determinar severidade a freqncia com que um
problema ocorre. Assim temos:
Grande freqncia: problemas ocorrem com mais de trs usurios.
Mdia freqncia: problemas ocorrem com dois ou trs usurios.
Baixa freqncia: problemas ocorrem com um usurio.
Essa escala de freqncia considera que apenas 5 usurios participam da
avaliao. Deve-se observar que ela deve ser ajustada para para um nmero maior ou
menor de participantes. Outra observao importante que em alguns mtodos de
avaliao, como no caso da avaliao heurstica, no h a participao de usurios.
Neste caso, deve-se considerar a freqncia de problemas identificados pelos
avaliadores.
Deve-se salientar que a importncia e a freqncia dos problemas de usabilidade
varia em funo da representatividade dos usurios participantes. Se todos os usurios
tem um perfil muito prximo, provavelmente os mesmos problemas sero identificados
por todos os participantes e daro uma grande importncia a todos os problemas
identificados, sejam eles graves ou no. Por outro lado, pode ocorrer que usurios
diferentes encontrem problemas distintos que no se repetem com outros usurios,
dando a falsa impresso de que no se trata de problemas graves. Para resolver tais
questes, deve-se usar da experncia em outras avaliaes e bom senso.
3. O Ambiente Web
Para melhor entender os problemas de usabilidade no ambiente Web, necessrio
compreender como a Web funciona, o que so aplicaes Web e quais so as diferentes
tecnologias que podem ser utilizadas para construir interfaces neste ambiente.
3.1 A arquitetura cliente-servidor
A Web foi criada por Tim Berner-Lee e o seu primeiro esboo foi publicado no
artigo Information Management: A Proposal (Berners-Lee, 1989; 1994)
3
como uma
soluo aos problemas do CERN de gerncia das informaes sobre os projetos
realizados em seus laboratrios. Desde ento, o projeto evoluiu e so vrias as razes
para o seu atual sucesso, mas duas merecem ser destacadas: sua arquitetura simples mas
eficiente e uma interface igualmente simples, originalmente baseada no paradigma de
hipertextos. A arquitetura basicamente um cliente/servidor instalado sobre uma rede
de computadores heterognea. Do lado do cliente est um programa, chamado browser
ou navegador, que intermedia a solicitao de informaes ao servidor e as apresenta
para o usurio. O servidor atende os diferentes clientes bem como outros servidores
indistintamente, como mostra a figura 4.
Figura 4 Modelo cliente/servidor da WWW.
Embora o modelo referencie uma arquitetura cliente/servidor, talvez fosse mais
adequado cham-la de request/respost (pedido/resposta) porque, de fato, este o tipo de
comunicao entre as partes; o cliente browser solicita um documento ao servidor que
processa a chamada, envia o documento ao cliente e encerra a comunicao. Assim, as

3
O artigo escrito em 1989 circulou inicialmente apenas dentro do CERN e posteriormente foi publicado
pela sua importncia histrica. A primeira demonstrao funcional do projeto ocorreu apenas em
fevereiro de 1991 [CAI95].
comunicaes entre o cliente e o servidor ocorrem de um modo descontnuo entre as
chamadas. Esta arquitetura tem 3 componentes principais: o protocolo de comunicao
HyperText Transfer Protocol (HTTP), o sistema de endereamento Uniform Resource
Locator (URL) e a linguagem HyperText Markup Language (HTML).
O protocolo HTTP (Berners-Lee, 1994) um meio de transporte de arquivos na
Web que executa sobre a camada TCP/IP da Internet. O protocolo consiste basicamente
da transio de 4 estados: conexo (o cliente estabelece uma conexo com o servidor);
requisio (o cliente envia um pedido ao servidor); resposta (o servidor devolve uma
resposta ao cliente); e encerramento (a conexo desfeita por ambas as partes). Quando
um documento ou um objeto (como uma imagem, por exemplo) enviado para o
cliente, anexado um cabealho com a informao necessria para que o browser possa
interpret-lo e apresent-lo adequadamente. Isto torna o protocolo independente do
browser, que ignora o contedo de objetos cujo cabealho no compreende.
URL a forma conhecida de endereamentos de objetos na Web. Consiste na
identificao do esquema utilizado (HTTP, FTP, etc.
4
) seguido do caminho at o objeto
ou documento como, por exemplo: http://www.inf.ufrgs.br/homepage.html ; onde
http o esquema, :// so caracteres de separao, www.inf.ufrgs.br o nome do
domnio Internet e homepage.html o documento solicitado.
O terceiro componente a linguagem baseada em hiperdocumentos HTML. Esta
linguagem especifica a estrutura e a formatao para documentos do tipo hipertexto
atravs de marcas (ou tags) que indicam a forma como este deve ser visualizado. Pode-
se destacar duas grandes vantagens na escolha de uma interface baseada em hipertextos
como HTML: i) a facilidade para associar informaes atravs de elos ou links
permitindo criar grandes redes de informaes; e ii) o mecanismo de navegao
uniforme com a simples seleo de objetos associados a links. Uma vantagem
secundria, o fcil aprendizado, mesmo por usurios no especializados.
A Web foi concebida como um meio para o intercmbio de informaes,
geralmente no formado de documentos; por isto usual tratar as informaes publicadas
neste ambiente indistintamente como documentos, hipertextos ou hiperdocumentos.
3.2 Aplicaes Web
Podemos definir uma aplicao Web como uma aplicao de software que
utiliza a Web como ambiente de execuo. Aplicaes Web envolvem Sites Web ou
sistemas Web [Conallem 00]. Sites Web a forma original de sistema hipermdia
distribudo, criado por Tim Bernes-Lee, com o propsito de permitir pesquisa e acesso
direto a documentos e informaes publicadas em vrios computadores que formam a
Internet. Documentos, arquivos armazenados em um computador servidor, so
acessados e visualizados atravs de um software chamado browser, instalado no

4
Os esquema mais utilizados so HTTP, TELNET, File Transfer Protocol (FTP), Gopher Protocol
(GOPHER), Eletronic Mail Address(MAILTO), Usenet News (NEWS) e Wide Area Information Server
(WAIS) [LEN97].
computador cliente, utilizando-se da infraestrutura da internet, atravs do protocolo
HTTP (Hyper Text Transfer Protocol).
A figura 5 mostra a arquitetura bsica de um Site Web, onde um servidor Web
recebe uma solicitao de um browser, localiza o documento em um sistema de
arquivos local, e envia o documento de volta ao browser. Os recursos no sistema so
interligados entre si atravs de links, que so a forma usual de navegao no sistema.
Estes recursos podem ser no s documentos textuais, mas tambm imagens, vdeo e
udio.
Figura 5 Arquitetura bsica de Site Web
Uma aplicao Web amplia o conceito de Web Site, ao adicionar funcionalidade
ao sistema. Em outras palavras, aplicao Web um sistema Web que permite aos
usurios executarem lgica de negcio com um browser Web. Uma aplicao Web deve
ser entendida como uma forma de uso de software acessando dados persistentes atravs
do servio Web, permitindo a construo dinmica de pginas para manipular estes
dados. Diferente de Sites Web estticos, onde o contedo um arquivo ou documento
pr-formatado (usando um editor HTML, por exemplo), aplicativos Web devem
construir dinamicamente o contedo em funo da interao do usurio com as pginas,
via browser. A arquitetura bsica mostrada na figura 6.

Web Server
http

Page Filter

Scripted Page Database
processes
references
result
Browse
Figura 6: Arquitetura de um Site Web Dinmico
3.3 Diversidade de tecnologias para interfaces Web
Inicialmente as interfaces Web nada mais eram do que documentos HTML
contendo texto e imagens interligados por links que permitiam navegar de um
documento a outro. Estes recursos suportados pela primeira verso de HTML 1.0 so
suficientes apenas para um nmero limitado de aplicaes. A necessidade de utilizar a
Servidor
Sistema
arquivos
local
Cliente
Internet
Web Server
Request
Document
Browser
Web como um ambiente de base para aplicaes mais complexas como, por exemplo
transaes com banco de dados, motivou o desenvolvimento de novas tecnologias.
Tecnologias para especificao de interfaces Web tais como CGI, CCS, JavaScript, etc.,
foram criadas como solues alternativas para diferentes problemas considerando o
desenvolvimento de aplicaes Web. Do ponto de vista da interface, cada tecnologia
suporta um estilo de interao diferente e, potencialmente, pode incluir problemas de
usabilidade diferentes.
No o objetivo aqui descrever exaustivamente todo o potencial de cada uma
das tecnologias, mas segue abaixo uma rpida descrio seguida de algumas referncias
teis sobre as tecnologias mais utilizadas para construo de interfaces Web.
importante que o avaliador esteja familiarizado com a tecnologia utilizada na construo
da interface a ser avaliada, pois isto vai lhe permitir dar melhores sugestes para os
problemas encontrados.
HTML
HTML um formato no proprietrio, baseado na Standart Generalized Markup
Language (SGML) para criao de hipertextos na Web. HTML utiliza marcas ou tags
tais como, <B> e </B>, para estruturar ou formatar o documento em formato texto. A
mais recente verso, HTML 4.0 ou HTML dinmico (DHTML), tornou-se uma
recomendao W3C em dezembro de 1997. Esta nova verso incorpora os padres
criados pelos fabricantes de browser, tais como, CSS, frames, JavaScript, alm de
aperfeioar as tabelas e melhorar a resoluo impressa dos documentos.
Referncias teis:
http://www.icmsc.sc.usp.br/manuals/HTML/ (em portugus)
http://www.w3.org/MarkUp/
http://www.echoecho.com/html.htm
http://nscience.chungbuk.ac.kr/references/html/
CGI
O protocolo HTTP permite a chamada de programas executveis hospedados no
servidor. Estes programas so chamados Common Gateway Interface (CGI) e podem ser
escritos em qualquer linguagem de programao tal como C ou Perl. Quando um
programa CGI executado, o resultado do seu processamento pode ser direcionado para
o browser cliente. Assim pode-se gerar aplicaes complexas com o acesso a banco de
dados ou criao interativa de documentos. Todo programa CGI executado no
servidor e a interface gerada como sada para o usurio continua esttica na sua
essncia.
ASP e PHP so variaes da tecnologia CGI. A diferena principal que o
cdigo a ser executado no servidor includo dentro do codgo HTML ao invs de ser
armazenado no servidor. Do lado do servidor um programa interpreta o cdigo ASP ou
PHP e processa as instrues devolvendo ao cliente o resultado.
Referncias teis:
CGI e PERL - http://www.w3.org/CGI/
CGI - http://hoohoo.ncsa.uiuc.edu/docs/tutorials/cgi.html
PHP: http://www.webdevelopersjournal.com/articles/why_php.html,
http://www.php.net/, http://www.phpbuilder.com/
ASP: http://www.aspdeveloper.net/, http://www.advantage.co.nz/ur/aspquiz.htm
CSS
Cascade Style Sheets permitem fazer com que a apresentao de pginas Web
seja determinada por um conjunto de especificaes de formatao de pgina e pela
especificao de preferncias tipogrficas e outras caractersticas do dispositivo do
cliente, de forma a garantir a continuidade visual do site. Anexando Style Sheets
documentos HTML possvel mudar a apresentao de documentos sem adicionar
novas marcas ou comprometer os mecanismos de independncia de plataforma. O nome
Cascade implica em que diferentes estilos podem ser combinados em um mesmo
documento. A sintaxe da linguagem um pouco diferente de HTML e requer um
esforo de aprendizagem. Talvez, a principal vantagem de CSS seja barrar a criao de
novas marcas em HTML para formatao dos documentos.
Referncias teis:
http://www.w3.org/Style/
http://www.awl.com/cseng/titles/0-201-41998-X/liebos/
JavaScript
JavaScript uma linguagem interpretada embutida dentro de arquivos HTML. O
funcionamento simples: quando um destes arquivos carregado, o prprio browser
interpreta o script e realiza as operaes especificadas. Embora seja bastante limitada
(no suporta aplicaes complexas nem transacionais que requerem comunicao via
rede), JavaScript permite a criao de animaes de imagens, botes e funes para
validao de campos em formulrios HTML, por exemplo. O diferencial a
possibilidade de criao daquilo que pode ser chamado documentos dinmicos, ou seja,
documentos que reagem imediatamente s interaes do usurio.
Uma ltima nota a respeito da tecnologia de Scripts a verso Jscript, um clone
do JavaScript desenvolvido pela Microsoft para executar sobre o browser Internet
Explorer. Os recursos e objetivos so semelhantes; contudo, JavaScript e Jscript no so
totalmente compatveis.
Referncias teis:
http://msdn.microsoft.com/scripting/default.htm?/scripting/jscript/default.htm
http://www.webdevelopersjournal.com/articles/jsintro1/js_begin1.html
Java
Java uma linguagem orientada a objetos desenvolvida pela Sun Microsystems
e cuja principal caracterstica ser uma linguagem interpretada que requer uma java
virtual machine (JVM - mquina virtual Java) para executar os programas nela
escritos. De fato, Java tambm o nome de uma marca usada para designar as
tecnologias Java Applications, Applets e Java Beans. Applets so pequenos programas
Java que rodam apenas dentro de um browser cliente, que implementam uma JVM.
Diferente de um script JavaScript, uma applet tem apenas uma chamada dentro
do cdigo HTML. A partir desta chamada, o cdigo Java pr-compilado carregado e
interpretado pelo browser. A arquitetura da linguagem garante independncia de
plataforma com a implementao da Abstract Windows Toolkit (AWT), que encapsula
os mecanismos de apresentao da interface. Contudo, por questes de segurana, todos
os recursos de acesso I/O foram retirados. Com isso, applets Java podem ter grande
expresso computacional, porm, no podem interagir no ambiente do computador do
usurio. Como compensao a esta limitao, existem facilidades para comunicao em
rede com servidores WWW ou diretamente com outras aplicaes.
Referncias teis:
http://java.sun.com/
Plug-ins
Plug-ins a denominao utilizada para designar componentes que so
adicionados aos browsers incorporando capacidade de manipulao de dados em outros
formatos que HTML. uma opo adotada por diversas empresas de software para
permitir que seus produtos se integrassem ao ambiente WWW sem a necessidade de
desenvolver seus prprios browsers. As principais aplicaes para plug-ins so:
visualizador de imagens, visualizadores de documentos, animaes, aplicaes 3-D e
VRML, udio, vdeo, entre outras. Exemplos:
Shockwave, animaes em flash: http://www.macromedia.com/shockwave
Real Player, arquivos de audio/video: http://www.real.com
QuickTime, video: http://www.apple.com/quicktime/
Referncias teis:
http://www.learnthenet.com/english/html/56plugins.htm
3.4 Diferenas entre browsers
A arquitetura cliente-servidor da Web baseada no princpio fundamental de
que usurios devem visualizar a mesma informao independente da plataforma de
software e hardware utilizado. Contudo, para visualizar as informaes necessrio que
cada usurio instale em seu computador um browser para interpretar o cdigo HTML.
Embora o cdigo HTML seja o mesmo, independente da plataforma ou do sistema
operacional utilizado, o browser em si especfico cada plataforma.
At 1993, um nico browser (Mosaic) era disponvel nas plataformas Windows,
OS/Mac e Unix. Apesar de algumas pequenas diferenas, pode-se dizer que todos os
usurios tinham acesso ao mesmo contedo de informao e a mesma apresentao.
Este panorama comea a mudar com o surgimento de concorrentes do Mosaic, como o
Lynx, Netscape e Internet Explorer, entre outros. Os fabricantes destes browsers
comeam a incluir caractersticas diferentes em seus browser como, por exemplo, tags
proprietrias que apenas executam em determinado browser. Para evitar a proliferao
de inmeros dialetos de HTML, novas verses de HTML incluem a novas tags
padronizando-as. Surgem assim as verses HTML 2.0, 3.2 e 4.0.
Browser
J
a
v
a
f
r
a
m
e
s
t
a
b
e
l
a
s
P
l
u
g
-
i
n
s
T
a
m
a
n
h
o
d
e

t
e
x
t
o
C
o
r

d
e
t
e
x
t
o
J
a
v
a
s
c
r
i
p
t
C
S
S
G
i
f
8
9
D
H
T
M
L
C
o
r

e
m
T
a
b
e
l
a
s
X
M
L
Explorer 6.0 X X X X X X X X X X X X
Explorer 5.5 X X X X X X X X X X X X
Explorer 5.0 X X X X X X X X X X X S
Explorer 4.0 X X X X X X X X X X X
Explorer 3.0 X X X X X X X X X X
Explorer 2.0 X X X
Netscape 6.1 X X X X X X X X X X X X
Netscape 6.0 X X X X X X X X X X X X
Navigator 4.7 X X X X X X X X X X X
Navigator 4.5 X X X X X X X X X X X
Navigator 3.0 X X X X X X X X X
Navigator 2.0 X X X X X X S X
Navigator 1.1 X X
Mosaic 3.0 X X X
Mosaic 1.0
Mozilla X X X X X X X X X X X X
AOL browser 5.0 X X X X X X
AOL browser 4.0 X X X X X
Opera 5.11 X X X S X X X X X X X X
Opera 4.02 X X X S X X X X X X X
Lynx X X
Legenda: X Suporte S Suporte parcial
Nenhum
Suporte
Tabela 1. Diferenas entre Web browsers para plataforma MS Windows.
Contudo, a concorrncia entre os browsers no se restringe padronizao da
linguagem HTML mas continua com o suporte a outras tecnologias tais como
JavaScript, Cascade Sytle Sheet (CSS) e XML, entre outras. Apesar dos esforos
realizados pelo W3C (rgo que regulamenta padres para tecnologia Web
http://www.w3.org/ ) para uniformizar a tecnologia para Web, alguns browsers
continuam adotando padres proprietrios ou suportando apenas parcialmente algumas
caractersticas. A tabela 1 resume algumas caractersticas dos browsers mais utilizados
atualmente na plataforma MS Windows
5
. Observe as diferenas entre o suporte a
tecnologias e recursos de formatao de texto.
As diferenas de apresentao e suporte tecnologia podem afetar diretamente a
usabilidade das interfaces. Por exemplo, considere um site Web cuja navegao
baseada em menu JavaScript e que 30% dos usurios no utilizam um browser com
suporte a essa tecnologia. Isto significa que 30% dos usurios deste site esto
experimentando problemas de usabilidade relativos navegao!

5
Tais caractersticas so vlidas apenas para os browsers citados quando executando sob a plataforma
MS Windows. Veja detalhes sobre outras plataforma em:
http://hotwired.lycos.com/webmonkey/reference/browser_chart/index.html.
Atualmente estima-se que 65% dos usurios Web utilizam o browser MS
Internet Explorer, sendo que o Netscape ocupa o segundo lugar, com pouco mais de
25%. Ainda que o Internet Explorer, aparentemente, domine o mercado, desenvolver
interfaces baseando-se apenas para este browser pode no ser a melhor estratgia, pois
assim se estaria excluindo uma grande parcela de usurios. Existem duas solues
possveis: a primeira consiste em utilisar um conjunto mnimo de funcionalidades que
seja suportado por todos os browser; a segunda construir diferentes interfaces, cada
uma adaptada a um browser diferente e incluir um mecanismo de deteco que
identifica o browser e direciona a interface mais adequada a cada caso.
importante que os avaliadores estejam cientes das diferenas entre os browsers
e levem este aspecto em conta durante a avaliao. Primeiro deve-se avaliar uma
interface Web com mais de um browser e em mais de uma plataforma. Alm disso,
deve-se considerar diferentes verses do mesmo browser. Sabe-se que, de maneira
geral, usurios so relutantes em atualizar seus browsers. Assim, no raro encontrar
usurios utilizando o primeiro browser instalado no seu computador.
A avaliao da interface considerando diferentes browsers, verses e
plataformas, multiplica o esforo de avaliao; mas o preo a pagar para garantir
usabilidade da interface para um pblico maior de usurios. Assim, recomenda-se que
sempre que possvel sejam realizadas avaliaes com diferentes browsers.
3.5 Diferenas entre interfaces Web e Wimp
Interfaces Web apresentam algumas diferenas com relao interfaces WIMP
(Windows, Icons, Mouse and Pointer devices) tais como interfaces encontradas sob as
plataformas MS Windows e OS/Mac. Estas diferenas so principalmente relativas ao
modo de utilizao destas interfaces e restries do ambiente Web. Entre as principais
podem ser citadas:
Usurios podem utilizar atalhos para acessar partes de uma aplicao Web sem
passar obrigatoriamente pela homepage do site. Em interfaces Wimp, o designer tem
controle total sobre a apresentao da interface e meios de impedir que usurios
explorem a interface de maneira outra que aquela predefinida. Mecanismos como
bookmarks, histrico de navegaes e acesso direto a URL usurios para explorar
interfaces Web.
Interfaces Wimp suportam, em geral, interaes mais complexas que interfaces
Web. Interfaces Web so caracterizadas principalmente pela interao do tipo
browsing que consiste em navegar entre pginas selecionando links. Usurios Web
passam mais tempo navegado entre pginas do que interagindo com objetos
contidos na pgina. Na prtica se observa o fenmeno de scanning segundo o qual
usurios passam a vista, isto , olham rapidamente pginas Web em busca de links
ou palavra-chaves que possam identificar o contedo procurado e, na maior parte do
tempo, no lem cuidadosamente o contedo apresentado.
Interfaces Web so relativamente fceis de construir mesmo por pessoas com pouca
formao. Em geral, pessoas sem formao especfica esto mais suscetveis a
desenvolver interfaces com problemas de usabilidade.
Interfaces Web so atualizadas muito mais rapidamente que interfaces Wimp. O que
significa que a cada modificao necessrio avaliar a usabilidade da interface para
garantir que problemas no sejam includos. Em interfaces Wimp, um vez concludo
e distribudo o software, problemas de usabilidade somente sero resolvidos na
futura verso.
Finalmente, o uso de um browser obrigatrio para a Web. Isto implica que uma
srie de ferramentas e funes so adicionadas interface e podem interferir no
design final.
Estas diferenas devem se levadas em considerao durante todo o processo de
avaliao de interfaces Web. Isto implica na adaptao de mtodos de avaliao de
usabilidade que sejam adequados ao ambiente Web. Em geral, so necessrios mtodos
de baixo custo para que se torne viavl a avaliao freqnte. Tambm so necessrios
mtodos de fcil realizao que possam ser aplicados mesmo por pessoas sem uma
formao especfica em IHC (at porque no existiriam especialistas em nmero
suficiente para avaliar todas as interfaces Web atualmente ativas).
4 Concepo de Interfaces Web
Antes de nos concentrarmos em como avaliar interfaces Web, convm abordar -
mesmo que superficialmente - alguns conceitos, modelos, metodologias e ferramentas
propostos para a concepo de aplicaes Web, cuja meta principal justamente
auxiliar o processo de design de sites Web de forma a termos um processo mais efetivo
resultando em sites Web de maior qualidade. De fato, hoje em dia amplamente
reconhecido pela comunidade de Interao Humano-Computador
6
(IHC), que
prefervel dedicar mais esforo para desenvolver aplicaes de modo que critrios de
usabilidade sejam considerados desde o incio e durante todo o seu processo de
construo do que para uma fase de avaliao a posteriori ao fim deste processo. No
entanto, vale a pena reforar que a avaliao continua a ser essencial sobretudo para
validar as escolhas da concepo e confirmar o nvel de satisfao dos usurios e deve
ser sempre realizada por melhor que seja o processo de concepo que a antecede.
O objetivo desta seo apresentar algumas das idias pertinentes e relevantes
concepo de interfaces Web assim como resumir as caractersticas de algumas tcnicas
e ferramentas de desenvolvimento, sejam elas de cunho comercial disponveis no
mercado ou de cunho acadmico resultantes de trabalhos de pesquisa.
Para isto, primeiramente (seo 3.4.1), alguns fundamentos sobre concepo de
interfaces Web so apresentados. A seo 3.4.2 descreve um ciclo de desenvolvimento
de aplicaes Web, explicando as caractersticas de cada etapa do ciclo. A seo 3.4.3
aborda mais detalhadamente o processo de design, enumerando na subseo 3.4.3.1 as
diferentes abordagens sistemticas para concepo de interfaces Web propostos para
este processo e na subseo 3.4.3.2 as variadas ferramentas existentes para suportar total
ou parcialmente este processo.
4.1 Fundamentos

6
Traduo adotada atualmente pela comunidade brasileira para a expresso inglesa Human-Computer Interaction
(HCI).
Atualmente muitos aspectos considerados fundamentais na concepo de interfaces
Web tm sido estudados, muitos livros sobre o assunto tm sido publicados abordando
vrios deles e muitas recomendaes (guidelines) para concepo de sites tm sido
compiladas. Mais do que isto, muitos sites tm sido construdos nos ltimos anos e a
necessidade cada vez maior de desenvolvimento leva esta acelerao do interesse
sobre o assunto. No entanto, mesmo com toda esta efervescncia, no se tem um
consenso sobre qual as melhores caractersticas de um site, qual o melhor processo para
constru-lo, quais os modelos a usar no seu processo de desenvolvimento, quais as
melhores formas de estrutur-lo, de permitir navegao e de usar a tecnologia
disponvel para tornar seu uso mais eficiente e agradvel. Cada autor apresenta o seu
conjunto de requisitos, recomendaes, tcnicas, modelos e ferramentas que considera
mais essencial. Por isto, concordamos com Ben Shneiderman, um dos mais renomados
autores da rea de IHC, que comentou em 1997: "...it will take a decade until sufficient
experience, experimentation, and hypothesis testing clarify issues". Desta forma,
apresentaremos aqui um conjunto de tpicos que, embora no sejam eventualmente
consensuais, julgamos importantes para quem for conceber sites e que serviro para a
compreenso de alguns dos tpicos discutidos posteriormente na parte de avaliao.
Como no inteno desta seo discutir com muita amplitude e profundidade o
processo de concepo, estes tpicos incluem as dimenses de concepo de sites Web
(seo 3.4.1.1), o ciclo de concepo de aplicaes Web (seo 3.4.1.2), algumas
caractersticas (seo 3.4.2) e recomendaes (seo 3.4.2.1), metodologias (seo
3.4.2.2) e ferramentas (seo 3.4.2.3) para projeto de interfaces Web.
4.1.1 Dimenses de Concepo
As aplicaes Web podem ser convenientemente descritas como hbridas entre
aplicaes hipermdia e sistemas de informao. Como uma aplicao hipermdia, uma
aplicao Web acessada de forma exploratria, no linear, e portanto as suas formas
de apresentao e navegao so de grande importncia. Como um sistema de
informao, a estrutura, o tamanho e a dinamicidade dos seus dados exigem solues
metodolgicas (como modelos conceituais, mtodos de mapeamento entre estruturas,
abstraes) e solues tecnolgicas consolidadas e eficazes (como SGBDs e
arquiteturas cliente-servidor) que auxiliem a gerenciar esta complexidade e que
permitam fcil interoperabilidade, evoluo e manuteno. Devido a sua natureza
hbrida, h fatores complicadores como a necessidade de manipular tanto dados
estruturados (tuplas e registros) quanto dados no-estruturados (multimdia) e de
compatibilizar esta variedade de informaes a diferentes estilos de apresentao e
navegao para usurios com diferentes nveis de competncia.
Por isto, segundo [Fraternali 99], uma aplicao Web caracterizada por trs
dimenses de projeto principais:
- Estrutural (ou Conceitual): que descreve a organizao da informao a
ser gerenciada pela aplicao, suas propriedades estruturais, e os
relacionamentos entre si; tipicamente, a dimenso estrutural descreve os objetos,
as associaes entre eles e seus objetos componentes; modelos para esta
dimenso incluem modelos de dados (p.ex. Entidade-Relacionamento) ou de
objetos (p.ex. diagramas de classes UML ou OMT) ou quaisquer outros modelos
tipicamente usados para modelagem conceitual de sistemas de informao;
- Navegacional: que focaliza as facilidades para o acesso e movimentao
em relao s informaes da aplicao, especificando as aes disponveis para
movimentao direta de um objeto a outro (navegao contextual) e os caminhos
de acesso para alcanar os objetos da aplicao, independente de movimentao
(navegao no-contextual) ; dado um esquema estrutural, podem haver vrios
diferentes esquemas navegacionais representando diferentes maneiras de acessar
e de se mover atravs da mesma informao; modelos para esta dimenso so
geralmente baseados em mquinas de estados (p.ex. statecharts) ou redes de
Petri;
- Apresentao: trata como o contedo e os aspectos de navegao sero
apresentados para o usurio; especificando o layout e o contedo de um conjunto
de elementos (pginas) similares da aplicao; dado um par (esquema de
estrutura, esquema de navegao) podem haver vrias diferentes esquemas de
apresentao representando diferentes modos de graficamente exibir a mesma
aplicao; entre modelos usados para esta dimenso incluem-se storyboards,
Abstract Data Views [COW95], croquis , maquetes, prottipos ou quaisquer
outros tipicamente usados para representar o componente de apresentao de
interfaces.
4.2 Ciclo de Concepo de Interfaces Web
O ciclo de concepo de interfaces Web uma espiral contnua, notadamente marcado
por sucessivas modificaes, que so muito mais freqentes em aplicaes Web que em
outros tipos de interfaces. Dentro deste ciclo espiral, vrias etapas se sucedem , embora
o nmero e a importncia de cada uma delas variem em funo da abordagem utilizada.
O ciclo proposto por Scapin et al [10] (ver figura 1), compreende as seguintes etapas:
Etapa 1: Engenharia de requisitos: a estrutura do site e o contexto de utilizao
so identificados;
Etapa 2: Especificao do site: modelos da interface so construdos a partir dos
requisitos obtidos durante a anlise de requisitos;
Etapa 3: Design do site: modelos so refinados e o site implementado de acordo
com o seu contedo;
Etapa 4: Implementao do site: corresponde a criao de pginas HTML e
objetos de som/imagem necessrios aplicao ;
Etapa 5: Utilizao do site e avaliao: so avaliadas a usabilidade da interface e
a coerncia da interface com relao aos requisitos iniciais;
Etapa 6: Manuteno do site: envolve um ciclo de maior durao que envolve a
coleta de novos requisitos e planejamento das modificaes identificadas durante a
etapa de avaliao.
Figura 1. Ciclo de desenvolvimento de um website
Este ciclo de desenvolvimento para Web deve ser fortemente baseado em um processo
sistemtico e cclico onde o passo de engenharia de requisitos tradicional deve ser
seguido pela especificao do site (veja figura 1). Uma descrio explcita do site pode
ajudar de vrias formas no desenvolvimento: formalizando requisitos do usurio,
guiando o projeto e a construo do site, documentando um conjunto de informaes
til no decorrer das atividades de avaliao e do site. Durante a fase de especificao do
site, so produzidos todos modelos descrevendo requisitos do(s) usurio(s), tarefas e
estrutura que ser usada para implementar o site.
Observa-se que, neste ciclo, um atalho possvel permite a implementao logo aps a
anlise de requisitos sem passar pela etapa de especificao, o que freqentemente
observado na prtica. Contudo, isto dificulta a construo de sites com maior
usabilidade pois, devido a necessidade de modificaes freqentes no site, cada vez que
um desenvolvedor altera manualmente uma interface ele est sujeito a incluir um
problema de usabilidade. Estes problemas podem estar associados a um erro relacionado
a operao em si (p.ex. um erro de digitao que torna um link inacessvel) ou uma
modificao na estrutura de navegao que elimina um caminho a um ramo da estrutura
antes acessvel.
A abordagem de desenvolvimento orientado a modelos visa evitar os atalhos e seguir
todas as etapas do ciclo de desenvolvimento. Assim - sempre referenciando a fig. 1 -
cada alterao da interface (novos requisitos como entrada da etapa 1) deve ser
especificada (etapa 2) antes de executada sobre a interface (etapas 3 a 5). Embora a
manuteno torne-se mais complexa e demorada, possvel verificar cada modelo a
cada alterao. Alm disso, a especificao da interface documenta a evoluo do site.
4.3 Concepo de Sites Web
Nos primeiros sites desenvolvidos para a Web, pouca importncia era dada aos
requisitos dos usurios e usabilidade das suas interfaces e, por conseqncia, muitas
interfaces Web no preenchiam as necessidades de seus usurios. Esta falha do processo
de desenvolvimento foi mais tarde parcialmente investigada quando a preocupao com
critrios de usabilidade e o uso de tcnicas centradas no usurio (User Centered Design
ou abreviadamente UCD) permitiu incluir os requisitos dos usurios no projeto do site.
Por exemplo, o uso combinado ou no de tcnicas de card sorting e questionrios foi
popularizado na forma de ferramentas para identificar os requisitos do(s) usurio(s) e
estruturar a informao de forma natural segundo o ponto de vista deste(s) usurio(s).
Embora simples, isto foi reconhecidamente um progresso de atitude orientada a aspectos
de interao humano-computador dentro do desenvolvimento no ambiente Web,
notadamente ainda muito orientado a tecnologia.
Entretanto, esta mudana de atitude insuficiente para a obteno de sites Web de
qualidade pois seu design ainda realizado de maneira muito informal. Atualmente, os
projetistas utilizam intensivamente algumas ferramentas para autoria e/ou edio de
pginas ou mais raramente para identificao de requisitos mas estas ferramentas (ver
seo 4.2.3) em sua maioria no fornecem suporte a muitas fases do ciclo de concepo
como especificao do site atravs de modelos e traduo (assistida ou automtica)
destes modelos visando um projeto das pginas e de elementos do site.
De fato, h surpreendentemente pouco esforo em prover suporte conceitual a
modelagem de interfaces WWW. Idealmente, um modelo para uso no desenvolvimento
de aplicaes Web e suas interfaces deve:
a) ter uma base rigorosa, sendo que o nvel de rigor mximo o nvel de um
formalismo, que possui uma fundamentao matemtica consolidada e permite
verificaes formais;
b) ser completo na sua habilidade de representar os aspectos estticos e
dinmicos das aplicaes Web e suas interfaces; e
c) ser independente de ferramentas implementadas que podem ser a ele
associadas.
Para construir sites Web complexos necessitamos, alm de entender e representar os
conceitos do domnio do problema (classes e objetos, propriedades, associaes, regras
de negcio, servios, etc), entender claramente e representar explicitamente as
caracteristicas mais relevantes do(s) usurio(s) e suas tarefas. Alm disto deve-se usar
este conhecimento para projetar cuidadosamente os aspectos de interao e os
respectivos modelos de navegao, dilogo e apresentao envolvidos de forma a
conseguirmos desenvolver aplicaes usveis que suportem adequadamente estas
tarefas.
No h um consenso sobre como deve-se realizar a sistematizao do processo de
desenvolvimento de aplicaes Web e quais modelos seriam necessrios e/ou
suficientes para este processo. Embora a prtica informal seja ainda aceitvel para
projetos de pequeno porte (projetos do your own web page ), isto torna-se crtico para
grandes e/ou complexos sites.
Alguns problemas comuns da ausncia de enfoque ou da utilizao de enfoques
informais incluem:
ambigidade dos requisitos e das especificaes;
ausncia de ferramentas para suportar sistematicamente, incrementalmente e
coerentemente o processo de desenvolvimento a partir dos requisitos e
especificaes; e
dificuldade de gerenciar a manuteno de um site quando sua complexidade e/ou
tamanho aumentam.
O objetivo da utilizao de modelos durante o processo de desenvolvimento de
aplicaes Web e suas interfaces duplo:
registrar/documentar o processo de desenvolvimento da aplicao, representando os
diferentes estgios e as diferentes informaes pertinentes e relevantes para o
projeto de interfaces Web com usabilidade. Exemplos tpicos so os modelos para as
diferentes dimenses de concepo mencionadas mas tambm informaes sobre os
usurios (suas caractersticas, habilidades, deficincias, freqncia de uso,etc) e
sobre as tarefas que eles realizaro com o suporte da aplicao (sua decomposio
em sub-tarefas, seu ordenamento, suas restries, suas pr- e ps-condies de
realizao, freqncia de realizao, criticidade,etc);
permitir a comunicao entre os membros da equipe (geralmente multidisciplinar)
envolvida com o desenvolvimento da aplicao Web.
Modelar uma aplicao Web significa, como para qualquer tipo de aplicao, descrever
suas caractersticas mais relevantes, sem considerao de detalhes de implementao.
4.3.1 Recomendaes para Projeto de Interfaces Web
A grande maioria dos mtodos e modelos para desenvolvimento de interfaces Web
consideram a interface como um componente de uma aplicao Web e portanto so um
subconjunto de mtodos e modelos para desenvolvimento de aplicaes Web. Estes por
sua vez so variantes de mtodos e modelos concebidos inicialmente para aplicaes
hipermdia.
Embora no haja consenso metodolgico, alguns autores propem um conjunto de
recomendaes que, se consideradas, podem resultar num projeto de sites Web de
qualidade. Apresentamos a seguir um resumo destas recomendaes, que esto
organizadas nos seguintes tpicos:
Reduzindo o tempo de resposta;
Preparando contedo para Web;
Organizando o site Web;
Definindo controles de navegao;
Projetando pginas Web.
Reduzindo o tempo de resposta
A grande maioria dos usurios Web conectam-se via modem e portanto tm
velocidades relativamente baixas de conexo. O tempo de resposta mais significativo
para usurios Web o tempo de carga (download) de pginas. Este tempo
determinado basicamente pelo tamanho da pgina e pela velocidade de conexo. Como
os projetistas podem controlar somente o primeiro, sugere-se:
* projete pginas pensando nas pessoas que conectam-se via modem;
* evite grandes grficos e geralmente use poucos grficos nas pginas;
* se usar grficos, reduza o nmero de cores, use taxa de compresso elevada e
use sempre textos associados aos grficos (atributos ALT para imagens);
Preparando contedo para Web
O contedo de um site Web deve ser concebido de modo especfico para este
meio, atravs de uma escrita do texto para ser lido on-line e de uma escolha adequada
do vocabulrio do site.
Escrevendo texto para ser lido on-line
Usurios Web no lem palavra por palavra, mas tipicamente procurando
informao destacada e alternando entre blocos de texto, ou seja, "passando a vista" ou
"lendo em diagonal". Logo, o texto na Web deve:
* ser fcil de "passar a vista", incluindo itens para facilitar esta tarefa
como tabelas de contedo, ndices, listas numeradas, realando palavras-chave, usando
ttulos e subttulos significativos;
* ser conciso: linguagem direta, e sem detalhes irrelevantes;
* ser objetivo: evitar jargo " promocional" de marketing e vendas, das
quais o usurio geralmente quer distncia;
Escolhendo o vocabulrio do site
Esta escolha envolve termos do domnio do problema e de preferncia adotados
comprovadamente pelos usurios: use tcnicas de entrevistas, observaes, card sorting
ou participatory design para descobrir e confirmar isto. Mais, a noo de que um termo
"bvio", "natural", "evidente", e "intuitivo" um mito: idealmente deve-se oferecer
mais de um termo de acesso a usurios que desejam achar informaes ou aes no site.
Um glossrio de sinnimos ou termos relacionados pode ser um auxlio importante.
Organizando o site Web
Organizar um site implica em definir a topologia deste site e escolher o nmero
de nveis em que seu contedo ser distribudo.
Em relao topologia, muitos autores defendem que a melhor a hierrquica
(mais fcil de estruturar informao), enquanto outros defendem que a melhor a forma
de rede (mais fcil de navegar). O importante, de fato, arranjar a informao de uma
forma significativa para os usurios e adot-la em todo o site. Para sites institucionais
ou sites com muita informao, sugere-se fortemente uma estrutura hierrquica que
inclua links transversais (como uma rede) para ligar informaes relacionadas.
Como uma conseqncia direta da escolha da topologia, o mais importante no
o nmero de nveis em si mas se a forma de organizao do site significativa para os
usurios. Ao invs de sites com muita amplitude (poucos nveis mas com muitos links a
cada nvel da hierarquia) ou com muita profundidade (muitos nveis com poucos links a
cada nvel), sugere-se agrupar os links relacionados para diminuir o nmero de links e
facilitar a navegao contextual.
Definindo controles de navegao
A definio de uma boa navegao inclui algumas preocupaes bsicas:
* tornar links predizveis: usar o vocabulrio adequado para mostrar opes de
links e adicionar descritores aos links que os navegadores mais recentes permitem ao
usurio visualizar antes de selecion-lo;
* escolher cores de links visando a manuteno de um cdigo cromtico para os
links no visitados (azul) e para os links j visitados (vermelho ou roxo);
* aproveitar a estrutura hipertextual e embutir links no texto;
* para os links no embutidos no texto, arranje-os em listas (verticais ou
horizontais) como menus de navegao ou como links que marcam o histrico do
caminho de acesso percorrido at a pgina corrente;
* se usar links associados a imagens, sempre inclua rtulos de texto junto s
imagens e faa toda a imagem "clicvel" e no s uma parte dela.
Projetando pginas Web
Uma pgina Web bem projetada se a) revela claramente a estrutura da
informao que ela contm; e b) oferece pontos de acesso facilmente reconhecveis para
esta informao. Isto pode ser obtido atravs de tcnicas como agrupamento de
informao relacionada, uso de espaos em branco para separar estes grupos e uso de
ttulos e subttulos para estruturar a pgina.
Alm disto, importante considerar tambm:
* densidade da pgina: em pginas Web, usa-se menos espao em branco do que
se costuma usar em pginas impressas;
* a quantidade de informao exibida em cada pgina, que deve ser minimizada:
use abreviaes bem conhecidas e escreva to concisamente quanto possvel;
*cores de fundo e cores de texto: para facilitar "passar a vista" tipicamente use
caracteres escuros com fundos claros; mais detalhes ver [Borges et al. 2000];
* legibilidade do texto: tamanho e tipo de fonte, uso de maisculas e minsculas,
estilo do fonte (itlico, negrito, etc) , contraste, e outros parmetros similares.
Muitos links contendo recomendaes e outras informaes teis para concepo de
interfaces Web existem. Alguns dos mais interessantes so:
Yale C/AIM WWW Style Manual , http://info.med.yale.edu/caim/manual/contents.html
Creating Killer Web Sites , http://www.killersites.com/index.html
Usabilidade , http://www.usabilidade.com
Site Use-o de Jacob Nielsen , http://www.useit.com
Usable Web , http://www.usableweb.com
Web site usability: design guidelines . http://infoweb.magi.com/~asd/guidelines/guide.htm
MicroSoft Improving Web Site Usability and Appeal,
http:// msdn.microsoft.com/library/en-us/dnsiteplan/html/IMPROVINGSITEUSA.asp
Research-based Web Design and Usability Guidelines ,
http://usability.gov/guidelines/
4.3.2 Abordagens Sistemticas para Concepo de Interfaces Web
O estgio atual no campo de mtodos e processos de desenvolvimento para Web
evoluiu a partir do desenvolvimento da rea de aplicaes hipermdia standalone (off
line)
Nas abordagens a serem discutidas a seguir, h uma inteno bem clara de separar
os conceitos em camadas de projeto: projeto conceitual (dimenso estrutural), projeto
navegacional (dimenso de navegao), aspectos de interface com usurio (dimenso de
apresentao). Alm disso, as modelagens utilizadas tentam, na maioria, se distanciar
do ambiente de implementao e das tecnologias subjacentes.
Para simplificar, as informaes apresentadas nas tabelas 2 e 3 resumem as
principais abordagens existentes para o desenvolvimento sistemtico de interfaces Web:
Hypertext Design Model (HDM), Relationship Management Methodology (RMM),
Object-Oriented Hypermedia Design Method (OOHDM), JESSICA , Web Application
Extension (WAE) eWeb Modeling Language (WebML).
Para simplificar a anlise de cada mtodo, apresentaremos apenas como cada
abordagem considera algumas caractersticas tais como passos do processo de
desenvolvimento, modelos e notaes usados e adoo de ferramentas de suporte.
Abordagens Passos do Processo Modelos e Notaes Ferramentas de
suporte
Referncias
Bibliogrficas
HDM / HDM-lite 1. Authoring-
in-the-large
2. Authoring-
in-the-small
Entidade-
Relacionamento
(E-R)
Autoweb System
(HDM-lite)
[Garzotto et al. 93]
[Gaedke et al. 00]
[Fraternali 98]
RMM
1. Projeto de
entidades
2. Projeto de
relacionamentos
(slice)
3. Projeto
navegacional
4. Projeto de
protocolo de
converso
5. Projeto de
tela de interface de
usurio
6. Projeto de
comportamento em
tempo de execuo
7. Construo
E-R
+
RMDM (Relationship
Management
Data Model)
RMCase
[Isakowitz et al 95]
[Diaz et al. 1995]
OOHDM
1. Projeto conceitual
2. Projeto
navegacional
UML/OMT (1)
Prpria (2)
OOHDM-Web [Schwabe et al. 92]
[Rossi et al. 96]
3. Projeto de
interface de
usurio
4. Implementao
Abstract Data Views
(3)
[Schwabe et al. 99]
[Segor et al. 00]
JESSICA
1. Modelagem:
a. Diagrama de
classes
b. Use-cases
(cenrios)
2. Gerao/Parsing
3. Compilao
4. Visualizao
UML/XML JESSICA System [Barta et al. 98]
WAE
RUP (Rational Unified
Process)
1. Requisitos
2. Anlise
3. Projeto
4. Implementa
o
5. Testes
6. Avaliao
UML c/ esteretipos
prprios
Rational Rose [Conallem 00]
WebML
1. Modelo estrutural
2. Modelo de
composio
3. Modelo de
apresentao
4. Modelo de
personalizao
Prpria/
XML
WebML Tool Suite [Ceri et al. 00]
Tabela 2: Resumo de abordagens para concepo de aplicaes Web
Na tabela 2, a coluna Passos do processo relaciona os passos realizados no
processo de desenvolvimento segundo cada abordagem. Apesar de cada mtodo usar
nomenclaturas diferentes para cada passo descrito, podemos perceber a importncia ou
ausncia dada a certas fases, notadamente a estrutura navegacional e projeto de interface.
A coluna Modelos e Notaes indica os modelos e notaes usados nos passos do processo,
referenciando, quando pertinente, os passos em que cada modelo/notao usado. A
coluna Ferramentas de suporte apresenta qual ferramenta de suporte gerao de
modelos e/ou cdigos de implementao existe associada abordagem. Maiores
detalhes podem ser obtidos consultando as referncias fornecidas na coluna Referncias
Bibliogrficas.
A tabela 3 identifica quais passos do ciclo de vida de desenvolvimento de
aplicaes Web so cobertos por cada abordagem.
Design do Site
Engenharia
de
Requisitos
Espec. do
Site
Conceitual Naveg. Apresent.
Implem. Avaliao
HDM / HDM-
lite
RMM
OOHDM
JESSICA
WAE
WebML
Tabela 3: Cobertura do ciclo de vida
4.2.3 Ferramentas
Uma simples busca na internet nos mostra que h hoje em dia uma grande quantidade
de ferramentas com o objetivo de auxiliar a construo de novas aplicaes Werb ou at
a migrao de sistemas legados para a plataforma Web. Com este objetivo comum,
todas permitem facilidades e um ganho considervel de esforo em relao ao
desenvolvimento manual de sites. No entanto, um cuidadoso olhar sobre suas
caractersticas revela que a maioria destas ferramentas concentra-se ainda sobre a fase
de implementao do site, no considerando ou considerando apenas parcialmente as
outras fases do ciclo de desenvolvimento Web (ver seo XXXX???).
Os principais tipos de ferramentas para concepo de interfaces Web so:
editores visuais HTML : editores WYSIWYG que permitem a construo de
pginas HTML sofisticadas sem programao (p.ex. MicroSoft FrontPage);
verificadores de links: que lem um documento HTML, extraem os vnculos
(links) de hipertexto e testam a validade dos URLs; estas ferramentas so
tipicamente associadas avaliao de sites e por isto esto descritas na seo
6;
gerenciadores de sites: que permitem exibir graficamente o contedo de um
site e suportam funes como remoo, renomeao, upload de pginas alm
de deteco e reparo de links "quebrados" (p.ex. VisualWeb, SiteAnalyst ,
WebTracer http://www.nullpointer.co.uk/-/tracer.htm, e Mapuccino
http://www.alphaworks.ibm.com/tech/mapuccino) ;
ferramentas de autoria de hipermdia estendidas para Web (Web-enabled
hypermedia authoring tool): que foram inicialmente concebidas para
desenvolvimento de aplicaes hipermdia off-line (no conectadas Web) e
que foram estendidas para suportar gerao de aplicaes Web (p.ex.
Asymetrix Toolbook e o Macromedia Director);
gateways Web-Bancos de Dados: que produzem pginas HTML
dinamicamente a partir do contedo de um banco de dados, geralmente
atravs de templates de pginas HTML embutindo consultas SQL,
processadas dinamicamente por um script CGI; exemplos desta categoria
incluem JavaSoft Java Server Pages (JSP), MicroSoft Active Server Pages
(ASP) e Allaire Cold Fusion Web Database Construction Toolkit;
editores de formulrios Web, geradores de relatrios e assistentes de
publicao de bancos de dados na Web (Web database publishing wizards):
que auxiliam a migrao de aplicaes baseadas em formulrios (forms) da
arquitetura cliente-servidor centrada em bancos de dados para a Web e que
suportam tarefas especficas associadas a esta migrao; o assistente de
publicao, por exemplo, permite a personalizao de pginas geradas pela
aplicao de modelos pr-definidos de apresentao aos objetos exportados
de bancos de dados;
geradores de aplicaes Web orientados a modelos: que fornecem cobertura
completa a todas as atividades de desenvolvimento, produzindo
automaticamente sites compostos de pginas de formato fixo criadas a partir
de modelos que descrevem a) o esquema do banco de dados, b) a definio
das aplicaes e suas unidades que vo manipular o banco de dados e c) as
preferncias dos usurios na forma de parmetros (cores, cabealhos,
imagens de fundo, rodaps, texto de ajuda, etc) que sero usados para
direcionar a gerao da apresentao das pginas. Exemplos incluem a
ferramenta AutoWeb [Fraternali 2000] e Web Development Suite da Oracle,
que contm inclusive a Designer 2000.
5 Mtodos de Avaliao de Usabilidade
Nos ltimos anos um grande nmero de mtodos tradicionais de avaliao de
usabilidade tm sido utilizados em projetos Web com pequenas adaptaes, e outros
tm sido desenvolvidos especificamente para este ambiente. Nesta seo so
apresentados os principais mtodos de avaliao de usabilidade aplicveis a interfaces
Web. Evidentemente esta lista no exaustiva e outros mtodos podem ser utilizados
para a mesma finalidade.
5.1 Diversidade de Mtodos de Avaliao
Os mtodos de avaliao de usabilidade disponveis podem ser classificados, em
um primeiro momento, como mtodos de inspeo de usabilidade e testes empricos
com a participao de usurios. Mtodos de inspeo caracterizam-se por empregarem
especialistas em interface que a utilizam em busca de possveis problemas de
usabilidade. Como exemplo cita-se a avaliao heurstica. Os mtodos com a
participao de usurios caracterizam-se pelo uso 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), questionrios e anlise de arquivos
de log, entre outros. Outros mtodos que envolvem usurios como, por exemplo, focus
group e classificao de cartes (card sorting), tambm so utilizados para descobrir
como os usurios organizam as informaes do domnio de problema, quais suas
expectativas e necessidades com relao interface.
5.2 Avaliao heurstica
A avaliao heurstica um mtodo tradicional de avaliao de usabilidade. Este
mtodo foi desenvolvido por Nielsen e Molich (Nielsen, 1993) e consiste da inspeo
sistemtica da interface do usurio com relao sua usabilidade. O mtodo foi
utilizado pela primeira vez em um interface Web em 1994, num estudo para o web site
da Sun Microsystems (Nielsen e Sano, 1995). Seu procedimento bsico o seguinte: um
avaliador interage com a interface e julga a sua adequao comparando-a com
princpios de usabilidade reconhecidos, as heursticas. Nielsen sugere um conjunto com
apenas 10 recomendaes heursticas para guiar a avaliao, enumeradas a seguir.
Dilogos Simples e Naturais: as interfaces de usurios devem ser o mais
simples possvel. Interfaces devem combinar as tarefas do usurio de forma a
simplificar o mapeamento entre os conceitos computacionais e os do usurio. Deve-se
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 compatvel com o modo pelo qual
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.
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.
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 recomendaes
que se aplicam por toda a interface. Se o nmero de recomendaes grande o usurio
ter de aprender/lembrar todas as recomendaes, 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 recomendaes. 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.
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.
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. Muitas vezes,
feedbacks especiais so necessrios para mostrar o andamento de uma tarefa ou
contextualizar uma navegao mais demorada do usurio.
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 Cancelar para abortar
uma tarefa. Muitas vezes, as sadas podem ser fornecidas por meio de uma facilidade de
desfazer (undo) a ltima operao e retornar ao estado anterior. Os usurios
rapidamente aprendem a confiar neste mecanismo e portanto ele 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.
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 da Receita Federal na poca de declarar o IRPF deve haver um link
na primeira pgina para declarao on-line ou para download dos programas de
declarao ao invs de obrigar o usurio a navegao pelo site at achar a pgina
correta, o que muitas vezes no muito fcil.
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.
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 e tornar muito improvvel que este erro ocorra.
Ajuda e Documentao: o melhor que um software que seja to fcil de usar
que no necessite de ajuda ou documentao. No entanto, se preciso, esta ajuda deve
estar facilmente acessvel on-line. 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 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. 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 encontrados durante a avaliao do CD-ROM Literatura Gacha
(veja figura 7), assim como comentrios que ilustram como os avaliadores utilizaram as
heursticas para identificar problemas.
Descrio do Problema Severidade
[1 3]
Heurstica violada e Comentrios
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.
3
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.
Na obra O tempo e o
Vento o boto [crtica]
(base da figura Obra)
disponvel mas, uma vez
selecionado, no mostra o
texto correspondente
crtica do livro, como
esperado.
2
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.
No existem opes de
atalho.
1
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.
Tabela 2 - Exemplos de Problemas de Usabilidade.
Autor - rico Verssimo. Obra O Tempo e o Vento.
Figura 7 - CD-ROM Literatura Gacha.
O mtodo de avaliao heurstica pode ser empregado sem modificaes em
projetos Web. Contudo, recentemente Nielsen e outros autores (Bailey, 1999) tem
sugerido outros conjuntos de recomendaes que podem ser utilizados em substituio
das heursticas clssicas de Nielsen. A avaliao heurstica um mtodo simples, cuja
eficincia reside na capacidade dos avaliadores de reconhecer problemas de usabilidade.
Em princpio, qualquer pessoa pode ser treinada para a aplicao deste mtodo, embora
melhores resultados sejam obtidos com avaliadores experientes. Outra vantagem deste
mtodo que ele pode ser aplicado em qualquer etapa do desenvolvimento, mesmo
sobre prottipos em papel.
5.3 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
(Rubin, 1994). 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 somente para udio. 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,ferramentas como LotusCam ou at mesmo papel e caneta). A Figura 8
apresenta um ensaio de interao no laboratrio de usabilidade da UFSC, o LabiUtil
7
.
Sempre que possvel deve-se selecionar para o teste usurios reais da interface.
Em alguns casos, se os usurios escolhidos no forem representativos, todo o teste pode
falhar na identificao de problemas de usabilidade. Contudo, pode ser difcel localizar
usurios reais de interfaces Web. Ainda que usurios reais possam ser localizados, a
distribuio geogrfica pode inviabilizar a sua participao.
Figura 8 - Ensaio de Interao em um laboratrio de usabilidade.

7
Imagem reproduzida com a permisso do LabiUtil (Universidade Federal de Santa Catarina UFSC,
Florianpolis; http://www.labiutil.inf.ufsc.br/ ).
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
de interfaces Web. Nielsen (1993) 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, embora 5 seja um nmero relativo para
garantir a eficincia do mtodo (Woolrych e Cockton 2001).
Durante o teste os usurios podero ser solicitados a realizar tarefas que so pr-
definidas (cenrios de teste) 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 por exemplo:
Procure no site da UFRGS o endereo postal do Instituto de Informtica., Qual o
nome do reitor da UFRGS?.
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, que fica
geralmente a cargo de especialistas em ergonomia. Basicamente, problemas de
usabilidade so identificados quando se observa usurios com dificuldades para
completar suas tarefas.
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 informado claramente ao usurio. Ainda que o usurio saiba
disto, a sesso de teste geralmente estressante para ele e dever do avaliador criar um
clima agradvel 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.
5.4 Inspeo de recomendaes ergonmicas (guidelines e checklist)
Boa parte do conhecimento sobre usabilidade tem sido sistematizado sob a
forma de guidelines ou conjuntos de recomendaes ergonmicas. A construo desses
guidelines resultado de pesquisas nas reas de cincia cognitiva, psicologia e
ergonomia. Em alguns casos, trata-se de conhecimento prtico que foi acumulado
durante o desenvolvimento de vrios projetos ou ainda, recomendaes de bom senso.
Exemplos de recomendaes foram apresentados na seo 4.3.1 De um modo geral no
existe um padro de descrio de recomendaes ergonmicas, que podem ter um
escopo amplo (que exige interpretao por parte do avaliador) ou especfico (aplicveis
diretamente ao projeto). Como exemplos de tais recomendaes cita-se duas:
Pginas iniciais, que suportam navegao, que devam ser lidas rapidamente ou,
que contenham grficos grandes, devem ser curtas. Usar pginas longas para
simplificar a manuteno do site e tornar as pginas mais fceis de imprimir.
(fonte: Lynch e Hortson, 1999)
Selecione cuidadosamente os ttulos de pginas. Use nomes que estejam
relacionados com o contedo ou funo da pgina. (Fonte: Nielsen, 1999)
Recomendaes ergonmicas podem ser usadas com o duplo propsito de
auxiliar o processo de concepo ou guiar a avaliao. Durante o processo de
concepo, designers devem consultar tais recomendaes que auxiliam evitar
problemas de usabilidade. Por outro lado, pode-se utilizar o conjunto de recomendaes
ergonmicas como suporte para a inspeo da interface; neste caso, a interface
inspecionada minuciosamente por um avaliador que verifica se todas as recomendaes
ergonmicas so respeitadas.
A avaliao de usabilidade usando guidelines consiste basicamente em ter um ou
mais avaliadores que investigam a interface e, quando um problema identificado este
associado uma ou mais recomendaes que foram violadas. O processo simples mas
exige uma grande experincia do avaliador, pois o conjunto de recomendaes
ultrapassa facilmente algumas dezenas a considerar. Algumas recomendaes no so
facilmente aplicadas e exigem a interpretao por parte do avaliador. Por estes motivos,
o processo de avaliao usando recomendaes ergonmicas pode ser bastante
exaustivo se o avaliador no tiver conhecimentos prvios sobre as recomendaes.
Uma soluo alternativa para este problema utilizar um checklist, que nada
mais do que um conjunto mnino de recomendaes diretamente aplicveis ao projeto,
que em geral, que no necessitem um grande esforo de interpretao. Geralmente
checklists focalizam alguns aspectos considerados importantes da interface e que,
potencialmente, podem hospedar os problemas mais graves de usabilidade. A tabela 3
apresenta um checklist para avaliao de sites Web de vendas online.
Checklists facilitam a anlise de recomendaes ergonmicas durante a
avaliao de usabilidade. Este tipo de inspeo pode ser particularmente interessante
quando se deseja realizar avaliaes rpidas de usabilidade, investigar a consistncia da
interface e verificar mudanas ocasionadas pela manuteno do site. Trata-se de um tipo
de inspeo de custo relativamente baixo que pode ser adaptado s diversas situaes de
avaliao, bastando para tanto selecionar as recomendaes ergonmicas adequadas.
Contudo, tal avaliao tende a ser restrita aos itens que fazem parte da avaliao.
De uma maneira geral, guidelines completas contam com centena de recomendaes
(ver Vanderdonckt, 1994; ISO, 1999), o que pode tornar o processo de inspeo tedioso.
A inspeco de guidelines deve, portanto ser utilizado com critrio e no substitui o uso
de outros mtodos de avaliaes com usurios. A inspeo com o uso de guidelines
adequada, durante a construo de prottipos funcionais, uma vez que a maioria das
recomendaes endereada a objetos de interao.
Navegao do site
Sim No Obs.
A navegao atual sempre clara (Onde eu estou?)?
Todas as pginas tem um links para a pgina inicial?
A estrutura do site simples?
Nomes tcnicos e jarges so evitados?
Nenhum recurso ou plug-ins desnecessrio utilizado?
Pginas so menores do que 50 Kb ?(para minimizar o tempo d download)
Encontrando produtos
Sim No Obs.
Clientes podem procurar produtas de diferentes maneiras?
Existe uma ferramenta de busca fcil de utilizar para procurar produtos?
Produtos so descritos adequadamente?
Produtos so classificados claramente?
Comprando
Sim No Obs.
O processo de compra claro e simples?
So aceitos cartes de crdito?
Pagamentos com carto de crditos usam mecanismos de segurana (SSL)?
A descrio da poltica de vendas clara e fcil de encontrar no site?
O procedimento para devoluo de produtos claro e fcil de encontrar no site?
Clientes podem pagar por telefone?
A empresa fornece informaes claras sobre a entrega de produtos?
A empresa tem suporte para clientes fora da rea metropolitana?
Clientes podem abandonar facilmente um processo de compra?
Clientes podem cancelar facilmente uma ordem de compra?
Servio ao cliente
Sim No Obs.
O suporte pode ser feito por mail?
O suporte pode ser feito por telefone e o nmero fcil de encontrar no site?
Todos os links grficos so tambm disponveis como links de texto (para clientes com
deficincia visual)
Todas as imagens tem uma ALT tag (para clientes com deficincia visual)
Preveno e recuperao de erros
Sim No Obs.
Erros no ocorrem facilmente.
Mensagens de erro so claras e teis.
Aspecto visual
O layout claro?
Animaes desnecessrias so evitadas?
O aspecto visual agradvel?
As pginas so legveis?
Tabela 3 - Checklist para avaliao de usabilidade para um sistema de vendas online
(fonte: Information & Design http://www.infodesign.com.au).
Os anexos F apresenta o guidelines para Web desenvolvido por Jakob Nielsen.
Outros guidelines recomendados: Lynch & Hortson (1999), Vanderdonckt (1994),
http://usability.gov/guidelines/index.html e http://www.foruse.com/Tools.htm.
5.5 Questionrios
Questionrios so ferramentas muito teis na avaliao da interao entre o
usurio e a interface. So utilizados para coletar informaes subjetivas sobre dados
sobre o perfil dos usurios, a qualidade da interface e quais problemas so encontrados
no seu uso. Estas informaes so to importantes quanto a performance no uso do
sistema, e no podem ser obtidas de outra forma seno perguntando aos usurios. O uso
de questionrios d ao avaliador a vantagem de aplicar vrios testes ao mesmo tempo
em locais diferentes. Questionrios podem ser teis de diferentes maneiras dentro do
desenvolvimento de interfaces Web como, por exemplo, para:
Identificar o perfil dos usurios. O objetivo deste tipo de questionrio basicamente
coletar informaes sobre os usurios. Tais informaes podem ser de origem
funcional, pessoal, sobre preferncias ou mesmo sobre a utilizao de computadores
e sistemas. Obviamente outras questes podem ser adicionadas para fins especficos
de avaliao.
Determinar o grau de satisfao dos usurios com relao a interface. Questionrios
especficos para descobrir a satisfao de usurios vm sendo pesquisados desde a
dcada de 80, e uma verso especfica para sites Web tem sido desenvolvida sob o
nome de WAMMI (disponvel por http://www.wammi.com/).
Estruturar informaes sobre problemas de usabilidade identificados por usurios,
na forma de questionrios para relato de incidentes crticos (ver seo 5.6).
Pode-se ainda utilizar questionrios para estruturar avaliaes com usurio (ver
seo 5.3), onde o usurio deve utilizar a interface de modo a poder responder as
questes. Neste caso, as perguntas devem ser definidas antes do teste e adaptadas a cada
contexto de avaliao.
Uma das grandes vantagens de questionrios a possibilidade de aplic-los um
grande nmero de usurios ao mesmo tempo, utilizando o prprio ambiente Web
atravs de formulrios eletrnicos. Contudo, deve-se salientar que os resultados exigem
um grande esforo de interpretao para identificar problemas de usabilidade. Os
questionrios para avaliar a satisfao dos usurios so interessantes do ponto de vista
de marketing, mas na maioria dos casos no explicam os resultados obtidos como por
exemplo por que razo os usurios gostam do site ou o que deve ser mudado para
melhorar a interface. Assim, questionrios de satisfao devem sempre ser
acompanhados de algum outro mtodo de avaliao que possa explicar as respostas
subjetivas dos usurios.
5.6 Relatos de incidentes crticos por usurios
Relato de incidentes crticos (IC) consiste simplesmente na anlise de descries
de aes e eventos que refletem problemas de usabilidade, ausncia de funes que
deveriam estar na interface, ou outros problemas que interferem na interao do usurio
com a interface. Geralmente, tais descries so realizadas pelos prprios usurios que
relatam ICs enquanto trabalham em suas tarefas dirias. So descries espontneas que
no ocorrem dentro de um contexto de avaliao e, portanto, so normalmente informais
e pouco estruturadas.
Webmasters e a equipe de manuteno do site so os alvos mais visados das
crticas e relatos de problemas encontrados no site. Observa-se, no entanto, que muitas
equipes de desenvolvimento negligenciam este tipo de informao. Existem vrias
razes que poderiam justificar o descaso dos webmasters. Uma delas o fato de que tais
profissionais nem sempre so as mesmas pessoas responsveis pelo design ou avaliao
do site, e portanto, no esto aptas a interpretar tais dados como indcios de que a
usabilidade do site pode estar sendo comprometida.
Alguns estudos experimentais realizados por Castilho (1998) sugerem que
alguns alguns fatores contextuais podem auxiliam na interpretao dos relatos. Estes
fatores so:
incio e fim do IC;
tarefa e objetivo do usurio antes do IC;
expectativa do usurio antes do IC;
freqncia do IC;
como evitar um IC;
sugestes do usurio para resolver o IC.
Um suporte mnimo pode ser oferecido aos usurios de modo a lhes facilitar a
tarefa de descrever ICs. Este suporte pode ser feito na forma de um treinamento rpido
que visa ensinar usurios a reconhecer um IC e a descreve-lo. Este tipo de treinamento
recomendado especialmente no caso de Intranet ou quando usurios representam um
pblico cativo, como no caso de cursos de treinamento a distncia, por exemplo. Outra
soluo oferecer questionrios que permitam aos usurios descrever o cenrio de
ocorrncia do problema.
Os principais problemas com esta tcnica so a qualidade da descrio e
confiabilidade nos relatos. Alm disto, o sucesso depende da boa vontade de usurios
em relatar os problemas que encontram na interface. Esta tcnica til, tendo um custo
menor que testes com usurios, embora a descrio e confiabilidade dos achados seja
bem inferior. Este mtodo de anlise deve ser aplicado durante todo o perodo de
utilizao da interface por usurios.
5.7 Anlise de Logs
Neste mtodo so analisadas as interaes do usurio atravs de arquivos de logs
gerados durante a utilizao do sistema. Anlise de arquivos de logs uma tcnica que
pouco interfere na realizao das tarefas, preservando assim pores do contexto do
trabalho real. A tarefa de coleta de dados relativamente barata, no exige a
participao do avaliador durante o teste e guarda todas as aes do usurio, o que de
difcil aquisio em outras tcnicas.
Em princpio este parece ser o mtodo de avaliao ideal para o ambiente Web,
uma vez que os servidores Web, que fornece as pginas ao cliente na Web, mantm um
arquivo de log das requisies dos clientes. Basicamente so registrados pelo servidor:
o IP da mquina utilizada pelo cliente;
data e horrio da solicitao;
nome do arquivo solicitado;
identificao do browser cliente;
identificao do sistema operacional do cliente;
pgina onde o usurio selecionou o link; e,
erros de solicitao de arquivo.
Os dois maiores problemas, porm, so identificar que tipos de dados so teis e
a forma de analis-los. No trabalho realizado por Siochi e Ehrich (1991), na anlise de
repetio de padres em arquivos de log, foram encontradas aes que sugeriram
problemas de usabilidade; porm, alguns somente foram identificados ou confirmados
quando os usurios explicaram o que estavam tentando fazer com aquelas aes. No
caso da Web, os registros em arquivos de log mantidos pelos servidores no so
suficientes para analisar toda a interao do usurios. Isto ocorre quando usurios usam
browsers off line, com cache local ou servidores proxy, que mascaram as requisies
evitando o acesso direto ao servidor. As ferramentas mais frequentes para anlise de
logs apenas realizam estatsticas de acesso das pginas mais visitadas e, em alguns
casos, a origem e os usurios mais frequentes. Entretanto estas informaes no dizem
muito sobre a usabilidade.
Contudo, uma simples anlise dos erros armazenados nos arquivos de log, pode
ser til na identificao de problemas relacionados a pginas no encontradas devido a
links invlidos (Sullivan, 1997). Outra forma de utilizar eficientemente arquivos de log
analisar as palavras-chaves informadas pelos usurios s ferramentas de busca, pois
elas indicam que tipo de informao os usurios esto procurando e podem sugerir
como facilitar o acesso a elas.
6 Ferramentas para avaliao automtica
Nesta seo introduzida a idia de avaliao automtica e so descritas algumas
ferramentas existentes para auxiliar esta tarefa.
6.1 Inspeo Automtica
No intuito de minimizar o esforo de avaliao de interfaces, vrias ferramentas
de software para inspeo automtica de interfaces Web tm sido desenvolvidas nos
ltimos anos. As primeiras ferramentas criadas verificavam apenas a consistncia do
cdigo HTML mas atualmente algumas so tambm capazes de verificar
recomendaes ergonmicas, identificar problemas de usabilidade e realizar correes
automaticamente. Tais ferramentas se tornaram bastante populares pois no exigem que
a pessoa que as utiliza seja um especialista para identificar problemas de usabilidade.
O processo de avaliao com o auxlio de tais ferramentas semelhante ao
mtodo de inspeo de recomendaes ergonmicas. Um programa l as pginas do site
e tenta identificar problemas de usabilidade que podem ser extrados a partir do cdigo
HTML. So alguns exemplos de problemas que podem ser identificados por tais
ferramentas:
Imagens que no possuem um texto alternativo (tag ALT) para usurios que no
carregam imagens ou so deficientes visuais;
A pgina contm mais de um link com o mesmo nome que ligam pginas diferentes;
A cor de fundo da pgina e a cor do texto tem pouco contraste tornando difcil a
leitura;
A pgina do site no contm nenhum link apontando para ela;
O link aponta para uma pgina que no existe;
A imagem informada no documento no existe no endereo especificado ou no
pode ser apresentada.
Algumas ferramentas limitam-se a identificao de problemas, outras
conseguem corrigir alguns dos erros encontrados. Contudo deve-se salientar que so
poucos os tipos de problemas que podem ser identificados automaticamente sem a
interpretao de um avaliador. Na maioria dos casos tais ferramentas identificam
situaes que sugerem a existncia de problemas e chamam a ateno da pessoa que as
utiliza, o qual deve interpretar o alerta e determinar se realmente um problema de
usabilidade. Portanto, o uso de tais ferramentas no resolve todos os problemas de
usabilidade nem elimina a necessidade de conhecer princpios bsicos de concepo de
interfaces erogonmicas, contudo elas facilitam o processo de inspeo que pode ser
tedioso quando realizado manualmente sobre grandes sites.
6.2 Funcionalidades de ferramentas de avaliao automtica
Podemos distinguir 3 categorias de inspeo: a) verificao do cdigo
HTML/CSS; b) verificao de recomendaes de acessibilidade; c) verificao de
recomendaes ergonmicas.
Ferramentas que verificam a conformidade do cdigo HTML/CSS no se
preocupam com outros aspectos ligados a usabilidade. Neste caso, a verificao
restrita a comparao do cdigo da pgina com o padro definido para a linguagem.
Tais ferramentas so interpretadores de cdigo, semelhantes aqueles que vem junto com
os compiladores de algumas linguagens de programao. Tais interpretadores so
capazes de identificar os marcadores <tags> utilizados e de determinar se eles fazem
parte da recomendao W3C (a organizao que define os padres para a web).
Marcadores que no seguem o padro podem funcionar em alguns browsers, mas
devem ser evitados pois podem comprometer a usabilidade da interface se os usurios
dispem de um browser diferente.
Para exemplificar o uso catastrfico de marcadores no padronizados a figura 9
apresenta o resultado de uma pgina que utiliza tais marcadores em dois browsers
diferentes (Internet Explorer e Netscape). Como pode-se observar, a pgina
compreensvel quando exibida pelo Internet Explorer mas ilegvel no Netscape.
Salienta-se que todos os fabricantes de browser esto cientes dos padres W3C e
implementam todas funcionalidades previstas. Seguir as recomendaes W3C uma
maneira que o desenvolvedor tem de se assegurar que o contedo das pginas Web ser
exibido corretamente por todos os browsers.
Internet Explorer Netscape
Figura 9. Problema de apresentao devido ao uso de marcadores no-padronizados
(http://www.terra.com.br/istoe/)
A segunda categoria de funcionalidade oferecida diz respeito a verificao de
recomendaes de acessibilidade, de acordo com a definio da Iniciativa para
Acessibilidade da Web (WAI http://www.w3.org/WAI/). Como mencionado
anteriormente na seo 2.2, acessibilidade (accessibility) implica em tornar utilizvel a
interface por qualquer pessoa, independente de sua deficincia fsica, sensorial,
cognitiva, condio de trabalho ou barreiras tecnolgicas. Contudo, observa-se que tais
recomendaes no beneficiam apenas os usurios com necessidades especiais mas
usurios em gerais, assim muitas ferramentas utilizam o conjunto de recomendaes
desenvolvido dentro da WAI como base para a inspeo.
A terceira categoria de funcionalidade inclui a inspeo de recomendaes
ergonmicas. Na maioria dos casos, tais recomendaes no so padronizadas e so
definidas pelos prprios autores das ferramentas. Tais recomendaes podem ou no ser
baseadas em estudos cientficos que justificam a sua aplicao. Tais ferramentas podem
incluir outras verificaes que no so definidas formalmente como acessibilidade ou
usabilidade mas podem ser teis ao desenvolvedor tais como a verificao ortogrfica
do texto, contadores de palavras e compatibilidade com indexadores de pginas que
facilitam a recuperao por ferramentas de busca.
Nas duas ltimas categorias de ferramentas ocorre o fenmeno de interpretao
da recomendao. Isto ocorre porque as recomendaes de usabilidade e acessibilidade
no foram necessariamente escritas para serem avaliadas automaticamente por
ferramentas. Para automatizar o processo, os desenvolvedores devem traduzir a
recomendao de modo a eliminar a ambigidade contida no texto. Assim, a
recomendao interpretada pelo desenvolvedor da ferramenta que a traduz na
implementao, o que explica em parte porque os resultados variam de um ferramenta
para outra. Por exemplo, considere o simples exemplo de contraste de cores. A
recomendao diz que a cor de fundo deve contrastar com a cor do texto mas no
informa nada sobre os valores aceitveis de contraste. Ao implementar esta
recomendao, a ferramenta armazena uma tabela de valores aceitveis, e tal tabela no
necessariamente a mesma para todas as ferramentas.
Constata-se que a capacidade de identificao das ferramentas de avaliao
automtica fortemente ligada forma de especificao da recomendao utilizada.
Para explicar melhor isto apresentamos uma segunda categoria de recomendaes e seus
nveis possveis de automatizao:
Inspeo automtica da recomendao: todos os elementos para a automatizao so
descritos na recomendao, sem ambigidade. Ex. Um link no deve apontar para
uma pgina que no existe.
Inspeo automtica com a interpretao da recomendao. Ex. Usar cores
contrastantes para o texto e fundo da pgina, esta recomendao pode ser
automatizada se uma tabela de valores aceitveis para cores for fornecida;
Inspeo parcial da recomendao, falta informao para identificar o problema mas
alertas podem ser dados. Ex. O nome de um link completamente diferente do
ttulo da pagina destino, neste caso a ferramenta no pode determinar se trata-se de
um link que liga uma pagina equivocadamente ou no, um alerta pode ser dado para
o avaliador.
A recomendao abstrata e no pode ser verificada automaticamente. Ex. Crie um
contexto de utilizao para a interface.
6.3 Ferramentas para avaliao automtica
De um modo geral, tais ferramentas oferecem recursos bastante limitados de
avaliao e no so capazes de identificar mais do que 35% dos problemas se
usabilidade, no melhor de todos os casos. Contudo, a sua utilizao simples e pode
realmente auxiliar na identificao de problemas importantes tais como a ocorrncia de
links invlidos, uso de cores com contraste adequado e existncia de texto alternativo
para imagens. Algumas ferramentas implementam mais do que uma destas
funcionalidades. Outras ferramentas no apenas oferecem recursos para a verificao
mas so capazes de corrigir automaticamente alguns dos problemas identificados.
Salienta-se que em geral as avaliaes so realizadas pelas ferramentas baseadas
no cdigo HTML e so puramente sintticas. Apenas algumas ferramentas so capazes
de avaliar recomendaes ergonmicas. Ferramentas podem ser usadas para auxiliar o
processo de avaliao de usabilidade, mas at o momento nenhuma das ferramentas
desenvolvidas capaz de substituir o uso de mtodos no-automticos de avaliao. A
seguir so apresentadas algumas ferramentas (e informaes de acesso) para avaliao.
Bobby - http://www.cast.org/bobby (1999)
Desenvolvido pela CAST, ele suporta inspeo automtica e manual de
recomendaes de usabilidades incluindo alertas. Analisa a compatibilidade entre vrios
browsers. Pode ser usado como ferramenta online ou instalado no servidor. A verso
para download escrita em Java. As recomendaes verificadas incluem o pacote WAI
entre outras.
Doctor HTML - http://www2.imagiware.com/RxHTML/ (1997)
Desenvolvido pela Thomas Tongue e Imagiware, ele realiza verificaes bsicas
de acessibilidade tais como verificao da tag "alt" em imagens e links vlidos. Ele
tambm verifica erros de sintaxe e correo ortografia do texto. Pode usar uma verso
online ou comprar ou comprar uma autorizao para instala-lo no servidor.
Dr. Watson - http://watson.addy.com/ (2000)
Dr. Watson um servio gratuito oferecido pela Addy & Associates (2000). Esta
ferramenta verifica o cdigo HTML 3.2, assim como extenses Netscape e Microsoft de
HTML 4.version 4.x. Watson tambm pode verificar a validade de links, tempo de
download de pginas, compatibilidade com ferramentas de busca, popularidade do link,
nmero de palavras no texto e correo ortogrfica. Nenhum verificao automtica da
acessibilidade verificada. Apenas a verso online disponvel.
Lift - http://www.usablenet.com/ (2001)
Lift Onsite e Lift Site so duas ferramentas desenvolvidas por UsableNet, Inc.
LIFT Onsite permite web designers testar e corrigir problemas de acessibilidade e de
usabilidade em pginas web incluindo problemas de navegao, velocidade de carga
da pagina, qualidade das imagens utilizadas, etc. Ele integra editores web tais como
Dreamweaver, GoLive, FrontPage, BB Edit. Esta ferramenta executa localmente
sobre MacOS.
LIFT Online uma parte do LIFT Onsite e funciona num esquema de pre-inscrio
no site.
Netmechanic - http://www.netmechanic.com/
Netmechanic contm um pacote completo de ferramentas de verificao que inclui
inspeo do cdigo, otimizao de imagens, velocidade de conexo e monitorao de
acesso do servidor.
WebSAT - http://zing.ncsl.nist.gov/WebTools/WebSAT/overview.html (1999)
WebSat faz parte de um pacote de 4 ferramentas para desenvolvimento de
interfaces Web com usabilidade. WebSate a ferramenta que realiza a inspeo de
recomendaes de acessibilidade de paginas web, navegao, legibilidade e tempo de
carga do site. Assim como Bobby, esta ferramenta capaz de dar alerta ao avaliador
para pores do site que requerem a interpretao da regra. Pode ser utilizada online ou
instalado localmente em plataformas Unix ou Windows 95/NT.
PageScreamer - http://www.crunchy.com/tools/PageScreamer.html (2002)
Desenvolvido pela Crunchy Technologies. Verifica e corrige contedo web
fornecendo equivalncia para elemento de texto. Verifica tabelas HTML, frames para
navegao. Executa sobre Windows 9x, Windows NT, Windows 2000, Linux, Sun
Solaris.
Page Valet - http://valet.webthing.com/page/ (2002)
Page Valet combina verificao formal e validao de acessibilidade baseadas
nas recomendaes WAI.
W3C CSS validator - http://jigsaw.w3.org/css-validator/ (1998)
Esta ferramenta verifica documentos web que utilizam CSS. Pode ser utilizada
online ou instalada localmente.
W3C HTML validation service - http://validator.w3.org/
um servio de verificao do cdigo HTML de acordo com as normas W3C
HTML. O servio disponvel online.
A-Prompt - http://aprompt.snow.utoronto.ca/
Desenvolvido pela universidade de Toronto. E gratuito e pode ser utilizado para
inspecionar a interface e corrigir problemas identificados.
Colorfield Insight - http://www.colorfield.com/insight.html
Permite aos designer predizer a legibilidade de uma imagem para deficientes
visuais. Desenvolvido pela Colorfield Digital Media (2000).
Para uma lista completa de ferramentas disponveis verifique o endereo:
http://www.w3.org/WAI/ER/existingtools.html.
7 Discusso e Consideraes Finais
At aqui foram descritos vrios conceitos e mtodos de avaliao de usabilidade
contudo pouco foi dito sobre como e quando utiliz-los. Mtodos de avaliao de
usabilidade so auxlios que devem ser considerados dentro do processo de
desenvolvimento de aplicaes e no como uma etapa isolada. Deve-se lembrar sempre
que o objetivo principal de uma avaliao melhorar a interface e no apenas estimar o
quanto uma interface boa ou ruim. Pode-se dizer que uma boa avaliao de
usabilidade no aquela que apenas identifica os problemas de usabilidade mas que
auxilia a equipe de desenvolvimento a solucion-los e a melhorar a interao do usurio
com a aplicao.
Avaliao de usabilidade exige preparao. Alguns podem argumentar que
apenas uma inspeo baseada no seu prprio feeling suficiente para determinar a
usabilidade de um site Web. Porm, no duvide que os resultados de tal avaliao sero
to duvidosos quanto os critrios que foram utilizados. Na maioria dos casos os critrios
expressam apenas uma opinio pessoal do avaliador e no a realidade dos usurios.
Vrios aspectos contam para o sucesso de uma avaliao, entre os principais
incluem-se a escolha do mtodo adequado a cada situao de avaliao, a aplicao do
mtodo nas etapas adequadas de desenvolvimento, a documentao da avaliao e a
formao contnua dos avaliadores. Esta seo visa justamente apresentar algumas
recomendaes e reflexes que podem auxiliar a considerar tais aspectos.
O processo de desenvolvimento de interfaces Web um ciclo de etapas
sucessivas de prototipao e avaliao. Interfaces Web esto sempre sendo atualizadas e
cada alterao pode interferir na usabilidade. Na maioria dos casos os projetos Web
dispem de recursos limitados para realizar avaliao de usabilidade tornando proibitivo
avaliao a cada atualizao do site. Assim, torna-se vital escolher o melhor momento
para realiz-las.
Observa-se que nas etapas em que se tem prottipos avanados e durante o uso
de interfaces por usurios pode-se optar entre diferentes mtodos de avaliaes. Deve-se
prestar ateno etapa de anlise de requisitos na qual uma srie de mtodos de coleta
de informao devem ser empregados. Vrias tcnicas, como por exemplo reunio com
usurios (focus group)(Nielsen, 1997) e classificao de cartes (Gaffney, 2000)
podem evitar alguns de problemas de usabilidade. Tais tcnicas no foram descritas
aqui pois esto alm do escopo deste captulo mas no devem ser menosprezados.
Alm das etapas sugeridas acima para avaliao, alguns eventos podem exigir
avaliaes adicionais. Exemplos de tais eventos incluem:
Mudanas na estrutura ou organizao do espao de informao do site;
Incluso ou mudana de tecnologia da interface;
Mudana do design grfico;
Incluso de novos mdulos ou novas tarefas suportadas pela aplicao.
Alm destes eventos, outros sinais de alerta, no mnimo, exigem a ateno dos
desenvolvedores:
Reduo visvel no nmero de acesso nos arquivos de logs;
Registros freqentes de erros nos arquivos de log;
Comentrios dos usurios incluindo reclamaes ou solicitaes de ajudas para
encontrar informaes no site.
imprescindvel documentar bem todo o processo de avaliao. A
documentao do projeto pode variar de projeto projeto de acordo com tempo e
recursos disponveis para esta tarefa e o escopo da avaliao. Aqui so apresentados um
conjunto mnimo que pode ser seguido (ver anexos A, B e C).
O primeiro documento compreende a descrio dos objetivos e requisitos para a
avaliao (anexo A). Nele definem-se as responsabilidade tcnicas e administrativas
para a boa conduo dos testes. Quanto responsabilidade tcnica incluem-se itens que
descrevem os objetivos gerais da avaliao como por exemplo, verificar se pelo menos
50% dos usurios do site so capazes de utilizar uma interface para fazer compras pela
internet, ou determinar qual o percentual dos usurios satisfeitos com a mudana do
design grfico. Este tipo de definio auxiliar na escolha do mtodo mais adequado
para avaliao. Ento, deve-se especificar plataforma a ser utilizada e recursos
necessrios para execuo da interface. As responsabilidades administrativas incluem a
definio dos papis e responsabilidade das pessoas participantes (o que
especialmente importante em grande projetos de avaliao), oramento disponvel,
prazos, etc.
Durante a avaliao, cada seo de teste deve ser acompanhada de uma
descrio do mtodo utilizado, usurio, avaliador responsvel e problemas identificados
em cada sesso de teste (ver anexo B). Este documento serve de base para a gerao de
um relatrio geral que resume os problemas encontrados durante todo o processo de
avaliao (ver anexo C). Neste relatrio geral deve-se eliminar as redundncias de
problemas identificados por mais de um usurio ou por mais de um teste; o importante
descrever o problema e o impacto geral para a aplicao. Sempre que possvel deve-se
incluir tambm sugestes para a soluo dos problemas.
A documentao da avaliao no deve ser restrita aos documentos apresentados
aqui, pois cada mtodo de avaliao ir exigir documentos especficos, especialmente
quando se realiza teste com usurios. Rubin (1994) apresenta uma srie de documentos
e procedimentos para conduo de testes com usurios que devem ser verificados pelos
avaliadores que escolherem este mtodo.
No sentido de guiar a avaliao de usabilidade sugere-se, ainda, as seguintes
recomendaes:
N 1 A melhor avaliao aquela que comea com um bom projeto.
Importante lembrar que a avaliao apenas um etapa dentro do processo de concepo
da interface e no uma atividade independente como visto na seo 4. Deve ser
considerado que mesmo a melhor avaliao no substitui os cuidados para evitar
problemas de usabilidade. O custo da correo de problemas de usabilidade sempre
muito mais elevado que o custo de evit-los.
N 2 - A usabilidade do site pode ser alterada em funo de manutenes,
atualizaes de contedo do site, mudanas de tecnologia, etc. Portanto, avaliaes
peridicas devem ser realizadas. Com que freqncia? Sempre que possvel, embora
de maneira geral a freqncia seja limitada, principalmente, ao prazo e oramento
disponveis.
N 3 Documentao a palavra-chave para a boa conduo da avaliao. Crie
uma base de problemas de usabilidade identificados, solues utilizadas e quais so os
problemas mais freqentes.
N 4 Investimento na capacitao das pessoas mesmo aquelas que no esto
diretamente relacionadas avaliao. importante que toda a equipe de
desenvolvimento esteja consciente da importncia da usabilidade do site. Desta forma
ser mais fcil explicar equipe de desenvolvimento a severidade dos problemas e
discutir alternativas possveis para sua soluo.
N 5 Utilizao de mais de um mtodo de avaliao, pois um nico mtodo
no capaz de identificar todos os problemas possveis.
N 6 Considerar que a Web um ambiente dinmico, assim como seus
usurios. Planeje a avaliao cuidadosamente considerando diferentes plataformas
(software e hardware), velocidades de conexo, etc.
8 Bibliografia
Attendees and Position Papers at CHI97 Workshop Usability testing World Wide Web
Sites, (1997). Available at:
http://www.acm.org/sigchi/webhci/chi97testing/particip.htm
BAILEY, B. (1999) Heuristic Evaluations. Insights from Human Factors International.
Available at: http://www.humanfactors.com/library/may99.asp
BARTA, R.; Schranz, M.: JESSICA: an object-oriented hypermedia publishing
processor. In Special Issue on the 7
th
. Int. WWW Conference, Brisbane, Australia.
1998. pp. 239-249.
BERGHEL, H. (1996) The client's side of the World-Wide Web. Communication of the
ACM 39, 1. P. 30 40.
BERGHEL, H. (1996) The client's side of the World-Wide Web. Communication of the
ACM 39, 1. P. 30 40.
BERNERS-LEE, T. (1989) Information Management: A proposal.
http://www.w3.org/History/1989/proposal.html
BERNERS-LEE, T.; et al. (1994) The World Wide Web. Communication of the ACM,
New York, v.37, n.8, p.76-82.
BEVAN, N. (1995) Usability is quality of use. In: Anzai & Ogawa (eds) Proc. 6th
International Conference on Human Computer Interaction, July. Elsevier.
http://www.usability.serco.com/papers/usabis95.pdf
BEVAN, N. (1998) Usability Issues in web site design. In: Proceedings of UPA'98,
Washigton DC, 22-26. Also available at:
http://www.usability.serco.com/papers/usweb98.pdf
BIAS, R. (2000) Usability Triage for Web Sites. 6th Conference on Human Factors and
the Web, Austin, TX, USA.
BORGES, R.C.M. ; Winckler, M.A.A.; Basso, K. Consideraes sobre o Uso de Cores
em Interfaces WWW. In: Proc. of IHC2000.
BRAJNIK, G. (2000) Automatic web usability evaluation: what needs to be done? 6th
Conference on Human Factors and the Web, Austin, TX, USA, June 19, 2000.
BRAJNIK, G. (2000) Automatic web usability evaluation: what needs to be done? 6th
Conference on Human Factors and the Web, Austin, TX, USA, June 19, 2000.
CASTILHO, J. C.; HARTSON, H. R.; HIX, D. (1998) The User-Reported Critical
Incident Method at a Glance. Disponvel por WWW em
http://hci.ise.vt.edu/~josec/remote_eval/docs/TR_user_reported_CI_method.pdf
CERI S., P.; Fraternali, P.; Bongio, A.: Web Modeling Language (WebML): a
modeling language for designing Web sites. Proceedings of the 9th International
Conference on the WWW (WWW9), Amsterdam, May 2000.
CERI, S.; FRATERNALI, P.; BONGIO, A. Language (WebML): a modeling language
for designing Web sites. 9th World Wide Web Conference, Amsterdan, May 15-19,
2000
CONALLEM, J.: Building Web Applications with UML. Addison Wesley, 2000.
COWAN, D. D.; LUCENA, J. P.: Abstract Data Views. Na Interface Specification
Concept to Enhance Design for Reuse. IEEE Transactions on Software Engineering,
21(3), maro 1995.
CYBIS, W. et al. (1998) Uma Abordagem Ergonmica para o Desenvolvimento de
Sistemas Interativos. In: WORKSHOP EM FATORES HUMANOS EM SISTEMAS
COMPUTACIONAIS, IHC, 1998, Maring Paran. Atas [S.l.:s.n.].
DEL GALDO, E.; NIELSEN, J. (1996) International User Interfaces. John Wiley &
Sons. New York. 276 p.
DIAZ, A., Isakiwitz, T., Maiorana, V. e Gilabert, G. RMC: A Tool to Design WWW
Applications. In Proc. Fourth Int. WWW Conf. Boston, 1995. pp. 11-14.
ETGEN, M.; CANTOR, J. (1999) What does getting WET (Web Event-logging Tool)
Mean for Web Usability? Proceedings of 5th Conference on Human Factors & the
Web, June 3, 1999, Maryland USA. Also available at:
http://zing.ncsl.nist.gov/hfweb/proceedings/etgen-cantor/index.html
FOWLER, S. L.; Novack, A. J.; Stillings, M. J. The Evolution of a Manufacturing Web
Site. 9th WWW Conference, Amsterdan, May 15-19, 2000.
FRATERNALI, P. Tools and approaches for developing data-intensive Web
applications: a survey. ACM Comput. Surv. 31, 3 (Sep. 1999), Pages 227 263.
FRATERNALI, P.; Paolini, P. Model-Driven Development of Web Applications: the
Autoweb System. ACM Transactions on Office Information Systems vol. 18 (4),
2000.
FRATERNALI, P.; Paolini, P.: A Conceptual Model and a Tool Environment for
Developing More Scalable, Dynamic, and Customizable Web Applications. In
EDBT98. 1998: 421-435.
GAEDKE, M.; Graef, G.: Development and Evolution of Web-Applications using the
WebComposition Process Model. Int. Workshop on Web Engineering at the 9
th
Word-Wide Web Conference (WWW9). Amsterdam. May, 2000.
GAFFNEY, G. (2000) Card Sorting.
http://www.infodesign.com.au/usability/cardsorting.html
GARZOTTO, F.; Paolini, P.; Bolchini, D.; Valenti, S.: Modelling by patterns of Web
Applications, Proc. IntI Workshop on the World Wide Web and Conceptual
Modeling. Springer Verlag, Berlin, 1999.
GARZOTTO, F.; Paolini, P.; Schwabe, D.: HDM A Model-Based Approach to
Hypertext Application Design. 1993. TOIS.
GELLERSEN, H-W; Gaedke, M. Object-oriented Web Application Development.
IEEE Internet Computing, Vol.3, No.1, February 1999.
GELL, N.; SCHWABE, D.; VILAIN, P. Modeling Interactions and Navigation in
Web Applications. Procedings of WWW and Conceptual Modeling 2000 Workshop;
Salt Lake City, USA. 2000.
HARTSON, H. R.; et al (1996). Remote Evaluation: The Network as an Extension of
the Usability Laboratory. Proceedings of CHI'96, April 13 - 18, 1996, Vancouver
Canada, 228-235. http://miso.cs.vt.edu/~usab/remote/docs/chi96_remoteusab.html
HOM, J. The Usability Methods Toolbox:
http://www.best.com/~jthom/usability/usable.htm
ISAKOWITZ, T.; Stohr, E.; Balasubramaniam, P.: RMM: A methodology for
structured hypermedia design. Comm of the ACM, outubro 1995.
ISO Draft International Standard (DIS) 9241-11 (1999), Ergonomic Requirements for
office work with visual display terminals, Part 11: Guidance on Usability,
International Standards Organization, Geneva.
LYNCH, P. J; HORTON, S. (1999) Web Style Guide : Basic Design Principles for
Creating Web Sites. Yale Univ Press. ISBN: 0300076754. 164 p.
MATIAS, M. (1995) Checklist: Uma ferramenta de suporte avaliao ergonmica de
interfaces. Florianpolis: PPGEP-UFSC. Dissertao de Mestrado. Disponvel por
WWW em: http://www.eps.ufsc.br/disserta/matias/
MAYHEW, D. (1992). Principles and Guidelines in Software User Interface Design,
Prentice Hall, Englewood Cliffs.
MURUGESAN, S.; Deshpande,Y.; Hansen, S.; Ginige, A.: Web Engineering: A New
Discipline for Development of Web-based Systems. Proc. First IntI Conf. Software
Engineering (ICSE), Workshop on Web Engeering, Univ. of Western Sydney,
Austrlia, 1999. Disponvel em http://aeims.uws.edu.au/WebEhome/ICSE99-WebE-
Proc/San.doc.
NANARD, J., Nanard, M.: Hypertext Design Environments and the Hypertext Design
Process, CACM 38(8). Augosto, 1995. Pg. 49-56.
NIELSEN, J. (1993) Usability Engineering. Boston - USA: Academic Press, 362 p.
NIELSEN, J. (1997) The Use and Misuse of Focus Groups.
http://www.useit.com/papers/focusgroups.html
NIELSEN, J. (1999) The Top Ten New Mistakes of Web Design.
http://www.useit.com/alertbox/990530.html
NIELSEN, J.; SANO, D. (1995) Sun Web: User Interface Design for Sun
Microsystem's Internal Web. Computer Networks and ISDN Systems (Selected
papers from the 2th WWW Conference1994). Amsterdan, v.28, n.1&2. 1995, p.179-
188. Also available at: http://www.useit.com/papers/sunweb/
ROSSI, G.; Schwabe, D.: OOHDM Object Oriented Hypermedia Design Method.
1996. Departamento de Informtica - Tese PUC-Rio. Disponvel em http://www-
lifia.info.unlp.edu.ar/~fer/oohdm/
ROSSI, G.; Schwabe, D.; Lyardet, F..: Improving Web Information Systems with
Navigational Patterns. Proc. WWW8, Elsevier, 1999.
RUBIN, J. Handbook of Usability Testing: How to Plan, Design and Conduct Effective
Tests. John Wiley & Sons. New York. 1994. 330 p.
SANO, D. (1996) Large-Scale Web Sites. John Wiley & Sons, New York, 288 p.
SCAPIN, D. et al. Transfering Knowledge of User Interfaces Guidelines to the Web. In.
Proc. of Tools for Working with Guidelines,. London: Springer; 2001; pp. 293-304.
SCHWABE, D. et al. Hypertext Development Using a Model-based Approach.
Software-Practice and Experience, New York, v.22, n.11, p.937-962, Nov. 1992.
SCHWABE, D. et al. Engineering Web Applications for Reuse, IEEE Multimedia,
Spring 2001, pp. 2-12.
SEGOR, C.; Gaedke, M.: Crossing the Gap - From Design to Implementation in Web-
Application Development. In Proceedings of Information Resources Management
Association International Conference, Anchorage, Alaska, USA. 2000.
SIOCHI, A. C.; EHRICH, R. W. (1991) 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.
SULLIVAN, T. (1997) Reading Reader Reaction: A proposal for Inferential Analysis
on Web Server Log Files. Disponvel por WWW em: http://www.uswest.com/web-
conference/proceedings/rrr.html
Useit.com: Jakob Nielsen's Website: http://www.useit.com/alertbox/
VANDERDONCKT, J (1994). Guide ergonomique des interfaces homme-machine,
Presses Universitaires de Namur, Namur.
Web Usability Questionnaire http://www.wammi.com/
WINCKLER, M. et al. (1999). Remote Usability Testing: a Case Study. (Short paper)
In: Proceedings OZCHI99. 28-30 November 1999, Wagga-Wagga, Australia.
WINCKLER, M.; Farenc, C.; Palanque, P.; Bastide, R. Designing Navigation for Web
Interfaces. In Proceedings: IHM-HCI2001, Lille, Frana, 10-14 Sep. 2001 (Short
paper).
WINCKLER, M.A.; FARENC, C.; PALANQUE, P.; PIMENTA,M.S.; Avaliao da
Navegao de Interfaces Web a partirde Modelos In: Proc. of IV Workshop sobre
Fatores Humanos em Sistemas Computacionais (IHC 2001), Florianpolis, Outubro
de 2001.
WINCKLER, M.A.; PIMENTA,M.S; PALANQUE, P.; FARENC, C.; Usability
Evaluation Methods: What is still missing for the WWW? In: Proc. of 9th
International Conference on Human-Computer Interaction, HCII2001, New Orleans
USA , August 5-10, 2001..
WOOLRYCH, A.; COCKTON, G. (2001) Why and when five users arent enough. In
proceedings... IHM-HCI 2001 (volume II, short paper). Lille, Frana.
World Wide Web Consortium: http://www.w3.org/
ANEXO A FORMULRIO DE DEFINIO DA
AVALIAO DE USABILIDADE
Objetivo: definir o escopo da avaliao. Inclui a descrio de mtodos a serem utilizados, pessoas
responsveis pela avaliao, objetivos a serem alcanados, produto a ser avaliado, etc. Este formulrio
deve ser preenchido logo no incio do processo de avaliao pelo responsvel do projeto.
1. Identificao Geral da avaliao
1.1 Cdigo da avaliao : ___________________________________________________________________
1.2 Produto/ Web site a ser avaliado: __________________________________________________________
1.3 Objetivos da avaliao: __________________________________________________________________
1.4 Pblico-alvo considerado: ________________________________________________________________
1.5 Coordenador geral do processo de avaliao:__________________________________________________
1.6 Cliente / responsvel pela avaliao: ________________________________________________________
2. Procedimentos
2.1 Mtodo(s) de avaliao a serem utilizado(s): _________________________________________________
2.2 Procedimentos gerais para realizao: _______________________________________________________
3. Recursos Necessrios
3.1 Prazos para realizao: __________________________________________________________________
3.2 Nmero de avaliadores participantes: _______________________________________________________
3.3 Nmero de usurios participantes: __________________________________________________________
3.4 Equipamentos:
Computador
PC
Macintosh
Estao Sun
Outro (especificar):
Sistema Operacional
Windows NT
Windows Millenium
Linux
OS/2
OS Mac
Outro (especificar):
Conexo internet
Modem: ( ) 14 kb/s ( ) 28 kb/s ( ) 56 kb/s
128 kb/s
T1
T3/ Cable
Software, browser, etc.
Nestcape (especificar verso):
Internet Explorer (especificar verso):
Plug-in Java
Plug-in Real udio
Plug-in Cosmo Player
Plug-in Adobe Acrobat Reader (PDF)
Plug-in Shockwave
Plug-in QuickTime
Plug-in LiveAudio
Plug-in Live3D
Outro (especificar):
Laboratrio de usabilidade
Sala com espelhos falsos
Cmera e vdeo
Software para coleta de interaes
Outros requisitos (especificar):
Ambiente normal de trabalho do usurios
Outros recursos, favor especificar:
4. Oramento
(Descrio detalhada do oramento para realizar da avaliao... )
ANEXO B - FORMULRIO PARA DESCRIO DE
PROBLEMAS
Objetivo: auxiliar na descrio de problemas de usabilidade identificados durante a realizao de
avaliaes de usabilidade. Cada seo de teste deve ser identificada por este formulrio. O conjunto de
problemas identificados aqui serve como base para a geral do relatrio geral de usabilidade (ver anexo
A.).
1. Identificao da avaliao
1.1 Cdigo da avaliao: _________________________________________________________________
1.2 Cdigo da seo de avaliao: __________________________________________________________
1.3 Mtodo de avaliao utilizado: __________________________________________________________
1.4 Data de realizao: __/__/__
1.5 Tempo total de avaliao: __horas __ minutos. Incio: __h__m Fim: __h __m
1.6 Avaliador
8
: _________________________________________________________________________
1.7 Usurio
9
: ___________________________________________________________________________
2. Tabela de Problemas Identificados
Cod.
10
Tarefa
11
Tempo
12
Descrio do problema
13
URL + obj.
14
Cenrio de uso
15
Impacto
16
1
2
3
4
5
6
7
8
9
10
11
12
...

8
Incluir o nome do avaliador que realiza as observaes ou anlise dos dados. No caso de mtodos de
inspeo como, Avaliao Heurstica, incluir apenas o nome do avaliador.
9
Observar a utilizao de cdigos para preservar a identidade dos usurios.
10
Cod. um nmero sequencial que idenfifica o problema.
11
Tarefa identificador ou a descrio da tarefa afetada pelo problema.
12
Tempo o tempo (min:seg) utilizado para realizao da tarefa ou o tempo investido pelo usurio antes
de desistir da tarefa.
13
Descrio do problema a descrio textual do problema.
14
URL + obj. a URL da pgina onde ocorreu o problema mais objetos considerados (ex. texto, link,
imagem, etc.).
15
Cenrio de uso a sequencia de aes realizadas antes, durante e aps a ocorrncia do problema.
16
Impacto o impacto atribudo ao problema (grave/ importante/ menor).
ANEXO C FORMULRIO RESUMO DE PROBLEMAS
IDENTIFICADOS
Objetivo: o objetivo deste formulrio criar uma tabela nica com todos os problemas
encontrados durante a avaliao de usabilidade do site, incluindo o resultado das
sees de avaliao. Neste formulrios os problemas identificados so descritos
independentemente do(s) mtodo(s) de avaliao utilizados.
1. Identificao da avaliao
1.1 Cdigo da avaliao: _________________________________________________________________
1.2 Responsvel pelo compilao dos resultados : ______________________________________________
1.3 Data: __/__/__
Cod.
Descrio do problema
Sesses de
ocorrncia
17
Impacto Freqncia Severidade
Solues
possveis
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
29
30
31
...

17
Cdigo de todas as sees onde o problema foi identificado.