2002 Winckler Pimenta Eri 2002 Cap3

3
Avaliao de Usabilidade de Sites Web

Marco Winckler1 Marcelo Soares Pimenta2 Resumo: Desde a inveno da Web, a tecnologia para construo de sites 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, que confrontam-se muito frequentemente com problemas de usabilidade. 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 captulo 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.
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 Instituto de Informtica - UFRGS Av. Bento Gonalves, 9500 - Caixa Postal: 15064 CEP 91501-970 - Porto Alegre - RS -Brasil
3.1 Introduo
A World Wide Web (WWW) ou simplesmente Web, foi criada por Tim Berners-Lee em 1989, nos laboratrios do 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 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 captulo 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 3.2), so apresentadas as caractersticas do ambiente Web (seo 3.3) assim como uma viso panormica sobre concepo de interfaces Web (seo 3.4) , de modo a permitir uma compreenso melhor dos objetivos e procedimentos envolvidos na avaliao (seo 3.5) e as ferramentas existentes (seo 3.6). Finalmente, a seo 3.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.
3.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.
3.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 3.1 apresenta um exemplo negativo (contra-exemplo) de interface que utiliza inadequadamente muitas cores, frames e textos em destaque. 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 Figura 3.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.
Figura 3.1: Exemplo negativo disponvel em: http://www.fooz.com/eric/bad/
a) Ausncia de informao
b) Inadequao ao contexto
Figura 3.2: Exemplos de problemas de usabilidade encontrados em http://www.englishpractice.com/
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 3.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, noconcluda): 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.
3.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 seguir3: 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.
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/
3.2.3. Ciclo de vida do projeto com usabilidade

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.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.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 contornlo 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.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.3.1. A arquitetura cliente-servidor

