Joel on Software

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)

 

Projeto de Interface com Usuário para Programadores
Capítulo 5: Consistência e Outros Fantasmas


Por Joel Spolsky
Traduzido por Rosana de Oliveira
22 de Abril de 2000

Os programas principais da série Microsoft Office, Word e Excel, foram desenvolvidos sem preparação na Microsoft, mas outros foram comprados de companhias externas, o notável FrontPage (foi comprado do Vermeer) e o Visio, comprado do Visio. As coisas que estes dois programas têm em comum? Eles foram originalmente desenvolvidos para parecer e se comportar como as aplicações da Microsoft Office.

A decisão de emular a IU do Office não foi meramente para "absorver" a Microsoft ou posicionar as companhias para aquisição; na verdade, Charles Ferguson, que desenvolveu o FrontPage, não hesitou em admitir a sua antipatia pela Microsoft; ele repetidamente implorou para o departamento de Justiça fazer alguma coisa sobre o Redmond Beasties (até que ele vendeu sua companhia para eles, depois disto sua posição ficou um pouco mais complicada). Na verdade Vermeer e Visio parecia ter copiado a IU do Office principalmente porque era oportuno: era mais fácil e mais rápido do que reinventar a roda.

Quando Mike Mathieu, um gerente do grupo de programa da Microsoft, fez o download do FrontPage do web site da Vermeer e experimentou, ele funcionou de forma parecida com o Word. Desde que funcionou da maneira que ele esperava que o programa funcionasse, era mais fácil de usar. E esta facilidade de usar deu a ele uma impressão favorável do programa na primeira vez.

Agora, quando a Microsoft fica com um primeira impressão favorável de um programa na primeira vez, eles pagam $150 milhões ou mais. O seu objetivo provavelmente é mais modesto; você quer que os seus clientes fiquem com uma impressão favorável e paguem talvez $39. Mas é a mesma idéia: consistência provoca facilidade de uso que por sua vez provoca uma sensação boa resultando em mais dinheiro para você.

É difícil super estimar o quanto de consistência ajuda as pessoas a aprender e usar uma grande variedade de programas. Antes dos GUIs, todo programa reinventava os mesmos fundamentos de interface com o usuário. Até mesmo uma simples operação como "sair" que todo programa tinha que ter era completamente inconsistente. Naqueles dias as pessoas tinham que memorizar, pelo menos o mínimo, o comando de sair de programas comuns para que eles pudessem sair e rodar um programa que eles entendessem. Os fanáticos pelos Emacs memorizavam ":q!" (e nada mais) no caso de eles se encontrarem travados na vi (interface visual) por engano, enquanto os usuários de vi memorizavam "C-x C-c" (Emacs tem a sua própria maneira para representar caracteres de controle). Até mesmo na terra do DOS, você não podia nem ao menos usar WordPerfect se você não tinha pelo menos um daqueles templates de plástico que te lembravam o que as teclas Alt+Ctrl+F3 fazia. Eu memorizava somente o F7 que te tirava de lá.

Não somente aquilo, mas pequenas inconsistências em coisas como o comportamento padrão (sobrescrever ou inserir) pode deixá-lo louco. Eu estava tão acostumado em usar Ctrl+Z para "desfazer" em aplicações Windows que quando eu uso Emacs eu estou constantemente minimizando a janela (Ctrl+Z) por engano. (O lado engraçado é que a razão principal que Emacs interpreta Ctrl+Z como minimizar é por causa da "consistência" com aquela terrível interface com usuário, csh, o C shell do UNIX.) Esta é uma daquelas menores frustrações que se somam para um sentimento geral de infelicidade.

Para pegar até mesmo em exemplo menor, Pico e Emacs ambos usam Ctrl+K para deletar linhas, mas com um comportamento ligeiramente diferente que geralmente mexe com o meu documento sempre que eu me encontro no Pico. Eu estou certo que você têm uma dúzia de exemplos próprios.

Nos primeiros dias do Macintosh, antes do Microsoft Windows, fanáticos pelo Apple falaram para todo mundo que a média de usuários Mac usavam mais programas diferentes para ter os seus trabalhos feitos do que a média dos usuários DOS. Eu não lembro dos números exatos, mas eu acredito que era alguma coisa entre 1 ou 2 programas para a média de usuários DOS versus doze programas para o usuário Mac. A razão era que era tão fácil aprender um programa novo no Mac por causa que eles geralmente trabalhavam da mesma maneira.

