Durabilidade das Diretrizes de Usabilidade de

Transcrição

UNIVERSIDADE PRESBITERIANA MACKENZIE
FACULDADE DE COMPUTAÇÃO E INFORMÁTICA
BACHARELADO EM CIÊNCIA DA COMPUTAÇÃO
Trabalho de Graduação Interdisciplinar
Vagner Figuerêdo de Santana
Durabilidade das Diretrizes de Usabilidade de Interfaces HomemComputador
São Paulo
2006
VAGNER FIGUERÊDO DE SANTANA
DURABILIDADE DAS DIRETRIZES DE USABILIDADE DE INTERFACES HOMEMCOMPUTADOR
Trabalho de conclusão de Curso de Ciência da Computação da Universidade Presbiteriana Mackenzie, apresentado como requisito parcial para a obtenção do Grau de Bacharel em Ciência da Computação.
ORIENTADORA: Profa. Dra. Pollyana Notargiacomo Mustaro
São Paulo
2006
S232d Santana, Vagner Figuerêdo de.
Durabilidade das diretrizes de usabilidade de interfaces homem
computador / Vagner Figuerêdo de Santana – 2006.
103 p. : il. ; 30 cm.
Trabalho de Conclusão de Curso (Bacharelado em Ciência da Computação) – Faculdade de Computação e Informática, Universidade Presbiteriana Mackenzie, São Paulo, 2006.
Bibliografia: p. 6165.
1. Usabilidade. 2. Diretrizes. 3. Interface humanocomputador. I. Título.
CDD 004.019
UNIVERSIDADE PRESBITERIANA MACKENZIE
FACULDADE DE COMPUTAÇÃO E INFORMÁTICA
CIÊNCIA DA COMPUTAÇÃO
Termo de Julgamento de Defesa de Trabalho de Graduação Interdisciplinar
Aos .........................................................de 2006, às ................ horas, no prédio ........, sala ......... da Universidade Presbiteriana Mackenzie, presente a Comissão Julgadora, integrada pelos senhores Professores, abaixo discriminados, iniciouse a apresentação do Trabalho de Graduação Interdisciplinar do Grupo de Trabalho formado pelos alunos abaixo e concluída a argüição, procedeuse ao julgamento na forma regulamentar, tendo a Comissão Julgadora atribuído as seguintes notas aos Candidatos
Título do Trabalho: "Durabilidade das Diretrizes de Usabilidade de Interfaces Homem
Computador"
ALUNOS
Número Matrícula
1. Vagner Figuerêdo de Santana
40217167
Nota Orientador
Média Final
do Aluno
2.
3.
4.
COMISSÃO JULGADORA
Orientador
Titular 1
Titular 2
Suplente
Média Obtida pelo Grupo de Trabalho
NOTA
Para constar, é lavrado o presente termo que vai assinado pela Comissão Julgadora e pelo Coordenador de TGI. São Paulo,
Comissão Julgadora
____________________________________________________________
Prof. ____________________________________________________________
Prof. ____________________________________________________________
Prof. Coordenador de TGI
____________________________________________________________
Prof. Dr. Roberto Cássio de Araujo
À minha noiva, pelo companheirismo e grande apoio; à minha mãe, por compartilhar comigo a crença de que atingiria meus objetivos.
AGRADECIMENTOS
À Profa. Dra. Pollyana Notargiacomo Mustaro, por ter sido uma exímia orientadora, por todos os conselhos e respostas, que me conduziram sempre para o caminho que deveria seguir.
Ao Antonio Graeff, por tudo que me ensinou sobre usabilidade e por ter despertado meu interesse sobre o assunto.
À Universidade Presbiteriana Mackenzie pelo incentivo à pesquisa.
Ao Prof. Dr. Nizam Omar, pela ilustre atenção que direcionou a este trabalho.
Aos professores Dr. Luciano Silva e Dr. Ismar Frango, pela sempre tão explícita vontade de ensinar e pelas riquíssimas aulas ministradas no curso de Ciência da Computação que tanto contribuíram para minha formação e para a elaboração deste trabalho.
Aos amigos Daniel José Pinto, Viviane Shishido, Rodrigo Portela, Eddie Sant’Ana e, em especial, Gabriela Doratioto e Hamilton de Matos, pelo compartilhamento de conhecimentos ao longo de todo o curso.
"Diretrizes de usabilidade informam a você como as pessoas tipicamente se comportam com designs parecidos."
(Jakob Nielsen)
RESUMO
Esta pesquisa visa analisar a percentagem de validade das diretrizes de interface de software homemmáquina de Sidney L. Smith e Jane N. Mosier. As diretrizes foram elaboradas em 1986 em um trabalho realizado na Divisão de Sistemas Eletrônicos da Força Aérea Norte
americana. Nesse projeto eles buscavam padronizar os programas produzidos na base militar de Hanscom, Massachusetts, EUA. Para isso, a investigação pautouse na categorização das diretrizes em relação à sua relevância na atualidade. Como resultado foi obtido um conjunto de diretrizes de usabilidade que possibilitou concluir que um número elevado (97%) dessas continua válida mesmo após cerca de 20 anos. Uma vez que a análise se deu pela relação de cada uma das normas com textos e artigos de Jakob Nielsen, voltados em sua grande maioria à usabilidade de web sites, o resultado convergiu de certa forma à usabilidade de páginas web. Esta constatação permitiu demonstrar que a base teórica elaborada há anos é relevante para o projeto de interfaces humanocomputador, sobretudo em relação à usabilidade e às tendências de sua aplicação em páginas web. Palavraschave: usabilidade, diretrizes, interface humanocomputador
ABSTRACT
This research aims to provide the percentage of valid humancomputer interface software guidelines described by Sidney L. Smith and Jane N. Mosier. Such guidelines were compiled in 1986 in a work produced at the Electronic Systems Division of the United States Air Force. In that project they searched for a way to standardize the software created at the military base of Hanscom, Massachusetts, USA. The current investigation focused on categorizing the guidelines and their actual relevance. The result of this research was a group of usability guidelines which leads to the conclusion that most (97%) of the norms are still valid even after 20 years. Since the analysis in this research was based on the relationship between each one of the guidelines and articles by Jakob Nielsen, which are, in most part, based on web sites usability, the result converged, in some way, to web pages usability. This fact made it possible to show that such theoretical bases built years ago are still relevant to projects of humancomputer interfaces, especially in usability and its trends concerning its use in web pages.
Keywords: usability, guidelines, humancomputer interface
SUMÁRIO
CAP. I INTRODUÇÃO...........................................................................................13
CAP. II – DIRETRIZES E A USABILIDADE...........................................................15
2.1. Interação HumanoComputador (IHC)..................................................................................................15
2.2. Usabilidade................................................................................................................................................15
2.3. Diretrizes de usabilidade..........................................................................................................................16
CAP. III – RECURSOS TÉCNICOS UTILIZADOS.................................................18
3.1. DocBook.....................................................................................................................................................18
3.2. Xalan..........................................................................................................................................................20
3.3. Disponibilização dos elementos da pesquisa...........................................................................................21
CAP. IV – METODOLOGIA.....................................................................................23
4.1. Modelagem................................................................................................................................................23
4.1.1. Padrão de Projeto Bridge.....................................................................................................................23
4.1.2. Padrão de Projeto Interpreter...............................................................................................................24
4.1.3 Padrões de Projeto Strategy e Visitor em conjunto..............................................................................26
4.1.4. Padrão de Projeto Façade....................................................................................................................26
4.1.5. Padrão de Projeto Proxy......................................................................................................................27
4.1.6. Padrão de Projeto Factory Method......................................................................................................28
4.1.7. O Padrão de Projeto Singleton.............................................................................................................29
4.1.8. Padrão de Projeto Composite..............................................................................................................30
4.1.9. União dos Padrões de Projeto GoF utilizados.....................................................................................31
4.2. Estruturação para a análise das diretrizes.............................................................................................33
4.3. Níveis de classificação para as diretrizes................................................................................................35
CAP. V RESULTADOS.........................................................................................36
5.1. Análise das diretrizes................................................................................................................................36
5.1.1. Diretrizes analisadas por Jakob Nielsen..............................................................................................37
5.1.2. Consistência.........................................................................................................................................39
5.1.3. Tempo de resposta...............................................................................................................................41
5.1.4. Retorno................................................................................................................................................42
5.1.5. Legibilidade.........................................................................................................................................44
5.1.6. Processamento sob comando explícito do usuário..............................................................................47
5.1.7. Compatibilidade com o mundo real, simplicidade, objetividade e logicidade....................................48
5.1.8. Navegação............................................................................................................................................50
5.1.9. Interfaces auditivas..............................................................................................................................51
5.1.10. Gerenciamento de erro.......................................................................................................................52
5.1.11. Flexibilidade.......................................................................................................................................54
5.1.12. Listas..................................................................................................................................................55
5.1.13. Sobrecarga da memória do usuário....................................................................................................56
5.1.14. Ícones.................................................................................................................................................56
5.1.15. Poluição visual...................................................................................................................................57
5.1.16. Encriptação........................................................................................................................................57
5.1.17. Acessibilidade e adaptação ao usuário...............................................................................................57
5.1.18. Ajuda..................................................................................................................................................60
5.1.19. Gráficos e animações.........................................................................................................................61
5.2. Resultados das classificações...................................................................................................................62
CAP. VI – CONCLUSÕES E TRABALHOS FUTUROS.........................................64
CAP. VII REFERÊNCIAS, ANEXOS....................................................................65
7.1. Referências Bibliográficas........................................................................................................................65
7.2. Bibliografia Complementar.....................................................................................................................68
ANEXO I. DIRETRIZES VÁLIDAS E PERTINENTES ..........................................70
Diretrizes analisadas por Jakob Nielsen........................................................................................................70
Consistência......................................................................................................................................................75
Tempo de Resposta..........................................................................................................................................80
Retorno.............................................................................................................................................................81
Legibilidade......................................................................................................................................................85
Processamento sob controle explícito do usuário..........................................................................................88
Compatibilidade com o mundo real, simplicidade, objetividade e logicidade...........................................88
Navegação.........................................................................................................................................................97
Interfaces Auditivas.........................................................................................................................................99
Gerenciamento de Erro...................................................................................................................................99
Flexibilidade...................................................................................................................................................103
Listas...............................................................................................................................................................104
Sobrecarga da memória do usuário.............................................................................................................105
Ícones...............................................................................................................................................................106
Poluição visual................................................................................................................................................106
Encriptação....................................................................................................................................................107
Acessibilidade e adaptação ao usuário.........................................................................................................107
Ajuda...............................................................................................................................................................109
Gráficos e Animações ...................................................................................................................................111
13 C A P . I I N T R O D U Ç Ã O
Cap. I Introdução
No presente momento, segundo pesquisas realizadas pela empresas Netcraft (2005) e Internet World Stats (2005) em dezembro de 2005 foram registrados 77,5 milhões de sites e mais de 1,018 bilhões de usuários. Este crescimento requer o desenvolvimento de propostas eficazes para apresentar soluções de interface que respondam às necessidades e expectativas dos usuários, potencializando a experiência destes. Isso transcende o projeto gráfico e engloba a concepção da aplicação como um todo, ou seja, envolve a estruturação, as tarefas e os elementos que possibilitam o ajuste e personalização do sistema às necessidades individuais. Para a elaboração deste tipo de proposta é necessário considerar princípios de interação humanocomputador que colaborem para a usabilidade da interface.
Neste contexto de contínuas mudanças, tornase relevante estudar e avaliar o quanto as diretrizes de usabilidade de interface de software são pertinentes ao longo das mudanças ocorridas no modo de projetar uma interface humanocomputador. As diretrizes analisadas no presente estudo, elaboradas em 1986, foram compiladas a partir de trabalhos anteriores dos autores Sidney L. Smith e Jane N. Mosier, ou seja, algumas das diretrizes estudadas neste trabalho foram elaboradas há mais de 20 anos.
Segundo o especialista em usabilidade Jakob Nielsen, “cerca de 90% das diretrizes de 1986 continuam válidas”. A partir desta premissa e da utilização dos preceitos metodológicos adotados por Nielsen ao analisar 60 das 944 diretrizes buscouse avaliar todas as diretrizes e verificar qual é o grau de relevância destas no atual cenário de estudos sobre usabilidade. Para isso foram usados livros e artigos de Jakob Nielsen, tendo em vista manter uma unidade teórica.
A presente pesquisa tratou de diretrizes de software e de sites como elementos semelhantes e afins. O trabalho de Jakob Nielsen é voltado para sites e as diretrizes elaboradas por Sidney L. Smith e Jane N. Mosier são voltadas para software; este ponto não alterou os resultados da pesquisa ou constituiu uma problemática ao longo da análise. Com o aumento da largura de banda nos últimos anos e com o equivalente crescimento dos serviços disponibilizados na Internet, cada vez mais, os serviços antes disponibilizados em software comprados e instalados no computador do usuário estão sendo disponibilizados online.
A partir destes elementos, a presente pesquisa classificou, baseada em textos e artigos deste autor, 49% das diretrizes elaboradas por Smith e Mosier. Elas foram classificadas em três categorias distintas: válidas e relevantes, parcialmente válidas e obsoletas.
Outro preceito metodológico foi o estabelecimento de relações entre as normas elaboradas em 1986 e os artigos publicados por Nielsen. Adotouse esta dinâmica devido à atualidade destes textos, à disponibilização dos mesmos na Internet e à disponibilização de anotações que informam sobre mudanças necessárias. Estes elementos são relevantes à pesquisa dado que a relação das diretrizes elaboradas em 1986 e textos desatualizados poderia prejudicar o resultado final deste trabalho. A partir da comprovação de um número relevante de diretrizes válidas podese afirmar que apesar da suposta simplicidade elas continuam constituindo práticas adequadas em uma área tão dinâmica quanto a de interface com o usuário. Conseqüentemente, após 20 anos podese utilizálas como bases sólidas para a construção de um software ou site fácil de usar.
C A P . I I N T R O D U Ç Ã O 14
No capítulo 2 são apresentadas as áreas de estudo interação humanocomputador e usabilidade, e como as mesmas se relacionam. De forma complementar, este também aborda a importância da utilização de diretrizes de usabilidade como ferramenta de apoio no projeto de interfaces. O capítulo 3 se constitui de uma apresentação da DTD (Document Type Definition) DocBook, suas aplicações e de como esse sistema auxiliou na dinâmica da pesquisa. O capítulo 4 apresenta a modelagem (em linguagem UML) elaborada no início da pesquisa, que por sua vez propiciou a visualização simplificada de cada um dos elementos desta, assim como suas relações e a visão global dos elementos resultantes da investigação. Neste, ainda são detalhadas todas as partes e padrões de projeto que compõem a modelagem e qual foi a estratégia de classificação das diretrizes analisadas neste projeto. O capítulo 5 é composto dos resultados da pesquisa. E, por fim, o capítulo 6 apresenta as conclusões obtidas e trabalhos futuros.
2 . 1 . I N T E R A Ç Ã O H U M A N O C O M P U T A D O R 15
Cap. II – Diretrizes e a usabilidade
2.1. Interação HumanoComputador (IHC)
O conceito de Interface pode ser caracterizado como qualquer local onde ocorra o contato entre duas entidades e são representadas as funções, responsabilidades e propriedades dos atores envolvidos nessa relação (ROCHA; BARANAUSKAS, 2003). Partindo deste preceito, IHC trata da específica relação do usuário com computador. O meio utilizado para que esta relação ocorra é a interface humanocomputador.
O termo IHC, que passou a ser utilizado em meados dos anos 80, se refere ao campo de estudos que aborda os aspectos relacionados à interação ocorrida via interface humano
computador. IHC, portanto, pode ser definida como a disciplina que, de forma interdisciplinar, investiga o design, avaliação e implementação de sistemas computacionais e interativos para o uso humano e o estudo dos principais fenômenos ao redor deles (ROCHA; BARANAUSKAS, 2003). Um conceitochave desta disciplina é a usabilidade, que se refere basicamente à capacidade de um produto ser utilizado facilmente (ISO 924111:1998) – este significado será discutido mais detalhadamente no item 2.2. O principal objetivo de IHC é a produção de sistemas computacionais usáveis, seguros e funcionais. Neste sentido, os desafios desta disciplina estão relacionados às maneiras de buscar soluções para instituir um design centrado no usuário (UserCentered Design), que é a filosofia que coloca o usuário como centro de todo o projeto de sistemas computacionais. Esta questão será abordada com maiores detalhes no item 2.3.
2.2. Usabilidade
O termo usabilidade surgiu no início dos anos 1980, quando começou a ser utilizado como um substituto para o termo "amigável", que possuía um sentido vago e subjetivo. Dias (2002) comenta que os usuários não precisam que as máquinas sejam amigáveis e sim que elas não interfiram nas tarefas dos usuários. Um sistema pode ser amigável para um usuário e não ser para outro.
Em 1991, a norma ISO/IEC 9126 apresentou a primeira definição formal para o termo como sendo um conjunto de atributos de software relacionado ao esforço necessário para seu uso e para o julgamento individual de tal uso por determinado conjunto de usuários (ISO 924111:1998). Em 1998, ele foi redefinido, e nessa ocasião foram incluídas as necessidades do usuário. No mesmo ano, houve ainda outra atualização, apresentada na norma ISO 924111 Guidance on Usability, desta vez considerando de maneira predominante o ponto de vista do usuário e o contexto de uso.
O documento também apresenta definições para os termos utilizados na atual abordagem de usabilidade. São eles:
•
Usuário é quem interage com o produto;
•
Contexto de uso envolve os usuários, tarefas, equipamentos, ambiente físico e social em que o produto é usado;
•
Eficácia é dada pela precisão e pela completeza com que usuários atingem seus objetivos. Em que a precisão se dá pela relação entre a qualidade dos resultados obtidos e a completeza é a proporção de resultados atingidos;
C A P . I I D I R E T R I Z E S E A U S A B I L I D A D E 16
•
Eficiência é relação da eficácia com a quantidade dos recursos gastos;
•
Satisfação é uma medida estabelecida pelo conforto e aceitabilidade do produto por parte dos usuários. Ela pode ser calculada por meio de métodos subjetivos e/ou objetivos.
A partir destes elementos a atual abordagem de usabilidade foi definida como “a capacidade de um produto ser usado por usuários específicos para atingir objetivos específicos com eficácia, eficiência e satisfação em um contexto específico de uso” (ISO 924111:1998).
No entanto, sua difusão e disseminação foram fenômenos decorrentes do interesse empresarial (RUBIN, 1994). Esta nova terminologia tornouse relevante no contexto dos negócios devido ao crescimento das vendas online, pois fez com que qualquer site de vendas difícil de utilizar tivesse menos lucro que os concorrentes que fossem mais fáceis de usar.
Dados revelam que em 1998 cerca de três bilhões de dólares deixaram de ser ganhos em sites norteamericanos devido ao design mal elaborado (ROCHA; BARANAUSKAS, 2003). Nielsen (2000a) aponta que websites que possuem má usabilidade equivalem a um número nulo de clientes. Nielsen (1994a) foi um dos teóricos que apresentou dados que justificam o investimento em usabilidade. Com isso, empresas passaram a atentar para o fato de que deveriam investir em projetos de interfaces humanocomputador de forma a tornálas fáceis de entender e utilizar.
2.3. Diretrizes de usabilidade
As diretrizes pesquisadas foram propostas para servirem como uma ferramenta em potencial para especialistas em projetos de interfaces humanocomputador (SMITH; MOSIER, 1986). Elas foram elaboradas em 1986 durante um projeto realizado na Divisão de Sistemas Eletrônicos da Força Aérea Norteamericana. Este objetivava padronizar os programas produzidos na base militar de Hanscom (Massachusetts, EUA) e resultou em um conjunto de 944 diretrizes de usabilidade.
Neste documento os autores comentam que as normas foram escritas para serem tão simples quanto possível para permitir sua aplicação de maneira geral. Mas, eles complementam que em alguns casos elas foram intencionalmente específicas para limitarem o escopo de sua aplicação e com isso evitar erros de interpretação, uma vez que as normas devem ser "traduzidas" para regras específicas de design antes de serem aplicadas (SMITH; MOSIER, 1986).
Sugerese também que a utilização das diretrizes em um dado projeto requer, em primeiro lugar, a identificação de todas as diretivas que são aplicáveis. Após isso, devese analisar o nível de importância de cada uma das normas do conjunto selecionado em relação à interface a ser projetada. E, por fim, aplicar o maior número possível das que foram identificadas como sendo de maior relevância.
As diretrizes de usabilidade são utilizadas no método de inspeção de interfaces de revisão de diretrizes (ROCHA; BARANAUSKAS, 2003). Este se utiliza da verificação da conformidade de uma interface em relação a uma série de normas para, assim, identificar possíveis pontos em que há necessidade de revisão do projeto de IHC. Além da revisão de diretrizes, Rocha e Baranauskas (2003) destacam outros métodos de inspeção, são eles: avaliação heurística, inspeção de consistência e em percurso cognitivo.
17 2 . 3 . D I R E T R I Z E S D E U S A B I L I D A D E
Os autores das normas alertam ainda para o fato de que as diretrizes não podem ocupar o lugar de especialistas em interface (SMITH; MOSIER, 1986). Nielsen (2006) complementa essa colocação ao comentar que diretrizes de usabilidade informam como as pessoas tipicamente se comportam com designs semelhantes. Rocha e Baranauskas (2003) apresentam a unificação destas duas idéias quando sugerem que o uso de diretrizes não deve ser entendido como uma receita a se seguir, mas sim como um conjunto de princípios norteadores de design. Dessa forma, estes princípios auxiliam na produção de interfaces que buscam o principal objetivo de IHC, que é produzir um design centrado no usuário (Usercentered Design), ou simplesmente UCD. Conceito que é utilizado não somente para representar as técnicas, métodos, e procedimentos para tornar produtos e sistemas usáveis, mas o mais significativo é que constitui uma filosofia que coloca o usuário como centro de todo o processo de desenvolvimento (RUBIN, 1994).
A essência do UCD está em fazer com que o produto seja adequado aos usuários, e não que os usuários se adaptem ao produto. Seus três princípios são:
•
Análise antecipada sobre os usuários e as tarefas. Onde é necessário colher informações dos usuários;
•
Medição empírica do uso do produto. Onde o foco está em registrar o quanto um dado produto é fácil de aprender e utilizar;
•
Design iterativo segundo o qual um produto é projetado, modificado e testado repetidamente. Onde o foco está em testar e ajustar o produto, em relação à usabilidade, durante todo o processo de desenvolvimento.
A partir destes conceitos, concluise que diretrizes de usabilidade formam uma base teórica que busca evitar erros recorrentes no projeto de interfaces e descreve os princípios de design que focam na elaboração de uma interface humanocomputador que funcione corretamente para a maioria de seus usuários.
C A P . I I I R E C U R S O S T É C N I C O S U T I L I Z A D O S 18
Cap. III – Recursos Técnicos Utilizados
3.1. DocBook
DocBook é uma definição de tipos para documentos (Document Type Definition), ou simplesmente DTD. Uma DTD estabelece quais são os elementos e a estrutura dos arquivos XML (eXtensible Markup Language) ou SGML (Standard Generalized Markup Language) que a utilizam. Seu intuito é manter a base pela qual um documento será validado e com isso verificar se documentos que fazem seu uso não possuem erros de estrutura.
A DocBook foi elaborada no início de 1991 em um projeto conjunto da HaL Computer Systems e da editora O'Reilly (WALSH; MUELLNER, 2005). Com o crescimento de sua popularidade surgiu a necessidade de uma organização que cuidasse apenas de sua manutenção. Nesse ponto, o Davenport Group se tornou o responsável e, em 1998, passou a ser responsabilidade do Technical Committee da OASIS (Organization for the Advancement of Structured Information Standards), que é a mantenedora atual do projeto.
A DocBook provê uma maneira estruturada de escrever documentos utilizando SGML ou XML (WALSH; MUELLNER, 2005). Atualmente este sistema é mais utilizado em livros e artigos técnicos da área de informática, mas isso não impede que seja utilizada em outras áreas, uma vez que sua estrutura corresponde às partes que compõe livros e artigos em geral.
Um dos recursos mais relevantes deste sistema é que ele possibilita uma marcação semântica e estruturada com seus mais de 300 elementos. Com isso, possibilita busca semântica e estruturação de conteúdos que podem variar de simples artigos até extensas coleções de livros. Além disso, ela possibilita aos softwares de publicação uma interpretação precisa dos documentos que a utilizam, pois se certificam que o documento processado está válido antes de utilizar os dados nele contido. Atualmente, através de programas de processamento – livres e comerciais – é possível transformar o conteúdo destes documentos em páginas HTML, arquivos no formato PDF, áudio e Braile.
Os programas de processamento necessitam, além do documento de dados (XML ou SGML) associado a uma DTD, de uma folha de estilo XSL (eXtensible Stylesheet Language). Esta indica para o processador qual deve ser a saída gerada para cada um dos elementos do arquivo de origem. Para tanto, a presente estudo fez o uso da XSL que faz parte do projeto DocBook, chamada DocBook XSL 1.69.1. Para fazer uso de uma DTD, um documento de marcação (HTML, XML, SGML, etc.) pode declarar seus elementos no próprio arquivo, fazer referência a um arquivo local, ou referenciar um arquivo remoto. A DocBook utilizada neste projeto foi referenciada remotamente. Para utilizála bastou incluir a seguinte linha de código no arquivo XML: <!DOCTYPE book PUBLIC "//OASIS//DTD DocBook XML V4.1.2//EN" "http://www.oasisopen.org/docbook/xml/4.1.2/docbookx.dtd">
A utilização dessa DTD combinada com um arquivo XML, que por sua vez foi associado à DocBook XSL, permitiu estruturação dos dados e a utilização de um processador que pudesse gerar páginas HTML e, assim, alcançar a versatilidade necessária à investigação. Isso também 19 3 . 1 . D O C B O O K
auxiliou ao longo do andamento da pesquisa, uma vez que facilitou a forma como a orientadora a acompanhou.
C A P . I I I R E C U R S O S T É C N I C O S U T I L I Z A D O S 20
3.2. Xalan
Xalan é um processador XSLT que integra o projeto Apache XML. Este que visa fornecer soluções em XML com qualidade comercial baseadas em padrões desenvolvidos de modo aberto e cooperativo, fornecer retorno às corporações mantedoras de padrões em relação à perspectiva de implementação e ser o foco das atividades relacionadas ao uso do XML pelos projetos da empresa. Utilizouse neste trabalho a versão 2.6 do processador, feito na linguagem de programação Java. Ele foi empregado para gerar páginas HTML a partir do arquivo XML estruturado com os elementos da DocBook. Além de páginas HTML o Xalan também transforma documentos XML em arquivos de texto simples, em XHTML ou em outros arquivos XML, bastando para isso alterar a XSL utilizada pelo arquivo de origem.
Com base no código HTML gerado, foi elaborada uma folha de estilos em CSS (Cascading Style Sheets) para definir os atribuídos visuais dos elementos resultantes do processamento do arquivo XML. A definição da aparência dos elementos foi mantida no arquivo tgi.css, que foi referenciado no comando que executava o processamento do arquivo de origem. As folhas de estilo em cascata, ou CSS, possibilitam a definição dos atributos visuais de elementos de arquivos estruturados, como páginas HTML, XML, etc. O objetivo deste recurso foi manter separados os atributos de apresentação dos dados em si. O código HTML gerado pelo Xalan define identificadores para os diferentes estilos de acordo com seu valor semântico no documento estruturado. Para o seguinte trecho do arquivo XML:
<epigraph>
<para>
<quote>Diretrizes de usabilidade informam a você como as pessoas tipicamente se comportam com designs parecidos.</quote>
</para>
<attribution>Jakob Nielsen</attribution>
</epigraph> A saída gerada em HTML foi a seguinte:
<div class="epigraph">
<p>“<span class="quote">Diretrizes de usabiliadade informam a você como as pessoas tipicamente se comportam com designs parecidos.</span>”</p>
<div class="attribution">
<span><span class="attribution">Jakob Nielsen</span></span>
</div>
</div>
Em que as identificações das classes representadas por class="epigraph" e class="attribution", são associadas às definições de estilo abaixo:
div.epigraph { marginbottom: 15px; fontstyle: italic; }
21 3 . 3 D I S P O N I B I L I Z A Ç Ã O D O S E L E M E N T O S D A P E S Q U I S A
div.epigraph p { margin: 20px 0 5px 0; padding; 5px; }
div.epigraph span.attribution { fontstyle: normal; }
A associação da página HTML gerada pelo Xalan com a folha de estilos CSS elaborada, possibilitou o realce da estrutura dos elementos da pesquisa (Figura 3.1).
Figura 3.1. Exemplo da renderização do código HTML
A utilização do Xalan para processar o arquivo XML (utilizando a DTD DocBook e XSL do mesmo projeto) forneceu de maneira simples um meio de disponibilizar os elementos da presente pesquisa em páginas HTML. E, dessa forma, possibilitou que a mesma pudesse ser acompanhada durante seu andamento.
3.3. Disponibilização dos elementos da pesquisa
A saída gerada pelo processador, além dos elementos da atual pesquisa, continha a data da última atualização, assim como uma lista contendo as alterações feitas desde a última publicação e as dúvidas encontradas ao longo do projeto. Neste sentido, esta estrutura configurou uma espécie de “Diário de Campo” da pesquisa.
A publicação da página HTML foi feita em um site mantido pelo autor deste trabalho e o endereço onde ela se encontrava foi divulgado apenas à orientadora da pesquisa. Para evitar que o trabalho fosse visto por outras pessoas durante sua elaboração e que sistemas de busca indexassem seu conteúdo, fezse o uso de uma autenticação simples para evitar acessos indevidos. Essa autenticação apenas validava uma sessão de 10 minutos, ou seja, permitia a visualização da página por um usuário devidamente autenticado e exigia uma nova autenticação após 10 minutos sem visitar a página.
Essa autenticação foi feita na linguagem de programação ASP (Active Server Pages) e não utilizou base de dados nem outros elementos que a tornassem demasiadamente complexa, uma vez que seu único intuito foi disponibilizar o devido acesso à orientadora. Neste ponto, buscouse C A P . I I I R E C U R S O S T É C N I C O S U T I L I Z A D O S 22
coesão sobre a escalabilidade, dado que o acesso a este recurso foi temporário e optouse em fazer um controle de acesso tão simples quanto possível, para que toda a atenção do projeto fosse dada à análise das diretrizes de usabilidade.
Além da DocBook ter possibilitado a marcação semântica, a estruturação hierárquica e a hipertextualização dos elementos resultantes da pesquisa (por exemplo, as normas estudadas, suas justificativas e referências bibliográficas), ela possibilitou a elaboração das novas seções em que os resultados foram organizados (item 5.1). A DocBook ainda auxiliou na disponibilização do material da pesquisa durante sua elaboração de forma a aumentar a interação entre orientando e orientadora, facilitando para esta última o acesso aos avanços do trabalho e assim mantêla mais próxima do resultado buscado, dado que tudo que havia sido feito e todas as dúvidas encontradas já haviam sido apresentados no documento publicado.
23 4 . 1 . M O D E L A G E M
Cap. IV – Metodologia
4.1. Modelagem
Utilizouse para a modelagem da estrutura deste trabalho um diagrama de classes em UML (Unified Modeling Language) aplicando os Padrões de Projeto GoF (Gang of Four) (GAMMA, et al., 1995). O intuito do presente modelo foi descrever unicamente a organização dos elementos envolvidos na presente pesquisa assim como a relação entre os mesmos. Portanto, as classes descritas neste item apenas representam a modelagem conceitual do problema e não contam com a respectiva implementação.
Para a organização das classes do diagrama fezse uso da modelagem em três camadas. As camadas representam os papéis que as classes nelas contidas devem representar. As três camadas utilizadas são:
•
Camada de interface – esta camada localizase em um dos extremos do modelo. Ela contém as classes delegadas em disponibilizar a interface e os controles disponíveis para o usuário. Estas, por sua vez, se comunicam apenas com sua camada vizinha, a camada de negócios;
•
Camada de negócios – constitui a camada intermediária do modelo. Ela recebe as solicitações feitas das classes contidas na camada de interface e é responsável por abrigar as regras de controle das requisições e de acesso aos dados contidos nas classes da camada de dados;
•
Camada de dados – esta camada localizase no extremo oposto ao da camada de interface. Ela contém as classes que representam a estrutura dos dados utilizados no sistema. Nelas são feitas as manipulações solicitadas pelas classes contidas na camada de negócios.
Primeiramente, serão discutidas as utilizações dos Padrões de Projeto em separado. Por fim, será apresentado um diagrama de classes reunindo todas os elementos, explicitando assim, a relação entre todos os Padrões de Projeto GoF escolhidos.
4.1.1. Padrão de Projeto Bridge
O intuito do Padrão de Projeto Bridge é fazer com que classes que utilizam um dado serviço sejam independentes da forma de como os mesmos são acessados, ou seja, de separar a forma de acesso, do serviço. Isso faz com que esses dois possam variar independentemente.
Na presente modelagem, utilizouse o padrão Bridge para desacoplar a abstração da implementação entre a classe XMLEditor (que representa o elemento responsável por manipular o XML) e a classe DocBookFacade (que representa, de forma centralizada, o acesso ao manipulação do arquivo) (Figura 2). Este padrão também foi usado para separar, da mesma forma, a abstração da implementação entre a classe HTMLViewer (que representa um visualizador de HTML) e a classe HTMLInterpreter (que representa a classe que interpreta os marcadores HTML) (Figura 4.1).
C A P . I V M E T O D O L O G I A 24
Figura 4.1. Utilização do Padrão de Projeto Bridge
4.1.2. Padrão de Projeto Interpreter
O Padrão Interpreter objetiva efetuar processamento baseado na interpretação de uma dada estrutura de dados. Ele é normalmente utilizado no processamento de estruturas que utilizam gramáticas e é uma forma comum de se adicionar funcionalidade às estruturas de dados que se baseiam em composição, ou seja, elementos que agregam outros elementos. Ele foi utilizado na classe HTMLInterpreter para representar o elemento utilizado pela classe HTMLViewer para interpretar os marcadores HTML e assim renderizálos para a classe BrowserInterface (Figura 4.2).
25 4 . 1 . M O D E L A G E M
Figura 4.2. Utilização do Padrão de Projeto Interpreter
4.1.3 Padrões de Projeto Strategy e Visitor em conjunto
O objetivo do Padrão de Projeto Visitor é fornecer um meio de processamento de estruturas de dados em árvore. Para isso, sugere que cada nó da estrutura possua um método que libere acesso ao seu conteúdo para que o Visitor percorrêla e efetuar o devido processamento. Ele foi utilizado nas classes ParserVisitor e HTMLParserVisitor para representar a forma utilizada pela classe HTMLInterpreter para percorrer o documento HTML (Figura 4.3). Figura 4.3. Utilização dos Padrões de Projeto Interpreter e Visitor
O objetivo do Padão Strategy é fazer com que diferentes algoritmos ou métodos de processamento sejam intercambiáveis independentemente da classe que os utiliza. Ele foi utilizado na classe HTMLParserVisitor para representar o encapsulamento do algoritmo que dita a forma de como o HTMLInterpreter percorre a estrutura em árvore do arquivo HTML (Figura 4.3).
4.1.4. Padrão de Projeto Façade
O Padrão de Projeto Façade busca fornecer um ponto de acesso unificado e simplificado às diversas funcionalidades de um subsistema. Dessa forma, ele representa um ponto de acesso unificado, provento escalabilidade, uma vez que qualquer futura manutenção do acesso ao sistema deveria ser focalizada no ponto onde o Façade atua, porém, essa mesma funcionalidade o torna pouco performático, pois ele pode se tornar limitador de desempenho de um dado sistema.
O Padrão Façade foi utilizado na classe DocBookFacade, para que suas subclasses fornecessem às classes que estendessem XMLEditor uma interface simplificada e centralizada de todas as funcionalidades disponibilizadas pelo subsistema formado pelas classes XMLIterator, XSLT, GuidelineAnalisysFactory e GuidelineFactory (Figura 4.4).
27 4 . 1 . M O D E L A G E M
Figura 4.4. Utilização do Padrão de Projeto Façade
4.1.5. Padrão de Projeto Proxy
O objetivo do Padrão de Projeto Proxy é fornecer um representante para um objeto e controlar o acesso a ele de forma transparente à classe que faz a requisição. Ou seja, dado uma classe cliente faz uma requisição ao Proxy, que por sua vez faz o pedido para a classe que realmente pode atendê
lo. Subseqüentemente o resultado é devolvido à classe cliente de forma que ela não tenha nenhuma informação de que houve esse encaminhamento, ou seja, este envio de pedido é transparente para a classe que fez a requisição.
O Padrão Proxy foi utilizado para representar a forma de como um pedido de processamento feito pela classe XMLDocBookFacade às classes que estendem a classe XSLT, seja transparente à fachada (Figura 4.5).
Figura 4.5. Utilização do Padrão de Projeto Proxy
4.1.6. Padrão de Projeto Factory Method
O objetivo do Padrão Factory Method é definir uma interface para a criação de um objeto e possibilitar que suas subclasses decidam quais objetos deseja instanciar, ou seja, delega as regras de instanciação de objetos às suas subclasses.O Padrão Factory Method foi utilizado para representar a forma de como a classe ComponentFactory delegou as regras de instanciação para suas subclasses, GuidelineAnalisysFactory e GuidelineFactory. Estas, por sua, vez são utilizadas pela fachada (XMLDocBookFacade), que invoca a criação dos objetos que representam as análises das diretrizes e as diretrizes (Figura 4.6).
29 4 . 1 . M O D E L A G E M
Figura 4.6. Utilização do Padrão de Projeto Factory Method
4.1.7. O Padrão de Projeto Singleton
O objetivo do Padrão de Projeto Singleton é garantir que uma classe possua somente uma instância sendo executada e fornecer um ponto de acesso a ela. Para alcançar seu objetivo ele utiliza um construtor privado, ou seja, ela é a única que pode criar sua única instância. Essa criação é transparente para todas as classes que utilizam o Singleton. O método único de acesso retorna uma referência para o objeto, caso já tenha sido acessado, senão, este mesmo método solicita a criação do objeto e retorna sua referência ao objeto que fez o pedido. Utilizouse o padrão Singleton na classe DocBookXML, uma vez que esta representa o arquivo único que contém os C A P . I V M E T O D O L O G I A 30
elementos da pesquisa fornecendo à classe XalanXSLT um meio único de acesso à sua instância (Figura 4.7). Figura 4.7. Utilização do Padrão de Projeto Singleton
4.1.8. Padrão de Projeto Composite
O objetivo do Padrão de Projeto Composite é representar estruturas em árvore. Ela é utilizada para compor objetos hierarquizados que se relacionam na forma todoparte.
Ele foi utilizado na classe que representa o arquivo XML, o qual contém os elementos da presente pesquisa, uma vez que a estrutura do arquivo representado possui uma hierarquia bem definida e que pode ser descrita como sendo uma árvore (Figura 4.8). 31 4 . 1 . M O D E L A G E M
Figura 4.8. Utilização do Padrão de Projeto Composite
4.1.9. União dos Padrões de Projeto GoF utilizados
Comentouse entre os itens 4.1.1 e 4.1.8 quais foram os Padrões de Projeto GoF (GAMMA et al., 1995) utilizados para modelar os diferentes elementos desta pesquisa. Porém, a reunião dos mesmos foi que possibilitou, previamente, o detalhamento de todos os elementos representativos da pesquisa. Dessa forma a visão global da pesquisa apresentada pelo diagrama (Figura 4.9) forneceu o espaço de estudo ao qual foram tomadas as decisões ao longo do projeto. C A P . I V M E T O D O L O G I A 32
Figura 4.9. Diagrama UML de classes, utilizando os Padrões de Projeto GoF
33 4 . 2 . E S T R U T U R A Ç Ã O P A R A A A N Á L I S E D A S D I R E T R I Z E S
O diagrama de classes utilizado para modelar o presente estudo, possibilitou não apenas a visualização de todos os seus elementos como e a relação entre eles. E mesmo sem representarem uma implementação propriamente dita, as classes e métodos representados no diagrama serviram como referência para estruturar e manter os elementos da pesquisa devidamente relacionados. 4.2. Estruturação para a análise das diretrizes
A investigação envolveu, num primeiro momento, o estudo detalhado e interpretação das 944 diretrizes presentes no documento Guidelines for Designing User Interface Software, de Smith e Mosier (1986). A partir desta análise, foi feita uma pesquisa para a verificação da equivalência dos resultados obtidos – em relação às necessidades atuais de projeto de interface humanocomputador – em artigos pertinentes à usabilidade publicados por Nielsen, compondo dessa forma uma análise qualitativa das normas. Contudo, nem sempre foi possível identificar uma ligação direta entre a diretriz estudada e as especificações apresentadas pelo autor. Nestes casos a estratégia adotada envolveu a verificação da equivalência com outras diretrizes ou heurísticas direcionadas aos mesmos objetivos.
O conjunto das diretrizes estudadas é voltado à GUI (Graphical User Interface) de software e o trabalho de Nielsen é direcionado à usabilidade de páginas web. Porém, isso não influenciou a relação proposta por este trabalho, uma vez que a diferença na utilização de ambos está vinculada ao objeto de estudo e não à base teórica de interação humanocomputador. Nielsen comenta que a diferença principal entre projeto de páginas web e GUI de software é que em páginas web o projetista deixa de controlar totalmente o projeto e compartilha a responsabilidade da interface com o usuário, atentando ainda para os hardware e software utilizados por este (NIELSEN, 2006).
A avaliação de cada uma das diretrizes seguiu o mesmo preceito metodológico adotado por Nielsen: verificar a relevância das mesmas no atual cenário de estudos de usabilidade. A partir deste pressuposto, buscaramse referências aos mesmos problemas e aos mesmos pontos passíveis de erro.
Porém, a análise do autor abordou apenas 60 das 944 diretrizes, o que constitui 6,35% do total das diretivas elaboradas em 1986. Ele utilizou 10 normas de cada uma das seis seções do trabalho de Smith e Mosier. A escolha dessas normas, segundo o autor, foi feita de maneira a simular um sorteio, pois o livro foi aberto aproximadamente no meio de cada uma das seis seções, e foram utilizadas como amostragem as 10 primeiras diretrizes das páginas selecionadas (NIELSEN, 2005).
Após a fase de classificação e análise das diretrizes a presente pesquisa obteve uma série de normas que contavam com justificativas e objetivos fortemente relacionados. A partir desta constatação, a organização da análise no presente documento se deu pela reunião de todas as diretivas que contavam com objetivos comuns e, por conseqüência disso, das justificativas comuns a estas. Segundo Shneiderman (1998), a utilização da taxonomia facilita comparações e organiza os tópicos de maneira a facilitar sua consulta numa primeira leitura. Com isso, buscouse com essa divisão apresentar os resultados de forma que a taxonomia das análises auxiliasse na organização e apresentação das mesmas. O resultado desta separação foi a criação de novas seções (item 5.1), utilizadas para reunir diretrizes correlatas além da forma sugerida pela divisão dos capítulos do trabalho de Smith e C A P . I V M E T O D O L O G I A 34
Mosier (1986), que estruturam a compilação de acordo com as funções de uma interface humano
computador. Contudo, a presente pesquisa buscou manter a relação abordada pelos autores das diretrizes, e para tal fez o uso de signos que utilizam representações icônicas, ou seja, se baseiam nas semelhanças e características que possuem em comum aos objetos que se referem (ROCHA; BARANAUSKAS, 2003), para abordar as funções atribuídas a cada um dos capítulos do trabalho de Smith e Mosier. São eles: •
O signo para representar o capítulo entrada de dados, que diz respeito às diretrizes relacionadas à entrada de texto, preenchimento de formulários, rótulos de campos de entrada de dados, assim como outras formas do usuário entrar dados via interface humanocomputador;
•
O signo para representar o capítulo apresentação de dados, que apresenta maneiras de como interfaces devem apresentar dados de formulários, de tabelas, de gráficos, etc.;
•
O signo para representar o capítulo controle de fluxo, que aborda as formas de interagir com usuário durante seu fluxo de trabalho, seja através de menus de seleção, linguagens de comando, tratamento de erros, teclas de atalho, entre outras formas de delegar o controle fluxo entre o usuário e o sistema;
•
O signo para representar o capítulo orientação do usuário, que trata principalmente de como sistemas de ajuda devem interagir com o usuário, assim como retorno do sistema;
•
O signo para representar o capítulo de transmissão de dados, que trata de troca de mensagens de uma maneira geral;
•
E por fim, o signo para representar o capítulo de segurança de dados, que aborda diferentes formas de evitar o acesso não autorizado aos dados.
A presente pesquisa buscou analisar todas as diretrizes da compilação de Smith e Mosier não classificadas por Nielsen. As normas analisadas e textos do autor estudado que estavam na língua inglesa foram traduzidos livremente pelo autor deste trabalho. A análise se deu pela ligação entre cada uma das diretrizes com artigos e livros de Jakob Nielsen, o que fez com que a análise convergisse, de certo modo, para usabilidade de páginas web.
35 4 . 3 . N Í V E I S D E C L A S S I F I C A Ç Ã O P A R A A S D I R E T R I Z E S
4.3. Níveis de classificação para as diretrizes
Os níveis de classificação utilizados na presente pesquisa foram os mesmos apresentados por Nielsen (2005b).
As categorias são as seguintes:
•
Válidas e relevantes, ou seja, diretrizes que continuam pertinentes aos projetos de interface humanocomputador atuais e podem ter aplicação imediata. Estas são representadas neste trabalho pela imagem .
•
Parcialmente válidas, ou seja, diretivas voltadas para uma necessidade atual, mas que se referem aos elementos de interface ou comportamentos de usuário que não ocorrem mais. Estas precisam de pequenas reformulações para ser utilizadas em projetos atuais de interfaces. Elas estão representadas neste trabalho pela imagem .
•
Obsoletas, ou seja, normas voltadas a elementos ou comportamentos de usuário já ultrapassados. Estas estão indicadas neste trabalho pela imagem .
C A P . V R E S U L T A D O S 36
Cap. V Resultados
5.1. Análise das diretrizes
Jakob Nielsen é considerado atualmente um dos maiores especialistas em usabilidade de sites do mundo. É um dos diretores da Nielsen Norman Group, empresa especializada em consultoria em usabilidade. Ele também é responsável pelo movimento "engenharia de usabilidade de desconto", que tem como objetivo fornecer maneiras simples e de baixo custo para aprimorar interfaces com o usuário. Nielsen é autor de 11 livros sobre projeto de interface com o usuário e hipertexto e escreve sobre usabilidade em sua coluna, chamada "Alertbox", no site useit.com (http://www.useit.com). Finalmente, ele detém 78 patentes nos Estados Unidos, a maioria delas sobre formas de como deixar a Internet mais fácil de usar.
Nielsen (2005a) comenta sobre a importância do trabalho realizado em 1986 por Smith e Mosier – onde colaborou de forma modesta –, em que foram elaboradas 944 diretrizes de usabilidade de interface humanocomputador. O fato que chama atenção no artigo, e que se tornou o ponto inicial deste trabalho é que, das 60 diretrizes analisadas pelo autor, 54 (90%) continuam válidas. Ele complementa que uma parte das diretrizes válidas é menos importante porque aborda elementos de interface que não são mais utilizados e precisam de alguns ajustes. Com isso, ele concluiu que 70% das diretrizes continuam válidas e relevantes às atuais necessidades de projeto de interface com o usuário. De maneira complementar, Nielsen coloca que a razão para a durabilidade das diretrizes de usabilidade é que elas dependem do comportamento humano, o qual muda lentamente. E que, as diretrizes que normalmente se tornam obsoletas estão relacionadas a tecnologias específicas (NIELSEN, 2005a).
A partir destes preceitos, o conjunto de diretrizes trabalhadas na presente pesquisa está distribuído nas próximas subseções. Elas foram reunidas de acordo com seus objetivos para que sua apresentação se fizesse de maneira estruturada e seguisse a forma apresentada por Nielsen (2005b). A reorganização alcançada reuniu, após a classificação das normas em cada um dos níveis apresentados no item 4.3, assuntos e objetivos correlatos. Para tal, foram utilizados os recursos hipertextuais obtidos a partir da utilização da DocBook, que forneceram dados para elaboração das novas partições que abrigam as normas relacionadas. Esses dados incluiam, por exemplo, referências, citações, comentários e análises.
O particionamento realizado neste trabalho está dentro das seguintes seções:
•
Diretrizes analisadas por Nielsen;
•
Consistência;
•
Tempo de resposta;
•
Retorno;
•
Legibilidade;
•
Processamento sob comando explícito do usuário;
•
Compatibilidade com o mundo real, simplicidade, objetividade e logicidade;
37 5 . 1 . A N Á L I S E D A S D I R E T R I Z E S
•
Navegação;
•
Interfaces auditivas;
•
Gerenciamento de erro;
•
Flexibilidade;
•
Listas;
•
Sobrecarga da memória do usuário;
•
Ícones;
•
Poluição visual;
•
Encriptação;
•
Acessibilidade e adaptação ao usuário;
•
Ajuda;
•
Gráficos e animações.
Os argumentos utilizados para sustentar as diretrizes válidas estão reunidos no início de cada um dos itens. As normas classificadas como parcialmente válidas ou obsoletas contam com suas respectivas justificativas. Desta forma, os argumentos e as justificativas citadas são os elementos que possibilitaram que a análise qualitativa das normas fosse feita. O aspecto qualitativo da classificação se deu através da reunião de textos de Nielsen que faziam referências diretas aos mesmos objetivos das diretrizes analisadas. Com isso, foi possível, através da utilização dos mesmos princípios e sugestões apresentadas nos textos reunidos, qualificar cada uma das normas estudadas em uma das três categorias propostas pelo autor e seguidas neste trabalho.
As seções seguintes contam com exemplos de diretivas válidas e pertinentes e a lista integral das que foram classificadas como parcialmente válidas e obsoletas. A lista completa das normas tidas como válidas e pertinentes se encontram no Anexo 1.
5.1.1. Diretrizes analisadas por Jakob Nielsen
Nesta seção são apresentadas as diretrizes já analisadas por Nielsen (2005b). Estas análises serviram como guia para todo o restante da pesquisa, pois se buscou classificar as diretrizes a partir da metodologia apresentada por ele.
Exemplo de diretriz válida e pertinente: Marcar campos opcionais e obrigatórios. No projeto de formulários, diferencie claramente e consistentemente campos obrigatórios de opcionais.
•
Marcadores de campos não preenchidos. Quando o comprimento de um item for variável, de forma que os dados preenchidos não substituam os marcadores em um campo, ignore qualquer marcador de campo no processamento feito pelo computador. C A P . V R E S U L T A D O S 38
Análise. Esta diretriz se tornou obsoleta, uma vez que sistemas atuais não utilizam mais marcadores (‘_’, por exemplo) para representar campos de entrada de dados, conforme afirma Nielsen (2005b).
•
Justificação automática de entradas de tamanho variável. Quando o comprimento de um item é variável, forneça justificação automática no processamento feito pelo computador; um usuário não deveria ter que justificar uma entrada à esquerda ou à direita. Análise. Esta diretriz se tornou obsoleta porque nos sistemas atuais os usuários não conseguem justificar as entradas, dado que os projetistas tipicamente justificam os campos de entrada de dados previamente, conforme afirma Nielsen (2005b).
•
Formato distinto para rótulos. Torne rótulos de campos de dados distintos, para que eles não sejam prontamente confundidos com entradas de dados, rótulos de opções de controle, mensagens de orientação, ou outro material exibido em tela. Análise. Esta diretriz é parcialmente válida porque, segundo Nielsen (2005b), os usuários devem ser capazes de distinguir rótulos de campos de entrada de dados. Contudo, ele também coloca que esta norma teria baixa relevância durante o projeto de uma interface humanocomputador atualmente, pois o sistema já fornece esta diferenciação.
•
Ativação simples para teclas de função. Assegure que qualquer tecla irá realizar a função que nela estiver rotulada com uma simples ativação, e sua função não será alterada com ativações repetidas. Análise. Esta diretriz se tornou obsoleta porque, segundo Nielsen (2005b), ao se considerar botões do mouse como sendo um tipo de tecla de função a presente norma não se refere a uma necessidade atual, uma vez que o duplo clique é um elemento largamente utilizado na interação do usuário com uma interface humanocomputador.
•
Teclas únicas para funções contínuas. Quando uma função é continuamente disponível, associe essa função a uma única tecla. Análise. Esta diretriz se tornou obsoleta porque, segundo Jakob Nielsen (2005b), sistemas atuais fazem o uso de diferentes mecanismos para tornar funções continuamente disponíveis, como menus persistentes ou barras de navegação. E complementa que atualmente é comum contar com um número de funções maior que o de teclas presentes no teclado.
•
Identificação de tela. Forneça um identificador único para cada tela e um local consistente no topo do quadro exibido. Análise. Esta diretriz se tornou obsoleta porque, segundo Nielsen (2005b), seu foco não permanece válido. Ele comenta que mesmo uma URL representando um identificador 39 5 . 1 . A N Á L I S E D A S D I R E T R I Z E S
único, os usuários não se referem às telas através de seus códigos. Conclui que, neste caso, o mais recomendado é fornecer um título que descreva claramente o conteúdo da página.
•
Indicando o modo operacional. Quando uma ação do usuário (ou do computador) efetua uma mudança no modo operacional que afetará ações subseqüentes do usuário apresente alguma indicação contínua do modo atual. Análise. Esta diretriz está parcialmente válida porque, segundo Nielsen (2005b), a utilização de modos operacionais foi descartada nos projetos atuais de design de interação. Entretanto, comenta que caso façase o uso dos modos este fato deve ser certamente ser indicado.
•
Indicando seleção de opções. Quando opções selecionadas anteriormente continuam em funcionamento, apresente essas opções automaticamente ou sob solicitação do usuário. Análise. Esta diretriz está parcialmente válida, porque segundo Nielsen (2005b), devido ao grande número de opções disponibilizadas pelos sistemas atuais é impraticável indicar todas as seleções anteriores. Ele comenta que o usuário deve contar com uma opção que o permita visualizar todas as opções escolhidas.
•
Editando cabeçalhos de endereços. Permita aos usuários editarem campos no cabeçalho de uma mensagem que esteja sendo preparada para transmissão. Análise. Esta diretriz está parcialmente válida porque, segundo Nielsen (2005b), é improvável que um campo de entrada de dados seja projetado de forma que não possa ser editável. O autor comenta que as atuais interfaces ainda não são projetadas da maneira ideal, mas que houve uma melhora representativa nos últimos 20 anos.
•
Redistribuindo mensagens recebidas. Permita aos usuários redistribuírem mensagens recebidas através da alteração de seus cabeçalhos. Análise. Esta diretriz está parcialmente válida porque, segundo Nielsen (2005b), sua intenção permanece correta, mas a maneira específica sugerida para redistribuir as mensagens está relacionada demasiadamente à tecnologia utilizada na época em que a diretriz foi elaborada.
5.1.2. Consistência
As diretrizes representadas nesta seção se referem de maneira geral à consistência em interfaces humanocomputador. O argumento principal para a classificação das seguintes normas de usabilidade que permanecem válidas está no fato de que, segundo Nielsen (1999a), “consistência é um dos princípios de usabilidade mais poderosos”, pois, quando o usuário compreende o funcionamento de diferentes elementos de uma interface, intra ou intersistema, suas expectativas são de encontrar interfaces semelhantes às que sabe utilizar.
O foco das seguintes normas diz respeito ao cuidado que se deve tomar para que diferentes interfaces intrasistema e intersistema possuam elementos de interface consistente, seja a respeito da cor, da ordem dos elementos, da forma de retorno ao usuário, da forma de como se dá a entrada de dados para o sistema, ou da consistência entre regras de negócio e implementação do software.
Outro ponto abordado se relaciona à importância de estar de acordo com padrões de design de interface. Neste ponto, Nielsen afirma que ao seguir padrões de design garantese que os usuários saberão, a priori, como utilizar um dado design de interface (1999b).
Exemplo de diretriz válida e pertinente: Posicionamento consistente do cursor. Na apresentação inicial de uma tela de entrada de dados, assegure que o cursor aparecerá automaticamente em uma posição consistente e útil.
•
Localização consistente dos rótulos. Posicione cada rótulo em um local acima ou à esquerda do(s) campo(s) de dados a ele associado(s). Análise. Esta diretriz está parcialmente válida, pois a orientação à esquerda ou à direita depende se o usuário é oriental ou ocidental, uma vez que, segundo Nielsen, o sistema deve se comunicar com os usuários de forma similar à utilizada pelos usuários fora do sistema (NIELSEN, 1994e).
•
Tipo de caixa consistente na codificação alfabética. Para códigos alfanuméricos apresente todas as letras consistentemente em letras maiúsculas ou em letras minúsculas. Análise. Esta diretriz está parcialmente válida, porque restringir a utilização dos códigos a letras maiúsculas ou letras minúsculas pode além de prejudicar a leitura ficar em desacordo com padrões de linguagem. Jakob Nielsen e Marie Tahir (2002) sugerem na diretriz de número 20 do livro Homepage Usabilidade: 50 Websites Desconstruídos, “Empregar letras maiúsculas e outros padrões de estilo com consistência”.
•
Área de exibição padrão para entrada de comando. Quando linguagem de comando é usada para controle de fluxo, forneça uma área de entrada de comando em uma localização consistente em todas as telas, preferivelmente na parte de baixo. Análise. Esta diretriz está parcialmente válida, porque elementos que devem estar em fácil localização para o usuário normalmente ficam no centro da página, que é o local por onde os usuários iniciam a leitura de uma tela. Segundo Nielsen e Tahir (2002), “quando uma página é carregada, os usuários focalizam sua atenção no centro da janela onde eles lerão o corpo do texto antes de se importarem em olhar acima de headerbars ou outros 41 5 . 1 . A N Á L I S E D A S D I R E T R I Z E S
elementos de navegação”. Porém, a diretriz está correta quando sugere que a localização da área de entrada de comandos deve ser consistente, uma vez que a consistência constitui um dos elementos mais relevantes na área de usabilidade (NIELSEN, 1999a).
5.1.3. Tempo de resposta
Este tópico engloba as diretrizes que fazem referência à importância dos curtos tempos de resposta e de como se deve manter o usuário informado durante tarefas que sejam mais lentas que o comum. O retorno ao usuário precisa ser rápido, pois responde à expectativa para uma dada tarefa, seja digitar uma letra ou aguardar o resultado de uma busca. Segundo Nielsen (2005c), “estabelecer e alcançar as expectativas do usuário é um dos princípios fundamentais de usabilidade da web”.
O autor afirma que o retorno durante um diálogo é um dos princípios mais básicos de usabilidade (NIELSEN, 1993), pois o tempo de resposta para o usuário deve ser tão breve quanto possível (NIELSEN, 1994b), e porque “O sistema deveria sempre manter os usuários informados sobre o que está acontecendo, através de retorno apropriado dentro de um tempo razoável.” (NIELSEN, 1994e). Tendo em vista as expectativas do usuário em relação ao sistema, têmse também o conceito de satisfação ao se utilizar uma interface humanocomputador. Sobre este tópico o autor comenta que a satisfação dos usuários está relacionada às suas expectativas, portanto se forem informadas sobre uma possível lentidão serão mais tolerantes com relação aos tempos de resposta (NIELSEN, 2000a).
Sobre limites de tempo, Nielsen apresenta três elementos que considera relevantes: 0,1 segundo é tempo de resposta necessário para que o usuário sinta que sua interação com o sistema está ocorrendo de maneira instantânea; 1 segundo é o tempo de resposta limite para manter a atenção completamente direcionada à tarefa em questão; e 10 segundos é o tempo de resposta limite para que o usuário mantenhase no atual diálogo (NIELSEN, 1994b).
Ele comenta ainda que qualquer resposta ao usuário que leve mais de 10 segundos necessita de um indicador de porcentagem da tarefa e que também deve ser fornecido um método para o usuário cancelar a operação a qualquer momento (NIELSEN, 1994b).
Exemplo de diretriz válida e pertinente: Tempo apropriado de resposta do computador. Assegure que a velocidade da resposta do computador para as entradas de controle do usuário é apropriada para a transação envolvida em geral, a resposta deveria ser mais rápida para transações entendidas pelo usuário como sendo simples.
•
Resposta rápida. Garanta com que o computador reconheça a entrada de dados rapidamente, para que usuários não sejam atrasados ou controlados devido à demora na resposta do computador; para tarefas comuns, o atraso para mostrar um retorno não deveria exceder 0,2 segundos. C A P . V R E S U L T A D O S 42
Análise. Esta diretriz está parcialmente válida, pois o tempo de resposta depende da tarefa em questão. Por exemplo, a velocidade em que uma letra deve aparecer após ser digitada deve ser mais rápida que a velocidade de download da página de um website. Mas de qualquer forma a velocidade da resposta é um dos fatores mais relevantes para se manter a atenção do usuário e, segundo Nielsen (1994b), “tempos de resposta devem ser mais curtos quanto for possível”.
•
Resposta rápida ao pedido de exibição. Assegure que a resposta do sistema a simples pedidos de apresentação de dados não leve mais que 0,5 a 1 segundo. Análise. Esta diretriz está parcialmente válida devido ao limite inferior apresentado, porque segundo Nielsen (1994b), o limite para o tempo de resposta que mantém a impressão de que o sistema está respondendo instantaneamente é de 0,1 segundo.
•
Preenchimento de formulário para entrada de dados. Considere preenchimento de formulário em tarefas onde certa flexibilidade na entrada de dados é necessária, como a inclusão de itens opcionais assim como obrigatórios, onde usuários terão treinamento moderado, e/ou onde a resposta do computador pode ser lenta. Análise. Esta diretriz está parcialmente válida, uma vez que, segundo Nielsen (1994b), as respostas às solicitações do usuário devem ser apresentadas o mais rápido possível, mas o autor comenta ainda que a utilização de formulários para a entrada de dados é a indicada quando o intuito é apenas colher dados preenchidos pelo usuário (2005d).
•
Tempo de resposta apropriado para mensagens de erro. Exiba uma mensagem de erro entre 2 e 4 segundos após a entrada do usuário na qual o erro foi detectado. Análise. Esta diretriz está parcialmente válida porque, segundo Nielsen (1994b), o tempo de resposta deve ser o mais breve possível. O intervalo utilizado na diretriz deveria apenas ser alterado para o limite de 10 segundos, que é o tempo necessário para manter a atenção do usuário no diálogo. 5.1.4. Retorno
As diretrizes apresentadas nesta seção se referem à importância do retorno que deve ser fornecido às ações do usuário. A resposta que é apresentada via interface humanocomputador a cada ação do usuário é a forma de manter um diálogo eficaz entre ele e o sistema. Segundo Nielsen (1993), o retorno durante um diálogo é um dos princípios fundamentais de usabilidade.
O retorno está relacionado principalmente à entrada e apresentação de dados, em que a apresentação de dados confirma para usuário que um processamento foi concluído corretamente (2005b). Após este ponto, o usuário é apto a prosseguir o diálogo através da próxima entrada para o sistema.
O autor enfatiza a importância do retorno em uma interface humanocomputador quando apresenta que os usuários devem ser sempre informados sobre o que está acontecendo no sistema (NIELSEN, 1994e).
Em um sistema em que ocorre a interação entre vários usuários, a importância da apresentação do status destes se dá pelos mesmos objetivos apresentados anteriormente para comunicação do usuário com o sistema. Tanto nesses casos como nos anteriores as normas aqui contidas apresentam a importância do usuário sempre possuir uma maneira de visualizar o status do sistema.
Exemplo de diretriz válida e pertinente: Retorno para conclusão de entrada de dados. Garanta que o computador responda à conclusão da entrada de dados com uma mensagem de confirmação, se a transferência dos dados foi bem sucedida, ou então com uma mensagem de erro.
•
Mostrar formato de proteção. Quando houver áreas de uma tela em que entradas de dados não podem ser feitas (espaços em branco, rótulos de campos protegidos, etc.), torne essas áreas insensíveis às ações de indicação, isto é, previna o cursor de acessar aquelas áreas. Análise. Esta diretriz está parcialmente válida, porque atualmente os espaços e rótulos de uma entrada de dados não são acessíveis de forma que possam ser alterados com um simples posicionamento do cursor, mas está correta onde diz que devemos prevenir que certos campos não sejam preenchidos. Nielsen (2005d) comenta que se pode melhorar a usabilidade de um formulário que contenha, por exemplo, campos de endereço da fatura e endereço de entrega se deixar os campos do endereço da fatura cinza (desabilitado) enquanto o usuário não clicar em um checkbox que desmarca a opção de que o endereço de entrega é o mesmo da fatura.
•
Exibição distinta de informação de controle. Projete todas as telas para que atributos relevantes ao controle de fluxo sejam distintos em posição e/ou formato. •
Retorno para seleção de menu. Quando um usuário tiver selecionado e entrado uma opção de controle por um menu, se não houver resposta natural imediatamente observável então o computador deve exibir algum outro reconhecimento daquela entrada.
Análise. As duas diretrizes anteriores estão parcialmente válidas, porque o tipo de distinção proposto por ambas já é mantido pelo sistema. Portanto, na maioria dos casos, não seria necessário avisar designers quanto a isso, mas ela se torna pertinente no contexto em que aplicações que cuidam da criação e manutenção dos elementos do formato, como Applets ou sites em Macromedia Flash, por exemplo, precisam manter a distinção entre os elementos. Nielsen apresenta, em uma das 60 diretrizes analisados por ele, que o retorno indicando a seleção de um item continua sendo um aviso significativo, mas tipicamente o C A P . V R E S U L T A D O S 44
sistema manipula o retorno automaticamente, o que torna este tipo de diretriz mais pertinente aos designs em relação às aplicações em Macromedia Flash (NIELSEN, 2005b).
•
Notificando alterações do projeto aos usuários. Quando alterações forem feitas no projeto de interface, incluindo alterações nas funções de orientação do usuário, informe essas alterações aos usuários. Análise. Esta diretriz está parcialmente válida, uma vez que os usuários devem ser informados das alterações substanciais, pois as interfaces na época em que o trabalho de Smith e Mosier foi elaborado não contavam com o número de elementos que podem sofrer alterações. Dessa forma sugerese que o sistema mantenha o usuário informado do que está acontecendo com o sistema (NIELSEN, 1994e) de forma que apenas sejam apresentadas para o usuário as informações que possam ser relevantes a ele (NIELSEN, 2003a).
•
Apresentação de mensagem opcional. No envio de mensagens, permita aos usuários escolherem quando transmitir uma versão visível ou transmitir diretamente através de um arquivo de dados localizado no computador. Análise. Esta diretriz está parcialmente válida, porque o fato da mensagem não ser apresentada não deve significar que nenhum retorno deva ser apresentado ao usuário dado que o sistema deve sempre fornecer o retorno apropriado a este (NIELSEN, 2000a). Mas está correta no ponto em que sugere a adaptação do envio de mensagem às necessidades do usuário. O autor comenta que se deve “prover liberdade e controle ao usuário” (2005b).
5.1.5. Legibilidade
O foco das normas desta seção está em manter os elementos de uma interface humanocomputador em uma disposição que os torne reconhecidos, compreensíveis e comparáveis facilmente. Os elementos citados englobam contraste entre cor de fundo e os outros elementos da interface, o tamanho de texto e forma de pontuação, e o destaque dos elementos selecionados, elementos que podem ser editados ou que necessitam de atenção imediata do usuário, por exemplo, sistemas de monitoração.
Jakob Nielsen comenta que a falta de legibilidade foi o mais comum entre 10 maiores erros de web design de 2005 (NIELSEN, 2005e). Em relação à legibilidade de elementos textuais, Jakob Nielsen e Marie Tahir (2002) alertam que violar o estilo padrão para nomes próprios reduz a legibilidade do texto e a credibilidade que os usuários têm em relação ao site. Da mesma forma, textos que possuem pontuação incomum com o intuito de chamar atenção ou como estilo de formatação reduzem a legibilidade.
Entre as formas sugeridas pelos autores para melhorar a legibilidade de um elemento está a utilização de listas para itens relacionados (NIELSEN; MORKES, 1997) e “marcação e ênfase para fazer com que palavras importantes capturem o olhar do usuário”(NIELSEN, 1997a). Ênfase esta que pode ser alcançada através de links, variações no tipo de fonte e no tipo de cor (NIELSEN, 1997b). Porém sua utilização deve ser cuidadosa, dado que “limitar os estilos de fonte e outros atributos de formatação de texto, como tamanhos, cores, etc. na página, porque o texto com design muito pesado pode se desviar do significado das palavras” (NIELSEN; TAHIR, 2002).
Exemplo de diretriz válida e pertinente: Rótulos próximos de campos de dados. Assegure que os rótulos estejam suficientemente próximos para serem associados a seus campos de dados, mas estejam separados dos campos de dados por ao menos um espaço.
•
Marcando os limites do campo. Mostre caracteres especiais ou outros meios consistentes de destaque para delinear claramente cada campo de dados. Análise. Esta diretriz está parcialmente válida, pois o uso de caracteres especiais não é mais necessário, mas o destaque e contraste dos campos de entrada de dados para delineá
los buscam uma melhor legibilidade, que contou com abordagens que justificam sua importância no início desta seção.
•
Marcas de mapeamento de linha. Para grandes tabelas, aquelas com muitas linhas, forneça alguma marca visual extra para auxiliar o usuário a visualizar uma linha através das colunas. •
Marcas de mapeamento de linha. Em tabelas densas com muitas linhas, insira uma linha em branco (ou algum outro atributo distintivo para auxiliar a visualização horizontal) após um grupo de linhas de intervalos regulares.
Análise. Estas duas diretrizes estão parcialmente válidas, porque a sugestão de ambas está em melhorar a legibilidade apenas de tabelas grandes ou densas, quando este ponto deveria ser buscado para qualquer tamanho de tabela. Sempre se deve tentar manter a melhor legibilidade possível, uma vez que a falta de atenção em relação a este ponto recai a um erro comum de web design (NIELSEN, 2005e).
•
Formato de rótulo distinto. Assegure que rótulos são distintivos em formato/posicionamento para auxiliar os usuários a distinguilos dos dados e outros atributos apresentados. Análise. Esta diretriz está parcialmente válida, porque seguindo a análise feita por Jakob Nielsen sobre a diretriz equivalente a esta no capítulo designado à entrada de dados o autor concluiu que os “Usuários precisam ser capazes de distinguir entre rótulos e campos de entrada de dados, mas não precisamos aconselhar designers para que tornem rótulos distintos uma vez que o sistema faz isso automaticamente” (2005b).
•
Elementos de exibição distintos. Torne os diferentes elementos do formato de exibição distintos um do outro. Análise. Esta diretriz está parcialmente válida, porque conforme apresentado anteriormente, este tipo de distinção já é mantida pelo sistema, o que torna a diretriz pertinente apenas em interfaces onde o projetista controla totalmente todos os elementos da interface com o usuário. •
Espaçamento para estruturar telas. Utilize espaço em branco para estruturar uma tela. C A P . V R E S U L T A D O S 46
Análise. Esta diretriz está parcialmente válida, porque pode parecer muito genérica e por isso, talvez, induzir os projetistas a não aproveitarem o espaço disponível na tela para manter espaços em branco. Mas está certa no ponto que o espaçamento bem projetado entre os elementos deixa mais clara e legível a estrutura da tela. Um exemplo de utilização desta diretriz é a linha de espaço que é comumente utilizada para separar parágrafos de texto. Segundo Jakob Nielsen, podese deixar um design menos entulhado quando se utiliza espaços em branco em vez de fios (2000a).
•
Entrada de comando, prompts, mensagens na parte de baixo. Reserve as últimas linhas de todas as telas para status e mensagens de erros, prompts, e entrada de comando. Análise. Esta diretriz se tornou obsoleta, porque conforme apresentado na página 38, o local em que os usuários focalizam primeiramente sua atenção é o centro da tela e não a parte inferior.
•
Marcadores próximos às palavras marcadas. Quando um símbolo especial é utilizado para marcar uma palavra, separeo do início da palavra por um espaço. Análise. Esta diretriz está parcialmente válida, uma vez que marcadores de palavras não são tão legíveis quantos outros recursos como cor de texto, tipo de fonte ou negrito, por exemplo. Mas está certa sobre a utilização de espaçamento entre marcadores e o item marcado, pois se busca melhorar a legibilidade, característica de importância já mencionada no início desta seção.
•
Sublinhando para dar ênfase. Quando uma linha é adicionada simplesmente para marcar ou enfatizar um item exibido, posicionea abaixo do item designado. Análise. Esta diretriz se tornou obsoleta, uma vez que a utilização de codificação de linha para textos se tornou um padrão para link e, segundo Jakob Nielsen (1999c), “usuários atualmente estão ficando confusos com qualquer texto sublinhado que não é um link”.
•
Azul saturado para cor de fundo. Utilize o azul saturado somente para atributos de fundo em uma tela, e não para dados críticos. Análise. Esta diretriz se tornou obsoleta, uma vez que, segundo Jakob Nielsen e Marie Tahir (2000), um design recomendado para a homepage, deve utilizar fundo de cor branca. No mesmo trabalho, os autores comentam que as diretrizes para homepages podem ser estendidas para as páginas comuns.
•
Codificação piscante. Considere codificação piscante quando um item exibido exigir uma necessidade urgente de atenção. 47 5 . 1 . A N Á L I S E D A S D I R E T R I Z E S
•
Piscando símbolos de marcação. Quando um usuário precisa ler um item exibido que possui codificação piscante, considere adicionar um símbolo extra como um asterisco para marcálo, e então faça com que marcador pisque em vez do item codificado.
Análise. Estas duas diretrizes se tornaram obsoletas, porque segundo Nielsen (1996a), “nunca inclua elementos de página que se movem incessantemente”.
•
Símbolo padrão para sugerir entrada. Escolha um símbolo padrão para indicar que uma entrada é exigida, e reserve o mesmo somente para este propósito. Análise. Esta diretriz está parcialmente válida, porque segundo Nielsen (2005b), a pontuação sugerida pela norma é uma boa prática na maioria dos casos, mas há algumas exceções, especialmente para formulários de websites. O autor comenta que buscas de websites podem conter um campo de entrada para o termo e um botão "Buscar", que neste caso faz o papel de rótulo e botão e não necessita dos dois pontos, por exemplo, como separador (NIELSEN, 2005b).
•
Menus diferenciáveis de outras informações exibidas. Se opções de menu são inclusas em uma tela em que o intuito é também de revisão de dados e/ou entrada de dados, que é uma abordagem de design comum, assegure que eles serão distintos de outras informações exibidas; posicione o menu consistentemente na tela e incorpore algumas características diferenciadas para indicar sua função especial. Análise. Esta diretriz está parcialmente válida, porque conforme mencionado anteriormente, a distinção proposta aqui já é mantida pelo sistema, porém pode ser pertinente em aplicações em que o projetista da interface controla completamente a aparência de todos os elementos da interface com o usuário (NIELSEN, 2005b).
•
Formato distinto para orientação do usuário. Projete o formato de telas para que o material de orientação do usuário seja prontamente diferenciável dos outros dados apresentados. Análise. Esta diretriz está parcialmente válida, porque conforme já explicitado por Nielsen (2005b) diretrizes que sugerem a manipulação de elementos aos quais os projetistas de interface normalmente não possuem acesso são menos importantes. Elas ganham espaço somente no projeto de interfaces em que se tem o controle total dos elementos nela contido. 5.1.6. Processamento sob comando explícito do usuário
As diretrizes acerca desta seção referenciam a forma de como se deve manter o processamento sob controle do usuário. Dado que o processamento e o status do sistema devem ser tão transparentes aos usuários quanto for possível.
Sobre essa transparência, o autor também comenta que “opções alteradas não devem fazer efeito até que o usuário clique no botão de comando (rotulado como ’OK‘ por exemplo)” (NIELSEN, 2004).
Exemplo de diretriz válida e pertinente: Ação explícita de envio. Sempre exija que o usuário execute uma ação de envio para iniciar o processamento dos dados preenchidos não inicie o processamento como um resultado de outra ação.
5.1.7. Compatibilidade com o mundo real, simplicidade, objetividade e logicidade
As diretrizes apresentadas a seguir buscam a “compatibilidade entre sistema e o mundo real”(1994e) sugerida por Jakob Nielsen. Esta compatibilidade busca associação dos elementos de uma interface humanocomputador aos objetos, termos, conhecimentos, etc., que fazem parte do cotidiano dos usuários.
A simplicidade, objetividade e logicidade dizem respeito à colocação do usuário como o mais ator central no processo para que o foco seja tentar responder às expectativas dos usuários e, dessa forma “falar a língua dos usuários” e “seguir convenções do mundo real, fazendo com que a informação apareça em uma ordem natural e lógica” (1994e).
A objetividade relacionada aos textos revela que os mesmos devem ser redigidos como as notícias, mensagens e informativos. Ao contrário de textos de pesquisa científica, devem seguir o modelo da pirâmide invertida, para que o texto comece com a conclusão, conforme apresenta Nielsen (1996b).
A simplicidade mostrouse importante em casos em que se procura reutilizar informações existentes e evitar a necessidade de que usuários se ocupem com extensos diálogos e extensas entradas de dados (NIELSEN, 1998a). Sob este aspecto também se encontram diretrizes que prezam pela confecção de diálogos simples, dado que “toda unidade de informação extra em um diálogo compete com as unidades de informação relevantes e reduzem sua visibilidade relativa” (1994e).
Também se tornou evidente a necessidade de fornecer meios para que usuários se locomovam livremente pelo sistema e que é necessário fornecer aos usuários uma “'saída de emergência' evidente para deixar um estado indesejado” (1994e).
Exemplo de diretriz válida e pertinente: Geração de dados automática. Quando dados rotineiros ou redundantes podem ser derivados pelo computador, apresente esses dados automaticamente para que o usuário possa revisálos, em vez de exigir o preenchimento pelo usuário.
•
Algarismos arábicos para itens numerados. Quando uma lista de itens for numerada, utilize algarismos arábicos em vez de romanos. Análise. Esta diretriz está parcialmente válida, pois dependendo dos usuários do sistema um modelo de algarismos pode ser mais indicado que outro para representar uma lista de 49 5 . 1 . A N Á L I S E D A S D I R E T R I Z E S
um dado assunto. Devese manter a numeração da lista compatível com a sua utilização fora do computador. Segundo Nielsen (1994e), “o sistema deveria falar a língua dos usuários”.
•
Itens numerados iniciando em 1. Quando linhas ou colunas são rotuladas com número, inicie a numeração com "1", em vez de "0". •
Justificação de dados alfabéticos. Mostre colunas de dados alfabéticos com justificação esquerda para permitir rápida visualização.
Análise. Estas duas diretrizes estão parcialmente válidas, porque o inicio da numeração com "0" ou com "1", ou a justificação à esquerda ou à direita, dependem do que eles representam. Devese rotular a tabela de acordo com as convenções dos dados nela contido no mundo real e justificar os dados de acordo com a orientação da linguagem do usuário. De acordo com uma das heurísticas de usabilidade de Jakob Nielsen, devese manter a “Compatibilidade entre sistema e o mundo real” (1994e).
•
Uso restrito de eixos descontínuos. Quando o interesse de comparação dos dados cai em um intervalo limitado, considere construir a escala dos eixos para enfatizar este intervalo, com uma quebra nos eixos apresentados para indicar descontinuidade com a origem da escala. Análise. Esta diretriz continua válida, pois é o que normalmente encontrase em gráficos com eixos cartesianos, em que não seria possível mostrar os dados do gráfico utilizando uma dada escala previamente escolhida. Neste ponto fazse uma marcação para indicar a descontinuidade no(s) eixo(s) que extrapolariam as dimensões da superfície e assim desenhar apenas a região de interesse. Segundo Jakob Nielsen, deve buscar a “Compatibilidade entre sistema e o mundo real” (1994e).
•
Paginando telas cheias. Quando uma tela contiver muitos dados para sua apresentação em um único quadro, particione os dados em páginas apresentáveis separadamente. Análise. Esta diretriz está parcialmente válida, porque a utilização da barra de rolagem é comum e por isso o limite de um quadro não é mais um limitador, porém ela busca manter o formato das telas o mais sucinto e objetivo quanto for possível. Segundo Jakob Nielsen (2000a), “usuários não gostam de páginas longas e com muita rolagem: eles preferem que o texto seja curto e que vá direto ao ponto”.
•
Número limitado de mensagens faladas. Limite a fala gerada pelo computador para fornecer somente algumas mensagens. Análise. Esta diretriz está parcialmente válida, porque se deve buscar compatibilidade com mundo real (NIELSEN, 1994e) e descrever precisamente os problemas (NIELSEN, 2001), C A P . V R E S U L T A D O S 50
mas com isso o sistema pode sobrecarregar o usuário com demasiada informação e se um design exige muito da memória dos usuários este será passível de erro (NIELSEN, 2003b).
5.1.8. Navegação
Esta seção se refere às diretrizes que reforçam a importância para que a interface com o usuário mantenhao sempre informado sobre qual é a sua posição e quais são seus possíveis destinos dentro de uma interface humanocomputador. Segundo Nielsen (2000a), “As interfaces de navegação precisam ajudar os usuários a responder às três perguntas fundamentais da navegação: Onde estou? Onde estive? Aonde posso ir?”.
Dessa forma, a contextualização do usuário dentro do sistema e de sua atual tarefa é fornecida, sem que o usuário sobrecarregue sua memória. A interface deve fornece as informações necessárias para a definição do contexto atual e assim permitir que o usuário consiga se locomover no sistema eficazmente (NIELSEN, 1997b).
Segundo Nielsen (2000c), ao se utilizar a navegação estrutural dáse o contexto que permite ao usuário interpretar melhor a página em que está (2000c). O autor também afirma que se deve “agrupar itens na área de navegação, de modo que os itens semelhantes fiquem próximos entre si” (NIELSEN; TAHIR, 2002). Ela também estipula que a estruturação adequada de navegação deve buscar “manter as opções visíveis sempre que for possível” (NIELSEN, 2004).
Sobre a navegabilidade do usuário acerca de um sistema computacional, a relação de parte das normas contidas nesta seção se deu pela relação com a disponibilidade de uma opção que possibilitasse ao usuário voltar um passo atrás. Dado que segundo Nielsen (1999a), “o botão VOLTAR é a linha vital do usuário da web e o segundo mais usado atributo de navegação (seguidos de links de hipertexto)”.
A clareza dos rótulos dos itens de navegação também é citada como sendo relevante nas normas a seguir e pelo autor estudado. Sobre título de link, ele afirma que seu objetivo “é ajudar os usuários a preverem o que vai acontecer se eles o seguirem” (NIELSEN, 1998b).
Exemplo de diretriz válida e pertinente: Contexto apresentado. Quando os resultados de uma entrada do usuário dependem do contexto estabelecido em entradas anteriores, apresente alguma indicação do contexto para o usuário.
•
Exiba o título no topo. Inicie cada tela com um título ou cabeçalho, descrevendo brevemente o conteúdo ou propósito da tela; deixe ao menos uma linha em branco entre o título e o corpo da tela. Análise. Ela possui duas abordagens: título da janela e título do conteúdo. No título de janela normalmente não é possível incluir espaço entre o conteúdo e ele, mas sobre a inclusão de uma descrição ela está válida. Jakob Nielsen e Marie Tahir (2002) apresentam na diretriz de número 75 do livro Homepage Usabilidade: 50 Websites Desconstruídos que se deve “Incluir uma descrição resumida do site no título da janela”. Mas, em relação ao 51 5 . 1 . A N Á L I S E D A S D I R E T R I Z E S
título do conteúdo, esta diretriz está parcialmente válida, porque atualmente contase com vários tamanhos de fonte; logo, a sugestão para a(s) linha(s) em branco entre o título e o corpo da tela não são mais necessárias, mas está correta ao afirmar que telas devem iniciar com seus títulos. Com isso é alcançado um dos pontos que uma interface de navegação deve auxiliar um usuário, a resposta à pergunta: “onde estou?”, conforme apresenta Jakob Nielsen (2000a).
•
Rótulo de identificação da tela. Quando um usuário selecionar exibições de dados, atribua a cada tela um rótulo identificador, isto é, um código alfanumérico ou abreviação que possa facilitar solicitações de tela do usuário. •
Rótulo de tela significativo. O rótulo de identificação da tela deveria ser único, curto, mas significante o suficiente para ser lembrado facilmente.
Análise. Estas duas diretrizes estão parcialmente válidas, porque segundo Nielsen (2005b), os usuários não se referem mais a telas específicas da mesma forma que faziam na época em que Smith e Mosier elaboraram as diretrizes, ou seja, através de códigos. O autor comenta que a diretiva atual seria fornecer um título que identifique rapidamente qual é o conteúdo de uma dada página (2005b).
•
Rotulando janelas. Quando um usuário pode selecionar sobreposições de janela predefinidas, atribua a cada sobreposição um rótulo identificador. Análise. Esta diretriz está parcialmente válida, porque em vez de identificar o rótulo deveria descrever as janelas. •
Indicando opções de controle apropriadas. Torne disponível aos usuários uma lista das opções de controle que são especificamente apropriadas para qualquer transação. Análise. Esta diretriz está parcialmente válida, porque atualmente os sistemas podem contar com uma lista muito grande de opções de controle possíveis, logo, devese disponibilizar a lista em questão desde que não polua a interface com o usuário; mas está certa no ponto que se devem apresentar ao usuário as opções que pode tomar (NIELSEN, 2000a).
5.1.9. Interfaces auditivas
As normas a seguir sugerem a utilização de interfaces auditivas para informar usuários sobre situações críticas, dado que sinais de áudio possuem maior alcance que uma mensagem apresentada na tela, e segundo Nielsen (1999d) “Esta propriedade faz com que sons sejam bons para alarmes”.
Sobre as características desse tipo de interfaces o autor afirma que o grande diferencial entre as interfaces auditivas e as visuais é que os ouvidos estão sempre capturando dados e que as interfaces visuais necessitam que o usuário esteja com os olhos direcionados à interface humano
computador, o que torna este tipo de interface bom para sistemas que comuniquem os usuários sobre situações críticas (por exemplo, alarmes em sistemas de monitoração). Contudo, “estes mesmos princípios do som o torna altamente importuno e intrusivo quando tocado em um ambiente com várias pessoas” (NIELSEN; TAHIR, 2002).
Em alguns casos essas interfaces são apenas para auxiliar a interface visual (NIELSEN; TAHIR, 2002), mas o autor ressalta sua importância dado que “em uma situação em que os usuários estejam com os olhos e mãos ocupadas. Se tiverem ou não deficiências, o combo teclado
mousemonitor falha nessas situações, como quando estiverem dirigindo carros ou consertamos equipamentos complexos” (NIELSEN, 2003c).
Por fim, a utilização das interfaces auditivas deve ser bem projetada, uma vez que sua má combinação pode ocasionar na perda dos usuários (NIELSEN 1993).
Exemplo de diretriz válida e pertinente: Sinais auditivos para alertar usuários. Durante entrada/edição de texto, forneça um sinal auditivo a qualquer hora que seja necessário chamar a atenção do usuário para a tela.
5.1.10. Gerenciamento de erro
As normas apresentadas a seguir contam com as seguintes vertentes: prevenir erros, auxiliar os usuários a identificarem os erros ocorridos e, por fim, corrigir eventuais erros.
Uma das formas de prevenção de erros é fornecer valores iniciais, uma vez que eles ajudam a reduzir erros, conforme apresenta Nielsen (2005f). Valores iniciais também auxiliam os usuários nesse aspecto por servirem como instrução de como preencher uma entrada de dados e servirem como retorno implícito, pois eles visualizam qual é o tipo de entrada esperada.
Nielsen apresenta que “usuários frequentemente escolhem funções erradas e necessitarão de uma 'saída de emergência' evidente para deixar um estado indesejado” (1994e). No auxílio fornecido aos usuários com o intuito de que identifiquem os erros, devese “eliminar condições passíveis de erro ou checálas e apresentar aos usuários uma opção de confirmação antes deles concluírem a ação” (1994e).
Dados que as mensagens devam ser “visíveis e altamente perceptíveis, tanto em termos da própria mensagem quanto como elas indicam qual elemento do diálogo os usuários precisam concertar” (NIELSEN, 2001), também devem oferecer ao usuário “Descrições precisas dos problemas, em vez de vagas generalizações como ’erro de sintaxe’ ” (NIELSEN, 2001). Nielsen (2001) enfatiza que as mensagens de erro devem ser curtas e diretas. Ele complementa que se devem utilizar expressões educadas na composição das mensagens de erro, de forma que o sistema não culpe os usuários, como ocorre nos casos em que o usuário efetua um comando que não é reconhecido pelo sistema e este, por sua vez, retorna para o usuário mensagens como "comando ilegal", por exemplo.
O autor sugere que “links de hipertexto podem ser utilizados para conectar uma mensagem de erro concisa a uma página com material adicional ou uma explicação do problema” (NIELSEN, 2001). O autor complementa que não se deve utilizar excessivamente este recurso.
Sobre a correção de erros, ele sugere oferecer ao usuário “conselho construtivo de como corrigir o problema” (NIELSEN, 2001). E com o intuito de facilitar a tarefa de correção de erros o autor sugere que se deve reduzir o trabalho de correção de erro e, caso seja possível, o sistema deve detectar as possibilidades de ações do usuário e deixar que o mesmo escolha uma dessas opções (NIELSEN, 2001). E complementa que se deve deixar “que usuários corrijam erros através da edição de suas ações originais em vez de ter que fazer tudo novamente” (2001).
Exemplo de diretriz válida e pertinente: Interrupção flexível. Quando múltiplos dados são enviados em uma única transação, como no preenchimento de um formulário, permita que o usuário reveja, cancele, ou faça um backup e altere qualquer item antes de efetuar a ação de envio.
•
Confirmação do usuário sobre alterações. Quando um usuário indicar a conclusão da edição de um documento, permita que o usuário confirme que as mudanças deveriam ser feitas ao documento original, ou então que escolha opções alternativas. Análise. Esta diretriz está parcialmente válida, porque atualmente encontramos a opção para salvar em outro documento como uma alternativa e a de sobrescrever o documento em edição como a opção padrão. Mas, está certa no ponto em que o usuário deve ter esta alternativa já que o enfoque é prevenir que alguma alteração indesejada seja feita ao documento original.
•
Mensagens de erro múltiplas. Quando múltiplas mensagens de erro são detectadas em uma entrada combinada feita pelo usuário, notifique o usuário, mesmo que as mensagens completas para todos os erros não possam ser apresentadas juntas. Análise. Esta diretriz se tornou obsoleta, porque segundo Jakob Nielsen (2001), mensagens de erro devem ser facilmente perceptíveis pelos usuários, tanto em termos da estruturação da mensagem de erro assim como indicar qual é o elemento do diálogo que necessita de correção.
•
Ajuda de múltiplos níveis. Quando uma tela inicial de ajuda fornece somente informação resumida, forneça explicações mais detalhadas em resposta à repetidas solicitações de ajuda feitas pelo usuário. C A P . V R E S U L T A D O S 54
Análise. Esta diretriz está parcialmente válida, uma vez que mudar a tela inicial de ajuda pode afetar a consistência. Mas está correta no ponto em que sugere que explicações mais detalhadas devem ser disponibilizadas ao usuário, porque segundo Nielsen (2001), links de hipertexto constituem uma forma de relacionar mensagens de erro e materiais que detalhem o problema ocorrido. O autor complementa que não se deve utilizar excessivamente este recurso.
•
Ação explícita para selecionar modos destrutivos. Exija que usuários executem uma ação explícita para selecionar qualquer modo operacional que possa resultar em perda de dados; o computador não deve estabelecer modos destrutivos automaticamente. Análise. Esta diretriz está parcialmente válida, porque segundo Nielsen, “Modos foram descartados pelo design moderno de interação”(2005b), mas está correta no ponto em que ações destrutivas devem ser confirmadas pelo usuário. Segundo Nielsen (2001), as condições que possam geram perda de dados devem ser verificadas pelo sistema, e caso sejam detectadas, devem apenas ser processadas após a confirmação do usuário.
•
Protegendo formatos de tela. Proteja atributos de formatação da tela, como rótulos de campos e delimitadores de campo, contra alteração acidental por parte dos usuários. Análise. Esta diretriz se tornou obsoleta, pois nos sistemas atuais os rótulos não são editáveis pelos usuários. Não utilizamse mais marcadores para representar campos de entrada de dados, conforme afirma Jakob Nielsen em artigo (2005b) onde analisou 60 das 944 diretrizes que compõe o trabalho objeto deste estudo.
5.1.11. Flexibilidade
As diretrizes desta seção estão ligadas à flexibilidade de entrada de comandos, entrada de dados e entradas de controle. Nielsen comenta que se deve “prover liberdade e controle ao usuário” (2000b).
A partir desta heurística delegase ao software a tarefa de normalização das entradas providas pelo usuário, uma vez que, devese permitir uma entrada de dados flexível (NIELSEN, 2005e), conforme afirma o autor em artigo onde enumera os 10 maiores erros de web design de 2005. E, em relação à entrada de comandos o autor sugere a inclusão de suporte a abreviações e comandos completos (NIELSEN, 2001b), assim como “permitir quantos sinônimos forem possíveis, e corrigir pequenos erros de digitação utilizando um verificador de ortografia” (NIELSEN, 2001b). Sobre entradas de controle o autor sugere que “usuários devem ser permitidos a suspender tarefas em direção ao seu objetivo para concluir a atividade mais tarde” (1994f).
Exemplo de diretriz válida e pertinente: Ponto decimal opcional. Permita a entrada opcional ou omissão do ponto decimal ao final de um número inteiro como alternativas equivalentes.
•
Mantendo itens de dados pequenos. Para códigos, números, etc., mantenha os campos pequenos, para que o comprimento de um item individual não exceda de 5 a 7 caracteres. Análise. Esta diretriz está parcialmente válida e o problema com ela está apenas no número de caracteres informado como limite. Isso ocorre porque dados como telefones, que atualmente já superam os 7 caracteres limitados na diretriz, são menos passíveis a erros quando recebem códigos de área, prefixo e número no mesmo campo(NIELSEN, 2005b). Atualmente em websites de bancos, os formulários para pagamento de contas contam com o número do boleto, que é relativamente grande e que normalmente é dividido em grupos menores.
•
Justificação automática das entradas. Forneça justificação automática para as estradas de dados em forma de tabela; um usuário não deveria ter que entrar com espaços ou estranhos caracteres de formatação para alcanças a justificação adequada. •
Justificação de entradas numéricas. Permita que os usuários concluam entradas numéricas em tabelas sem que tenham que se preocupar com a justificação; o computador deveria justificar números inteiros à direita, ou então justificar em relação ao ponto decimal se o mesmo estiver presente.
Análise. Estas duas diretrizes se tornaram obsoletas, porque nos sistemas atuais os usuários não conseguem justificar as entradas, dado que os projetistas tipicamente justificam os campos de entrada de dados de antemão(NIELSEN, 2005b).
•
Seleção do destino. Permita aos usuários especificarem o(s) destinatário(s) para qual(is) os dados serão transmitidos. Análise. Esta se tornou obsoleta, porque segundo Nielsen (2005b), em análise sobre diretriz relacionada à edição dos endereços de cabeçalhos, é pouco provável que haja projetistas de interface humanocomputador que elaborem campo de endereço não editável. 5.1.12. Listas
Esta seção comporta as normas relacionadas aos elementos estruturados em listas de elementos. O foco principal desta seção está em tornar fácil a identificação de um item contido em uma lista qualquer.
Na busca de um elemento, Nielsen (2003d) comenta que “uma das principais diretrizes de usabilidade para páginas de categorias é deixar que os usuários filtrem os itens de acordo com os atributos de interesse”. O autor qualifica esses filtros de atributos como sendo uma maneira efetiva de lidar com listas (NIELSEN, 2003d).
Por fim, sobre a organização de listas, o autor sugere que se deve fazêla de forma vertical, com opção por linha. E caso seja necessária uma lista horizontal devese cuidar para que o espaçamento entre os elementos deixe claro onde estão seus limites (NIELSEN, 2004).
Exemplo de diretriz válida e pertinente: Formato de lista em coluna única. Formate as listas para que cada item inicie em uma nova linha isto é, uma lista deveria ser apresentada como uma única coluna.
5.1.13. Sobrecarga da memória do usuário
As diretrizes classificadas a seguir buscam evitar que usuários necessitem lembrar de mais informações do que o necessário ou praticável, uma vez que a interface com o usuário auxiliálos nesse ponto. Nesse ponto o sistema poderia gravar informações que possam ser úteis ao usuário de forma que consultas futuras possam ser feitas.
Nielsen (2003b) apresenta que ao exigir que os usuários sem lembrem de muitas informações, a interação com o mesmo será passível de erro e difícil de usar, pois as pessoas normalmente se esquecem de algumas informações quando você sua a memória. Além das informações, as normas também se referem à sobrecarga da memória do usuário ao exigir que ele se lembre da formatação de certos dados, por exemplo, letras maiúsculas ou minúsculas em códigos.
De forma complementar, sobre dados codificados o autor comenta que não se devem misturar letras maiúsculas com minúsculas (NIELSEN, 1999e).
Exemplo de diretriz válida e pertinente: Questões exibidas separadamente. Em um diálogo de pergunta e resposta, apresente cada questão separadamente não exija que usuários respondam várias questões de uma vez.
5.1.14. Ícones
As diretrizes desta seção tratam da utilização de iconografia para reforçar ou facilitar o entendimento do significado desejado. Sobre a utilização destes elementos gráficos, Nielsen (1994c) comenta que eles “devem ser apresentados com rótulos para aumentar a habilidade dos usuários entendêlos”.
O autor apresenta que “ícones representando objetos são mais fáceis de entender do que ícones representado funções” (NIELSEN, 1994d) e que, para navegação entre idiomas diferentes, “o melhor símbolo visual para uma linguagem é provavelmente uma bandeira” (NIELSEN, 1996c). Porém, Jakob Nielsen e Marie Tahir (2002) informam que a utilização de ícones em navegação deve ser feita apenas se eles ajudarem os usuários a reconhecerem imediatamente uma classe de itens.
Exemplo de diretriz válida e pertinente: Menus iconográficos. Quando usuários do sistema possuem bases lingüísticas diferentes, considere fornecer menus gráficos no qual apresenta ícones para representar as opções de controle.
5.1.15. Poluição visual
As diretrizes contidas nesta seção dizem respeito exclusivamente à apresentação somente dos dados que forem úteis aos usuários. Nesse ponto Nielsen (2003a) conclui que devese escrever somente informações que os usuários realmente necessitem.
Sobre excesso de informações desnecessárias em diálogos entre o usuário e o sistema, o autor comenta que “diálogos não devem conter informações que sejam irrelevantes ou raramente necessárias. Toda unidade de informação extra em um diálogo compete com as unidades de informação relevantes e reduzem sua visibilidade relativa.” (NIELSEN, 1994e).
Exemplo de diretriz válida e pertinente: Somente dados essenciais apresentados. Reduza os dados apresentados de acordo com as necessidades do usuário, forneça somente dados necessários e imediatamente úteis para qualquer transação não sobrecarregue as telas com dados fora de contexto.
5.1.16. Encriptação
As diretrizes desta seção dizem respeito aos pontos em que a encriptação de dados são essenciais. Jakob Nielsen é categórico em relação ao assunto e afirma que “segurança e encriptação devem estar impregnadas: nenhuma informação no formato texto deveria em tempo algum cruzar a Internet; nem qualquer mensagem deveria ser enviada sem uma assinatura digital” (NIELSEN, 1999f). O autor comenta que aproximações atuais como PGP (Pretty Good Privacy) são difíceis de usar quando se trata do usuário médio. A segurança devia simplesmente acontecer sem que os usuários tivessem que configurar tal recurso (NIELSEN, 1999f).
Exemplo de diretriz válida e pertinente: Encriptação. Quando dados sensíveis podem ser expostos ao acesso não autorizado, forneça a capacidade para encriptar esses dados.
5.1.17. Acessibilidade e adaptação ao usuário
As normas apresentadas a seguir fazem referência à acessibilidade que o sistema deve possuir e de como este deve ser projetado de forma a se adaptar aos diferentes perfis de usuário, seja em relação às configurações dos periféricos ou do sistema.
Nielsen apresenta que se deve projetar com enfoque no significado em vez de apresentação da página, de modo que seja possível para usuários com necessidades especiais acessarem (1996d).
Em relação às tarefas de entradas de dados, não se deve exigir que usuários necessariamente troquem de um dispositivo para outro para concluir uma entrada de dados que possa ser efetuada em no dispositivo que está sendo manipulado. O autor também comenta que muitos usuários não conseguem efetuar movimentos detalhados utilizando o mouse e que também têm dificuldades em pressionar várias teclas simultaneamente (1996d). Dessa forma devese evitar a utilização de um único meio para a utilização de um sistema. Sob o mesmo aspecto o autor afirma que a utilização de teclas de acesso torna a seleção de opções mais rápida para usuários experientes e aumenta a acessibilidade (NIELSEN, 2004). Em formulários de entradas de dados devese manter a utilização padrão da tecla TAB, para alterar de um campo para outro, e da tecla ENTER, para enviar o formulário. Alcançando a consistência em relação ao uso geral destas teclas e impedindo que usuários troquem para outro dispositivo, do teclado para um dispositivo de apontamento e viceversa.
Sobre o tamanho de imagens, o autor também comenta que o sistema deve oferecer aos usuários meios para aumentar fotos para uma visualização mais próxima (NIELSEN, 2005e).
Um exemplo de adaptação ao usuário referese à tentativa de prever uma possível ação do usuário. Nielsen apresenta exemplos como a atribuição do foco do teclado ao primeiro campo quando o formulário for apresentado(NIELSEN, 2005e) e mecanismos de reutilização das informações de um tipo de cadastro unificado (NIELSEN, 1999g).
Em relação à configurabilidade desejada quando há adaptação ao usuário o autor comenta que os mesmos devem ser invisíveis para o usuário novato, para que o sistema possa suprir as necessidades de usuários experientes e inexperientes (NIELSEN, 1994e).
Ainda sobre a questão da flexibilidade em relação a como deve ser o funcionamento de um sistema para os usuários, complementa que se deve deixar que usuários trabalhem em diferentes partes de um problema na seqüência que fizer sentido a eles (NIELSEN, 2005d).
Eventos decorridos de ações não solicitadas pelos usuários devem ser configuráveis conforme apresentam Nielsen e Marie Tahir (2002). Segundo os autores, o recarregamento automático de uma página web pode parecer abusivo e resulta em problema quando o local que estava sendo utilizado pelo usuário desapareceu ou mudou de posição após esta ação (NIELSEN; TAHIR, 2002) Um exemplo do controle de atualização desejável nesses casos é o fornecido por software de caixa email em que é possível configurar o intervalo de verificação de novas mensagens.
Exemplo de diretriz válida e pertinente: Facilidade ou dificuldade apropriada para ações do usuário. Assegure que a facilidade das ações do usuário será compatível com os fins desejados torne ações freqüentes ou urgentes fáceis de serem executadas, mas faça com que ações potencialmente destrutíveis exijam atenção extra por parte do usuário.
•
Área de apontamento grande para seleção de opção. Na seleção de alternativas, projete uma área aceitável para apontamento (isto é, posicionamento do cursor) para ser tão grande quanto consistentemente possível, incluindo ao menos a área do rótulo apresentado mais meio caractere de distância em volta do rótulo. Análise. Esta diretriz está parcialmente válida, uma vez que a referência da área selecionável ao rótulo é vaga e, caso seja fixa, pode não ser ideal para todos os usuários. Se os rótulos estiverem projetados em tamanho pequeno, muitos usuários terão problemas em selecionálos, pois segundo Nielsen (2002), “botões de comando e outros objetos de interação [...] precisam ser razoavelmente grandes e fáceis de clicar”.
•
Apresentação dos dados controlada pelo usuário. Permita aos usuários controlarem a quantia, formato, e complexidade dos dados apresentados conforme for necessário para se adequar às necessidades de uma tarefa. Análise. Esta diretriz está parcialmente válida, pois nos sistemas atuais não é comum que o usuário tenha este controle sobre a apresentação dos dados. Talvez a aplicação fosse ampliada caso ela propusesse não bloquear o controle padrão que os usuários possuem sobre os dados apresentados. A diretriz de número 100 do livro Homepage Usabilidade: 50 Websites Desconstruídos, de Jakob Nielsen e Marie Tahir (2002) mostra que "É melhor se concentrar nos recursos que virão com uma estrutura mais eficiente, mais legível para o maior número de usuários. Entretanto, respeite as preferências do navegador dos usuários, como tamanho de fonte, usando tamanhos relativos em vez de absolutos".
•
Tamanho de janela adequado. Quando uma janela precisa ser utilizada para a visualização de dados, assegure que ela possa apresentar mais de uma linha de dados. Análise. Esta diretriz se tornou obsoleta, porque atualmente até dispositivos móveis como celulares, por exemplo, apresentam mais de uma linha de texto, e segundo Nielsen (2000a), a maioria dos usuários da web utiliza a resolução de 800x600. Logo, não se faz mais necessário o aviso referente à necessidade de apresentação de mais de uma linha de dados.
•
Área de apontamento grande para seleção de opção. Se a seleção do menu é alcançada através de apontamento, como em telas de toque. Na seleção de alternativas, projete uma área aceitável para apontamento para ser tão grande quanto consistentemente possível, incluindo ao menos a área do rótulo apresentado mais meio caractere de distância em volta do rótulo. Análise. Esta diretriz está parcialmente válida, uma vez que a referência da área de seleção ao rótulo é vaga e, caso seja fixa, pode não ser ideal para todos os usuários. Se os rótulos estiverem projetados em tamanho pequeno, muitos usuários terão problemas em selecioná
los (NIELSEN, 1996d) O autor também afirma que “botões de comando e outros objetos de interação [...] precisam ser razoavelmente grandes e fáceis de clicar” (2002).
•
Posicionamento automático do cursor. Na apresentação de menus separados (isto é, para menus não inclusos na exibição dos dados), quando a seleção de menus é através de apontamento o computador deveria posicionar o cursor automaticamente na primeira opção listada; quando a seleção de menu é por entrada de código, posicione o cursor na área de entrada de comando. Análise. Esta diretriz está parcialmente válida, uma vez que o apontamento automático deve estar sob o comando do usuário, ou seja, deve ser habilitado apenas sob o comando do usuário, mas está correta no ponto em que sugere que se deve colocar o foco do cursor no primeiro campo de entrada. Nielsen (2005e) sugere que o foco do cursor deve ser atribuído ao primeiro campo de entrada de um formulário, uma vez que isso economizará um clique do usuário.
•
Teclas simples para funções freqüentes. Teclas que controlam funções freqüentemente utilizadas devem permitir simples ativação de tecla e não devem exigir combinações (control/shift) de teclas. Análise. Esta diretriz está parcialmente válida, uma vez que “muitos sistemas modernos possuem tantas funções continuamente disponíveis que exigiria mais teclas de função que o teclado possui” (2005b), mas sempre que for possível devemse manter as funções mais utilizadas mais facilmente acessíveis aos usuários.
5.1.18. Ajuda
As diretrizes seguintes referemse às formas de como o sistema deve auxiliar seus usuários. Nielsen comenta que o ideal é que sistemas possam ser utilizados sem documentação, porém, há casos em que a utilização desde recurso se faz necessária. Além disso, qualquer informação de orientação deve ser objetiva e focada na tarefa do usuário (NIELSEN, 1994e).
Porém, em relação aos websites, o autor comenta que quando estes necessitam de um sistema de ajuda normalmente são fracassados, ou seja, não obtém êxito em sua função (NIELSEN, 2000d). Nielsen juntamente com Marie Tahir (2002) comentam que se as tarefas em questão são complexas, um mecanismo de ajuda ou previsão para que o usuário possa lidar com novos resultados, a utilização de ajuda é justificável.
Exemplo de diretriz válida e pertinente: Tela de previsão. Para auxiliar um usuário a entender e responder efetivamente a complexas atualizações de dados, considere apresentar uma previsão dos estados de dados futuros baseados em análise computadorizada de um modelo apropriado da dinâmica dos dados.
•
Dicionário de abreviações. Se as abreviações forem usadas, forneça um dicionário de abreviações disponível para consulta online. 61 5 . 1 . A N Á L I S E D A S D I R E T R I Z E S
Análise. Esta diretriz se tornou obsoleta, uma vez Nielsen e Tahir (2002) sugerem que ajuda não deve ser oferecida a não ser que a complexidade a torne inevitável.
•
Dicionário de abreviações. Forneça um dicionário completo de abreviações utilizado para entrada de dados, apresentação de dados, e entrada de comando, para referência online para o usuário e na documentação do projeto. Análise. Esta diretriz se tornou obsoleta, pois compartilha da mesma justificativa relacionada à diretriz anterior. Nielsen e Tahir (2002) comentam que um sistema de ajuda deve ser fornecido apenas quando a complexidade do sistema a torne inevitável.
5.1.19. Gráficos e animações
As normas comentadas nesta seção dizem respeito à elaboração de gráficos, seja em duas ou em três dimensões. Sobre a utilização de gráficos tridimensionais, Nielsen comenta que “a má resolução de tela impossibilita a renderização de objetos remotos com detalhes suficientes para serem reconhecíveis; qualquer texto no fundo é ilegível”(2000a).
Segundo Nielsen (1999a), gráficos devem ser mantidos de forma que sua análise seja fácil e que a ordenação dos dados nele contidos seja natural. Para a análise de detalhes de imagens, o autor comenta que o sistema deve oferecer aos usuários meios para aumentar imagens para uma visualização mais próxima (2005e).
Exemplo de diretriz válida e pertinente: Uso restrito de escala tridimensional. Considere a escala tridimensional, onde o eixo Z é adicionado à tela, somente em aplicações especiais para usuários experientes.
5.2. Resultados das classificações
A partir das 60 diretrizes já analisadas por Nielsen (2005b), conseguiuse estabelecer ligações que demonstravam a validade, os pontos que deveriam sofrer atualizações e a obsolescência, de mais 462 diretrizes, o que resulta em 55% do total das diretrizes de Smith e Mosier (Figura 5.1).
Diretrizes de usabilidade de Smith e Mosier
6,36%
Cobertas pela presente pesquisa
Não cobertas pela presente pesquisa
48,94%
44,70%
Analisadas por Nielsen
Figura 5.1. Percentagem de Diretrizes avaliadas que compõem o projeto de Smith e Mosier
A percentagem de diretrizes categorizadas como válidas e relevantes que se esperava obter em relação às especificidades da web era de cerca de 70%, porém o resultado superou as expectativas e atingiu 87% das normas avaliadas. Já as obsoletas alcançaram apenas 3% desse conjunto (Figura 5.2).
Diretrizes de usabilidades avaliadas
3,00%
10,00%
Válidas e relevantes
Parcialmente válidas
Obsoletas
87,00%
Figura 5.2. Percentagem de validade e relevância das diretrizes
63 5 . 2 . R E S U L T A D O S D A S C L A S S I F I C A Ç Õ E S
A hipótese elaborada no início da pesquisa era de que mais de 90% das diretrizes avaliadas continuariam válidas. Por válida entendese a soma das diretrizes categorizadas como válidas e relevantes com as categorizadas como parcialmente válidas. O resultado final não somente confirmou como sobrepujou as expectativas, pois se verificou que 97% das diretrizes continuam em vigor mesmo após 20 anos (Figura 5.3). Resultado da avaliação das diretrizes
3,00%
Válidas
Obsoletas
97,00%
Figura 5.3. Relação das diretrizes válidas e obsoletas
Ao final da análise foi possível confirmar a veracidade da afirmação de Nielsen (2005a), em que relata que as diretrizes que possuem durabilidade maior, ou seja, continuam pertinentes ao longo das mudanças ocorridas na forma de se projetar uma interface humanocomputador, tendem a ser menos específicas em relação à tecnologia utilizada em uma interface com o usuário. Ele complementa que essas normas são mais duráveis, pois descrevem o comportamento humano, o qual muda lentamente.
C A P . V I C O N C L U S Õ E S E T R A B A L H O S F U T U R O S 64
Cap. VI – Conclusões e trabalhos futuros
A ampliação do escopo da análise realizada por Nielsen e a busca de uma aproximação mais precisa em relação à percentagem de validade de diretrizes elaboradas em 1986 constituem objetivos alcançados por esta pesquisa. A partir disso, podese afirmar que, apesar da aparente simplicidade, elas continuam constituindo, mesmo após 20 anos, uma base adequada para o projeto de elaboração de uma interface humanocomputador fácil de usar, pois evitam erros recorrentes nessa etapa de projeto de sistemas.
A classificação das diretrizes, que foi o núcleo do presente estudo, se baseou unicamente no trabalho de Jakob Nielsen. Neste ponto, propõese como trabalho futuro o refinamento do resultado obtido através de estudos de bibliografias complementares vinculadas à interação humano
computador que permitam a comprovação da categorização das diretrizes não cobertas por este trabalho, ou seja, o conjunto de 422 diretrizes de usabilidade de interfaces humanocomputador.
De maneira complementar, propõese como trabalho futuro uma análise das diretrizes que compõe os resultados desta pesquisa tendo em vista uma mudança paradigmática das interfaces para um modelo que trate exclusivamente de interfaces tridimensionais. Dessa forma, poderia ser feita uma análise em relação à durabilidade das diretrizes estudadas após uma grande mudança no que diz respeito ao paradigma utilizado.
Outro ponto revelado neste trabalho é que o contexto de desenvolvimento de interface para a Web deve considerar o UCD (design centrado no usuário), ou seja, todos seus elementos devem derivar do ponto de vista do usuário. E com isso fazer com que o produto seja adequado aos usuários, e não obrigar os usuários a se adequarem ao produto. Uma das formas de se garantir que um produto tenha um UCD adequado é a utilização de testes de usabilidade (RUBIN, 1994).
No princípio desta pesquisa sugeriuse a elaboração de um site onde seriam feitos testes de usabilidade relacionados a um conjunto das diretrizes que não tivessem sido relacionadas aos textos de Nielsen e contassem com análises do autor da presente pesquisa. Porém, notouse ao longo da elaboração das tarefas e cenários dos testes de usabilidade, que objetivariam a validação das classificações feitas pelo autor deste projeto, seriam demasiadamente tendenciosas. Por este motivo esta parte da pesquisa foi retirada do escopo do projeto para que o resultado obtido não fosse invalidado por dados inconsistentes. Propõese, também, como trabalho futuro a relação das diretrizes não classificadas com resultados de testes de usabilidade e que essa ligação seja feita de forma que não se encontre nenhuma tendência.
65 7. 1 . R E F E R Ê N C I A S B I B L I O G R Á F I C A S
Cap. VII Referências, Anexos
7.1. Referências Bibliográficas
DIAS, Cláudia (2002) "Usabilidade na Web: Criando Portais Mais Acessíveis", Alta Books. December 2005 Web Server Survey. Netcraft. 1 Dez. 2005. Disponível na Internet em: http://news.netcraft.com/archives/2005/12/index.html. Acesso em: 08 jan 2006.
GAMMA, E. et al. (1995) “Design Patterns: Elements of Reusable ObjectOriented Software”, Reading, AddisonWesley.
INTERNATIONAL STANDARD ORGANIZATION (ISO) “Ergonomic requirements for office work with display terminals (VDTs). Part 11: Guidance on usability”. Genève, 1998x.
INTERNET USAGE STATISTICS The Big Picture. Internet World Stats Usage and Population Statistics. 31 Dez. 2005. Disponível na Internet em: http://www.internetworldstats.com/stats.htm. Acesso em: 08 jan 2006.
NIELSEN, Jakob. (2005a) Durability of Usability Guidelines. Disponível na Internet em: http://www.useit.com/alertbox/20050117.html. Acesso em 17 jan 2005.
______. (2005b) Sixty Guidelines From 1986 Revisited. Disponível na Internet em: http://www.useit.com/alertbox/20050117_guidelines.html. Acesso em 28 out 2005.
______. (2005c) Weblog Usability: The Top Ten Design Mistakes. Disponível na Internet em: http://www.useit.com/alertbox/weblogs.html. Acesso em 15 jan 2006.
______. (2005d) Forms vs. Applications.
Disponível na Internet em: http://www.useit.com/alertbox/forms.html. Acesso em 03 nov 2005.
______. (2005e) Top Ten Web Design Mistakes of 2005. Disponível na Internet em: http://www.useit.com/alertbox/designmistakes.html. Acesso em 05 nov 2005.
______. (2005f) The Power of Defaults.
Disponível na Internet em: http://www.useit.com/alertbox/defaults.html. Acesso em 20 dez 2005.
______. (2004) Checkboxes vs. Radio Buttons. Disponível na Internet em: http://www.useit.com/alertbox/20040927.html. Acesso em 18 jan 2006.
______.
(2003a) Information Pollution.
Disponível na
http://www.useit.com/alertbox/20030811.html. Acesso em 22 dez 2005.
Internet
em: ______. (2003b) Misconceptions About Usability.
Disponível na Internet em: http://www.useit.com/alertbox/20030908.html. Acesso em 14 jan 2006.
______. (2003c) Voice Interfaces: Assessing the Potential. Disponível na Internet em: http://www.useit.com/alertbox/20030127.html. Acesso em 02 fev 2006.
______. (2003d) Top Ten Web Design Mistakes of 2003. Disponível na Internet em: http://www.useit.com/alertbox/20031222.html. Acesso em 27 dez 2005.
______. (2002) Usability for Senior Citizens.
______. (2001a) Error Message Guidelines.
Disponível na Internet em: http://www.useit.com/alertbox/20010624.html. Acesso em 22 dez 2005.
______. (2001b) Deferred Hypertext: The Virtues of Delayed Gratification. Disponível na Internet em: C A P . V I I R E F E R Ê N C I A S , A N E X O S 66
http://www.useit.com/alertbox/20010930.html. Acesso em 23 jan 2006.
NIELSEN, Jakob. (2000a) Projetando Websites. Rio de Janeiro: Elsevier.
______. (2000b) Reset and Cancel Buttons.
Disponível na Internet em: http://www.useit.com/alertbox/20000416.html. Acesso em 05 nov 2005.
______.
(2000c) Is Navigation Useful?
Disponível http://www.useit.com/alertbox/20000109.html. Acesso em 22 dez 2005.
na
Internet
em: ______. (2000d) Novice vs. Expert Users.
______, Jakob. (1999a) The Top Ten New Mistakes of Web Design. Disponível na Internet em: http://www.useit.com/alertbox/990530.html. Acesso em 17 dez 2005.
______. (1999b) Do Interface Standards Stifle Design Creativity? Disponível na Internet em: http://www.useit.com/alertbox/990822.html. Acesso em 22 dez 2005.
______. (1999c) "Top Ten Mistakes" Revisited Three Years Later. Disponível na Internet em: http://www.useit.com/alertbox/990502.html. Acesso em 5 jan 2006.
______. (1999d) Readers' Comments on the new Top10 Design Mistakes. Disponível na Internet em: http://www.useit.com/alertbox/990530_comments.html. Acesso em 16 dez 2005.
______. (1999e) URL as UI. Disponível na Internet em: http://www.useit.com/alertbox/990321.html. Acesso em 15 dez 2005.
______. (1999f) UserSupportive Internet Architecture. Disponível na Internet em: http://www.useit.com/alertbox/990919.html. Acesso em 19 fev 2006.
______. (1999g) Web Research: Believe the Data. Disponível na Internet em: http://www.useit.com/alertbox/990711.html. Acesso em 15 dez 2005.
______. (1998a) Readers' Comments on the Reputation Manager. Disponível na Internet em: http://www.useit.com/alertbox/980208_comments.html. Acesso em 21 dez 2005.
______. (1998b) Using Link Titles to Help Users Predict Where They Are Going. Disponível na Internet em: http://www.useit.com/alertbox/980111.html. Acesso em 20 jan 2006.
______. Be Succinct! (Writing for the Web). (1997a) Disponível na Internet em: http://www.useit.com/alertbox/9703b.html. Acesso em 01 fev 2006.
______. How Users Read on the Web. (1997b) Disponível na Internet em: http://www.useit.com/alertbox/9710a.html. Acesso em 23 dez 2005.
______. (1996a) Original Top Ten Mistakes in Web Design. Disponível na Internet em: http://www.useit.com/alertbox/9605a.html. Acesso em 6 jan 2006.
______. (1996b) Inverted Pyramids in Cyberspace. Disponível na Internet em: http://www.useit.com/alertbox/9606.html. Acesso em 23 dez 2005.
______. (1996c) International Web Usability.
______. (1996d) Accessible Design for Users With Disabilities. Disponível na Internet em: http://www.useit.com/alertbox/9610.html. Acesso em 15 dez 2005.
______. (1994a) Guerrilla HCI: Using Discount Usability Engineering to Penetrate the Intimidation Barrier. Disponível na Internet em: http://www.useit.com/papers/guerrilla_hci.html. Acesso em 5 jan 2006.
67 7. 1 . R E F E R Ê N C I A S B I B L I O G R Á F I C A S
______. (1994b) Response Times: The Three Important Limits. Disponível na Internet em: http://www.useit.com/papers/responsetime.html. Acesso em 02 nov 2005.
NIELSEN, Jakob. (1994c) 1994 Design of SunWeb Sun Microsystems' Intranet. Disponível na Internet em: http://www.useit.com/papers/sunweb/. Acesso em 25 jan 2006.
______.
(1994d) CHI94 Trip Report.
Disponível na http://www.useit.com/papers/tripreports/chi94.html. Acesso em 28 dez 2005.
Internet
em: ______. (1994e) Ten Usability Heuristics.
Disponível na Internet em: http://www.useit.com/papers/heuristic/heuristic_list.html. Acesso em 17 dez 2005.
______. (1994f) Goal Composition: Extending Task Analysis to Predict Things People May Want to Do. Disponível na Internet em: http://www.useit.com/papers/goalcomposition.html. Acesso em 13 fev 2006.
______. (1993) Noncommand User Interfaces.
Disponível na Internet em: http://www.useit.com/papers/noncommand.html. Acesso em 15 dez 2005.
NIELSEN, Jakob; MORKES, John. (1997) Concise, SCANNABLE, and Objective: How to Write for the Web. Disponível na Internet em: <http://www.useit.com/papers/webwriting/writing.html>. Acesso em 23 dez 2005.
NIELSEN, Jakob; TAHIR, Marie. (2002) Homepage Usabilidade: 50 Websites Desconstruídos. Rio de Janeiro: Campus. p. 141.
ROCHA, Heloisa Vieira da, BARANAUSKAS Maria Cecilia C. (2003) "Design e Avaliação de Interfaces HumanoComputador", Campinas, NIED/UNICAMP.
RUBIN, Jeffrey (1994) "Handbook Of Usability Testing: How to plan, design, and conduct effective tests", EUA, New York, John Wiley & Sons Inc.
SHALLOWAY, Alan; TROTT, James R. (2004) "Explicando Padrões de Projeto: Uma Nova Perspectiva em Projeto Orientado a Objeto", Brasil, São Paulo, Artmed Editora S.A.
SHNEIDERMAN, Ben. (1998) Desingning the User Interface: Strategies for Effective HumanComputer Interaction. Third Edition, Addison Wesley Longman, Inc.. p. 5361. SMITH, Sidney; L. MOSIER, Jane N. (1986) "Guidelines For Designing User Interface Softwared", Disponível na Internet em: http://www.hcibib.org/sam/. Acesso em 17 jan 2005.
WALSH, Norman; MUELLNER, Leonard (2005) "DocBook: The Definitive Guide", Disponível na Internet em: http://www.docbook.org/tdg/en/html/docbook.html. Acesso em 13 mai de 2005.
C A P . V I I R E F E R Ê N C I A S , A N E X O S 68
7.2. Bibliografia Complementar
MILES, Matthew B.; HUBERMAN, A. Michael. “Qualitative data analysis: an expanded sourcebook”.
NIELSEN, Jakob. Search: Visible and Simple. Disponível na Internet em: http://www.useit.com/alertbox/20010513.html. Acesso em 16 dez 2005.
______. Intranet Usability: The TrillionDollar Question. Disponível na Internet em: http://www.useit.com/alertbox/20021111.html. Acesso em 19 dez 2005.
______. Impact of Data Quality on the Web User Experience. Disponível na Internet em: http://www.useit.com/alertbox/980712.html. Acesso em 20 dez 2005.
______. Medical Usability: How to Kill Patients Through Bad Design. Disponível na Internet em: http://www.useit.com/alertbox/20050411.html. Acesso em 21 dez 2005.
______. Ten Best Government Intranets.
______. Changes in Web Usability Since 1994. Disponível na Internet em: http://www.useit.com/alertbox/9712a.html. Acesso em 28 dez 2005.
______. When Bad Design Elements Become the Standard. Disponível na Internet em: http://www.useit.com/alertbox/991114.html. Acesso em 5 jan 2006.
______. Guidelines for Visualizing Links.
______. Predictions for the Web in 1999.
______. Weblog Usability: The Top Ten Design Mistakes. Disponível na Internet em: http://www.useit.com/alertbox/weblogs.html. Acesso em 15 jan 2006.
______. DropDown Menus: Use Sparingly.
______. Ten Good Deeds in Web Design.
______. Supporting MultipleLocation Users.
______. Supporting MultipleLocation Users.
______. Deceivingly Strong Information Scent Costs Sales. Disponível na Internet em: http://www.useit.com/alertbox/20040802.html. Acesso em 31 jan 2006.
______. LowEnd Media for User Empowerment. Disponível na Internet em: http://www.useit.com/alertbox/20030421.html. Acesso em 13 fev 2006.
______. Goal Composition: Extending Task Analysis to Predict Things People May Want to Do. Disponível na Internet em: http://www.useit.com/papers/goalcomposition.html. Acesso em 13 fev 2006.
______. In Defense of Print. Disponível na Internet em: http://www.useit.com/alertbox/9602.html. Acesso em 18 fev 2006.
______.
Security
&
Human
Factors.
Disponível
na
Internet
em: 69 7. 2 . B I B L I O G R A F I A C O M P L E M E N T A R
http://www.useit.com/alertbox/20001126.html. Acesso em 28 fev 2006.
STAYTON, Bob. “DocBook XSL: The Complete Guide”. Disponível na Internet em: http://www.sagehill.net/docbookxsl/. Acesso em 13 maio 2005.
The Apache XML Project XalanJava. Disponível na Internet em: http://xml.apache.org/xalanj/. Acesso em 20 out 2005.
Anexo I. Diretrizes Válidas e Pertinentes Abaixo são apresentadas de forma estruturada as diretrizes analisadas que permanecem válidas e pertinentes aos atuais projetos de interface humanocomputador.
Diretrizes analisadas por Jakob Nielsen
•
Marcar campos opcionais e obrigatórios. No projeto de formulários, diferencie claramente e consistentemente campos obrigatórios de opcionais.
•
Tabulação explicita para campos de dados. Deixe que usuários executem uma ação explicita de teclar ("tabular") para mover o foco de um campo para o próximo; o computador não deve fornecer a tabulação automaticamente.
•
Formato de rótulos consistente. Quando campos são distribuídos em uma tela, adote um formato consistente para relacionar os rótulos às áreas de entrada de dados.
•
Rótulos informativos. Ao rotular os campos de entrada de dados utilize textos descritivos, ou então padronizados, termos predefinidos, códigos e/ou abreviações; evite códigos arbitrários.
•
Pontuação do rótulo como uma marcação da entrada de dados. O rótulo de cada campo de entrada deve terminar com um símbolo especial, significando que a entrado pode ser feita.
•
Dicas do formato dos dados nos rótulos. Inclua em um rótulo uma dica adicional do formato dos dados quando isso parecer ajudar.
•
Rotulando unidades de medida. Quando uma unidade de medida é associada consistentemente com um campo, coloquea como sendo parte do rótulo do campo em vez de exigir que o usuário a inclua.
•
Repetindo apresentação de dados cíclicos. Quando curvas representam dados cíclicos, considere estender o gráfico para repetir porções incompletas do ciclo apresentado.
•
Apresentação direta de diferenças. Quando usuários precisam avaliar a diferença entre dois conjuntos de dados, plote esta diferença diretamente como uma curva à direita, em vez de exigir que os usuários comparem visualmente as curvas que representam os conjuntos de dados originais.
•
Gráficos de superfície. Quando curvas representam partes de um todo, considere utilizar um gráfico de superfície no qual curvas são empilhadas uma sobre outras para representar quantias agregadas, e as áreas definidas abaixo das curvas são texturizadas ou sombreadas.
71 A N E X O I . D I R E T R I Z E S V Á L I D A S E P E R T I N E N T E S
•
Ordenando dados em um gráfico de superfície. Ordene as categorias de dados em um gráfico de superfície para que as curvas das menores variáveis sejam mostradas na parte de baixo e as curvas das maiores variáveis sejam mostradas no topo.
•
Rotulando gráficos de superfície. Onde o espaço permitir, rotule as áreas diferentes do gráfico de superfície diretamente nas faixas texturizadas ou sombreadas.
•
Curvas cumulativas. Considere curvas cumulativas para mostrar o total atual em qualquer ponto; mas não conte com as curvas cumulativas para mostrar efetivamente a quantidade alterada em qualquer ponto.
•
Gráficos de barra. Considere gráficos de barra, onde as quantidades numéricas são representadas por uma extensão linear de barras paralelas, para comparar uma simples medida através de um conjunto de várias entidades ou para uma amostra de uma variável em intervalos discretos.
•
Histogramas. Considere histogramas, gráficos de barras sem espaço entre as barras, quando houver muitas entidades ou intervalos a serem plotados.
•
Direção consistente das barras. Em uma série de gráficos de barras relacionados, adote uma orientação consistente de barras apresentando informação similar, na vertical ou horizontal.
•
Espaçamento de barra. Distancie barras adjacentes o suficiente para que uma comparação visual direta possa ser feita sem movimento dos olhos.
•
Lógica consistente para teclas combinadas. Se combinações (control/shift) de teclas são usadas, a relação lógica entre as funções com e sem shift acionado deve ser consistente de uma tecla para outra.
•
Retorno para ativação de tecla de função. Quando ativação de uma tecla de função não resulta em nenhuma resposta imediatamente observável, forneça aos usuários alguma outra forma de reconhecimento por parte do computador.
•
Retorno para solicitações de impressão. Quando a solicitação do usuário para uma saída impressa for manipulada por uma impressora remota, dê ao usuário uma mensagem de aviso confirmando que o pedido de impressão começou e está sendo processado.
•
Retorno para entradas de controle. Forneça alguma indicação do status da transação toda hora que a resposta de conclusão para o usuário for adiada.
•
Retorno para interrupção feita pelo usuário. Após a interrupção do processamento de dados, apresente uma mensagem de aviso assegurando o usuário de que o sistema retornou para o status anterior.
•
Indicando teclas de função ativas. Se algumas teclas de função estão ativas e outras não, indique no subconjunto corrente de teclas ativas através de alguma forma fácil de notar, talvez por uma iluminação mais brilhante.
•
Desativar teclas de função desnecessárias. Quando teclas de função não são necessárias para qualquer transação corrente, desabilite temporariamente essas teclas sob 73 A N E X O I . D I R E T R I Z E S V Á L I D A S E P E R T I N E N T E S
o controle do computador; não exija que os usuários aplique nenhum revestimento mecânico para este propósito.
•
Indicando a conclusão do processamento. Quando o processamento de uma entrada do usuário for atrasado, informe ao usuário quando o processamento for concluído, e forneça orientação apropriada para futuras ações do usuário.
•
Atribuição consistente de teclas de função. Se uma função é atribuída a uma tecla especial em uma transação, atribua essa função à mesma tecla em outras transações.
•
Funções consistentes em diferentes modos de operação. Quando uma tecla de função realiza funções diferentes de modos operacionais diferentes, atribua funções equivalentes ou similares à mesma tecla.
•
Retorno fácil às funções de base. Se funções atribuídas a conjuntos de teclas mudam como um resultado de seleção por parte do usuário, dê aos usuários meios fáceis de retornar às iniciais, funções de base.
•
Localização distinta. Agrupe teclas de função em locais distintos no teclado para facilitar seu aprendizado e uso; posicione teclas de funções freqüentemente utilizadas nas posições mais convenientes.
•
Identificando telas de múltiplas páginas. Quando listas ou tabelas de dados se estendem além da capacidade de um simples frame da tela, informe o usuário de que a tela continua em múltiplos frames.
•
Indicando a seleção de item. Quando um usuário seleciona um item apresentado com o intuito de executar alguma operação nele, destaque esse item na tela.
•
Mensagens de erro informativas. Quando o computador detecta um erro de entrada, apresente uma mensagem de erro para o usuário declarando o que está errado e o que pode ser feito sobre ele.
•
Listas informais de distribuição. Permita aos indivíduos ou grupos criarem suas próprias listas informais de distribuição para uso local.
•
Listas dentro de listas. Dentro de uma lista de distribuição, permita que o usuário inclua outras listas de distribuição assim como nomes de indivíduos.
•
Modificando listas de distribuição. Forneça auxílio por parte do computador para permitir que usuários modifiquem listas de distribuição já criadas.
•
Expansão automática de endereços parciais. Permita que usuários preencham um nome parcialmente quando estiver especificando endereços, se aquele irá identificar um destino único.
•
Checagem automática de endereço. Forneça checagem por parte do computador para precisão de endereço (isto é, conteúdo e formato reconhecidos) e exija que o usuário corrija erros antes de iniciar a transmissão da mensagem.
•
Endereçando respostas para mensagens recebidas. Se um usuário deseja responder uma mensagem, forneça o(s) endereço(s) apropriado(s) automaticamente, junto com uma referência para aquela mensagem recebida.
•
Apresentação única de endereço. Assegure que o endereço de qualquer destinatário será apresentado somente uma vez na mensagem.
•
Distribuição em série. Em aplicações que exigem revisão coordenada das mensagens por vários destinatários, permita que o remetente especifique a distribuição em série para que a mensagem seja passada de um destinatário para o próximo.
•
Logon fácil. Projete o processo de logon e procedimentos para identificação do usuário para que seja tão simples quanto possível e consistente com proteção de dados contra uso não autorizado.
•
Sugestão de logon. Projete o processo de logon para fornecer sugestões para todas as entradas a serem feitas pelo usuário, incluindo senhas e/ou qualquer que sejam os outros dados exigidos para confirmar a identidade do usuário e autorizar os privilégios apropriados de acesso ou alteração dos dados.
•
Escolha de senha feita pelo usuário. Quando senhas são exigidas, permita que usuários escolham sua própria senha.
•
Alteração de senha. Permita aos usuários alterar sua própria senha a qualquer momento.
•
Preenchimento de senha privado. Quando uma senha precisa ser preenchida por um usuário, assegure que o preenchimento possa ser privado; entradas de senha não devem ser exibidas.
•
Limitação de tentativas de logon mal sucedidas. Imponha um limite máximo para o número e freqüência de tentativas de logon mal sucedidas que irão fornecer uma margem para erro do usuário enquanto protegem o sistema de tentativas de acesso ilegítimo.
•
Testes auxiliares para autenticar a identidade do usuário. Quando um sistema de segurança exige identificação do usuário mais severa do que é fornecida pelo preenchimento de senha, planeje testes auxiliares que possam autenticar o usuário sem impor demanda impraticável na memória do usuário.
•
Reconhecimento contínuo de identidade do usuário. Uma vez que uma identidade de usuário tenha sido autenticada, assegure que sejam quais forem os privilégios de acesso/alteração que estejam autorizados para esse usuário continuarão durante a sessão de trabalho.
•
Autorização simples de acesso aos dados. Estabeleça autorização de usuário para acesso aos dados no logon inicial; não exija uma outra autenticação quando um usuário solicita a exibição de um dado em especial.
•
Classificação de segurança apresentada. Quando dados apresentados são classificados em relação a propósitos de segurança, inclua uma indicação proeminente da classificação de segurança em cada tela.
Consistência
•
Posicionamento consistente do cursor. Na apresentação inicial de uma tela de entrada de dados, assegure que o cursor aparecerá automaticamente em uma posição consistente e útil.
•
Rótulo consistente. Torne os rótulos de campos consistentes; sempre utilize o mesmo rótulo para indicar o mesmo tipo de entrada de dados.
•
Formato consistente de rótulo. Adote um formato consistente para rotular linhas e colunas das tabelas apresentadas.
•
Posicionamento consistente dos rótulos. Posicione os rótulos em um mapa consistentemente em relação às características apresentadas que eles designam.
•
Texto consistente dos rótulos. Assegure que os rótulos são redigidos consistentemente, para que o mesmo item de dados tenha o mesmo rótulo caso ele apareça em formulários diferentes.
•
Formato consistente para rótulos de tela. Posicione os rótulos identificadores usados para exibir a seleção em um local proeminente e consistente em cada tela.
•
Formulário compatível para entrada e apresentação de dados. Quando formulários são utilizados para revisão dos dados apresentados assim como para entrada de dados, torne o formulário para entrada de dados compatível com o de saída; use os mesmos rótulos e mesma ordenação para ambos.
•
Formulário compatível para entrada e apresentação dos dados. Quando formulários são usados para entrada de dados assim como para apresentação dos dados, assegure que o formato de apresentação dos dados é compatível com qualquer que seja o formato usado para a entrada de dados; utilize os mesmos rótulos e ordenação dos itens para ambos.
•
Formato consistente de apresentação. Para qualquer tipo de apresentação de dados, mantenha um formato consistente de uma tela para outra.
•
Formato consistente através das telas. Assegure que a disposição e layout dos campos de dados correspondentes está consistente de uma tela para outra.
•
Codificação consistente entre as telas. Atribua significados consistentes para símbolos e outros códigos, de uma tela para outra.
•
Texto consistente. Para dados e rótulos apresentados, escolha palavras com cuidado e useas consistentemente.
•
Texto consistente entre as telas. Assegure que o texto é consistente de uma tela para outra.
•
Texto consistente. Escolha algum formato consistente para redigir as opções apresentadas nos pontos de decisão de um fluxograma.
•
Estrutura gramatical consistente. Utilize uma estrutura gramatical consistente para dados e rótulos na mesma e em outras telas.
•
Formato de texto consistente. Quando material textual é formatado, como em mensagens estruturadas, adote um formato consistente de uma tela para outra.
•
Texto consistente com orientação do usuário. Assegure que o texto e o formato exigido das funções de controle sejam refletidos consistentemente no texto de orientação do usuário, incluindo todos os rótulos, mensagens, e material instrucional.
•
Redação de opção consistente com linguagem de comando. Se a seleção de menu é usada em conjunto com linguagem de comando ou como uma alternativa a ela, projete o texto e a organização sintática das opções de menu exibidas para corresponder consistentemente aos elementos definidos e estrutura da linguagem de comando.
•
Texto consistente. Assegure que os nomes para teclas de função, nomes de comandos, etc., sejam consistente para funções similares ou idênticas em seqüências de transações diferentes.
•
Texto consistente com entradas de controle. Escolha o texto para orientação do usuário que seja consistente com as palavras utilizadas para entradas de controle.
•
Estrutura gramatical consistente. Seja consistente na construção gramatical quando formular orientação do usuário.
•
Preservar zeros significativos. Quando um usuário precisar entrar valores numéricos que serão mais tarde apresentados, preserve todos os zeros significantes; zeros não podem ser removidos arbitrariamente após o ponto decimal caso afetem o significado do número em termo de dígitos significantes.
•
Preservar zeros significativos. Quando um usuário precisar preencher valores numéricos que serão mais tarde apresentados, preserve todos os zeros significantes; zeros não podem ser removidos arbitrariamente após o ponto decimal caso afetem o significado do número em termo de dígitos significantes.
•
Método consistente para seleção de atributos. Quando estiver editando dados gráficos, permita aos usuários alterarem atributos de apresentação por qualquer que seja o meio utilizado para selecionálos na primeira vez.
•
Aceitação de entradas corretas. Assegurese de que todas as entradas corretas serão aceitas e processadas corretamente pelo computador.
•
Apresentação consistente com as necessidades de entradas. Assegure que a apresentação dos dados é consistente na escolha do termo, formato, e estilo básico com as necessidades das entradas de dados e controle.
•
Formato consistente dentro dos campos de dados. Assegure que o formato interno dos campos de dados freqüentemente utilizados é consistente de uma tela para outra.
•
Espaçamento consistente de coluna. Mantenha espaçamento de coluna consistente dentro da tabela, e de uma tabela para outra.
•
Consistência. Utilize lógica consistente no desenho de telas com gráficos, e mantendo o formato padrão, rótulo, etc., para cada método de apresentação gráfica.
•
Formato consistente de anotação. Formate qualquer anotação apresentada consistentemente em relação aos elementos gráficos.
•
Símbolos padrões. Estabeleça significados padrões para símbolos gráficos e useos consistentemente dentro e entre os sistemas que contam com os mesmos usuários.
•
Escala consistente. Se usuários precisam comparar dados gráficos através de uma série de gráficos, use a mesma escala para cada gráfico.
•
Análise interativa de pontos dispersos agrupados. Quando pontos dispersos são agrupados em uma tela somente para mostrar relações entre várias variáveis, forneça algum meio interativo para auxiliar os usuários para que se um usuário selecionar um conjunto de dados no gráfico então os pontos correspondente em outros gráficos sejam demarcados.
•
Ordenação compatível nas legendas. Se uma legenda precisa ser apresentada em um gráfico, ordene os códigos na legenda para que sejam compatíveis com a ordem no espaço das curvas correspondentes no gráfico.
•
Códigos de linha consistente. Quando codificar informações pelo tipo de linha em uma série de gráficos apresentados, utilize esta codificação consistentemente para representar os dados correspondentes.
•
Codificação consistente dos elementos. Quando for necessário distinguir diferentes tipos de elementos de fluxograma, adote um esquema de codificação consistente para esse propósito.
•
Disposição consistente das opções. Quando um fluxograma é projetado para que um usuário tenha que tomar decisões em vários passos, apresente as opções disponíveis em alguma ordem consistente passo a passo.
•
Disposição consistente. Quando vários mapas diferentes forem apresentados, adote uma disposição consistente para que o topo de cada mapa sempre represente a mesma direção.
•
Projeção consistente. Quando mapas representam grandes áreas geográficas, adote um método consistente para projetar a curvatura da terra na superfície plana da tela.
•
Formato consistente. Adote uma organização consistente para a localização de várias características de uma tela para outra.
•
Ordem para comparação de dados. Se usuários precisam analisar conjuntos de dados para discernir similaridades, diferenças, tendências, e relações, estruture o formato da tela para que os dados sejam consistentemente agrupados.
•
Uso consistente de símbolos especiais. Quando utilizar símbolos especiais para indicar condições críticas, utilizeos somente para esse propósito.
•
Atribuição única aos códigos de cores. Quando a codificação de cores é utilizada, assegure que cada cor representa somente uma categoria de dados exibidos.
•
Orientação consistente Mover versus Rolagem. Adote uma orientação consistente para enquadramento de exibição durante o projeto de interface para que os usuários possam 1) conceber o quadro apresentado como sendo uma janela se movendo sobre um array de dados, aqui chamado de "mover", ou 2) conceber os dados como um movimento atrás de um quadro de exibição fixo, comumente chamado "rolagem".
•
Enquadramento de forma integral para todos os dados. Assegure que as funções de enquadramento atuem de forma integral para que a movimentação e/ou zoom afetem todos os dados apresentados da mesma maneira.
•
Controle consistente dentro das janelas. Quando ações de controle como os comandos de entrada, que podem ser feitos por um usuário que efetue uma sobreposição de janelas, assegure que essas ações de controle serão consistentes de uma janela para outra.
•
Ações consistentes do usuário. Assegure para que as ações do controle de fluxo sejam consistentes em forma e conseqüência; empregue meios similares para alcançar fins similares, de uma transação para outra, de uma tarefa para outra, em toda a interface com o usuário.
•
Terminologia consistente para controle de fluxo. Para material instrucional, como rótulos de tela, orientação online e outras mensagens para usuários, adote uma terminologia consistente para se referir ao controle de fluxo.
•
Formato consistente para formulários de controle. Assegure que formulários para entradas de controle sejam consistentes no formato; seus projetos devem geralmente estar de acordo com diretrizes para o projeto de formulários de entrada de dados.
•
Codificação consistente das opções de menu. Se códigos de letras são usados para seleção de menu, utilize essas letras consistentemente na designação de opções de uma transação para outra.
•
Exibição consistente das opções de menu. Quando menus são fornecidos em telas diferentes, projeteos para que as listas de opções sejam consistentes no texto e na ordenação.
•
Projeto consistente de menus hierárquicos. Quando menus hierárquicos são usados, assegure que o formato apresentado e a lógica da seleção sejam consistentes em todos os níveis.
•
Redação de comandos consistente. Projete todas as palavras em uma linguagem de comando, e suas abreviações, para serem consistentes no sentido, de uma transação para outra, e de uma tarefa para outra.
•
Técnicas padrão para edição de comando. Permita aos usuários editarem comandos errados com as mesmas técnicas que são empregadas na edição de entradas de dados.
•
Representação coerente da organização dos dados. Estabeleça uma única representação para a organização dos dados para formulação de consulta, em vez de várias representações.
•
Opção "continuar" consistente. Em qualquer passo em uma seqüência de transação definida, se há somente um único passo seguinte apropriado então forneça um opção de controle consistente para continuar para a próxima transação.
•
Apresentação consistente da informação de contexto. Assegure que a informação apresentada para fornecer contexto para controle de fluxo é distintiva em posição e formato, e consistentemente apresentada de uma transação para a próxima.
•
Entrada explícita de correções. Quando um usuário completar a correção de um erro, se for uma entrada de comando ou entrada de dados, exija que usuários executem uma ação explícita para reenviar o material corrigido; utilize a mesma ação de confirmação que foi usada na entrada original para reenviar.
•
Alarmes distintos e consistentes. Assegure que sinais de alarme e mensagens são distintos para cada classe de eventos.
•
Procedimentos padrão. Projete procedimentos padrão para concluir tarefas similares e logicamente relacionadas.
•
Formato de tela consistente. Crie formatos de tela com uma estrutura consistente e evidente para o usuário, para que qualquer tipo especial de dado esteja sempre apresentado no mesmo local e da mesma maneira.
•
Formato consistente para orientação do usuário. Formate cada tipo diferente de orientação do usuário consistentemente entre as telas.
•
Convenções de codificação consistente. Assegure que símbolos e outros códigos tenham significados consistentes de uma tela para outra.
•
Retorno consistente. Assegure que todas as entradas feitas pelo usuário produzirão consistentemente alguma resposta perceptível no computador; quando um terminal estiver em uso, sua tela nunca deve estar vazia.
•
Formato consistente para sugestões. Utilize estilo e pontuação consistente em todas as sugestões.
•
Posicionamento consistente do cursor. No último passo na geração de uma tela de saída, assegure que o computador vai automaticamente posicionar o cursor para que ele apareça em uma posição consistente na tela para cada tipo de transação.
•
Procedimentos consistentes. Assegure que os procedimentos para preparar, enviar e receber mensagens, sejam consistentes de uma transação para outra, e sejam consistentes com procedimentos em relação a outras tarefas de manipulação de informação.
•
Composição de mensagem compatível com entrada de dados. Assegure que os procedimentos para composição de mensagens sejam compatíveis com procedimentos gerais de entrada de dados, especialmente aqueles para edição de texto.
•
Visualização da mensagem compatível com apresentação de dados. Assegure que auxílios oferecidos pelo computador e procedimentos para visualização de mensagens sejam consistentes com outras capacidades do sistema para apresentação de dados em geral.
•
Procedimentos consistentes. Forneça procedimentos claros e consistentes para diferentes tipos de transações, particularmente aqueles envolvendo entrada de dados, alteração e detecção, e correção de erros.
Tempo de Resposta
•
Retorno durante entrada de dados. Forneça retorno para todas as ações durante entrada de dados; mostre as teclas digitadas a cada toque.
•
Regerar dados alterados. Aonde o computador precisar regerar uma tela para atualizar os itens alterados, considere regerar somente aqueles itens alterados se isso for acelerar a apresentação da saída.
•
Tempo apropriado de resposta do computador. Assegure que a velocidade da resposta do computador para as entradas de controle do usuário é apropriada para a transação envolvida; em geral, a resposta deveria ser mais rápida para transações entendidas pelo usuário como sendo simples.
•
Tempo apropriado de resposta do computador. Assegure que a velocidade da resposta do computador para entradas do usuário é apropriada ao tipo de diálogo; a resposta a seleções de menu, teclas de funções, e a maioria das entradas durante uma interação gráfica deve ser imediata.
•
Resposta rápida. Assegure que a resposta do computador às entradas do usuário será rápida, com tempo consistente da maneira apropriada para os diferentes tipos de transação.
•
Disponibilidade de controle. Permita que usuários façam entradas de controle quando necessário; as entradas de controle de fluxo não devem ser atrasadas devido a atrasos na resposta do computador.
•
Interrupção para finalizar o bloqueio de controle. Em situações onde o bloqueio de controle ocorre, forneça ao usuário um meio auxiliar de controle de entrada, como uma tecla de função especial, para abortar a transação que causar bloqueio prolongado.
•
Interrupção de transações feitas pelo usuário. Forneça flexibilidade no controle de fluxo em permitir que um usuário interrompa ou cancele uma transação corrente, de maneiras apropriadas às necessidades da tarefa.
•
Confirmando retorno em grande escala. Se uma consulta resultará em um retorno de dados de grande escala, exija que o usuário confirme a transação ou senão adote outra ação para filtrar a consulta antes de processar.
•
Reconhecimento especial de alarmes críticos. Se usuários são obrigados a reconhecer um alarme específico ou crítico de alguma maneira especial, assegure que tal reconhecimento não ira inibir ou atrasar a resposta do usuário que remediará a condição crítica de inicialização.
•
Carga do sistema. Quando a execução de tarefa é afetada pela carga operacional (por exemplo, número de usuários online), permita ao usuário obter informação indicando o desempenho do sistema, expressado em termos de tempo de resposta do computador.
Retorno
•
Retorno para conclusão de entrada de dados. Garanta que o computador responda à conclusão da entrada de dados com uma mensagem de confirmação, se a transferência dos dados foi bem sucedida, ou então com uma mensagem de erro.
•
Retorno para entradas de dados repetitivas. Para uma tarefa de repetição de entradas de dados que seja concluída como uma contínua série de transações indique que a entrada foi bem sucedida atualizando a tela de entrada de dados, automaticamente removendo os dados já processados em preparação para a próxima entrada.
•
Selecionando elementos gráficos. Forneça aos usuários meios para a indicação e seleção de elementos gráficos apresentados para manipulação.
•
Selecionando cores. Se usuários puderem selecionar cores como um atributo dos elementos gráficos, permita que eles especifiquem cores diretamente via apontamento em exemplos apresentados, em vez que exigir que eles nomeiem as cores.
•
Apresentando atributos correntes. Durante a entrada/edição dos dados gráficos, apresente os atributos selecionados que afetarão as ações correntes para a pronta confirmação do usuário.
•
Validação de transações seqüenciais na hora certa. Em uma tarefa de entradas de dados repetitivas, valide os dados para cada transação e permita que o usuário corrija os erros antes de iniciar outra transação.
•
Mostrar alterações na escala. Quando um mapa ou outro gráfico tiver sido expandido de sua cobertura normal, forneça algum identificador de escala do fator de expansão.
•
Indicando alteração dos dados. Quando mudanças nos dados mapeados são significativos para a tarefa do usuário, inclua elementos gráficos auxiliares para indicar essas mudanças.
•
Removendo destaque. Se destaque é usado para enfatizar itens de exibição importantes, remova tal destaque quando ele não tiver mais significado.
•
Sinalizando a conclusão da exibição da saída. Se a geração de tela for lenta, notifique o usuário quando a exibição da saída for concluída.
•
Mostrar a escala de mudança. Quando uma tela for expandida de sua cobertura normal, forneça algum indicador de escala do fator de expansão.
•
Integração visual dos gráficos alterados. Se um usuário precisa integrar visualmente mudanças de padrões em uma exibição gráfica, atualize os dados em uma velocidade apropriada para habilidades humanas de percepção para esses tipos de atualização de dados.
•
Rotulando supressão de tela. Quando dados tiverem sido suprimidos de uma tela, anote a tela com algum rótulo apropriado para lembrar os usuários que dados foram suprimidos.
•
Sinalizando alterações dos dados suprimidos. Quando dados tiverem sido suprimidos de uma tela, avise os usuários se alguma significante (mas não exibida) alteração é detectada no processamento dos dados novos feito pelo computador.
•
Retorno para entradas de controle. Assegure que o computador reconheça todas entradas de controle imediatamente; para cada ação feita pelo usuário deveria ter alguma reação aparente do computador.
•
Indicando a conclusão do processamento. Quando o processamento em resposta a uma entrada de controle é prolongado, dê aos usuários alguma indicação positiva da conclusão subseqüente, e informação relacionada apropriada.
•
Rotulando teclas multifunção. Se uma tecla é utilizada para mais de uma função, sempre indique ao usuário qual função está atualmente disponível.
•
Indicando valores iniciais de controle. Quando controle é concluído por entradas de comando pelo teclado ou opções de código, se um valor inicial for definido para uma entrada de controle nula então indique este valor ao usuário.
•
Indicando o status de pausa. Se uma opção de pausa é fornecida, apresente algum indicador do status de pausa a qualquer hora que esta opção for selecionada pelo usuário, e sugira a ação de continuar que irá permitir a continuação da transação interrompida.
•
Rotulando congelamento de tela. Quando uma tela tiver sido congelada, anote a tela com alguns rótulos apropriados para lembrar os usuários do seu status congelado.
•
Sinalizando alterações para dados congelados. Quando uma tela que está sendo atualizada em tempo real tiver sido congelada, informe os usuários se alguma significante (mas não exibida) alteração é detectada no processamento dos dados novos feito pelo computador.
•
Indicando bloqueio de controle. Se entradas de controle precisam ser adiadas até que o computador processe entradas anteriores, então indique este atraso ao usuário.
•
Indicando o status de suspender. Se uma opção de suspender é fornecida, apresente algum indicador do status de suspender a qualquer hora que a opção for selecionada pelo usuário, e, em um logon subseqüente, sugira ao usuário os procedimentos que permitirão a continuação da transação suspensa.
1
•
Apresentação do modo operacional1. Quando o contexto de controle de fluxo é estabelecido em termos de um modo operacional definido, lembre os usuários do modo atual e outras informações pertinentes.
•
Resposta apropriada à todas entradas. Projete o software de interface para lidar apropriadamente com todas as possíveis entradas de controle, corretas e incorretas.
•
Bloqueio de teclado. Se a qualquer instante o teclado for bloqueado, ou o terminal estiver desativado de qualquer forma, notifique o usuário.
•
Outros usuários. Quando a execução de uma tarefa exigir troca de dados e/ou interação com outros usuários, permita ao usuário obter informação com respeito às outras pessoas utilizando o sistema naquele momento.
•
Sistemas externos. Quando a execução de tarefa requer troca de dados e/ou interação com outros sistemas, permita ao usuário obter informações relevantes de status dos sistemas externos.
•
Indicando status. Forneça alguma indicação do status do sistema aos usuários a qualquer hora.
•
Informação sobre o status de comunicação. Permita aos usuários acessarem a informação sobre o status dizendo respeito à identidade dos outros usuários do sistemas que estejam online, e à disponibilidade de comunicação com sistemas externos.
•
Retorno automático. Forneça retorno automático para transmissão de dados confirmando que as mensagens foram enviadas ou indicando falhas, conforme for necessário para permitir participação efetiva do usuário na manipulação de mensagem.
•
Notificação de novas mensagens no logon. Quando usuários efetuam logon em um sistema, notifique os sobre qualquer transmissão de dados recebida desde a última utilização do sistema.
•
Alerta de ameaça à segurança. Forneça lógica por parte do computador que gere mensagens e/ou sinais de alerta com o intuito de prevenir usuários (e administradores de sistema) de potenciais ameaças à segurança dos dados, isto é, de tentativa de invasão de usuários não autorizados. •
Diferenciando dados reais de simulados. Quando dados simulados e funções simuladas do sistema são fornecidas (talvez para treinamento de usuário), assegure que dados reais estejam protegidos e o uso real do sistema seja claramente distinguível de operações simuladas.
Nos itens 5.1.1 e 5.1.10, as diretrizes voltadas à alteração do modo operacional foram classificadas como parcialmente válidas. Nesta seção, a norma que trata do mesmo assunto objetiva a apresentação do modo operacional. Assim, ela foi classificada como válida e pertinente baseada na importância do retorno ao usuário, conforme descrito no item 5.1.4.
•
Diferenciando dados reais de simulados. Quando dados simulados são armazenados e processados em um sistema (talvez para treinamento de usuário), assegure que alterações dos dados simulados são processadas separadamente e não afetam dados reais.
•
Retorno para seleção de modo. Quando o resultado de uma ação do usuário for contingente em relação seleções prévias entre modos operacionais diferentemente definidos, forneça uma indicação contínua do modo corrente, particularmente quando entradas do usuário em naquele modo possa resultar em perda de dados.
Legibilidade
•
•
Apresente as áreas definidas para entrada de dados. Quando a entrada de dados em uma tela é permitida somente em algumas áreas, como durante o preenchimento de um formulário, forneça definição visual clara para os campos.
•
Campos de dados visivelmente distintos. Forneça clara definição visual dos campos de dados, para que os dados sejam diferentes dos rótulos e outros atributos de apresentação.
•
Texto distinguível da anotação. Assegure que anotações do texto apresentado sejam distinguíveis do texto em si.
•
Rótulos próximos de campos de dados. Assegure que os rótulos estejam suficientemente próximos para serem associados a seus campos de dados, mas estejam separados dos campos de dados por ao menos um espaço.
•
Rótulos próximos de campos de dados. Assegure que cada rótulo está suficientemente próximo para ser associado com seu campo de dados, mas esteja separado de seu campo de dados por ao menos um espaço.
•
Símbolo padrão para indicar a entrada. Escolha um símbolo padrão para indicar entrada e o reserve somente para esse uso.
Rótulos distintos. Projete rótulos distintos para cabeçalhos de colunas e rótulos de linhas, para que os usuários possam diferenciálos das entradas de dados.
Mínima pontuação de abreviações. Minimize a pontuação de abreviações e •
siglas.
•
Uso convencional de tipo de caixa misto. Apresente textos contínuos convencionalmente em caixaalta e caixabaixa.
•
Pontuação convencional. Utilize pontuação convencional nos textos apresentados; sentenças deveriam terminar com um ponto final ou outra pontuação especial.
•
Listas para itens relacionados. Para uma série de itens relacionados (palavras, frases, instruções, etc.), apresenteos em uma lista em vez de texto corrido.
•
Marcas de mapeamento de coluna. Separe as colunas em uma tabela por espaços brancos suficientes, ou por algum outro atributo diferente, para assegurar a separação das entradas em uma linha.
•
Destacar elementos selecionados. Quando um usuário tiver selecionado (isto é, apontado para) um elemento gráfico apresentado, destaque esse elemento de alguma maneira para que o usuário possa antecipar as conseqüências de qualquer ação sugerida envolvendo aquela seleção.
•
Destacando texto. Quando uma passagem crítica for digna de ênfase para separála do restante do texto, destaque a passagem com escurecimento/clareamento ou coloração ou por alguma outra notação, em vez de caixaalta.
•
Destacando dados críticos. Quando a atenção do usuário precisa ser direcionada a uma região de uma tela gráfica mostrando dados críticos ou anormais, destaque esse atributo com algum meio distinto de codificação dos dados.
•
Destacando. Se alguns pontos plotados representam dados de significância particular, destaqueos para tornálos visualmente distintos dos outros.
•
Destacando. Em gráficos que apresentam múltiplas curvas, se uma curva representa dados de particular significância, destaquea.
•
Destacando. Em um gráfico de barras simples, se uma barra representa dados de significância particular, destaquea.
•
Destacando. Se um segmento particular de um gráfico de pizza requer ênfase, destaqueo através de um sombreamento ou tom especial e/ou por "explosão", isto é, deslocandoo levemente do restante da pizza.
•
Destacando. Se uma imagem ou diagrama contiver dados de significância particular, implicando uma necessidade especial de atenção do usuário, destaqueos.
•
Destacando. Se um elemento em um fluxograma representa dados de significância particular, implicando uma necessidade especial de atenção do usuário, destaque esse elemento.
•
Destacando. Se uma área em um mapa representa dados de significância particular, implicando uma necessidade especial de atenção do usuário, destaquea.
•
Destacando dados críticos. Forneça codificação distintiva para destacar itens de exibição importantes que exigirem a atenção do usuário, especialmente quando esses itens forem apresentados raramente.
•
Destacando dados modificados. Quando dados forem atualizados seguindo atualização automática da tela, considere destacar essas alterações dos dados temporariamente.
•
Destacando informação crítica para o usuário. Seja qual for o método usado para marcar itens críticos na apresentação de dados, adote métodos similares para destacar a apresentação de informações de orientação crítica para o usuário.
•
Destacando mensagem. Forneça ao software habilidades para indicar dados transmitidos com destaque apropriado para enfatizar condições de alarme/alerta, indicadores de prioridade, ou outra informação com significância de segunda ordem que possa afetar a manipulação de mensagem..
•
Barras agrupadas ou sobrepostas. Quando medidas agrupadas em dois conjuntos de dados precisam ser comparadas, considere apresentar cada par como barras contínuas ou parcialmente sobrepostas.
•
Codificação de área. Quando diferentes áreas de um mapa precisam ser definidas, ou quando uma distribuição geográfica de uma variável particular precisa ser indicada, considere a utilização de padrões de textura ou de cor ou códigos de tonalidade para esse propósito.
•
Uso limitado de codificação de tamanho. Considere codificação de tamanho, isto é, variar o tamanho de símbolos alfanuméricos e outros exibidos, somente para aplicações onde a tela não esteja cheia.
•
Codificação de cor para categorias de dados. Quando um usuário precisa distinguir rapidamente entre várias categorias discretas de dados, especialmente quando itens de dados estão dispersos na tela, considere a utilização de uma única cor para exibir os dados em cada categoria.
•
Cores facilmente diferenciáveis. Quando utilizar cores para codificação de categorias discretas de dados, assegure que elas sejam facilmente diferenciáveis.
•
Legibilidade dos dados alterados. Se usuários precisam ler precisamente valores de dados alterados, assegure que esses dados sejam exibidos grandes o suficiente para serem lidos.
Processamento sob controle explícito do usuário
•
Ação explícita de envio. Sempre exija que o usuário execute uma ação de envio para iniciar o processamento dos dados preenchidos; não inicie o processamento como um resultado de outra ação.
•
Ação explícita de cancelamento. Exija que o usuário execute uma ação explícita para ordenar o cancelamento da entrada de dados; cancelamento de dados não devem ser realizado como um resultado de outra ação.
•
Ações explícitas do usuário. Exija que usuários adotem ações explícitas para especificar o processamento de dados feito pelo computador; o computador não deve adotar ações extras (e possivelmente irreconhecíveis) além do daquelas especificadas pelo usuário.
•
Ações explícitas do usuário. Exija que usuários efetuem alguma ação explícita do tipo ENTER para concluir uma transação de entrada/alteração de dados; alteração de dados não deve ocorrer como um possível e não reconhecido efeito colateral de outras ações.
•
Controle através de ação explícita do usuário. Permita que usuários controlem transações através de ações explícitas; adie o processamento computacional até que uma ação explícita do usuário tenha sido tomada.
•
Controle através de ações explícitas do usuário. Projete os procedimentos de transmissão de dados para que o envio e recebimento das mensagens sejam concluídos através de ações explícitas do usuário.
•
Controle através de ação explícita do usuário. Assegure que o computador altere os dados somente como sendo um resultado de ações explícitas do usuário, e que ele não inicia alterações automaticamente.
•
Transmissão iniciada pelo usuário. Permita que usuários iniciem a transmissão de dados diretamente, através da entrada do comando explícito de envio.
•
Envio explícito de correções. Exija que usuários efetuem uma ação explícita de envio para que ocorra o processamento por parte do computador das correções de erro; essa deve ser a mesma ação que foi tomada para enviar os dados originalmente.
Compatibilidade com o mundo real, simplicidade, objetividade e logicidade
•
Unidades de medida familiares. Empregue unidades de medida que sejam familiares para o usuário.
2
•
Texto familiar. O texto dos rótulos de dados apresentados deve utilizar termos familiares e jargões orientados a tarefa dos usuários, e evitar jargões de designers e programadores que não forem familiares aos usuários.
•
Abreviações comuns. Quando abreviações são usadas, escolhas aquelas que são facilmente reconhecidas, e não abrevie palavras que produzam abreviações incomuns ou ambíguas.
•
Clareza do texto. Projetando telas de texto, especialmente textos compostos para orientação do usuário, se esforce pela simplicidade e clareza dos textos.
•
Organização lógica. Organize os dados tabulares de alguma forma reconhecível para facilitar seu exame e assimilação.
•
Direção normal dos rótulos. Apresente a anotação do gráfico apresentado, incluindo rótulos dos eixos do gráfico, em uma direção normal em relação à leitura de texto.
•
Convenções de escala. Siga práticas convencionais na utilização de escalas, para que os valores em um eixo aumentem ao se afastar da origem, e o eixo horizontal X seja usado para plotar tempo ou causa postulada de um evento (a variável independente) e o eixo vertical Y usado para plotar o efeito causado (a variável dependente).
•
Ordem lógica dos passos. Projete os fluxogramas2 para que os passos sigam alguma origem lógica.
•
Direção convencional de caminho. Projete fluxogramas para que o caminho da seqüência lógica seja consistente com as convenções familiares de direção, isto é, da esquerda para direita (para usuários acostumados a ler inglês) e do topo para baixo, ou talvez em sentido horário.
•
Utilização convencional de setas. Em fluxogramas e outros gráficos, utilize setas de uma maneira convencional para indicar relações direcionais nas ligações seqüenciais entre vários elementos.
•
Convenções de codificação familiar. Adote códigos para apresentação (e entrada) que estejam de acordo com abreviações aceitáveis e expectativas gerais do usuário.
As diretrizes de Smith e Mosier se referem aos fluxogramas utilizados nas interfaces de software produzidos na base militar de Hanscom. Atualmente, podese aplicálas na construção de mapas de site, por exemplo, pois estes, de maneira análoga, descrevem um fluxo dentro do sistema. Uma das diferenças principais estaria relacionada à linguagem normalmente utilizada para descrever laços, expressões condicionais, etc.
•
Seqüências lógicas de transação. Quando projetar uma seqüência de transações relacionadas para alguma tarefa de manipulação de informações, use análise de tarefa para assegurar que essas transações constituirão uma unidade lógica ou sub
tarefa do ponto de vista do usuário, e para determinar quais opções de controle usuários necessitarão em qualquer ponto.
•
Redação familiar. Escolha palavras para uma linguagem de comando que reflitam o ponto de vista do usuário, e sejam correspondentes à linguagem operacional do usuário.
•
Convenções familiares de codificação. Assegure que os códigos e abreviações de entrada/apresentação de dados estão em conformidade com a utilização convencional e com as expectativas do usuário.
•
Texto familiar. Quando estiver formulando rótulos, sugestões e mensagens de orientação do usuário adote uma terminologia familiar aos usuários.
•
Formulário compatível com documentos de origem. Quando a entrada de dados envolver a transcrição de documentos, assegure que a apresentação do formulário se adapte (ou esteja compatível com) esses documentos, em termos de ordenação dos itens, agrupamento de dados, etc.
•
Itens de dados em ordem lógica. Se não houver documento de origem ou informação externa envolvida, então projete os formulários para que os itens de dados estejam ordenados na seqüência em que o usuário pensaria neles.
•
Tabela para conjuntos de dados relacionados. Quando um conjunto de dados precisa ser preenchido seqüencialmente, em séries repetitivas, forneça um formato organizado em tabelas onde os conjuntos de dados possam ser digitados linha a linha.
•
Rótulos informativos. Assegure que os cabeçalhos das colunas e os rótulos das linhas sejam formulados de maneira informativa, para que eles auxiliem na entrada de dados.
•
Rotulando unidades de medida. Inclua as unidades de medida para apresentação dos dados ou no rótulo ou como parte de cada item de dados.
•
Rotulando barras agrupadas. Quando barras são apresentadas em pares, rotule as barras diretamente em um par para distinguir as duas entidades sendo comparadas, em vez de apresentar uma legenda separada.
•
Rotulando gráficos de pizza. Se gráficos de pizza são usados, rotule os segmentos diretamente em vez de fazêlo através de uma legenda separada, em orientação normal em relação ao texto lido.
•
Rotulando funções de movimentação. Quando uma orientação de movimentação é mantida consistentemente, escolha nomes de funções de exibição de enquadramento que se refiram ao movimento do quadro exibido (ou janela) e não para movimentar os dados exibidos.
•
Rótulo de controle autoexplicativo. Rotule teclas de função e outros controles claramente para indicar suas funções.
•
Rótulo de dados autoexplicativos. Rotule todos dados apresentados claramente.
•
Geração automática de dados rotineiros. Para dados rotineiros que podem ser derivados de registros do computador, programeo para que ele acesse e entre esses dados automaticamente.
•
Computação automática de dados derivados. Forneça computação automática dos dados derivados, para que um usuário não tenha que calcular e preencher qualquer número que possa ser derivado dos dados já acessíveis ao computador.
•
Entrada automática de dados redundantes. Se os dados que são acessíveis ao computador estão logicamente relacionados com outras entradas, programeo para retornar e enviar esses itens de dados redundantes automaticamente.
•
Geração de dados automática. Quando dados rotineiros ou redundantes podem ser derivados pelo computador, apresente esses dados automaticamente para que o usuário possa revisálos, em vez de exigir o preenchimento pelo usuário.
•
Atualização automática de arquivos referenciados. Forneça atualização automática de arquivos referenciados quando for necessário, para que um usuário não tenha que entrar com os mesmos dados duas vezes.
•
Apresentação de dados consistente com convenções do usuário. Apresente os dados consistentemente de acordo com padrões e convenções familiares para os usuários.
•
Estabelecimento de padrões de apresentação. Quando nenhuma convenção específica para os usuários tiver sido estabelecida, adote padrões de design de interface para apresentação dos dados.
•
Uso mínimo de abreviações. Prefira apresente palavras por completo do que abreviações.
•
Abreviações definidas no texto. Quando palavras em texto são abreviadas, defina cada abreviação em parênteses após sua primeira ocorrência.
•
Sentenças iniciando com o tópico principal. Coloque o tópico principal de cada sentença no início do parágrafo.
•
•
•
Estrutura de sentença simples. Utilize sentenças curtas e simples.
Texto distinto. Use palavras distintas em vez de contrações ou formas combinadas, especialmente em frases envolvendo negação.
Sentenças afirmativas. Utilize enunciados afirmativos em vez de negativos.
•
Seqüência relacionada ao tempo. Quando uma sentença descreve uma seqüência de eventos, e redija a mesma com uma ordem correspondente das palavras.
•
Disposição lógica de lista. Adote algum princípio lógico pelo qual dispõe listas; onde nenhum princípio se aplicar, ordena as listas alfabeticamente.
•
Formulários para dados relacionados. Utilize formulários para apresentar conjuntos de dados relacionados em campos rotulados separadamente.
•
Texto descritivo dos rótulos. Escolha uma palavra ou frase para rotular cada campo que descreverá o conteúdo do mesmo.
•
Itens unidos para comparação direta. Se os itens de dados precisam ser comparados em uma base caractere a caractere, apresente diretamente um abaixo do outro.
•
Justificação de dados numéricos. Justifique colunas de dados numéricos em relação ao ponto decimal fixado; se não houver ponto decimal, então os números devem ser justificados à esquerda.
•
Escala linear. Empregue uma escala linear para os dados apresentados, em preferência à logarítmica ou outro método nãolinear de escala.
•
Escalas numéricas iniciam em zero. Quando usuários precisam comparar quantidades agregadas na mesma tela, ou acerca de uma série de telas, a escala dos dados numéricos deveria iniciar com zero.
•
Rotação. Em uma aplicação onde um usuário precise examinar um objeto mostrado de diferentes pontos de vista, permita ao usuário rotacionar a imagem apresentada.
•
Fluxogramas. Considere fluxogramas para representação esquemática de uma seqüência de informação, isto é, para apresentar dados que são logicamente relacionados em termos de processos seqüenciais.
•
Decisão simples a cada passo. Quando um fluxograma é projetado para que o usuário tenha que tomar decisões em vários passos, exija somente uma decisão a cada passo, em vez de combinar decisões para reduzir o tamanho do fluxograma.
•
Disposição lógica das opções. Quando um fluxograma é projetado para que o usuário tenha que tomar decisões em vários passos, apresente as opções disponíveis em alguma ordem lógica.
•
Mapas. Forneça mapas para apresentar dados geográficos, isto é, relações de direção e distância entre locais físicos.
•
Movendo o conteúdo para um enquadramento da tela flexível. Quando um mapa exceder a capacidade de um quadro da tela, em termos de extensão e detalhes da cobertura, considere fornecer aos usuários a capacidade de mover o quadro apresentado sobre a área mapeada com o intuito de examinar áreas diferentes do atual interesse.
•
Organização lógica dos dados. Assegure que as telas sejam formatadas para agrupar itens de dados com base em algum princípio lógico, considere concessões derivadas da análise de tarefas.
•
Dados agrupados em seqüência de uso. Quando dados exibidos são utilizados em alguma ordem temporal ou espacial, considere agrupar esses dados pela seqüência de uso para preservar essa ordem.
•
Dados agrupados por função. Quando conjuntos de dados são associados a questões particulares ou relacionadas às funções particulares, considere agrupar cada conjunto para ajudar a ilustrar esse relacionamento funcional.
•
Dados agrupados por importância. Quando alguns itens de dados exibidos são especialmente importantes, isto é, fornecem informação significante e/ou exigem resposta imediata do usuário, considere agrupar esses itens no topo da tela.
•
Dados agrupados alfabeticamente ou cronologicamente. Quando não houver lógica apropriada para agrupar dados por seqüência, função, freqüência ou importância, adote algum outro princípio como um agrupamento alfabético ou cronológico.
•
Códigos significativos. Adote códigos significativos ou familiares, em vez de códigos arbitrários.
•
Estabelecendo padrões para codificação de forma. Quando a codificação de forma é utilizada, atribua códigos baseados em padrões estáveis ou significados convencionais.
•
Atribuição convencional de códigos de cores. Escolha cores de codificação com base em associações convencionais a cores em especial.
•
Numeração continua em uma lista de múltiplas páginas. Quando uma lista de itens numerados excede uma página, numere os itens continuamente em relação ao primeiro item na primeira página.
•
Numerando páginas exibidas. Quando a saída exibida possui mais de uma página, anote cada página para identificar a continuação.
•
Utilizando o movimento do cursor livre. Em aplicações onde um usuário pode mover um cursor livremente na página de dados exibidos, adote mover em vez de rolar como a base conceitual de exibir o enquadramento.
•
Controle compatível com a habilidade do usuário. Assegure que os meios de controle de fluxo são compatíveis com as habilidades do usuário, permitindo ações simples do tipo passo a passo para iniciantes, mas permitindo a entrada de comandos mais complexos de usuários experientes.
•
Nomes congruentes para funções de controle. Ao selecionar nomes para funções de controle de fluxo, escolha nomes que sejam semanticamente congruentes com o uso natural, especialmente para pares opostos.
•
Compatibilidade com expectativas do usuário. Assegure que os resultados de qualquer entrada de controle sejam compatíveis com as expectativas do usuário, para que uma alteração no estado ou valor de um elemento controlado seja exibido da maneira esperada ou de forma natural.
•
Diálogo compatível com tarefa e usuário. Considere as necessidades da tarefa e características ligadas ao usuário quando escolher tipo(s) de diálogo(s) e quando projetam a lógica do controle de fluxo.
•
Seqüência compatível com documentos de origem. Quando for solicitada a entrada de dados de um documento de origem, assegure que a seqüência vai combinar com a seqüência no documento de origem.
•
Seleção única por menu. Cada menu exibido deve permitir somente uma seleção por parte do usuário.
•
Opções de menu formuladas como comandos. A formulação das opções de menu devem representar comandos para o computador, em vez de questões para o usuário.
•
Ordem lógica das opções de menu. Liste opções de menu em ordem lógica; se nenhuma estrutura lógica for evidente, então exiba as opções na ordem de sua freqüência esperada de uso, com o mais freqüente listado primeiro.
•
Agrupamento lógico das opções de menu. Formate um menu para indicar logicamente grupos relacionados de opções, em vez de uma cadeia não diferenciada de alternativas.
•
Ordenação lógica de opções agrupadas. Se opções de menu são agrupadas em subunidades lógicas, apresenteas em grupos em uma ordem lógica; se nenhuma estrutura lógica for evidente, então exiba os grupos na ordem de sua freqüência esperada de uso.
•
Combinação lógica de teclas de função. Se combinação (control/shift) de teclas é utilizada, as funções combinadas em uma tecla devem ser logicamente relacionadas.
•
Redação funcional. Projete uma linguagem de comando para que um usuário possa entrar comandos em termos da função desejada, sem se preocupar com processamento de dados do computador, armazenamento e mecanismos de retorno.
•
Nomes de comandos significativos. Escolha nomes de comando que sejam significativos, e que especificamente descrevem as funções implementadas.
•
Organização natural dos dados. Projete uma linguagem de consulta para que reflita a estrutura ou organização dos dados de forma que pareça ser natural para os usuários.
•
Expressões orientadas à tarefa. Projete uma linguagem de consulta para que a formulação de uma consulta especifique simplesmente quais dados são solicitados; um usuário não deve informar ao computador como encontrar os dados.
•
Organização e rotulação das opções listadas. Projete a lista de opções gerais para mostrar opções de entrada de controle agrupadas, rotuladas e ordenadas em termos de suas funções lógicas, freqüência de uso e prioridade, seguindo as diretrizes gerais para projeto de menu.
•
Texto de opção orientado à tarefa. Empregue texto orientado a tarefa para opções de controle para refletir a visão do usuário da transação atual.
•
Somente opções disponíveis oferecidas. Ofereça aos usuários somente opções de controle que estejam realmente disponíveis para a transação atual.
•
Texto orientado à tarefa. Adote texto orientado à tarefa para rótulos, sugestões e mensagens de orientação do usuário, incorporando seja quais forem os termos especiais e jargões técnicos empregados nas tarefas do usuário.
•
Frases afirmativas. Adote texto afirmativo em vez de negativo para mensagens de orientação do usuário.
•
Voz ativa. Adote voz ativa em vez da passiva nas mensagens de orientação do usuário.
•
Seqüência temporal. Quando a orientação do usuário descreve uma seqüência de passos, siga a mesma seqüência no texto da orientação do usuário.
•
Sinais de data e tempo. Quando a execução de tarefa requer ou implica a necessidade de avaliação de quando a informação entrou em uso, inclua na tela informação de data e tempo.
•
Folheando ajuda. Permita aos usuários ver as telas de ajuda online, assim como fariam em um manual impresso, para ganhar familiaridade com as funções do sistema e procedimentos operacionais.
•
Comprimento de mensagem variável. Permita que usuários componham mensagens de qualquer comprimento.
•
Envie uma única cópia. Assegure que somente uma cópia de qualquer mensagem será transmitida para qualquer um dos destinatários.
•
Cancelar mensagem. Permita aos usuários cancelar qualquer mensagem que tenha sua transmissão iniciada, se ela não tiver ainda sido recebida pelo destinatário.
•
Permissão simples para entrada/alteração de dados. Estabeleça uma permissão de usuário para entrada/alteração de dados no logon inicial; não exija uma outra permissão quando um usuário tentar transações especiais de entrada/alteração de dados.
•
Procedimentos simples. Torne procedimentos para entrada/alteração de dados tão simples quanto for possível, seguindo as diretrizes de projeto de funções de entrada de dados.
Navegação
•
Contexto para os dados apresentados. Assegure que cada tela providenciará o contexto necessário, recapitulando dados anteriores quando necessário para que usuários não tenham que contar com sua memória para interpretar novos dados.
•
Contexto apresentado. Se as conseqüências de uma entrada de controle vão diferir dependendo do contexto estabelecido por uma ação anterior, então apresente alguma indicação contínua do contexto atual para orientar o usuário.
•
Opções de menu dependendo do contexto. Projete um menu para apresentar somente aquelas opções que são atualmente disponíveis no contexto atual para um usuário em particular.
•
Definindo contexto para usuários. Projete o software de controle de fluxo para manter o contexto para o usuário por todas as séries de transações que englobam uma tarefa; onde for apropriado, apresente os resultados das entradas anteriores que afetam ações presentes, e indique opções atualmente disponíveis.
•
Contexto apresentado. Quando os resultados de uma entrada do usuário dependem do contexto estabelecido em entradas anteriores, apresente alguma indicação do contexto para o usuário.
•
Mantendo contexto para entrada de dados. Em uma transação envolvendo entrada de dados extensa, apresente um registro cumulativo de qualquer entrada anterior que seja relevante à entrada atual.
•
Mostrar a posição da seção visível na visão geral. Quando uma tela tiver sido expandida de sua cobertura normal, forneça algum indicador gráfico da posição na tela completa da seção visível.
•
Mostrar a posição da seção visível na visão geral. Quando o usuário mover sobre uma tela expandida com o intuito de visualizar seções diferentes, forneça algum indicador gráfico da posição na tela completa da seção visível.
•
Mostrar a posição da seção visível na visão geral. Quando uma tela tiver sido movida e/ou expandida de sua cobertura normal, forneça algum indicador gráfico da posição na tela completa da seção visível atualmente.
•
Eixos duplicados. Quando dados de uma escala contiverem valores muito grandes, apresente eixos duplicados, para que o eixo X apareça no topo e em baixo, e o eixo Y à esquerda e direita do gráfico.
•
Ligando diagramas secionados através de links. Quando dados diagramados excedem a capacidade de um quadro da tela e precisa ser mostrado em seções separadas, C A P . V I I R E F E R Ê N C I A S , A N E X O S 98
forneça uma visão geral do diagrama, uma notação consistente para indicar links lógicos de suas várias seções, e uma forma fácil para que usuários se movam de uma seção para outra.
•
Referência estável para dados em mudança. Quando dados gráficos apresentados são automaticamente atualizados, forneça alguns elementos estáveis de tela, por exemplo, coordenadas, limites geográficos, etc.
•
Rótulos de página. Em uma exibição de múltiplas páginas rotule cada página para mostrar relação com as outras.
•
Rótulos para tabelas de múltiplas páginas. Para uma tabela que exceda a capacidade de um quadro, assegure que os usuários poderão ver o cabeçalho da coluna e os rótulos de linhas em todas as seções da tabela.
•
Retorno para a cobertura de exibição normal. Se um usuário puder se mover sobre uma tela estendida, ou exibição expandida de zoom, forneça meios cômodos para o usuário retornar à cobertura de exibição normal.
•
Exibição completa das opções de menu. Projete um menu para exibir todas as opções apropriadas para qualquer transação em particular.
•
Menu geral. Forneça um menu geral de opções básicas como sendo o topo do nível na estrutura hierárquica de menu, um "porto seguro" ao qual um usuário sempre pode retornar como um ponto inicial consistente para entradas de controle.
•
Estrutura de menu lógica. Apresente opções de menu em grupos lógicos.
•
Retorno para menus de nível maior. Quando menus hierárquicos são usados, exija que usuários tomem uma simples ação para retornar ao nível maior anterior.
•
Retorno ao menu geral. Quando menus hierárquicos são utilizados, exija que usuários executem uma simples ação de teclar para retornar ao menu geral no nível de topo.
•
Lista geral de opções de controle. Forneça uma lista geral (menu) de opções de controle que esteja sempre disponível para servir como um "porto seguro" ou ponto inicial consistente para começar uma seqüência de transação.
•
Fácil seleção de opções importantes. Quando menus hierárquicos são usados, projete sua estrutura para permitir acesso imediato do usuário às opções críticas ou freqüentemente selecionadas.
•
Título explicativo para menu. Apresente um título explicativo para cada menu, refletindo a natureza da escolha a ser feita.
•
Indicando a posição atual na estrutura de menu. Quando menus hierárquicos são usados, apresente ao usuário alguma indicação da posição atual na estrutura de menu.
•
Opções de menu distintas de ramificação de menu. Formate a apresentação de menus hierárquicos para que essas opções às quais na verdade executam entradas de controle possam ser diferenciáveis de opções que meramente ramificamse para outros menus.
•
Apresentando códigos de opções. Quando usuários precisam selecionar opções através de entrada de código, apresente o código associado a cada opção de uma maneira distinta e consistente.
•
Destacando dados selecionados. Quando um usuário estiver executando uma operação sobre algum item de tela selecionado, destaque esse item.
•
Modo operacional. Quando uma ação está disponível sob modos operacionais diferentes, então indique claramente o modo atualmente selecionado.
•
Orientação para controle de fluxo. Em qualquer ponto de uma seqüência de transação, forneça orientação informando ao usuário como continuar.
Interfaces Auditivas
•
Sinais auditivos para alertar usuários. Durante entrada/edição de texto, forneça um sinal auditivo a qualquer hora que seja necessário chamar a atenção do usuário para a tela.
•
Reconhecimento de alarme. Forneça aos usuários um meio simples de reconhecer e desligar sinais de alarme não críticos.
•
Desligar alarme. Forneça aos usuários meios simples de desligar alarmes auditivos, sem apagar qualquer mensagem que acompanhe o sinal auditivo.
•
Codificação auditiva. Considere exibições auditivas como meios de suplementar a exibição visual, ou como meios alternativos de saída de dados em aplicações onde a exibição visual não é viável.
•
Codificação auditiva distintiva. Para saídas auditivas, empregue sons distintos para codificar itens que exijam atenção especial do usuário.
•
Saída por fala. Considere saída por fala gerada pelo computador para mensagens de orientação do usuário em ambientes com baixo ruído, quando a atenção do usuário não puder ser direcionada para uma tela ou quando fornecer uma tela é impraticável.
Gerenciamento de Erro
•
Interrupção flexível. Quando múltiplos dados são enviados em uma única transação, como no preenchimento de um formulário, permita que o usuário reveja, cancele, ou faça um backup e altere qualquer item antes de efetuar a ação de envio.
•
Opção de cancelar. Se apropriado para o controle de fluxo, forneça uma opção de cancelar e que terá o efeito de apagar quaisquer mudanças feitas pelo usuário e restaurar a tela atual para sua versão anterior.
•
Opção de finalizar. Se apropriado para o controle de fluxo, forneça uma opção de finalizar a qual terá o efeito de concluir uma seqüência de transação repetitiva.
•
Valores iniciais. Quando prováveis valores podem ser definidos para entradas de dados em uma tarefa particular, ofereça esses valores default para acelerar a entrada de dados.
•
Valores iniciais para entrada de controle. Considere preenchimento de formulário como um meio de apresentar valores iniciais para parâmetros em entradas de controle complexas.
•
Valores iniciais seguros. Se valores iniciais são fornecidos para entradas de controle, assegure que eles protegerão contra perda de dados, ou ao menos não contribuirão para o risco de perda de dados.
•
Corrigindo erros de entrada de comando. Se uma entrada de comando não for reconhecida, permita que o usuário revise o comando em vez de rejeitar o comando completamente.
•
Revisando comandos destrutivos. Se uma entrada de comando pode ter conseqüências destruidoras, exija que o usuário revise e confirme a interpretação apresentada do comando antes dele ser executado.
•
Edição de comando. Permita que usuários editem um comando estendido durante sua composição, através de redigitação, antes de tomar uma ação explícita para confirmar o comando.
•
Revisão e edição de entradas feitas pelo usuário. Para todas as entradas, seja entrada de dados ou comando, permita aos usuários editar o material estabelecido antes de solicitar o processamento do computador.
•
Posicionamento do cursor após erro. Além de fornecer uma mensagem de erro, marque a localização do erro detectado através do posicionamento do cursor naquele ponto da tela, isto é, no campo de dados ou palavra do comando.
•
Exibindo entradas errôneas. Quando uma entrada errônea tiver sido detectada, continue a apresentála, assim como a mensagem de erro, até que correções sejam feitas.
•
Edição das entradas errôneas feita pelo usuário. Após a detecção de erro, exija que o usuário preencha novamente somente a porção de entrada de dados/comando que não está correta.
•
Sugerindo correção de comando. Se um elemento de uma entrada de comando não é reconhecido, ou logicamente inapropriado, sugira ao usuário corrigir aquele elemento em vez de exigir que entre novamente com o comando inteiro.
•
Confirmação do usuário para entradas destrutivas. Quando uma entrada de controle causará uma mudança extensa nos dados armazenados, procedimentos e/ou operação do sistema, e particularmente se essa mudança não for facilmente reversível, notifique o usuário e exija conformação da ação antes de efetuála.
•
Confirmação do usuário sobre entradas destrutivas. Exija que o usuário efetue alguma ação explícita para confirmar uma entrada de dados/comando potencialmente destrutiva antes que o computador a execute.
•
Confirmação por parte do usuário em relação às ações destrutivas. Exija que usuários executem ações explícitas para confirmar ações duvidosas e/ou potencialmente destrutivas de alteração de dados antes que elas sejam aceitas para execução.
•
Confirmação por parte do usuário em relação às ações destrutivas. Exija que usuários efetuem uma ação explícita para confirmar uma entrada de controle potencialmente destrutiva antes que ela seja aceita pelo computador para execução.
•
Ações de controle reversíveis (desfazer). Permita aos usuários desfazerem uma ação de controle precedente que possa ter causado uma perda de dados não pretendida.
•
Prevenindo perda de dados no logoff. Quando um usuário solicitar logoff, verifique transações pendentes e se qualquer transação pendente não for concluída, ou se dados serão perdidos, apresente uma mensagem consultiva solicitando a confirmação por parte do usuário.
•
Usuários avisados sobre potencial perda de dados. Formule a questão da ação de confirmar para avisar usuários explicitamente sobre qualquer possível perda de dados.
•
Desfazer para reverter ações de controle. Assegure que qualquer ação do usuário pode ser imediatamente revertida por um comando de desfazer.
•
Prevenindo usuários sobre potencial perda de dados. Para condições que possam exigir atenção especial do usuário para se proteger contra perda de dados, forneça um alarme explícito e/ou mensagens de prevenção para sugerir as ações apropriadas.
•
Prevenindo perda de dados no logoff. Quando um usuário solicitar logoff, verifique transações pendentes e se qualquer transação pendente não for concluída, ou se dados serão perdidos, apresente uma mensagem consultiva solicitando a confirmação do usuário.
•
Mensagens de aviso. Quando uma entrada de dados ou comando parecer duvidosa, em termos da lógica de validação definida, apresente uma mensagem de aviso solicitando que o usuário confirme essa entrada.
•
Correção de dados imediata. Se uma transação de entrada de dados tiver sido concluída e erros forem detectados, permita que usuários façam correções diretamente e imediatamente.
•
Atraso no logon. Se um usuário tentar se autenticar em um sistema e o logon for negado devido a indisponibilidade do sistema, apresenta uma mensagem para informar ao usuário qual é o status do sistema e quando ele ficará disponível.
•
Mensagens de erro específicas. Torne o texto das mensagens de erro tão específicas quanto possível.
•
Mensagens de erro orientadas à tarefa. Adote um texto para mensagens de erro que seja apropriado para a tarefa do usuário.
•
Mensagens de erro consultivas. Se uma entrada de dados ou (mais freqüente) uma entrada de controle precisa ser feita entre um pequeno conjunto de alternativas, uma mensagem de erro que é apresentada em resposta a uma entrada errada deveria indicar as alternativas corretas.
•
Mensagens de erro breves. Faça mensagens de erro breves, mas informativas.
•
Texto neutro para mensagens de erro. Adote texto neutro para mensagens de erro; não jogue a culpa no usuário, ou personifique o computador, ou tente tornar uma mensagem divertida.
•
Mensagens de erro de vários níveis. Seguido da saída de uma mensagem de erro simples, permita que usuários solicitem uma explicação mais detalhada do erro.
•
Registro de transações anteriores. Permita aos usuários solicitarem um registro das transações anteriores com o intuito de revisar essas ações.
•
Notificação de falha de transmissão. Se a transmissão de uma mensagem não for concluída, notifique o remetente e se possível inclua uma explicação do problema.
•
Aviso de formatos incompatíveis. Se uma mensagem (ou outra transmissão de dados) chegar em formato incompatível com a decodificação fornecida pelo sistema e/ou capacidades dos dispositivos, aconselhe o destinatário a empregar ações apropriadas que não destruam a mensagem em si ou qualquer outro dado.
•
Proteção contra interrupções. Quando uma ação proposta pelo usuário for interromper uma seqüência de transação corrente, forneça meios automáticos para prevenir perda de dados; se perdas de dados em potencial não podem ser prevenidas, avise o usuário e não interrompa sem a confirmação dele.
•
Editando dados antes do envio. Permita aos usuários corrigir entradas de dados (e entradas de controle) antes de efetuarem a explícita ação ENTER.
•
Editando entradas após detecção de erro. Após a detecção de erro, permita aos usuários editarem as entradas para que eles tenham que redigitar apenas aquelas porções que estão no erro.
•
Exibindo valores iniciais. Apresente valores iniciais práticos para entrada de dados para que usuários possam revisálos e confirmálos para processamento.
Flexibilidade
•
Ponto decimal opcional. Permita a entrada opcional ou omissão do ponto decimal ao final de um número inteiro como alternativas equivalentes.
•
Zeros não significativos opcionais. Para dados numéricos gerais, permita entrada opcional ou omissão dos zeros não significativos como alternativas equivalentes.
•
Espaços simples e múltiplos equivalentes. Trate espaços simples e múltiplos como sendo equivalentes na entrada de dados; não exija que usuários contem espaços em branco.
•
Ignorando espaços na entrada de comando. Trate espaços entre as palavras simples e múltiplos como equivalente quando processar entradas de comando.
•
Validação de dados automática. Forneça lógica de validação automática dos dados para checar qualquer item que for preenchido e/ou corrija formato ou conteúdo exigido para processamento de dados subseqüente.
•
Iniciativa do usuário no controle de fluxo. Permita que os usuários tomem iniciativas e controlem a interação com o computador; tente antecipar necessidades do usuário e forneça opções de controle de usuário e respostas do computador em todos os casos.
•
•
Abreviação de comandos. Permita que usuários abreviem comandos.
Interpretando comandos com ortografia errada. Quando um conjunto de possibilidades de entradas de comando for bem definido, programe o computador para reconhecer e executar erros comuns de ortografia dos comandos, em vez de exigir um novo preenchimento.
•
Reconhecendo sinônimos de comandos. Se um sistema terá muitos usuários novatos ou ocasionais, assegure que o computador possa reconhecer uma variedade de sinônimos para cada palavra definida na linguagem de comando.
•
Reconhecendo sintaxe alternativa. Se um sistema terá muitos usuários novatos ou ocasionais, assegure que o computador possa reconhecer prováveis formas alternativas de sintaxe de comando.
•
Formulação flexível de consulta. Permita que usuários empreguem formas alternativas quando estruturarem consultas, correspondendo a alternativas comuns na linguagem natural.
•
Sinônimos para terminologia padrão. Quando um usuário solicita ajuda em um tópico específico, o computador deve aceitar sinônimos para terminologia padrão do sistema.
•
Lógica para unir consultas. Projete uma linguagem de consulta para incluir elementos lógicos que permitam unir consultas seqüenciais como uma única entrada.
•
Ligando consultas seqüenciais. Projete uma linguagem de consulta que permita ligação lógica de consultas seqüenciais.
•
Opção de suspender. Se apropriado para o controle de fluxo, forneça uma opção de suspender que terá o efeito de apresentar o status atual da transação quando um usuário deixar o sistema, e permitir a continuação do trabalho no ponto onde o usuário mais tarde registrou no sistema.
•
Controle flexível do usuário. Forneça controle flexível de transmissão de dados, para que usuários possam decidir quais dados devem ser transmitidos, quando, e onde.
•
Interrupção. Permita aos usuários interromper a preparação, revisão, ou disposição de uma mensagem, e então resumir qualquer uma dessas tarefas a partir do ponto de interrupção.
Listas
•
Formato de lista em coluna única. Formate as listas para que cada item inicie em uma nova linha; isto é, uma lista deveria ser apresentada como uma única coluna.
•
Formato de lista em coluna única. Quando múltiplas opções de menu são apresentadas em uma lista, apresente cada opção em uma nova linha, isto é, formate a lista como uma única coluna.
•
Estrutura hierárquica para listas longas. Para uma lista longa, estendendose para mais de uma página, considere adotar uma estrutura hierárquica para permitir seu particionamento lógico em listas relacionadas mais curtas.
•
Filtros para ordenar visualização de mensagem. Permita aos usuários especificarem "filtros" baseados no remetente da mensagem, tipo ou conteúdo, que possa controlar a ordem em que as mensagens recebidas serão lidas.
Sobrecarga da memória do usuário
•
Letras maiúsculas e minúsculas equivalentes. Para dados codificados, trate letras maiúsculas e minúsculas como sendo equivalentes.
•
Questões exibidas separadamente. Em um diálogo de pergunta e resposta, apresente cada questão separadamente; não exija que usuários respondam várias questões de uma vez.
•
Recapitulando respostas anteriores. Quando uma série de questões propostas pelo computador são vinculadas umas às outras, apresente as respostas de questões anteriores quando essas fornecerão contexto para ajudar o usuário a responder uma questão atual
•
Apresentação de parâmetros de controle. Permita que usuários revisem quaisquer parâmetros que estejam disponíveis.
•
Exibição explícita de opções. Quando as entradas de controle para qualquer transação forem selecionadas entre um pequeno conjunto de opções, mostreas em um menu adicionado à tela de trabalho, em vez de exigir que o usuário lembrese delas ou acesse uma tela de menu a parte.
•
Informação de orientação sempre disponível. Assegure que informações específicas de orientação do usuário estejam disponíveis para apresentação em qualquer ponto de uma seqüência de transação.
•
Carga mínima de memória sobre o usuário. Projete os procedimentos de transmissão de dados de forma a minimizar a carga de memória sobre o usuário.
•
Listas de distribuição do sistema. Forneça listas de distribuição formal reconhecidas pelo sistema para que usuários possam especificar múltiplos endereços através do nome de uma única lista de distribuição.
•
Apelidos de endereçamento atribuídos pelos usuários. Permita que usuários definam apelidos para endereços formais, salvar esses apelidos em seus próprios arquivos, e especificálos quando estiverem endereçando mensagens.
•
Enfileiramento automático para transmissão. Forneça enfileiramento automático para mensagens que estejam prontas para serem transmitidas, com o intuito de reduzir o envolvimento do usuário na rotina de processar a transmissão de dados.
•
Enfileirando transmissões mal sucedidas. No evento de falha na transmissão, forneça enfileiramento automático para preservar mensagens prontas para serem transmitidas.
•
Manutenção automática dos registros. Quando um log de transmissão de dados é exigido, mantenhao automaticamente, baseado nas especificações do usuário em relação aos tipos de mensagem e formatos de registros.
•
Registros automáticos sobre acesso aos dados. Quando registros de acesso aos dados são necessários, o computador deve mantêlos automaticamente; não conte com os usuários para executar ações críticas de manutenção de registros.
Ícones
•
Símbolos pictóricos. Projete símbolos pictoriais (por exemplo, ícones, pictogramas) para que se assemelhem aos objetos ou processos que eles representam, e teste o conjunto de símbolos resultantes com um grupo representativo de usuários para assegurar que os significados pretendidos serão entendidos.
•
Menus iconográficos. Quando usuários do sistema possuem bases lingüísticas diferentes, considere fornecer menus gráficos no qual apresenta ícones para representar as opções de controle.
•
Rótulos verbais complementares. Se ícones forem usados para representar ações de controle em menus, apresente um rótulo verbal com cada ícone para ajudar a garantir que o significado pretendido será entendido.
Poluição visual
•
Somente dados essenciais apresentados. Reduza os dados apresentados de acordo com as necessidades do usuário, forneça somente dados necessários e imediatamente úteis para qualquer transação; não sobrecarregue as telas com dados fora de contexto.
•
Apenas informação necessária apresentada. Ajuste a apresentação gráfica às necessidades do usuário e forneça apenas aqueles dados necessários às tarefas do usuário.
•
Somente informação necessária apresentada. Ajuste a tela em qualquer transação para as informações atualmente necessárias ao usuário, para que somente dados relevantes sejam apresentados.
•
Somente escala simples. Projete os gráficos para que somente uma escala simples seja apresentada em cada eixo, em vez de incluir escalas diferentes para curvas no gráfico.
•
Diagramas. Utilize diagramas para mostrar relações espaciais, com foco seletivo nos dados requeridos especificamente por uma tarefa do usuário, em aplicações onde desenhar uma ilustração por completo talvez seja desnecessariamente complicado.
•
Falando diretamente para os usuários. Escolha o texto para orientação do usuário que fale diretamente com o usuário, em vez de falar sobre os usuários.
•
Texto conciso de sugestões. Utilize texto conciso para sugestões; elimine palavras irrelevantes.
•
Procedimento de logon separado. Em aplicações onde usuários precisam efetuar logon no sistema, projete o logon como um procedimento separado que é concluído antes que um usuário seja obrigado a selecionar entre várias opções operacionais.
Encriptação
•
Encriptação. Quando dados sensíveis podem ser expostos ao acesso não autorizado, forneça a capacidade para encriptar esses dados.
•
Encriptando mensagens. Quando isso for necessário para transmitir dados delicados através de canais de comunicação não seguros, forneça encriptação automática para proteger tais dados.
•
Proteção automática dos dados transmitidos. Assegure que seja quais forem as medidas adotadas para proteção de dados durante a transmissão – por exemplo, encriptação, checagem de paridade, bufferização até que ocorra a confirmação do destinatário – elas serão aplicadas automaticamente, sem a necessidade de uma ação do usuário.
•
Autenticação de origem de mensagem. Quando um usuário precisa confirmar a identidade de uma origem de mensagem, forneça auxílio computacional para este propósito.
Acessibilidade e adaptação ao usuário
•
Dados preenchidos somente uma vez. Garanta que o usuário tenha que entrar com qualquer dado somente uma vez, e que o computador possa acessar esses dados caso ele seja necessário para a mesma tarefa ou para tarefas diferentes.
•
Método único de entrada de dados. Projete as transações de entrada de dados e as telas associadas de forma com que o usuário consiga utilizar um método de manipulação, e não precise alterar para outro.
•
Mínimo uso de shift. Projete as transações de entrada de dados para minimizar a necessidade do uso de shift.
•
Posicionamento automático do cursor. Quando um formulário para entrada de dados é apresentado, o computador deveria posicionar o cursor automaticamente no início do primeiro campo de entrada.
•
Apontamento. Quando a entrada de dados gráfica envolver apontamento freqüente em uma superfície da tela, projete a interface com o usuário de forma que as ações para controle de apresentação e controle de seqüência também sejam executáveis via apontamento, para minimizar a troca de um dispositivo de entrada para outro.
•
Zoom para posicionamento preciso. Quando a entrada de dados exigir o posicionamento exato de elementos gráficos, usuários deveriam ser permitidos a solicitar a expansão da área crítica apresentada ("zoom") para tornar a tarefa de posicionamento mais fácil.
•
Zoom para exibir expansão. Quando um usuário possa precisar entender relações entre dados exibidos mais precisamente, ou para visualizar dados em fotos, diagramas, mapas, etc. em mais detalhes, forneça a capacidade de zoom que permita ao usuário expandir a tela de qualquer área selecionada.
•
Codificação de cor redundante. Torne a codificação de cor redundante com alguma outra característica de exibição como simbologia; não codifique apenas pela cor.
•
Atualização automática da tela. Quando dados exibidos são alterados como um resultado de eventos externos, um usuário deve ser capaz de solicitar atualização automática (gerada pelo computador) dos dados alterados, e ser capaz de controlar a taxa de atualização.
•
Seleção de menu através de entrada digitada. Quando a seleção de menu é um meio secundário (ocasional) de entrada de controle, e/ou somente pequenas listas de opções são necessários, então considere a execução da seleção através de entrada digitada.
•
Evitando seleção de menu com entrada de comando. Permita que usuários experientes evitem uma série de seleções de menu e façam uma entrada de comando diretamente.
•
Posicionamento do cursor para opções entradas pelo teclado. Quando usuários precisam selecionar opções através de entradas pelo teclado de um código correspondente, posicione o cursor em uma área de entrada de controle na geração da tela.
•
Linguagem de comando. Considere diálogos de linguagem de comando para tarefas envolvendo uma ampla variedade de entradas de controle, onde os usuários podem ser altamente treinados e que usem o sistema freqüentemente.
•
Controle de fluxo flexível. Forneça meios flexíveis de controle de fluxo para que os usuários possam efetuar transações envolvendo entrada de dados, apresentação, e 109 A N E X O I . D I R E T R I Z E S V Á L I D A S E P E R T I N E N T E S
transmissão, ou possam obter orientação que for necessária na conexão com qualquer transação.
•
Orientação flexível para o usuário. Quando técnicas adotadas para orientação do usuário (apresentação de listas de opções, sugestão de comando, etc.) puderem atrasar usuários experientes, forneça caminhos ou modos alternativos permitindo um usuário evitar procedimentos padrão de orientação.
•
Facilidade ou dificuldade apropriada para ações do usuário. Assegure que a facilidade das ações do usuário será compatível com os fins desejados; torne ações freqüentes ou urgentes fáceis de serem executadas, mas faça com que ações potencialmente destrutíveis exijam atenção extra por parte do usuário.
Ajuda
•
Tela de previsão. Para auxiliar um usuário a entender e responder efetivamente a complexas atualizações de dados, considere apresentar uma previsão dos estados de dados futuros baseados em análise computadorizada de um modelo apropriado da dinâmica dos dados.
•
Diálogos de pergunta e resposta. Considere diálogos de pergunta e resposta para tarefas de entrada de dados rotineiras, onde os itens de dados são conhecidos e sua disposição pode ser limitada, onde usuários terão pouco ou nenhum treinamento, e onde se espera que a resposta do computador seja moderadamente rápida.
•
Orientação online do sistema. Forneça material de referência descrevendo as capacidades do sistema e procedimentos disponíveis aos usuários para exibição online.
•
Sugestões solicitadas pelo usuário. Permita aos usuários solicitarem sugestões geradas pelo computador quando for necessário determinar parâmetros exigidos em uma entrada de comando, ou para determinar opções disponíveis para um próximo comando apropriado.
•
Lista geral de comandos. Forneça uma lista geral de comandos básicos, com orientação de formato de comando apropriado, que sempre será disponível para servir como um "porto seguro" ou ponto inicial consistente para compor entradas de comando.
•
Índice de comandos. Em aplicações onde um usuário pode efetuar entradas de comando, forneça um índice de comandos online para guiar a seleção e composição dos comandos.
•
Lista geral de opções de controle. Forneça uma lista geral de opções de controle básico que estará sempre disponível para servir como um "porto seguro" ou ponto inicial consistente para entradas de controle.
•
Auxílio de controle gráfico para usuários eventuais. Para usuários eventuais, considere fornecer auxílio gráfico para complementar outros tipos de controle de fluxo.
•
Sugerindo entradas de controle. Forneça aos usuários qualquer informação que possa ser necessária para guiar entradas de controle em qualquer ponto em uma seqüência de transação, através da incorporação de sugestões na tela e/ou através de sugestões em respostas aos pedidos de ajuda.
•
Sugestões solicitadas pelo usuário. Quando usuários variam em relação à experiência, o que ocorre freqüentemente, forneça sugestões como um atributo opcional de orientação que possa ser selecionado por novatos, mas que possa ser omitido por usuários experientes.
•
Maneiras fáceis de conseguir orientação. Permita que usuários alternem entre qualquer transação de tratamento de informações e seu material de orientação associado.
•
Documentando mensagens de erro. Como um complemento à orientação on
line, inclua na documentação do sistema uma listagem e explicação de todas as mensagens de erro.
•
Ajuda. Em acréscimo aos auxílios explícitos (rótulos, prompts, mensagens de aviso) e auxílios implícitos (dica), permita aos usuários obter, além disso, orientação através da solicitação de ajuda.
•
Ajuda orientada à tarefa. Adapte a resposta de uma solicitação de ajuda em relação o contexto da tarefa e da transação atual.
Gráficos e Animações •
Uso restrito de escala tridimensional. Considere a escala tridimensional, onde o eixo Z é adicionado à tela, somente em aplicações especiais para usuários experientes.
•
Ordenando dados em gráficos de barras empilhadas. Em gráficos de barras empilhadas, ordene as categorias de dados dentro de cada barra da mesma seqüência, com as categorias menos variáveis na parte de baixo e as mais variáveis na parte de cima.
•
Auxílios para análise de ilustrações. Quando usuários precisam analisar imagens em detalhes, forneça auxílios apropriados por parte do computador para esse propósito.

Durabilidade das Diretrizes de Usabilidade de

Transcrição

Documentos relacionados

REGULAMENTO DE PREMIAÇÃO TOP CATEGORIA APRAS 2013

Top Categoria APRAS REGULAMENTO 2015

de estudos

PCI410025 - Pós Graduação em Ciência da Informação

3,8% - Apas

Apresentação do PowerPoint

ÁREA TEMÁTICA: 2

ICC406 - IComp

Title, 36-Point Arial Bold – Title Case

História das redes sociais Desde sua introdução