O primeiro esboo da Web foi publicado no artigo Information Management: A Proposal (Berners-Lee, 1989; 1994)4 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 3.4.
Figura 3.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 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
4
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.
11
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.5) 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. Podese 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.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, 2000). 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 computador cliente, utilizando-se da infraestrutura da internet, atravs do protocolo HTTP (Hyper Text Transfer Protocol). A figura 3.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. 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
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).
5
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 3.6.
Internet
Cliente Request
Browser
Servidor
Web Server Document
Sistema de arquivos local
Figura 3.5: Arquitetura bsica de Site Web
http Browse
Web Server
result references Scripted Page
Database
Page Filter
processes
Figura 3.6: Arquitetura de um site web dinmico
3.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 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.
13
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.ht m 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/
15
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.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. 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 3.1 resume algumas caractersticas dos browsers mais utilizados atualmente na plataforma MS Windows6. Observe as diferenas entre o suporte a tecnologias e recursos de formatao de texto.
6
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.
Javascript
Tamanho de texto
Plug-ins
Cor em Tabelas
X X X X X X X X X X X X X X X
DHTML
tabelas
frames
Cor de texto
Gif89
Java
Browser
Explorer 6.0 Explorer 5.5 Explorer 5.0 Explorer 4.0 Explorer 3.0 Explorer 2.0 Netscape 6.1 Netscape 6.0 Navigator 4.7 Navigator 4.5 Navigator 3.0 Navigator 2.0 Navigator 1.1 Mosaic 3.0 Mosaic 1.0 Mozilla AOL browser 5.0 AOL browser 4.0 Opera 5.11 Opera 4.02 Lynx
X X X X X X X X X X X
X X X X X X X X X X X X
X X X X X X X X X X X X X X X X X X X X
X X X X X X X X X X X X X X X X X X X
X X X X X X X X X X X X
X X X X X X X X X X S
X X X X X X X X X
X X X X
X X X X
X X
X X X X X X
S S
X X X X X
X X X X
X X
X X
Legenda:
X Suporte
Suporte parcial
Nenhum Suporte
Tabela 3.1: Diferenas entre web browsers para plataforma MS Windows
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! 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.
XML
X X S X X X X X
CSS
17
3.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).
3.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-Computador7 (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.
3.4.1. Fundamentos
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
Traduo adotada atualmente pela comunidade brasileira para a expresso inglesa Human-Computer Interaction (HCI).
7
19
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. 3.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, 1999), 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 (Cowan, 1995), croquis , maquetes, prottipos ou quaisquer outros tipicamente usados para representar o componente de apresentao de interfaces.
3.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, 2001) ver figura 3.7 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 3.7: 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 3.7). 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
21
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. 3.7 - 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.
3.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 3.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 associadas.
ferramentas implementadas que podem ser a ele
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. 3.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
23
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;
25
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/enus/dnsiteplan/html/improvingsiteusa.asp Research-based Web Design and Usability Guidelines , http://usability.gov/guidelines/
3.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 3.2 e 3.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 HDM / HDM-lite
Passos do Processo 1. Authoring-in-thelarge 2. Authoring-in-thesmall

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 1. Projeto conceitual 2. Projeto navegacional 3. Projeto de interface de usurio 4. Implementao 1. Modelagem: a.Diagrama de classes b.Use-cases (cenrios) 2. Gerao/Parsing 3. Compilao 4. Visualizao RUP (Rational Unified Process) 1. Requisitos 2. Anlise 3. Projeto 4. Implementao 5. Testes 6. Avaliao 1. Modelo estrutural 2. Modelo de composio 3. Modelo de apresentao 4. Modelo de personalizao
Modelos e Notaes EntidadeRelacionamento (E-R) E-R + RMDM (Relationship Management Data Model)
Ferramentas de suporte Autoweb System (HDM-lite)
Referncias Bibliogrficas (Garzotto et al, 1993) (Gaedke et al, 2000) (Fraternali, 1998) (Isakowitz et al, 1995) (Diaz et al, 1995)
RMM
RMCase
OOHDM
UML/OMT (1) Prpria (2) Abstract Data Views (3) UML/XML
OOHDM-Web
(Schwabe et al, 1992) (Rossi et al, 1996) (Rossi et al, 1999) (Segor et al, 2000) (Barta et al, 1998)
JESSICA
JESSICA System
WAE
UML c/ esteretipos prprios
Rational Rose
(Conallem, 2000)
WebML
Prpria/ XML
WebML Tool Suite
(Ceri et al, 2000)
Tabela 3.2: Resumo de abordagens para concepo de aplicaes Web
Na tabela 3.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.
27
A tabela 3.3 identifica quais passos do ciclo de vida de desenvolvimento de aplicaes Web so cobertos por cada abordagem.
Engenharia de Requisitos
Espec. do Site
Design do Site
Implem. Conceitual Naveg. Apresent. Avaliao
HDM / HDMlite RMM OOHDM JESSICA WAE WebML Tabela 3.3: Cobertura do ciclo de vida
3.4.3.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 3.4.2). 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 3.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.
3.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.
3.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
29
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.
3.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 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.
31
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 3.4 so apresentados alguns dos problemas encontrados durante a avaliao do CD-ROM Literatura Gacha (veja figura 3.8), assim como comentrios que ilustram como os avaliadores utilizaram as heursticas para identificar problemas.
Descrio do Problema
Na pgina rico Verssimo h a opo de visualizar um vdeo sobre o autor, que disponvel pelo cone de uma cmera filmadora (figura autor). Ao iniciar o vdeo no h como interromp-lo. Na obra O tempo e o Vento o boto [crtica] (base da figura Obra) disponvel mas, uma vez selecionado, no mostra o texto correspondente crtica do livro, como esperado. No existem opes de atalho.
Severidade [1 3]
Heurstica violada e Comentrios

