Um livro muito bom a respeito é "User Interface Design for Programmers" de Joel Spolsky. A edição impressa está esgotada na Amazon, mas você pode ler hoje mesmo se optar pela versão Kindle. Melhor ainda, parte do material está disponível gratuitamente no site do Joel. É material de quase dez anos atrás mas os princípios continuam valendo.
Uma Interface Intuitiva
"Intuitivo" é um termo muito mencionado quando se fala de UI. As pessoas querem sentar na frente do programa e sair usando. Como se consegue isto?
Um termo que Joel usa é affordance, que ao pé da letra é "permitir" mas que podemos traduzir para "facilitar". Em uma boa interface os objetos "facilitam" o seu uso. É tão óbvio o uso destes objetos que eles parecem "implorar" para serem usados. Esta técnica, entretanto, é limitada quando temos que indicar ações ou escolhas que não tem um equivalente na vida normal. E aí que entra a principal técnica para uma boa interface: a consistência.
Consistência
Se não dá para evitar que o usuário tenha que aprender algo, que ele aprenda somente uma vez. Se ele puder usar o mesmo objeto, da mesma forma, para obter o mesmo resultado, não vai demorar muito para que o seu uso fique intuitivo. Melhor ainda se esta consistência não estiver limitada a um aplicativo mas se extenda a vários.
Isto leva ao que considero a regra de ouro do projeto de UI: O projeto de UI não é lugar de ser criativo. Pode parecer um paradoxo, já que o projeto de UI parece ser lugar para um artista. Embora os aspectos estéticos sejam importantes (e já vou falar deles), um bom projeto de UI consiste em dispor adequadamente elementos padronizados.
Esta consistência visual é incentivada pelos próprios sistemas operacionais, que costumam incluir um bom conjunto de elementos gráficos "prontos". É vital que o projetista conheça os elementos disponíveis, seus recursos e variações e, principalmente, quando eles devem ser usados.
Às vezes existem várias opções possíveis. Neste caso deve-se optar pela que seja mais confortável ao operador. Considere a entrada de um número. Algumas opções:
- Seleção por radio button: prático se as opções forem poucas e a operação for principalmente pelo mouse.
- Seleção em um drop list: também para o caso de poucas opções. Tem a vantagem de ocupar menos espaço na tela e a desvantagem das opções não estarem claras.
- Digitação em um text box: pode ser mais trabalhoso para o operador e para o programador (por envolver consistências) mas é mais prático para uma faixa grande de valores e funciona bem em uma tela com bastante digitação.
Vamos considerar dois elementos básicos da interfaces atuais: os checkbox e os radio buttons (minha experiência é com Windows mas imagino que isto se aplique aos principais SOs atuais). Os elementos padrões do SO possuem uma aparência que automaticamente associamos à forma de operação: checkbox são opções independentes e radio buttons são agrupados em conjuntos onde uma opção exclui as demais.
Uma pequena digressão: será que alguém ainda lembra dos rádios com botões mecânicos onde o pressionamento de um fazia saltar o que já estava pressionado ou esta é uma metáfora cuja origem já se perdeu?
Vamos supor que você ache o checkbox feio e resolva inventar uma aparência diferente (e você certamente não vai estar sozinho nisto). O seu usuário vai ter que aprender que este seu elemento funciona como um checkbox (ou pior, entender um funcionamento parecido mas não igual). O que o usuário ganha em troca deste esforço? Um visual que você acha mais bonito (no que ele pode não concordar).
O pior que você pode fazer, entretanto, é mudar a operação de um elemento padrão. Por exemplo, você faz um checkbox funcionar como radio button (já ví isto). Você acaba de confundir o seu usuário. É um passo esta confusão se transformar em frustração e depois raiva.
Estética
Sim, a estética é importante. Principalmente no que se refere à legibilidade da UI. Cores e fontes diferenciados podem auxiliar a organização da tela, mas devem ser usados com muita parcimônia.
No Windows é bastante trabalhosa a mudança de cores e fontes para quem está programando diretamente a API do Windows. A partir do Visual Basic, estas mudanças ficaram triviais e é natural que alguns desenvolvedores tenham se entusiasmado além da conta.
Uma tela cheia de cores e fontes diferentes confunde a visão do operador. Além disso, o seu cérebro vai ficar tentando achar significados por trás destas pistas falsas.
Por último, é bom lembrar que o Windows já possui recursos para o usuário customizar as cores dos elementos gráficos (alguém ainda lembra dos temas?). Forçar uma cor ou um tamanho de letra vai impedir o funcionamento destas configurações.
Ajudando o Operador a Não Errar
Uma característica das UIs é que elas precisam estar preparadas para erros do operador. É inadmissível que informações sejam processadas sem um mínimo de consistência e particularmente vexaminoso quando um erro fatal ocorre mais adiante porque uma informação inválida ou inconsistente foi aceita.
Um mínimo que deve ser feito é fazer uma consistência dos dados e a apresentação de uma mensagem clara sobre qual foi o erro detectado e quais as principais alternativas para corrigí-lo.
Melhor ainda é examinar alternativas que o impeçam de errar. Retomando o exemplo anterior, uma lista de valores válidos impede os erros que podem ser cometidos na digitação em um campo livre.
Pequenos Cuidados
Um olhar atento a detalhes é importante. Reveja bem os textos utilizados, garanta que não escapou um erro de digitação e que os termos são consistentes entre as telas. Não se esqueça de definir atalhos e de verificar a ordem de tabulação.
Nenhum comentário:
Postar um comentário