Joel on Software Joel sobre Software

Projeto de Interface com Usuário para Programadores
Capítulo 1
Capítulo 2
Capítulo 3
Capítulo 4
Capítulo 5
Capítulo 6
Capítulo 7
Capítulo 8
Capítulo 9

Outros artigos de "Joel on Software" em Português

Outros artigos de "Joel on Software" em Inglês

Envie email para o autor (apenas em Inglês)

Um dos primeiros princípios de interfaces GUI foi que você não deveria pedir que as pessoas se lembrassem de coisas que o computador poderia lembrar. O exemplo clássico é a caixa de diálogo Abrir Arquivo, que mostra para as pessoas uma lista de arquivos ao invés de pedir para lembrar e digitar o nome exato do arquivo. As pessoas lembram das coisas um pouco melhor quando lhe são dadas algumas pistas, e elas preferencialmente escolhem alguma coisa de uma lista do que ter que lembrar de memória. 

Um outro exemplo é o menu. Historicamente, fornecendo um menu completo de comandos disponíveis que substituíam as interfaces com as velhas linhas de comando, onde você tinha que memorizar os comandos que você queria usar. E isto é, fundamentalmente, a razão porque as interfaces de linhas de comando não são melhores do que as interfaces GUI, não importa o que os seus amigos do UNIX digam para você. Usar uma interface de linha de comando é como ter que aprender Koreano para pedir comida em uma filial do McDonalds em Seoul. Usar uma interface baseada em menu é como ser capaz de apontar para a comida que você quer e acenar com a cabeça vigorosamente: isto transmite a mesma informação sem a curva de aprendizado.

Considere o processo de seleção de arquivo em um programa gráfico típico:

 Felizmente, o Windows 98 introduziu o suporte por thumbnail, portanto você pode ver os arquivos como este:

Isto faz com que seja significantemente mais fácil abrir o arquivo que você quer; ele nem mesmo necessita do esforço mental para procurar as palavras nas figuras.

Você pode ver o princípio da mínima memória em funcionamento em características como auto completar, também. Mesmo se você precisar digitar alguma coisa, alguns programas fazem suposições educadas sobre o que você vai digitar:

Neste exemplo, tão logo você digita "M", o Excel supõe que você provavelmente vai digitar Male, porque você digitou Male antes nesta coluna, e propõe isto através da função auto completar. Mas o "ale" é pré selecionado portanto se você não queria digitar Male, você pode continuar digitando (talvez "ystery") e sobrescrever a suposição do Excel sem perda de esforço.

Microsoft Word foi um pouco além nas suposições sobre o que você vai digitar, como todo mundo já usou aquele produto durante o festivo mês de Maio e já descobriu:

Projetando Para Pessoas Que Têm Coisas Melhores Para Fazer Com Suas Vidas, o Retorno

Nos capítulo anteriores, eu trouxe três princípios:

• Usuários não lêem as coisas (capítulo 6)

• Usuários não podem usar o mouse (capítulo 7)

• Usuários não lembram de nada

Você pode estar começando a ter a impressão que eu penso que os usuário são estúpidos. Isto não é verdade. Desrespeitando os seus usuários é o quão arrogante o software como Microsoft Bob criou (e jogou na lixeira do diretório bin), e ninguém está muito feliz.

Por outro lado, existe um tipo de arrogância muito pior no design de software: a presunção arrogante que "meu software é muito legal, as pessoas vão ter que revirar seus cérebros para lidar com ele." Este tipo de atitude irritante é muito comum no mundo do software grátis. Ei, Linux é grátis! Se você não é esperto o suficiente para decifrá-lo, você não merece estar usando-o!

A atitude humana tende na direção da curva do sino. Talvez 98% de seus clientes são espertos o suficiente para usar um aparelho de televisão. Aproximadamente 70% deles podem usar Windows. 15% podem usar Linux. 1% pode programar. Mas somente 0.1% deles podem programar em uma linguagem como C++. E somente 0.01% deles podem imaginar a programação Microsoft. (E todos eles, sem exceção, usam barbas e óculos.)

O efeito desta queda suave é que sempre que você "diminuir a barra" por menor que seja a quantidade, faz o seu programa, digamos, 10% mais fácil de usar, você aumenta dramaticamente o número de pessoas que podem usa-lo, digamos, em 50%.

Portanto, eu realmente não acredito que as pessoas são imbecis, mas eu acho que se você tentar constantemente projetar o seu programa de modo que ele seja fácil o suficiente para imbecis usarem, você vai fazer um programa popular, e fácil de usar que as pessoas gostam. E você ficará surpreso como o que parece uma pequena melhora na usabilidade se traduz em um número maior de clientes.

Um bom modo de avaliar a usabilidade de um programa ou caixa de diálogo que você nunca viu antes é agir como um pequeno estúpido. Não leia as palavras na caixa de diálogo. Faça suposições aleatórias sobre o que as coisas fazem sem verificar. Tente usar o mouse com um só dedo. Cometa um monte de erros, e geralmente se mova em volta. Veja se o programa faz o que você quer, ou pelo menos, gentilmente se guie ao invés de explodir. Seja impaciente. Se você não pode fazer o que você quer imediatamente, desista. Se a IU não pode resistir a você agir geralmente de forma imatura e estúpida, ela pode dar algum trabalho.