Fornecer sadas claramente marcadas e prevenir erros: os avaliadores consideraram o problema muito grave (5) porque ele obriga o usurio a ver todo o vdeo mesmo que a sua ativao tenha sido ocasionada por um click acidental. Esta uma situao de erro que poderia ser minimizada com a opo para interromper o vdeo. Observa-se aqui um problema que foi classificado por mais de uma heurstica, o que aceitvel na identificao de problemas complexos como este. Fornecer Mensagens de Retorno Adequada: Sabendo que mensagens adequadas so necessrias para a eficiente utilizao da interface, o avaliador inspeciona a interface em busca de todas as situaes onde boas mensagens de retorno no so fornecidas. Assim, o avaliador identificou este problema e atribuiu severidade moderada (3) supondo que os usurios ficariam desorientado sobre a funo de crtica. Fornecer atalhos: o avaliador usou esta heurstica para procurar situaes que necessitassem de atalhos. Contudo, foi considerado que atalhos no so necessrios nesta aplicao e por isto uma severidade baixa (1) foi atribuda. Esta heurstica lembra o avaliador de considerar as situaes onde atalhos so necessrios.
Tabela 3.4: Exemplos de problemas de usabilidade
Autor - rico Verssimo.
Obra O Tempo e o Vento.
Figura 3.8: 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.
3.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 3.9 apresenta um ensaio de interao no laboratrio de usabilidade da UFSC, o LabiUtil8. 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
Imagem reproduzida com a permisso do LabiUtil (Universidade Federal de Santa Catarina UFSC, Florianpolis; http://www.labiutil.inf.ufsc.br/ ).
33
usurios reais de interfaces Web. Ainda que usurios reais possam ser localizados, a distribuio geogrfica pode inviabilizar a sua participao.
Figura 3.9: Ensaio de Interao em um laboratrio de usabilidade
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 prdefinidas (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.
3.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 3.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.5 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
35
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.
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.5: Checklist para avaliao de usabilidade para um sistema de vendas online (fonte: Information & Design http://www.infodesign.com.au)
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.
3.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 3.5.6).
Pode-se ainda utilizar questionrios para estruturar avaliaes com usurio (ver seo 3.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.
3.5.6. Relatos de incidentes crticos por usurios
37
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.
3.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.
3.6. Ferramentas para avaliao automtica

Nesta seo introduzida a idia de avaliao automtica e so descritas algumas ferramentas existentes para auxiliar esta tarefa.
3.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
39
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.
3.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 3.10 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 3.10: Problema de apresentao devido ao uso de marcadores nopadronizados (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 3.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
41
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.
3.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 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/
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/ Dr. Watson um servio gratuito oferecido pela Addy & Associates. 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/ 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 preinscrio 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 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.
43
PageScreamer - http://www.crunchy.com/tools/PageScreamer.html 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/ Page Valet combina verificao formal e validao de acessibilidade baseadas nas recomendaes WAI. W3C CSS validator - http://jigsaw.w3.org/css-validator/ 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. Para uma lista completa de ferramentas disponveis verifique o endereo: http://www.w3.org/WAI/ER/existingtools.html.
3.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
45
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. 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.
3.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 7th. 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: http://www.w3.org/History/1989/proposal.html A proposal.
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_me thod.pdf CERI S., P.; Fraternali, P.; Bongio, A.: Web Modeling Language (WebML): a modeling language for designing Web sites. Proceedings of the 9th
47
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. 1114. 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 9th Word-Wide Web Conference (WWW9). Amsterdam. May, 2000. GAFFNEY, G. (2000) Card http://www.infodesign.com.au/usability/cardsorting.html Sorting.
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 http://www.best.com/~jthom/usability/usable.htm Toolbox:
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, NIELSEN, J. (1997) The Use and Misuse of http://www.useit.com/papers/focusgroups.html J. (1999) The Top Ten New Mistakes http://www.useit.com/alertbox/990530.html of Focus Web Groups. Design.
49
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 WebApplication 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/
51
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
9
Fim: __h __m
1.6 Avaliador : ____________________________________________________________ 1.7 Usurio10: _____________________________________________________________ 2. Tabela de problemas identificados

Cod.11 1 2 3 4 5 6 7 8 9 10 11 12 ... Tarefa12 Tempo13 Descrio do problema14 URL + obj.15 Cenrio de uso16 Impacto17
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. 10 Observar a utilizao de cdigos para preservar a identidade dos usurios. 11 Cod. um nmero sequencial que idenfifica o problema. 12 Tarefa identificador ou a descrio da tarefa afetada pelo problema. 13 Tempo o tempo (min:seg) utilizado para realizao da tarefa ou o tempo investido pelo usurio antes de desistir da tarefa. 14 Descrio do problema a descrio textual do problema. 15 URL + obj. a URL da pgina onde ocorreu o problema mais objetos considerados (ex. texto, link, imagem, etc.). 16 Cenrio de uso a sequencia de aes realizadas antes, durante e aps a ocorrncia do problema. 17 Impacto o impacto atribudo ao problema (grave/ importante/ menor).
53
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 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 ... Sesses de ocorrncia18 Impacto Freqncia Severidade Solues possveis
18
Cdigo de todas as sees onde o problema foi identificado.

2002 Winckler Pimenta Eri 2002 Cap3

Diunggah oleh

Informasi Dokumen

Deskripsi Asli:

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

2002 Winckler Pimenta Eri 2002 Cap3

Diunggah oleh

Hak Cipta:

Format Tersedia

3

Avaliao de Usabilidade de Sites Web

Avaliao de Usabilidade de Sites Web

3.2.1. O que usabilidade?

Avaliao de Usabilidade de Sites Web

Figura 3.1: Exemplo negativo disponvel em: http://www.fooz.com/eric/bad/

Figura 3.2: Exemplos de problemas de usabilidade encontrados em http://www.englishpractice.com/

Avaliao de Usabilidade de Sites Web

3.2.3. Ciclo de vida do projeto com usabilidade

Figura 3.3: Ciclo de vida do projeto com usabilidade

Avaliao de Usabilidade de Sites Web

3.3. O Ambiente Web

3.3.1. A arquitetura cliente-servidor

Figura 3.4: Modelo cliente/servidor da WWW

Avaliao de Usabilidade de Sites Web

3.3.2. Aplicaes Web

Web Server Document

Sistema de arquivos local

Figura 3.5: Arquitetura bsica de Site Web

result references Scripted Page

Figura 3.6: Arquitetura de um site web dinmico

3.3.3. Diversidade de tecnologias para interfaces Web

Avaliao de Usabilidade de Sites Web

Avaliao de Usabilidade de Sites Web

3.3.4. Diferenas entre browsers

Tabela 3.1: Diferenas entre web browsers para plataforma MS Windows

Avaliao de Usabilidade de Sites Web

3.3.5. Diferenas entre interfaces Web e Wimp

3.4. Concepo de interfaces Web

Avaliao de Usabilidade de Sites Web

3.4.2. Ciclo de concepo de interfaces Web

Figura 3.7: Ciclo de desenvolvimento de um website

Avaliao de Usabilidade de Sites Web

3.4.3. Concepo de sites Web

c) ser independente de associadas.

ferramentas implementadas que podem ser a ele

Avaliao de Usabilidade de Sites Web

Avaliao de Usabilidade de Sites Web

Abordagens HDM / HDM-lite

Passos do Processo 1. Authoring-in-thelarge 2. Authoring-in-thesmall

Ferramentas de suporte Autoweb System (HDM-lite)

UML/OMT (1) Prpria (2) Abstract Data Views (3) UML/XML

UML c/ esteretipos prprios

WebML Tool Suite

(Ceri et al, 2000)

Tabela 3.2: Resumo de abordagens para concepo de aplicaes Web

Avaliao de Usabilidade de Sites Web

3.5. Mtodos de avaliao de usabilidade

3.5.1. Diversidade de mtodos de avaliao

Avaliao de Usabilidade de Sites Web

3.5.2. Avaliao heurstica

Avaliao de Usabilidade de Sites Web

Heurstica violada e Comentrios

Tabela 3.4: Exemplos de problemas de usabilidade

Autor - rico Verssimo.

Obra O Tempo e o Vento.

Figura 3.8: CD-ROM Literatura Gacha

3.5.3. Ensaios de interao

Avaliao de Usabilidade de Sites Web

Figura 3.9: Ensaio de Interao em um laboratrio de usabilidade

3.5.4. Inspeo de recomendaes ergonmicas (guidelines e checklist)

Avaliao de Usabilidade de Sites Web

3.5.6. Relatos de incidentes crticos por usurios

Fim: h m

1.6 Avaliador : 1.7 Usurio10: _ 2. Tabela de problemas identificados