Usabilidade é sinônimo de facilidade de uso. Se um produto é fácil de usar, o usuário tem maior produtividade: aprende mais rápido a usar, memoriza as operações e comete menos erros. Veja também essa entrevista sobre o que é usabilidade.
O leitor Milano fez uma crítica ferrenha sobre essa mania estadunidense de criar termos só para vender seu peixe. O resultado é que sofremos uma enxurrada de termos tão parecidos que é difícil definir onde termina um e começa outro.
Como vocês verão na conversa, vejo o fenômeno como inevitável ao processo. Se estão sendo criadas coisas novas, é preciso dar uma de Adão e dar nome às elas. Como não temos o discernimento absoluto de Deus, temos que nos contentar com nomes meramente aceitáveis.
Para quem não pôde assistir no ano passado, a Ilearn está
promovendo seu novo ciclo de palestras gratuitas online dias 18 e 21 de janeiro,
com vídeoconferência e tudo. Falarei sobre a importância
da Usabilidade e o Prof. Bechara falará sobre webstandards, dois assuntos
quentíssimos. Como as palestras não serão gravadas e o
número de vagas é limitada, corra e se
inscreva já. Mesm quem não estiver interessado no assunto, vale à pena só pra ver a ferramenta que eles desenvolveram em Flash para conferências online. No Brasil, funciona melhor que o Breeze da Macromedia, pode acreditar.
Quem quiser dar uma espiada nos slides, ainda tenho que fazer algumas alterações,
mas o da palestra anterior está disponível nessa nova
seção do site.
O leitor Leonardo Cidral me mandou um email perguntando se era melhor exibir os erros decorrentes da validação de um formulário no próprio corpo da página ou em caixas de alerta do Javascript. Na maioria dos casos, é melhor a primeira alternativa, mas nada impede que se tenha as duas, caso o erro seja muito grave (num contexto de aplicação, claro).
Janelinhas de Javascript não são acessíveis para quem
anda com o Javascript desligado ou abre a página num
dispositivo móvel. Depois os usuários tem o costume de
não ler essas janelinhas e simplesmente clicar sim em
todos os diálogos desse tipo. Uma vez fechada a janela,
o usuário não tem como abrí-la de novo.
A solução mais comum e eficiente é uma mensagem
grande de que faltou alguma informação no formulário no topo da página (incluindo um ícone triangular amarelo com um ponto exclamação) e ao lado dos campos que possuem erros explicar o que está errado.
Como prometido na entrevista
para o Tableless, estou preparando uma nova versão deste blog para
2005 e a primeira coisa que fiz foi verificar se as subcategorias do Movable
Type permitiriam a expansão que pretendo fazer. Além de integrar
meu portifólio no gerenciador, vou poder separar os artigos, pesquisas
acadêmicas, entrevistas e etc. Parece que vai funcionar bem, já
adicionei alguns tipos novos.
Esse Movable Type tá ficando um gerenciador de conteúdo poderosíssimo.
Tô até cogitando usá-lo em projetos comerciais.
Porém, só depois de ter montado o diagrama de navegação
para o novo Usabilidoido (totalizando 25 seções) é que
me dei conta de que teria que criar ícones para as novas ou então
deixar de lado os ícones atuais. Para mim, nesse tamanho diminuto eles
dão um charme a mais sem poluir a página. E vocês, o que
acham?
Sim, quero ouvir a opinião de vocês para a nova versão!
Acho que não terei a oportunidade de fazer testes de usabilidade formais,
até porque só conheço pessoalmente um punhado de leitores.
A esmagadora maioria está espalhada por todos as demais cidades desse
país.
Na ArqHp, Theofilho Mathias
perguntou como convencer seu cliente a não mudar sua loja de HTML para
esse modelo da Digitalpages,
que tenta imitiar em Flash um catálogo de vendas impresso. O pessoal
da lista foi unânime: alerte para o encarecimento do custo. O Irapuan
Martinez foi além e citou as desvantages de interação daquele
formato:
Virar folhas de revistas reais é um esforço. Pra querer repetir,
no meio on line, O ESFORÇO DA VIDA REAL? E pelo menos, o folheto posso
aprochegar perto das janelas da alma e conseguir ler as letras miúdas.
Com o jornalzinho em mãos, não preciso clicar, lançar
uma folha nova (pop up) e esperar uma segunda animação Flash
carregar o que quero ver mais detalhado.
É um esforço patético. Se web não é TV,
que dirá, uma publicação com páginas a serem viradas.
Recebi a monografia da leitora Tissiane Quevedo sobre uma pesquisa feita com
as páginas iniciais dos websites de três universidades catarinenses,
seguindo os parâmetros da Engenharia da Usabilidade. Soa familiar não?
Tem tanto a ver com meu Trabalho de Conclusão de Curso que aproveitei
e já citei na versão
final.
O grande mérito do trabalho dela é dar uma visão bastante
ampla para uma monografia sobre a Engenharia de Usabilidade, disciplinas que
foca na análise e solução de problemas de usabilidade.
Em primeio lugar ela conceitua Usabilidade e Ergonomia, em segundo levanta recomendações
para designs usáveis provenientes de diversos autores (muito bem resumidas,
recomendo), em terceiro aplica testes com usuários e quantifica resultados
precisos e, afinal, faz recomendações específicas ao que
pode ser mudado aos websites para melhorarem. É isso aí que faz
um Engenheiro de Usabilidade (também chamado de Analista de Usabilidade).
Encontrei no Google Scholars a monografia
sobre Testes de Usabilidade escrita por Kátia Gomes Ferreira. Grande
achado. Sempre procurei uma referência em português sobre o assunto
e nunca tinha encontrado nada que fosse aprofundado.
Quem deseja realizar testes de usabilidade com validade científica,
precisos e quantitativos, agora não tem mais a desculpa de falta de referência
em português. A monografia já é suficiente para começar
a fazer testes. Contém exemplos dos documentos necessários para
a realização dos testes, como por exemplo, o Guia do Avaliador.
Lá, se encontra o roteiro do teste, sente só:
O avaliador recebe o participante, o cumprimenta e o convida a se sentar
e se sentir confortável e relaxado.
O avaliador entrega ao participante o Questionário para Identificação
do Perfil do Participante (Anexo 3).
Após completar o questionário, o participante recebe o Script
de Orientação do teste (Anexo 4). O avaliador lê o script
junto com o participante reforçando que o anonimato do produto deve
ser mantido após os testes e que o centro da
avaliação é o produto e não o participante em
si. O participante deve ser informado que ele estará sendo observado
e filmado e que a integridade do participante será totalmente resguardada,
sendo utilizada a observação e as imagens somente para fins
de análise do teste. O avaliador deve reforçar outras informações
constantes do script e retirar dúvidas do participante sobre a sessão
de teste.
Após serem passadas as orientações, o avaliador informará
ao participante que ele pode utilizar o sistema livremente durante cinco minutos.
Passado este tempo, o avaliador irá orientar o participante a retornar
à Área de Trabalho do Windows (se for o caso) e será
entregue a lista de tarefas para execução (Lista de Tarefas,
Anexo 5). Os acontecimentos observados pelo avaliador deverão ser registrados
no formulário de Coleta de Dados pelo Avaliador (Anexo 6). Um outro
integrante da Tools Corporation irá cronometrar e registrar o tempo
gasto na realização das tarefas.
Depois de completadas todas as tarefas, o avaliador irá entregar
ao participante o Questionário de Avaliação do Sistema
pelo Participante (Anexo 7) para ser completado.
Depois que o participante acabou de completar este questionário,
o avaliador informará que será dada uma pausa de dez minutos
para o café.
Passada pausa para o café, terá inicio a sessão de
questionamento do participante sendo usado como guia o formulário de
Tópicos para Questionamento (Anexo 8). Outros tópicos além
dos descritos neste formulário deverão ser acrescentados de
acordo com os acontecimentos ocorridos durante o teste.
O avaliador agradece ao participante, entrega- lhe um brinde por sua colaboração
e se despede.
Testes como esses são excelentes para garantir a usabilidade de uma
aplicação. No projeto de websites, entretanto, prefiro uma abordagem
mais solta, como a sugerida pelo Steve Krug, no Don´t
Make Me Think.
Num antigo post falei um pouco sobre as chamadas táticas
de guerrilha em testes de usabilidade.Vamos lá, pessoal, usabilidade
é para todos!
Após algumas semanas sem dormir direito, terminei finalmente meu Trabalho
de Conclusão de Curso em Jornalismo. O assunto, é claro, tinha
que ter a ver com Web.
Donald Norman, sócio do Jakob
Nielsen e um dos maiores gurus do design, respondeu uma pergunta pública
que fiz a ele. Li muitos artigos de sua autoria e estou finalizando seu livro
mais conhecido, The
Design of Everyday Things, que trata da usabilidade dos objetos por uma
perspectiva da psicologia cognitiva. Fiquei extremamente feliz por ser contemplado
por tão sábia e ampla resposta, aprendi muuuuito. Recomendo a
todos que façam suas perguntas
ao homem.
Minha dúvida surgiu quando tive contato com um estudo que relacionava
usabilidade percebida à estética. Concluí que no contexto
Web, esta última é mais importante, porém, aproveitei a
oportunidade para que o autor do badalado Emotional
Design me confirmasse isso. Claro, como um legítimo bom guru, desconfirmou:
"não é mais, nem menos importante: tudo depende da ocasião".
Ah, ficar em cima do muro é fácil. Fácil nada, note a justificativa
do homem.
Pergunta
Websites e aplicações Web são supostamente feitos para
serem usados uma ou poucas vezes, então a usabilidade percebida (correlacionada
com a estética) seria mais importante do que a usabilidade real (tempo
para finalização da tarefa, número de erros encontrados,
etc) na Web?
(Não estou dizendo que a usabilidade não é importante,
só estou na dúvida se a estética é mais importante
para superar a competição brutal da Web e conquistar a atenção
do usuário do que a usabilidade real que não é percebida)