AgileZ

Programar muitas vezes é considerado como sinônimo de codificar, ou seja, escrever código para ser compilado. A importância de um bom algoritmo na qualidade final de um software é indiscutível e não pretendo levantar discussões a este respeito por aqui, mas colocar em pauta outro aspecto – que também é programação – porém nem sempre tem a atenção merecida: a interface gráfica, ou, mais precisamente, a interface de usuário (IU).

Assim como a parte que fica por debaixo dos panos (o código) a interface gráfica tem uma importância fundamental para o sucesso de seu sistema. Padrões de projeto (Design Patterns), Grasp, POO, POA e etc. São inúmeras as técnicas existentes para auxiliar a construção de excelentes softwares. Mas, quantos de vocês conhecem alguma para desenhos de interfaces gráficas? O que deve ter em mente o programador ou projetista de interface para construir uma boa IU?

Imagine a seguinte situação: você acabou de liberar uma nova versão de seu sistema com um novo e badalado recurso de cálculo de preço, baseado em uma intricada fórmula de previsão de custos, cujo código você morre de orgulho de dizer que foi de sua autoria. A janela que implementa este recurso possui alguns campos para digitação dos materiais aos quais o usuário pretende calcular o preço, e, eventualmente atualizar seu cadastro de produtos com os valores obtidos. O que parecia ter tudo pra ser um sucesso não repercutiu como o esperado, e você logo se pergunta: o que pode ter saído errado? O código está perfeito, fiz testes unitários e utilizeis todos os padrões GoF aplicáveis, entretanto, um recurso que teria tudo pra ser um sucesso não está sendo utilizado como o esperado.

Voltando a atenção à interface do usuário, constatamos que ela possui uma grave falha: o sistema possui um cadastro de produtos extenso, e a nova tela não permite que o usuário faça uma seleção para importar os produtos pelo grupo, por intervalo de código, por classificação ABC ou por algum outro critério. O usuário, frustrado por não conseguir digitar os produtos com facilidade, acaba evitando utilizar o novo recurso. Se uma análise de usabilidade fosse feita ANTES de o recurso ser liberado ao mundo externo, o resultado seria diferente.

A palavra chave, quando falamos em IU, é USABILIDADE. Interfaces gráficas foram feitas para – além de serem bonitinhas – facilitarem o trabalho de quem as utiliza. Beleza sem usabilidade é a mesma coisa que uma Ferrari sem volante. É linda, porém não vai servir para o propósito ao qual foi feita.

A tarefa do projetista de IU não é fácil. Cometemos vários equívocos ao desenhar uma nova janela ou página apenas porque não pensamos como um usuário. E não é pra menos: nós não somos usuários. Se colocar no lugar do usuário é uma tarefa difícil e é o segredo para o sucesso de qualquer IU. Com qual freqüência o recurso será utilizado? É crítico? Velocidade faz diferença? É acessível via teclado ou exige o uso do mouse?

Chega de perguntas. O objetivo é apenas um:

Uma boa IU é aquela que se comporta da forma como o usuário espera que ela se comporte.

Simples, direto, claro. Se você coloca um botão lindo com ícones em 3D, mas não deixa claro para o que ele serve, não está construindo uma interface boa para o usuário. Coloque legendas claras e, se possível, hints explicativos e teclas de atalho explicitas, pois nem todo mundo gosta ou pode ficar utilizando mouse (cansa mais que teclado, principalmente em tarefas repetitivas). Se o padrão do sistema operacional é que em caixas de mensagens o botão OK venha antes do Cancelar, siga desta forma. Se tem um recurso não implementado, não coloque o botão na janela apenas para que o usuário tenha que clicar e ver que nada acontece. Recursos incompletos são piores que a ausência total deles.

Outra característica interessante relacionada ao usuário: eles não gostam de ler. Não adianta fazer um manual explicando como utilizar a nova janela, pois eles não o lerão de forma alguma. Da mesma forma, não adianta escrever caixas de diálogos com textos explicativos muito grandes. Eles não lerão e sequer pensarão em clicar em OK ou Cancelar antes de apertar a tecla ENTER do teclado. Textos curtos e claros são ideais. Ao invés de dizer: ‘Você apertou a tecla X, tem certeza que quer executar o procedimento X?’ utilize ‘Executar X?’.

Muitos usuários também são inseguros, portanto, evite questionar as ações dele a menos que seja necessário. Mensagens do tipo: ‘Tem certeza que deseja fazer isto?’ ou ‘Isto vai finalizar o sistema, tem certeza que quer finalizar o sistema?’ tem efeito negativo, pois sugere ao usuário que ele fez algo que não devia. É mais adequado usar: ‘Sair agora?’ ou ‘Fazer X?’.

Usuários gostam de pensar que recursos parecidos devem se comportar da mesma forma. Então, se vai construir uma janela nova, pergunte-se se não existe um padrão a ser seguido. Não inove sem critério, um aplicativo cujas IUs tem aspectos funcionais diferentes umas das outras são difíceis de usar. Se o botão para sair da janela se chama ‘Sair’, utilize sempre assim e não ‘Fechar’, ‘Encerrar’. Se a tecla ESC fecha a tela, procure disponibilizar o mesmo atalho para todas as janelas. A janela de Contas a pagar pode ser redimensionada, então a janela de Contas a receber também o deve.

Tem dúvida sobre qual melhor abordagem para um recurso? Não invente, pergunte ao usuário, faça um teste de interface com ele, observe como ele interage com os botões, menus e mensagens. É a melhor forma de descobrir.

p.s. Acabei de digitar o texto aqui no Word, e tentei selecionar tudo usando a combinação de teclas CTRL+A, que é padrão na maioria dos editores de texto. Não preciso falar que não funcionou, lembrei que no Word é CTRL+T.