Consistência é o príncipio fundamental de um bom design de IU, mas é na verdade somente um corolário do axioma "faça o modelo do programa coincidir com o modelo do usuário", porque no modelo do usuário é provável que reflita a maneira que os usuários vêm o comportamento de outros programas. Se o usuário aprendeu que dar duplo-clique no texto significa selecionar a palavra, você pode mostrar para eles um programa que eles nunca viram antes e eles pensarão que a maneira de selecionar uma palavra é dar um duplo-clique nela. E agora, aquele programa que é melhor selecionar palavras quando você dá um duplo-clique (em oposição a, vamos dizer, procurar palavras no dicionário), qualquer que seja, você tem um problema de usabilidade.

Se consistência é tão obviamente benéfica, porque eu estou perdendo o seu tempo e o meu insistindo nisto? Infelizmente, existe uma força negra lá fora que luta contra a consistência, que é a tendência natural dos designers e programadores que é ser criativo.

Agora, Eu odeio ser aquele a dizer para você "não seja criativo," mas infelizmente, para fazer com que uma interface de usuário seja fácil de usar, você vai ter que levar a sua criatividade para alguma outra área. Na maioria das decisões de IU, antes que você faça o design de qualquer coisa do rascunho, você tem que olhar para o que outros programas populares estão fazendo e emular aquilo o mais próximo possível. Se você está criando um programa de edição de documento de algum tipo, é melhor que ele se pareça muito com o Microsoft Word, até os botões de acesso rápido que você tem no menu em comum. Alguns dos seus usuários estarão acostumados a usar Ctrl+S para salvar; alguns deles usarão o Alt+F,S para salvar, e ainda outros usuários usarão o Alt,F,S (soltando a tecla Alt). Outro grupo irá procurar o floppy disk na área superior esquerda do programa e clicá-lo. Todos os quatro melhores funcionamentos, ou seus usuários vão obter alguma coisa que eles não queriam.

Eu vi companhias onde os gerentes se orgulham em fazer coisas deliberadamente diferente da Microsoft. "Só porque a Microsoft faz, não quer dizer que é o certo," eles se gabam, e então começam a criar uma interface de usuário totalmente diferente daquelas que as pessoas estão acostumadas. Antes que você comece a conversa de que "só porque a Microsoft faz, não significa que é o certo," por favor considere duas coisas:

  1. Mesmo se isto não é certo, se a Microsoft está fazendo isto em um programa popular como Word, Excel, Windows, ou Internet Explorer, então milhões de pessoas vão pensar que isto é certo, ou pelo menos, razoavelmente padrão, e eles vão assumir que o seu programa funciona da mesma maneira. Até mesmo se você pensar (como os engenheiros do Netscape 6.0 claramente pensaram) que Alt+Left não é uma boa tecla de atalho para "Voltar", existem literalmente milhões de pessoas lá fora que tentarão usar Alt+Left para voltar, e se você se recusa a fazer isto baseado em algum principio religioso que o Bill Gates é o mal nerd arqui-inimigo Gargamel, então você está gratuitamente arruinando o seu programa para que você se sinta contente e satisfeito, e seus usuários não o agradecerão por isto.
  2. E não esteja tão certo que isto não é o correto. A Microsoft gasta mais dinheiro em testes de usabilidade do que você faz, eles mantêm estatísticas detalhadas baseados em milhões de chamadas telefônicas de suporte técnico, e há uma boa chance de que eles fizeram isto desta maneira porque mais pessoas podem imaginar como usar isto daquela maneira.

Para criar um bom programa com uma interface de usuário usável, você vai ter de deixar seus príncipios de lado, obrigado. Microsoft pode não ser a única companhia para copiar: se você está fazendo uma livraria online, você deveria provavelmente estar certo que o seu web site está pelo menos semanticamente parecido com a Amazon. Amazon mantêm o seu cartão de compras por 90 dias. Você pode pensar que é mais esperto e limpar o cartão depois de 24 horas. Se você fizer isto, haverão clientes Amazon que colocam pedidos em seu cartão de compras e voltam duas semanas mais tarde esperando que os pedidos ainda estejam lá. Quando não estiver, você perdeu um cliente.

Se você está fazendo um editor de fotos de alta qualidade para profissionais, eu lhe asseguro que 90% de seus usuários vão conhecer o Adobe Photoshop, portanto é melhor que você faça algo muito parecido com o Photoshop nas áreas onde seu programa se sobrepõe. Se você não fizer, as pessoas vão dizer que o seu programa é difícil de usar, mesmo que você pense que é mais fácil de usar do que o Photoshop, porque não está se comportanto da maneira que eles esperam que se comporte.

Existe uma outra tendência popular de reinventar os controles comuns que vem com o Windows. Nem me fale sobre o Netscape 6. Havia um tempo quando você podia dizer o programa que era compilado com o compilador Borland C++ porque eles usavam grandes botões de OK com enormes caixa de verificação verde. Isto não era nem perto tão ruim quanto Kai's Photo Soap:

