Pod Cast sobre conceitos de usabilidade, testes de usabilidade e o dia da usabilidade, escute em:
http://www.podcast1.com.br/blog.php?codigo_canal=2114
sábado, 12 de maio de 2007
sexta-feira, 27 de abril de 2007
Palestra online sobre Usabilidade
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.
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.
Mensagens de erro em Javascript
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.
Autor
Frederick van Amstel - Quem? / Contato - 26/12/2004
Palavras-chave
diálogo alerta erros erro mensagem mar
Opções
Imprimir
Enviar
Assinar
function disableForm(theform) {
if (document.all document.getElementById) {
for (i = 0; i
Email:
Fazer login sem registrar-se é um crime
Teclando perigosamente
Digitar planilhas na Web pode enlouquecer
Comentários
Diego Pires 26/12 às 16:01
Muito boa essa sugestão da mensagem no topo da página. Vou pensar em alguma forma de implementar isso de uma boa forma nos meus sistemas. Alguma sugestão?
Mateus Damião 26/12 às 19:23
Olá
Visito o Usabilidoido diariamente, tem sido de grande ajuda para mim, no sentido de construção de um conceito de internet mais objetivo, usável e focado no usuário.
Quanto ao artigo muito interessante isso, ótima dica.
Sempre pensei que as "berrantes" caixas de alerta fossem a melhor solução.
Acredito que acontece o mesmo que acontece no efeito "cegeuira de banner", e por isso, não seria a melhor solução.
Talvez o uso de alguma técnica como por exemplo um script que gera logo acima ou ao lado o alerta, no caso de uma validação de formulário.
T+ ;)
CARLÃO 29/06 às 10:53
Gostaria de ajuda, pois não consigo acessar algumas imagens e e-mails.A titulo de exemplo, vejam a mensagem que aparece quando tento acessar um e-mail.
javascript:readmsg(2,false)
Guilherme Gonçalves Brito 20/04 às 10:03
Existe algum documento que descreva os padrões de usabilidade para internet??? onde posso Encontrá-lo???Desde já muito Obrigado!!!
Guilherme Gonçalves Brito
Frederick van Amstel 20/04 às 11:12
Existe o Padrão E-Poupatempo do Governo de São Paulo:
http://www.cqgp.sp.gov.br/downloads/LTS008-RT-010V2.PDF
E também algumas bibliotecas de padrões de interação em inglês:
http://www.visi.com/~snowfall/InteractionPatterns.html
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.
Autor
Frederick van Amstel - Quem? / Contato - 26/12/2004
Palavras-chave
diálogo alerta erros erro mensagem mar
Opções
Imprimir
Enviar
Assinar
function disableForm(theform) {
if (document.all document.getElementById) {
for (i = 0; i
Email:
Fazer login sem registrar-se é um crime
Teclando perigosamente
Digitar planilhas na Web pode enlouquecer
Comentários
Diego Pires 26/12 às 16:01
Muito boa essa sugestão da mensagem no topo da página. Vou pensar em alguma forma de implementar isso de uma boa forma nos meus sistemas. Alguma sugestão?
Mateus Damião 26/12 às 19:23
Olá
Visito o Usabilidoido diariamente, tem sido de grande ajuda para mim, no sentido de construção de um conceito de internet mais objetivo, usável e focado no usuário.
Quanto ao artigo muito interessante isso, ótima dica.
Sempre pensei que as "berrantes" caixas de alerta fossem a melhor solução.
Acredito que acontece o mesmo que acontece no efeito "cegeuira de banner", e por isso, não seria a melhor solução.
Talvez o uso de alguma técnica como por exemplo um script que gera logo acima ou ao lado o alerta, no caso de uma validação de formulário.
T+ ;)
CARLÃO 29/06 às 10:53
Gostaria de ajuda, pois não consigo acessar algumas imagens e e-mails.A titulo de exemplo, vejam a mensagem que aparece quando tento acessar um e-mail.
javascript:readmsg(2,false)
Guilherme Gonçalves Brito 20/04 às 10:03
Existe algum documento que descreva os padrões de usabilidade para internet??? onde posso Encontrá-lo???Desde já muito Obrigado!!!
Guilherme Gonçalves Brito
Frederick van Amstel 20/04 às 11:12
Existe o Padrão E-Poupatempo do Governo de São Paulo:
http://www.cqgp.sp.gov.br/downloads/LTS008-RT-010V2.PDF
E também algumas bibliotecas de padrões de interação em inglês:
http://www.visi.com/~snowfall/InteractionPatterns.html
Cadastros são barreiras desnecessárias
Não gosto de preencher cadastros, mas sou obrigado a fazer isso quase que semanalmente para experimentar novos serviços gratuitos e pagos na Web. Antigamente costumava preencher cadastros falsos, mas a piada logo perdeu a graça.
Não tenho dados estatísticos, mas acredito que a maioria das pessoas odeie preencher cadastros e só a minoria efetivamente os preenche. Fiz uma divertida enquete em áudio com meus colegas da faculdade de Comunicação Social da UFPR sobre o assunto:
Cadastros são legais? [MP3] 3'88"
Note como na enquete, com exceção do Jackson Sardá (o cara ingênuo da foto), todos tem uma imagem negativa dos cadastros. Porquê disso?
Em primeiro lugar, ao navegar na Web, o usuário está interagindo pelo mouse. Trocar para o teclado exige um certo custo, mais ainda se o usuário não conhecer a tecla Tab que navega entre as caixas de entrada de texto e tiver que ficar alternando mouse-teclado-mouse-teclado. Isso é muito cansativo.
Em segundo, formulários no mundo real estão associados a coisas chatas da vida, tais como prova final, pagamento de contas, imposto de renda, hospitais e etc.
Em terceiro, boa parte dos formulários na Web aproveitam a oportunidade para extorquir do usuário dados que não seriam necessários para a prestação do serviço. Os profissionais de marketing não entendem que cadastro não é feito para mineração de dados (data-mining), mas sim para permitir que o usuário obtenha o serviço.
Em quarto, a esmagadora maioria dos formulários tem problemas de usabilidade e design, inclusive nos de papel. Os mais pedantes são a exigência de um formato fixo para a entrada de dados (ex: "digite seu CPF sem pontos ou traços") e as mensagens de erro que não ajudam a resolver problemas.
Note no exemplo abaixo como a instrução é confusa para usuários leigos -- poucos sabem o que são "caracteres especiais". A mensagem de ajuda lá de baixo instrui o usuário a clicar num botão "cadastrar senha" para recuperá-la. Talvez não fosse necessário tal número de telefone caso houvesse um botão "alterar senha".
Ainda existem outros fatores, mas não vou citá-los senão ninguém mais vai querer fazer cadastros na Web. Não digo que eles devem se extintos, até porque em certos momentos o benefício que um cadastro traz ao usuário compensa o esforço, mas ressalto que deve haver um bom motivo para cada dado exigido.
Estávamos discutindo na Ilearn sobre o tamanho do cadastro necessário para assistir as palestras online que estou ministrando. A Sonia me perguntou quais dados eu achava essencial pedir. Respondi que só deveriam ser pedidos os dados que o usuário pudesse visualizar o benefício de fornecê-lo.
Ao contrário do que o Irapuan julgou, as palestras que a Ilearn promove não visam angariar dados pessoais. Pedimos os dados primeiro por uma questão de responsabilidade (para que as vagas não sejam ocupadas por um engraçadinho que não apareça) e segundo para planejar cursos presenciais, por exemplo. Concordo plenamente que isso não está claro no cadastro e que alguns dados nem precisariam ser pedidos, mas já estamos trabalhando para mudar isso.
O CPF, por exemplo, já não será mais cobrado daquela forma. Durante a discussão, fiz uma inusitada analogia sobre o efeito subjetivo da sequência do formulário atual:
Você disse que o pessoal não está preenchendo com dados errados. Talvez isso fosse diferente se o formulário de inscrição não pedisse o CPF logo de cara. Do jeito que está ele invoca seriedade, funciona semelhante a um leão de chácara que pede a identidade na entrada de uma boate pra ver se é de maior. Se esse CPF fosse apenas um dos campos no formulário completo, esse efeito seria amenizado.
Prevejo que no futuro uma empresa surgirá com uma solução de cadastro único, tal como o .NET Passport da Microsoft, mas que só trabalhe com isso. Assim, ela pod fazer acordos com outras empresas para trazer comodidade aos seus clientes, que não precisariam preencher novos cadastros. Bastaria um login e senha universal e o usuário estaria dentro do orkut, G-a-z-z-a-g, Gmail, palestras da Ilearn e o que for.
[ Nota] Se alguém ficar rico com essa idéia, por favor, me mande uma caixa de bombons =)
Autor
Frederick van Amstel - Quem? / Contato - 13/04/2005
Palavras-chave
formulário registro cadastro cadastrar registrar dados informações data-mining boti
Opções
Imprimir
Enviar
Assinar
function disableForm(theform) {
if (document.all document.getElementById) {
for (i = 0; i
Email:
Fazer login sem registrar-se é um crime
Cadastro no Concurso Trama Universitário
Designers são heróis e programadores são vilões?
Comentários
Antonio Santos 14/04 às 13:09
Acho que nenhuma empresa (a não ser medalhões como a própria Microsoft) via apostar nisso por enquanto. A grande maioria dos programinhas como Gator e barras de Alexa ou Google que prometem preencher algum dado do usuário em formulários dão a impressão de maior insegurnaça. O Gator é conhecido spyware e este favor de preencher pra vc vem em troca de espionar sua navegação e estatísticas de sua vida de cobaia nos labirintos da web.Minha impressão é que isto gerou um efeito contrário, isto é, um lugar onde seus dados fiquem armazenados dá mais insegurança ao usuário. Quem está armazenando merece minha confiança?Há outro problema (o de sempre): padrões. Os campos deveriam ser padronizados e se não consegue isto nem de tantas outras coisas mais simples...
Fred 14/04 às 13:23
Concordo Antonio, o desafio maior vai ser justamente inspirar confiança. As ferramentas atuais não são convincentes, mas acredito que seja possível conseguir uma solução que inspire confiança.
Essa empresa iria estabelecer padrões de cadastro e quem quisesse aderir ao sistema, teria que aderir aos padrões. Claro que para fazer isso, ela dependeria de muita negociação. Por isso que disse que essa empresa deveria ser independente e trabalhar somente com isso.
Agora que a gente está discutindo, lembrei de uma funcionalidade que possui o Gerenciador de Conteúdo Drupal. Se você possui uma conta em pelo menos um site que use o sistema, você pode fazer o login em qualquer outro desse jeito: seu_login@dominio. Onde dominio é o endereço do site drupal onde você já tinha cadastro. Um site consulta o outro, não sei como.
Não tenho dados estatísticos, mas acredito que a maioria das pessoas odeie preencher cadastros e só a minoria efetivamente os preenche. Fiz uma divertida enquete em áudio com meus colegas da faculdade de Comunicação Social da UFPR sobre o assunto:
Cadastros são legais? [MP3] 3'88"
Note como na enquete, com exceção do Jackson Sardá (o cara ingênuo da foto), todos tem uma imagem negativa dos cadastros. Porquê disso?
Em primeiro lugar, ao navegar na Web, o usuário está interagindo pelo mouse. Trocar para o teclado exige um certo custo, mais ainda se o usuário não conhecer a tecla Tab que navega entre as caixas de entrada de texto e tiver que ficar alternando mouse-teclado-mouse-teclado. Isso é muito cansativo.
Em segundo, formulários no mundo real estão associados a coisas chatas da vida, tais como prova final, pagamento de contas, imposto de renda, hospitais e etc.
Em terceiro, boa parte dos formulários na Web aproveitam a oportunidade para extorquir do usuário dados que não seriam necessários para a prestação do serviço. Os profissionais de marketing não entendem que cadastro não é feito para mineração de dados (data-mining), mas sim para permitir que o usuário obtenha o serviço.
Em quarto, a esmagadora maioria dos formulários tem problemas de usabilidade e design, inclusive nos de papel. Os mais pedantes são a exigência de um formato fixo para a entrada de dados (ex: "digite seu CPF sem pontos ou traços") e as mensagens de erro que não ajudam a resolver problemas.
Note no exemplo abaixo como a instrução é confusa para usuários leigos -- poucos sabem o que são "caracteres especiais". A mensagem de ajuda lá de baixo instrui o usuário a clicar num botão "cadastrar senha" para recuperá-la. Talvez não fosse necessário tal número de telefone caso houvesse um botão "alterar senha".
Ainda existem outros fatores, mas não vou citá-los senão ninguém mais vai querer fazer cadastros na Web. Não digo que eles devem se extintos, até porque em certos momentos o benefício que um cadastro traz ao usuário compensa o esforço, mas ressalto que deve haver um bom motivo para cada dado exigido.
Estávamos discutindo na Ilearn sobre o tamanho do cadastro necessário para assistir as palestras online que estou ministrando. A Sonia me perguntou quais dados eu achava essencial pedir. Respondi que só deveriam ser pedidos os dados que o usuário pudesse visualizar o benefício de fornecê-lo.
Ao contrário do que o Irapuan julgou, as palestras que a Ilearn promove não visam angariar dados pessoais. Pedimos os dados primeiro por uma questão de responsabilidade (para que as vagas não sejam ocupadas por um engraçadinho que não apareça) e segundo para planejar cursos presenciais, por exemplo. Concordo plenamente que isso não está claro no cadastro e que alguns dados nem precisariam ser pedidos, mas já estamos trabalhando para mudar isso.
O CPF, por exemplo, já não será mais cobrado daquela forma. Durante a discussão, fiz uma inusitada analogia sobre o efeito subjetivo da sequência do formulário atual:
Você disse que o pessoal não está preenchendo com dados errados. Talvez isso fosse diferente se o formulário de inscrição não pedisse o CPF logo de cara. Do jeito que está ele invoca seriedade, funciona semelhante a um leão de chácara que pede a identidade na entrada de uma boate pra ver se é de maior. Se esse CPF fosse apenas um dos campos no formulário completo, esse efeito seria amenizado.
Prevejo que no futuro uma empresa surgirá com uma solução de cadastro único, tal como o .NET Passport da Microsoft, mas que só trabalhe com isso. Assim, ela pod fazer acordos com outras empresas para trazer comodidade aos seus clientes, que não precisariam preencher novos cadastros. Bastaria um login e senha universal e o usuário estaria dentro do orkut, G-a-z-z-a-g, Gmail, palestras da Ilearn e o que for.
[ Nota] Se alguém ficar rico com essa idéia, por favor, me mande uma caixa de bombons =)
Autor
Frederick van Amstel - Quem? / Contato - 13/04/2005
Palavras-chave
formulário registro cadastro cadastrar registrar dados informações data-mining boti
Opções
Imprimir
Enviar
Assinar
function disableForm(theform) {
if (document.all document.getElementById) {
for (i = 0; i
Email:
Fazer login sem registrar-se é um crime
Cadastro no Concurso Trama Universitário
Designers são heróis e programadores são vilões?
Comentários
Antonio Santos 14/04 às 13:09
Acho que nenhuma empresa (a não ser medalhões como a própria Microsoft) via apostar nisso por enquanto. A grande maioria dos programinhas como Gator e barras de Alexa ou Google que prometem preencher algum dado do usuário em formulários dão a impressão de maior insegurnaça. O Gator é conhecido spyware e este favor de preencher pra vc vem em troca de espionar sua navegação e estatísticas de sua vida de cobaia nos labirintos da web.Minha impressão é que isto gerou um efeito contrário, isto é, um lugar onde seus dados fiquem armazenados dá mais insegurança ao usuário. Quem está armazenando merece minha confiança?Há outro problema (o de sempre): padrões. Os campos deveriam ser padronizados e se não consegue isto nem de tantas outras coisas mais simples...
Fred 14/04 às 13:23
Concordo Antonio, o desafio maior vai ser justamente inspirar confiança. As ferramentas atuais não são convincentes, mas acredito que seja possível conseguir uma solução que inspire confiança.
Essa empresa iria estabelecer padrões de cadastro e quem quisesse aderir ao sistema, teria que aderir aos padrões. Claro que para fazer isso, ela dependeria de muita negociação. Por isso que disse que essa empresa deveria ser independente e trabalhar somente com isso.
Agora que a gente está discutindo, lembrei de uma funcionalidade que possui o Gerenciador de Conteúdo Drupal. Se você possui uma conta em pelo menos um site que use o sistema, você pode fazer o login em qualquer outro desse jeito: seu_login@dominio. Onde dominio é o endereço do site drupal onde você já tinha cadastro. Um site consulta o outro, não sei como.
Canalize a raiva do usuário
Alguns dias atrás, me peguei numa daquelas situações tão comuns aos usuário de PC: dando socos na escrivaninha porque tava demorando demais pra fazer uma tarefa corriqueira e eu estava apressadíssimo pra sair. Como tenho uma boa noção do funcionamento do hardware e software, raramente fico nervoso com ele, mas naquele momento, não quis nem pensar na causa da lentidão anormal. Não havia tempo para arrumar nada, tinha que sair ligeiro!
A maioria dos usuários desconhece as razões para os eventuais problemas que ocorrem no uso do computador e, por isso, não economizam suspiros, xingamentos, chacoalhadas no monitor e pontapés na CPU. O pior é que ninguém percebe que estão agindo como se o computador fosse outra pessoa e pudesse entender tais repreensões!
Por que não entrar na onda, então? Vamos dar às nossas interfaces a possibilidade de pelo menos, dar sinais de recebimento da repreensão. Certamente o usuário se sentirá mais satisfeito no dia em que o computador gemer de dor em resposta aos socos, mesmo que isso não resulte em melhor na perfomance. Não, não, desculpe, isso seria ridículo demais. Nas primeiras vezes seria engraçado, mas depois faria os usuários terem mais raiva ainda.
Porém, acredito que a solução paliativa ainda assim pode amenizar a frustração do usuário. É melhor receber a mensagem de que o aplicativo travou e terá de ser fechado do que simplesmente parar de funcionar e logo após fechar.
No Windows XP, parece que a Microsoft finalmente entendeu isso. Ao invés da tela azul da morte do Windows 98, agora o XP diz ao usuário numa janela elegante que o programa não está mais respondendo. E vai além: oferece a possibilidade de enviar um relatório do erro para a Microsoft, algo como denunciar o "programa infrator".
Eu particularmente nunca usei esse recurso, porque não confio na Microsoft, mas tenho o maior prazer de colaborar com a Mozilla Foundation para corrigir os bugs de seus produtos que uso diariamente: o navegador Firefox e o leitor de email Thunderbird. Quando trava alguns desses programas, abre uma aplicativo intitulado Quality Assurance Feedback (retorno sobre a qualidade) que permite enviar as informações do erro. Acredito que mesmo os usuários que não conhecem a filosofia open-source sentem menos raiva quando isso acontece porque demonstra o compromisso com a melhoria.
Voltando para nosso mundo Web, como aplicar essa estratégia de tratamento de erro em nossas interfaces? Quais são os momentos em que os usuário mais sentem frustração ao usar uma aplicação Web ou website? Que tipo de emoção sentem? Podemos canalizar um impulso negativo para melhorar a interface?
Cada caso é um caso e precisa ser analisado com calma. A idéia é boa, mas é preciso muito cautela para não piorar ainda mais a situação, que é muito delicada. Lidar com emoções não é pra qualquer um. Em geral, profissionais das exatas não são muito bons nisso; psicólogos e redatores são mais indicados.
Quando tive esse insight fiquei com a maior vontade de aplicá-lo numa interface. Enquanto dava uma espiada nos logs de busca deste blog, percebi a quantidade de pessoas que procurava por assuntos nada a ver. De alguma forma (pelo Google, imagino), essas pessoas caem no meu blog e procuram por termos como 'juegos del exorcista', 'tutorial php', 'pai rico pai pobre', 'desenho de bonecas' e, principalmente, 'orkut'.
Essas pessoas devem sair do meu site com raiva por terem caído nele. Tentei amenizar a situação para eles e, de quebra, criei um canal de aprimoramento da busca pelos próprios leitores. Muitas das "denúncias" não posso fazer nada a respeito, porque realmente nunca falei sobre o assunto. Porém, é comum receber denúncias de posts que não continham uma determinada palavra-chave relevante. Adiciono no gerenciador de conteúdo e pronto, problema resolvido!
O que acharam da solução? Já tinham visto algo parecido?
[ nota ] Depois de escrever esse post, encontrei uma pesquisa acadêmica séria (ou nem tanto) sobre o fenômeno "computer rage". Os pesquisadores da Universidade de Maryland entrevistaram muitas pessoas e chegaram a conclusão de que é preciso educar as pessoas para descarregar sua raiva pelo PC de forma segura. Para isso, gravaram uma série de vídeos explicando como demolir seu monitor sem tomar um choque, derreter o mouse sem se queimar e etc. Não sei quem é mais louco: se são os usuários ou se são os pesquisadores... seja quem for, Freud explica.
A maioria dos usuários desconhece as razões para os eventuais problemas que ocorrem no uso do computador e, por isso, não economizam suspiros, xingamentos, chacoalhadas no monitor e pontapés na CPU. O pior é que ninguém percebe que estão agindo como se o computador fosse outra pessoa e pudesse entender tais repreensões!
Por que não entrar na onda, então? Vamos dar às nossas interfaces a possibilidade de pelo menos, dar sinais de recebimento da repreensão. Certamente o usuário se sentirá mais satisfeito no dia em que o computador gemer de dor em resposta aos socos, mesmo que isso não resulte em melhor na perfomance. Não, não, desculpe, isso seria ridículo demais. Nas primeiras vezes seria engraçado, mas depois faria os usuários terem mais raiva ainda.
Porém, acredito que a solução paliativa ainda assim pode amenizar a frustração do usuário. É melhor receber a mensagem de que o aplicativo travou e terá de ser fechado do que simplesmente parar de funcionar e logo após fechar.
No Windows XP, parece que a Microsoft finalmente entendeu isso. Ao invés da tela azul da morte do Windows 98, agora o XP diz ao usuário numa janela elegante que o programa não está mais respondendo. E vai além: oferece a possibilidade de enviar um relatório do erro para a Microsoft, algo como denunciar o "programa infrator".
Eu particularmente nunca usei esse recurso, porque não confio na Microsoft, mas tenho o maior prazer de colaborar com a Mozilla Foundation para corrigir os bugs de seus produtos que uso diariamente: o navegador Firefox e o leitor de email Thunderbird. Quando trava alguns desses programas, abre uma aplicativo intitulado Quality Assurance Feedback (retorno sobre a qualidade) que permite enviar as informações do erro. Acredito que mesmo os usuários que não conhecem a filosofia open-source sentem menos raiva quando isso acontece porque demonstra o compromisso com a melhoria.
Voltando para nosso mundo Web, como aplicar essa estratégia de tratamento de erro em nossas interfaces? Quais são os momentos em que os usuário mais sentem frustração ao usar uma aplicação Web ou website? Que tipo de emoção sentem? Podemos canalizar um impulso negativo para melhorar a interface?
Cada caso é um caso e precisa ser analisado com calma. A idéia é boa, mas é preciso muito cautela para não piorar ainda mais a situação, que é muito delicada. Lidar com emoções não é pra qualquer um. Em geral, profissionais das exatas não são muito bons nisso; psicólogos e redatores são mais indicados.
Quando tive esse insight fiquei com a maior vontade de aplicá-lo numa interface. Enquanto dava uma espiada nos logs de busca deste blog, percebi a quantidade de pessoas que procurava por assuntos nada a ver. De alguma forma (pelo Google, imagino), essas pessoas caem no meu blog e procuram por termos como 'juegos del exorcista', 'tutorial php', 'pai rico pai pobre', 'desenho de bonecas' e, principalmente, 'orkut'.
Essas pessoas devem sair do meu site com raiva por terem caído nele. Tentei amenizar a situação para eles e, de quebra, criei um canal de aprimoramento da busca pelos próprios leitores. Muitas das "denúncias" não posso fazer nada a respeito, porque realmente nunca falei sobre o assunto. Porém, é comum receber denúncias de posts que não continham uma determinada palavra-chave relevante. Adiciono no gerenciador de conteúdo e pronto, problema resolvido!
O que acharam da solução? Já tinham visto algo parecido?
[ nota ] Depois de escrever esse post, encontrei uma pesquisa acadêmica séria (ou nem tanto) sobre o fenômeno "computer rage". Os pesquisadores da Universidade de Maryland entrevistaram muitas pessoas e chegaram a conclusão de que é preciso educar as pessoas para descarregar sua raiva pelo PC de forma segura. Para isso, gravaram uma série de vídeos explicando como demolir seu monitor sem tomar um choque, derreter o mouse sem se queimar e etc. Não sei quem é mais louco: se são os usuários ou se são os pesquisadores... seja quem for, Freud explica.
Design de interação da Olympus D-395
Além da charmosa Benq 1300, eu tenho uma câmera Olympus D-395. A Benq é uma câmera super-fácil de usar, ágil e barata, mas a qualidade das fotos é baixa. A Olympus é complicada, lenta e barata, mas a qualidade das fotos é boa. Qual delas eu prefiro? As duas, ora. A Benq posso levar pra qualquer lugar que não perco muito se for assaltado, enquanto a Olympus só é usada quando saio prevendo que vou tirar fotos.
Quando quero preparar a Olympus para uma foto diferente do padrão automático da câmera, demora tanto tempo que sempre perco o momento decisivo da cena. Já tive experiências com uma Cybershot e uma Coolpix, mas elas eram ainda piores. Ah, que saudades da minha Pentax analógica... os conjuntos de anéis, alavancas e rodinhas são muito mais práticos pra fazer o ajuste fino do que os menus das câmeras digitais porque cada controle possui:
posição física diferente
modo de interação diferente (girar, apertar, puxar)
maior granulação (mais opções)
Tudo bem, eu sei que era mais difícil entender o modelo conceitual da câmera monoreflexa (combinação da abertura do diafragma, velocidade do obturador, intensidade do flash e foco) do que o modelo conceitual das câmeras digitais (botões, modos e menus), mas se queremos fazer algo além do que elas fazem automaticamente, gastamos tanto tempo ou temos tanta dificuldade que nem vale à pena.
No diagrama abaixo, está representado o layout do lado de trás da minha câmera D-395 e seus menus de configuração.
A minha principal frustração com esse design é a posição da função macro. Alternar entre fotos à distância e fotos próximas (close) é um procedimento frequente numa sessão de fotos de família. Enterrar a função macro a 6 cliques de distância definitivamente não foi uma boa decisão.
Na verdade, todas as opções do menu "CAM" estão enterradas. Só para chegar a esse menu é preciso primeiro clicar no botão "OK" e depois pressionar o botão esquerda para selecionar "Modo Menu". Uma vez dentro do menu, se você usar o botão "OK" para selecionar uma opção, ele sai do menu imediatamente e o processo recomeça. Para escolher as opções do menu se usa as teclas direcionais (direita, baixo, esquerda, cima), mas na hora de confirmar uma seleção, aí sim é preciso usar o botão "OK". O problema com esse botão é que foram atribuídas três funções a ele: "abrir menu", "fechar menu" e "ok". Num contexto, o botão tem uma função, noutro contexto, outra função. Isso confunde.
Ao invés de ficar só na crítica, resolvi verificar se o conhecimento de design de interação adquirido com a experiência em websites e aplicações serviria também para o design de um produto tão diferente do que estou acostumado a trabalhar.
A função macro está no lugar da função de disparo atrasado, já que ela não é muito usada. Não é sempre que temos um suporte adequado para deixar a máquina encostada enquanto corremos para aparecer na foto.
O botão "OK" foi substituído por um botão "Modo" que só faz isso: alterna entre os modos foto, vídeo e configuração, representados por ícones dentro de abas. A função "ok", necessária para confirmar uma seleção, pode ser executada muito bem pela tecla direita.
Mudei alguns ícones e rótulos para maior clareza e reorganizei os menus, agrupando as funções com maior similaridade. Para ter uma usabilidade ótima, seria necessário adicionar mais botões e fazer mudanças físicas no layout da câmera, mas isso teria que ser feito em conjunto com engenheiros. Meu objetivo era propor pequenas mudanças que tivessem grandes resultados.
Para ter certeza de que melhorou, seria necessário montar um protótipo funcional para cada versão (antiga e nova), testar com usuários e comparar os resultados, mas infelizmente não tenho tanto tempo sobrando assim...
Mesmo com os problemas de usabilidade que demonstrei, ainda assim recomendo a Olympus D-395 para quem ainda não tem uma digital. A sensibilidade à luz e definição de imagem é superior à Cybershot da Sony e custa menos.
Quando quero preparar a Olympus para uma foto diferente do padrão automático da câmera, demora tanto tempo que sempre perco o momento decisivo da cena. Já tive experiências com uma Cybershot e uma Coolpix, mas elas eram ainda piores. Ah, que saudades da minha Pentax analógica... os conjuntos de anéis, alavancas e rodinhas são muito mais práticos pra fazer o ajuste fino do que os menus das câmeras digitais porque cada controle possui:
posição física diferente
modo de interação diferente (girar, apertar, puxar)
maior granulação (mais opções)
Tudo bem, eu sei que era mais difícil entender o modelo conceitual da câmera monoreflexa (combinação da abertura do diafragma, velocidade do obturador, intensidade do flash e foco) do que o modelo conceitual das câmeras digitais (botões, modos e menus), mas se queremos fazer algo além do que elas fazem automaticamente, gastamos tanto tempo ou temos tanta dificuldade que nem vale à pena.
No diagrama abaixo, está representado o layout do lado de trás da minha câmera D-395 e seus menus de configuração.
A minha principal frustração com esse design é a posição da função macro. Alternar entre fotos à distância e fotos próximas (close) é um procedimento frequente numa sessão de fotos de família. Enterrar a função macro a 6 cliques de distância definitivamente não foi uma boa decisão.
Na verdade, todas as opções do menu "CAM" estão enterradas. Só para chegar a esse menu é preciso primeiro clicar no botão "OK" e depois pressionar o botão esquerda para selecionar "Modo Menu". Uma vez dentro do menu, se você usar o botão "OK" para selecionar uma opção, ele sai do menu imediatamente e o processo recomeça. Para escolher as opções do menu se usa as teclas direcionais (direita, baixo, esquerda, cima), mas na hora de confirmar uma seleção, aí sim é preciso usar o botão "OK". O problema com esse botão é que foram atribuídas três funções a ele: "abrir menu", "fechar menu" e "ok". Num contexto, o botão tem uma função, noutro contexto, outra função. Isso confunde.
Ao invés de ficar só na crítica, resolvi verificar se o conhecimento de design de interação adquirido com a experiência em websites e aplicações serviria também para o design de um produto tão diferente do que estou acostumado a trabalhar.
A função macro está no lugar da função de disparo atrasado, já que ela não é muito usada. Não é sempre que temos um suporte adequado para deixar a máquina encostada enquanto corremos para aparecer na foto.
O botão "OK" foi substituído por um botão "Modo" que só faz isso: alterna entre os modos foto, vídeo e configuração, representados por ícones dentro de abas. A função "ok", necessária para confirmar uma seleção, pode ser executada muito bem pela tecla direita.
Mudei alguns ícones e rótulos para maior clareza e reorganizei os menus, agrupando as funções com maior similaridade. Para ter uma usabilidade ótima, seria necessário adicionar mais botões e fazer mudanças físicas no layout da câmera, mas isso teria que ser feito em conjunto com engenheiros. Meu objetivo era propor pequenas mudanças que tivessem grandes resultados.
Para ter certeza de que melhorou, seria necessário montar um protótipo funcional para cada versão (antiga e nova), testar com usuários e comparar os resultados, mas infelizmente não tenho tanto tempo sobrando assim...
Mesmo com os problemas de usabilidade que demonstrei, ainda assim recomendo a Olympus D-395 para quem ainda não tem uma digital. A sensibilidade à luz e definição de imagem é superior à Cybershot da Sony e custa menos.
Afinal, o que é ícone? Como criar ícones?
A edição de setembro da Revista Webdesign traz uma reportagem completa sobre ícones, contando com a opinião de especialistas no assunto como Ronaldo Gazel, Mauro Pinheiro, Felipe Memória e outros. A reportagem consegue tocar em praticamente todos os principais aspectos a serem considerados na criação de ícones: padronização, ilustração, estética e etc. Abaixo publico a entrevista completa que o jornalista Luis Rocha me propôs durante a elaboração da matéria.
Como podemos definir um ícone?
A palavra ícone vem do grego eikon, que significa imagem, mas em nosso ramo essa palavra é usada para apontar um tipo específico de imagem. Quando falamos em imagem, é importante entender que a imagem é sempre uma representação de um objeto, embora tratemos a imagem do objeto como se fosse o próprio objeto. Posso apontar para a superfície de um tubo de raios catódicos (um monitor) e dizer: “essa aqui é sua pasta de documentos”, embora não haja pasta alguma ali. O objeto a que estou me referindo, em última análise, é uma área física num disco rígido que pode guardar dados. Uma pasta de papel também serve para guardar dados, logo, a imagem da pasta serve como metáfora para facilitar o entendimento do uso da área do disco rígido. O ícone é, portanto, segundo a Semiótica peirciana, uma imagem que tenha alguma relação de semelhança entre a representação e o objeto que, se for convincente, permite que usemos a representação sem tomar conhecimento do objeto.
Existe alguma diferença ou a função dos pictogramas no mundo real e dos ícones no mundo virtual são as mesmas?
Se tomarmos o virtual como o mundo abstrato da mente humana, incluindo, entre outras, o ciberespaço, ícones só existem no plano virtual. Como objetos reais, não passam de um amontoado de rabiscos ou de pontos luminosos num monitor. O ícone é sempre uma abstração, pois funciona como uma representação de um objeto outro que não a própria representação. O virtual e o ícone já existiam muito antes da Internet, portanto, nesse novo meio, continuam tendo a mesma função.
Falando especificamente da função dos ícones em interfaces digitais, você acredita que o seu objetivo esteja mais ligado à memorização de determinadas tarefas ou a estética gráfica?
Os primeiros ícones surgiram como metáforas para facilitar o entendimento do funcionamento dos sistemas, como no exemplo da pasta. A estratégia deu tão certo que as pessoas se lembravam mais da forma do ícone do que do nome do comando que ele representava. Logo, os ícones se tornaram a cara do software, desempenhando papel fundamental na formação de sua própria identidade. Foi a partir daí que o valor estético dos ícones começou a ser explorado em softwares. Por influência da linguagem visual das interfaces de softwares, as primeiras páginas Web incluíam ícones sem ganho funcional, apenas para parecer que a página era mais “interativa”. Esses ícones não tinham a função de facilitar a memorização nem o aprendizado; seu único objetivo era o ganho estético. Com o ingresso massivo de designers na criação de interfaces, o que parecia inconciliável se tornou indissociável. O Design mostrou que valor estético e valor funcional não precisavam competir entre si.
A eficiência dos ícones depende do nível de familiaridade das pessoas com as representações que se pretende passar?
Não necessariamente. Uma imagem pode ser facilmente lembrada mesmo que não faça referência direta a algum objeto que conhecemos previamente, pois nossa mente é capaz de criar inúmeras associações indiretas. É por esse motivo que uma pintura abstrata pode suscitar algum tipo de sentimento ou idéia. A eficiência do ícone está mais ligada à adequação ao contexto. Se uma interface oferece uma série de ícones abstratos que se diferenciam entre si o suficiente e fazem sentido para o contexto da interface, possivelmente, eles serão eficientes. No Brasil, os ícones usados em fornos microondas fazem referências a objetos concretos (figura de peixe para a programação “assar peixe”), enquanto que na Suécia eles são mais abstratos (duas barras paralelas para a programação “descongelar”).
Hoje, já podemos afirmar que a internet possui uma iconografia particular (por exemplo: utilizamos a imagem de uma casa para indicar a página principal de um site)?
A maioria dos ícones que encontramos com freqüência na Web tem suas origens nos softwares de desktop. A imagem da casa para indicar “home” já era usada antes da Web em apresentações multimídia feitas com o Hypercard, o avô do Director. Entretanto, a transposição deve ser feita com cuidado. Será que o usuário já viu este ícone em algum software? Se viu, será que ele entendeu? Se entendeu, será que ele vai entender se eu colocar nessa aplicação Web? Essas perguntas não podem ser respondidas com base no achismo. Melhor testar com usuários reais.
Por outro lado, o avanço da tecnologia permite que o desenvolvimento de um site possua uma série de novas funcionalidades. Por exemplo: o espaço para comentários vem se tornando uma função muito comum (e o símbolo de um balão tem sido o ícone mais utilizado para representá-lo). Diante disso, quais são as principais etapas a serem consideradas na hora de se criar um novo ícone (escolha de cores, tamanho, tipo de traço etc.)? Caso possível, poderia citar um bom exemplo nesta área?
A primeira etapa ao se criar um novo ícone é não criar um novo ícone. Para quê reinventar a roda? Se o ícone para comentários na maioria dos websites similares ao que você está trabalhando é um balão, então é melhor usar um balão também, a não ser que o objetivo seja confundir ou chamar a atenção para o próprio ícone. O contexto onde estará o ícone é que vai dizer qual será sua função principal: embelezar, agilizar, desorientar ou o que for. É preciso, entretanto, ser consistente na função dos ícones. Ícones agilizadores não devem se misturar a ícones embelezadores, do contrário, ambos perdem força. Isso acontece porque os ícones não são percebidos em separado, mas sim fazendo parte de uma série. O usuário entende a função do ícone comparando-o com os ícones e controles próximos. Por esse motivo é tão importante usar uma mesma linguagem visual (bordas, cores, perspectiva, iluminação) e figurada (objetos, atores) entre todos os ícones de uma interface. Na tela de configurações do sistema operacional BeOS R5.0.1, a inconsistência na linguagem utilizada em alguns elementos chama a atenção.
Leia a materia completa:
http://www.usabilidoido.com.br/afinal_o_que_e_icone_como_criar_icones.html
Como podemos definir um ícone?
A palavra ícone vem do grego eikon, que significa imagem, mas em nosso ramo essa palavra é usada para apontar um tipo específico de imagem. Quando falamos em imagem, é importante entender que a imagem é sempre uma representação de um objeto, embora tratemos a imagem do objeto como se fosse o próprio objeto. Posso apontar para a superfície de um tubo de raios catódicos (um monitor) e dizer: “essa aqui é sua pasta de documentos”, embora não haja pasta alguma ali. O objeto a que estou me referindo, em última análise, é uma área física num disco rígido que pode guardar dados. Uma pasta de papel também serve para guardar dados, logo, a imagem da pasta serve como metáfora para facilitar o entendimento do uso da área do disco rígido. O ícone é, portanto, segundo a Semiótica peirciana, uma imagem que tenha alguma relação de semelhança entre a representação e o objeto que, se for convincente, permite que usemos a representação sem tomar conhecimento do objeto.
Existe alguma diferença ou a função dos pictogramas no mundo real e dos ícones no mundo virtual são as mesmas?
Se tomarmos o virtual como o mundo abstrato da mente humana, incluindo, entre outras, o ciberespaço, ícones só existem no plano virtual. Como objetos reais, não passam de um amontoado de rabiscos ou de pontos luminosos num monitor. O ícone é sempre uma abstração, pois funciona como uma representação de um objeto outro que não a própria representação. O virtual e o ícone já existiam muito antes da Internet, portanto, nesse novo meio, continuam tendo a mesma função.
Falando especificamente da função dos ícones em interfaces digitais, você acredita que o seu objetivo esteja mais ligado à memorização de determinadas tarefas ou a estética gráfica?
Os primeiros ícones surgiram como metáforas para facilitar o entendimento do funcionamento dos sistemas, como no exemplo da pasta. A estratégia deu tão certo que as pessoas se lembravam mais da forma do ícone do que do nome do comando que ele representava. Logo, os ícones se tornaram a cara do software, desempenhando papel fundamental na formação de sua própria identidade. Foi a partir daí que o valor estético dos ícones começou a ser explorado em softwares. Por influência da linguagem visual das interfaces de softwares, as primeiras páginas Web incluíam ícones sem ganho funcional, apenas para parecer que a página era mais “interativa”. Esses ícones não tinham a função de facilitar a memorização nem o aprendizado; seu único objetivo era o ganho estético. Com o ingresso massivo de designers na criação de interfaces, o que parecia inconciliável se tornou indissociável. O Design mostrou que valor estético e valor funcional não precisavam competir entre si.
A eficiência dos ícones depende do nível de familiaridade das pessoas com as representações que se pretende passar?
Não necessariamente. Uma imagem pode ser facilmente lembrada mesmo que não faça referência direta a algum objeto que conhecemos previamente, pois nossa mente é capaz de criar inúmeras associações indiretas. É por esse motivo que uma pintura abstrata pode suscitar algum tipo de sentimento ou idéia. A eficiência do ícone está mais ligada à adequação ao contexto. Se uma interface oferece uma série de ícones abstratos que se diferenciam entre si o suficiente e fazem sentido para o contexto da interface, possivelmente, eles serão eficientes. No Brasil, os ícones usados em fornos microondas fazem referências a objetos concretos (figura de peixe para a programação “assar peixe”), enquanto que na Suécia eles são mais abstratos (duas barras paralelas para a programação “descongelar”).
Hoje, já podemos afirmar que a internet possui uma iconografia particular (por exemplo: utilizamos a imagem de uma casa para indicar a página principal de um site)?
A maioria dos ícones que encontramos com freqüência na Web tem suas origens nos softwares de desktop. A imagem da casa para indicar “home” já era usada antes da Web em apresentações multimídia feitas com o Hypercard, o avô do Director. Entretanto, a transposição deve ser feita com cuidado. Será que o usuário já viu este ícone em algum software? Se viu, será que ele entendeu? Se entendeu, será que ele vai entender se eu colocar nessa aplicação Web? Essas perguntas não podem ser respondidas com base no achismo. Melhor testar com usuários reais.
Por outro lado, o avanço da tecnologia permite que o desenvolvimento de um site possua uma série de novas funcionalidades. Por exemplo: o espaço para comentários vem se tornando uma função muito comum (e o símbolo de um balão tem sido o ícone mais utilizado para representá-lo). Diante disso, quais são as principais etapas a serem consideradas na hora de se criar um novo ícone (escolha de cores, tamanho, tipo de traço etc.)? Caso possível, poderia citar um bom exemplo nesta área?
A primeira etapa ao se criar um novo ícone é não criar um novo ícone. Para quê reinventar a roda? Se o ícone para comentários na maioria dos websites similares ao que você está trabalhando é um balão, então é melhor usar um balão também, a não ser que o objetivo seja confundir ou chamar a atenção para o próprio ícone. O contexto onde estará o ícone é que vai dizer qual será sua função principal: embelezar, agilizar, desorientar ou o que for. É preciso, entretanto, ser consistente na função dos ícones. Ícones agilizadores não devem se misturar a ícones embelezadores, do contrário, ambos perdem força. Isso acontece porque os ícones não são percebidos em separado, mas sim fazendo parte de uma série. O usuário entende a função do ícone comparando-o com os ícones e controles próximos. Por esse motivo é tão importante usar uma mesma linguagem visual (bordas, cores, perspectiva, iluminação) e figurada (objetos, atores) entre todos os ícones de uma interface. Na tela de configurações do sistema operacional BeOS R5.0.1, a inconsistência na linguagem utilizada em alguns elementos chama a atenção.
Leia a materia completa:
http://www.usabilidoido.com.br/afinal_o_que_e_icone_como_criar_icones.html
Assinar:
Postagens (Atom)