Bem, então, é impressionantemente bonito, mas o O com uma linha cortanto ele (que significa "não") me lembra de um "OK," e o padrão no Windows é ter o OK na esquerda, portanto eu me pego teclando o botão errado toda hora. O único benefício em ter simbolos divertidos ao invés do "OK" e "Cancel" como todo mundo é que você pode mostrar o quanto você é criativo. Se as pessoas cometem erros por causa da criatividade do Kai, bem, este é somente o preço que eles tem que pagar por estar na presença de um artista. (Um outro problema com esta "caixa de diálogo" é que não tem uma barra padrão de títulos que pode ser usada para mover a caixa de diálogo na tela. Portanto se a caixa de diálogo está na caminho de alguma coisa que você quer ver para poder responder a pergunta, você está sem sorte.)

Agora, há muito a ser ganho por ter uma interface de usuário inteligente, com boa aparência. O bom design gráfico como o do Kai é agradável e irá atrair as pessoas para o seu programa. O truque é fazer isto sem quebrar as regras. Você pode alterar a aparência visual das caixas de diálogo, um pouco, mas não quebre a funcionalidade.

Quando a primeira versão do Juno foi escrita, tinha a caixa de diálogo padrão de log on que solicitava seu nome de usuário e uma password. Depois que você entrava com o nome de usuário, você supunha que tinha que pressionar TAB para ir para o campo de password e digitar a password.

Agora, este usuário distraído da gerencia de programação do Juno, que tinha muito mais experiência com UNIX do que com Windows, portanto ele estava acostumado a digitar o nome de usuário, e então pressionar o ENTER para pular para o campo de password (ao invés de TAB). Agora, quando você está escrevendo um programa e usa como alvo um usuário não especialista em Windows, um programador UNIX não é provavelmente o exemplo ideal de um usuário típico, mas este gerente estava insistindo muito que a tecla Enter deveria mover para o próximo campo ao invés de utilizar o padrão Windows. "Só porque a Microsoft faz isto, não significa que é o certo," ele disse.

Então os programadores gastaram uma quantidade considerável de tempo para escrever alguma caixa de diálogo complicada para fazer com que o código trabalhasse em torno do comportamento default do Windows. (Ser inconsistente é quase sempre mais trabalhoso do que agir como a sua plataforma espera). Este código era um grande pesadelo na manutenção; ele não se adaptou tão bem quando nós mudamos do Windows 16-bit para 32-bit. Ele não fazia o que as pessoas esperavam. E assim que novos programadores se juntavam na equipe, eles não entendiam porque havia esta subclasse estranha para as caixas de diálogo.

Um número grande de programadores tentaram reimplementar vários controles comuns do Windows, de botões à barras de rolagem à barras de ferramentas e barras de menu (A coisa favorita para reimplementar da equipe da Microsoft Office). Netscape 6.0 foi tão longe como reimplementar cada controle comum do Windows. Isto geralmente tem alguns efeitos ruins não previsíveis. O melhor exemplo é com a caixa de edição. Se você reimplementar a caixa de edição, existem uma quantidade grande de utilitários que você você nem mesmo conhece (como o suplemento editor de lingua Chinesa, e a versão bidirecional do Windows que suporta texto da direita-para-esquerda) que vão parar de funcionar porque eles não reconhecem a sua caixa de edição não padrão. Alguns dos revisores da versão preliminar do Netscape 6.0 perceberam que a caixa de URL, usando um controle de edição não padrão do Netscape, não suporta as características comuns do controle de edição como clicar com o botão direito para abrir um menu de contexto.

Quando você se encontrar argumentando com um fundamentalista anti-Microsoft ou um designer gráfico criativo sobre consistência, eles estão inclinados a citar Emerson incorretamente: "Consistência é o fantasma de mentes pequenas..." A citação real é "Uma consistência estúpida é o fantasma das mentes pequenas." Bons designers de IU usam a consistência inteligentemente, e, acima de tudo não podem exibir sua criatividade tão bem, no decorrer do percurso isto faz os usuários mais felizes.



> Capítulo 6

Esse artigo apareceu originalmente em Inglês com o título User Interface Design for Programmers Chapter 5: Consistency and Other Hobgoblins  

Joel Spolsky é o fundador da Fog Creek Software, uma pequena empresa de software na cidade de Nova York. Formou-se na Universidade de Yale, e trabalhou como programador e gerente na Microsoft, na Viacom e no Juno.


O conteúdo dessas páginas reflete exclusivamente a opinião do autor.
Todo o conteúdo Copyright ©1999-2005 Joel Spolsky. Todos os direitos reservados.

FogBUGZ | CityDesk | Fog Creek Software | Joel Spolsky