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 3: Opções


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

Quando você vai a um restaurante e vê um cartaz que diz "Não são permitidos Cachorros," você pode pensar que o cartaz é puramente restritivo: Sr. Restaurant não gosta de cachorros em volta, então quando ele construiu o restaurante ele colocou aquele cartaz.

Se fosse assim por qualquer motivo, haveria também um cartaz "Não permitimos Cobras"; afinal, ninguém gosta de cobras. E um cartaz "Não permitimos Elefantes", porque eles quebram as cadeiras quando se sentam.

A razão real que indica isso é histórica: existe um marco histórico que indica que as pessoas costumavam trazer seus cachorros no restaurante.

Cartazes mais proibitivos existem porque os proprietários de um estabelecimento ficou doente e cansado de pessoas fazendo X, então eles fizeram um cartaz pedindo a eles para por favor não fazerem X. Se você vai em um daqueles velhos restaurantes familiares de 50 anos, como o Yankee Doodle em New Haven, as paredes são cobertas com cartazes dizendo coisas como "Por favor não coloquem suas mochilas na mesa," evidência mais antropológica que as pessoas costumavam colocar suas mochilas na mesa frequentemente. Pela idade do cartaz você pode imaginar quando mochilas eram populares entre os estudantes locais. 

Às vezes eles são difíceis de imaginar. "Por favor não traga garrafas de vidro no parque" deve significar que alguém se cortou andando sobre vidro quebrado, enquanto estava andando descalço na grama uma vez, e esta é uma boa escolha que eles impuseram à cidade.

Software tem um registro arqueológico similar, também: é e chamado de Caixa de Opções. Selecione a caixa de opções Tools | Options e você verá uma relação de argumentos que os designers de software tinham sobre o design do produto. Nós deveríamos abrir automaticamente o último arquivo que o usuário estava trabalhando? Sim! Não! Depois de duas semanas de debate, ninguém quer ferir os sentimentos de ninguém, o programador coloca um #ifdef como precaução enquanto os designers discutem. Eventualmente eles decidem fazer disto uma opção.

Não tem que ser um debate entre duas pessoas: pode ser um dilema interno. Eu simplesmente não posso decidir se nós deveríamos otimizar o banco de dados pelo tamanho ou velocidade. Por outro lado, você chega a conclusão com coisas como o que é inquestionavelmente a mais estúpida caixa de diálogo("wizard") na história do sistema operacional Windows. Esta Caixa de Diálogo é tão estúpida que merece algum tipo de comentário. Uma nova categoria de comentário. É a caixa de diálogo que aparece quando você tenta encontrar alguma coisa no Help:

O primeiro problema com esta caixa de diálogo é que ela é confusa. Você está tentando encontrar ajuda no arquivo de help. Você não dá a mínima, naquele momento, se o banco de dados é pequeno, grande, personalizado ou coberto com chocolate. Neste meio tempo, esta desagradável, desagradável caixa de diálogo está dando uma pequena explicação que ela deve criar uma lista (ou banco de dados). Existem pelo menos três parágrafos lá, a maioria dos quais são completamente confusos. Existe uma frase irritantemente estranha "seu(s) arquivo(s) de ajuda". Você vê, você pode ter um ou mais arquivos. Como se você se importasse neste momento que poderia ser mais do que um. Como se isto fizesse a mínima diferença. Mas o programador que trabalhou naquela caixa de diálogo estava obviamente em um dilema por acreditar na possibilidade que poderia ser mais do que um arquivo(s) de help e seria incorreto dizer arquivo de help, agora, seria?

Não me deixe começar a dizer sobre como a maioria das pessoas que querem ajuda não são o tipo de pessoas que entendem estes tipo de dificuldade. Ou que até mesmo usuários avançados, programadores com PhDs em Ciência de Computadores que sabem tudo sobre indexação completa de textos, não seriam capazes de imaginar o que eles realmente estão pedindo para escolher.  

Para piorar as coisas, isto não é nem mesmo uma caixa de diálogo... é um assistente (a segunda página que simplesmente diz alguma coisa como "muito obrigado por se inscrever nesta total perda de tempo," para parafrasear). E é óbvio considerar que os designers tinham alguma idéia de qual opção é a melhor; afinal de contas, eles chegaram a recomendar uma das opções.

O que nos traz para nossa segunda principal regra de design de interface com o usuário:

Toda vez que você fornece uma opção, você está pedindo para o usuário tomar uma decisão.

Pedir para o usuário tomar uma decisão não é por si só uma coisa ruim. Liberdade de escolha pode ser maravilhoso. Pessoas adoram pedir bebidas tipo-expresso no Starbucks porque eles conseguem fazer tantas opções. Grande-meio café descafeinado meio café normal-leite desnatado-chocolate-com chantilly. Super Quente!

O problema vem quando você pede que eles façam uma escolha que eles não se importam. No caso de arquivos de ajuda, as pessoas estão procurando o arquivo de ajuda porque elas estão tendo problemas na solução de alguma coisa que elas realmente querem resolver, como fazer um convite de aniversário. A tarefa de convite de aniversário tem sido infelizmente interrompida por causa que eles não podem imaginar como imprimir balões do lado de cima e embaixo, ou que quer que seja, eles vão para o arquivo de ajuda. Agora, algum programador da Microsoft usou uma ferramenta de indexação do help com uma idéia elaborada da sua própria importância para o esquema inteiro das coisas e tem a audácia, e auto-confiança, para interromper o usuário mais uma vez e começar a ensinar ao usuário coisas sobre como fazer listas (ou banco de dados). Este segundo nível de interrupção é completamente não relacionado com convites de aniversário, e isto simplesmente vai complicar e eventualmente irritar o usuário.

E acredite em mim, usuários se importam sobre muito menos coisas do que você pode pensar. Eles estão usando o seu software para cumprir uma tarefa. Eles pouco se importam com o processo. Se é um programa gráfico, eles provavelmente querem ser capazes de controlar cada ponto até o nível mais detalhado. Se isto é uma ferramenta para construir um web site, você pode apostar que eles são obsessivos sobre fazer o web site parecer exatamente do jeito que eles querem que pareça.

Eles entretanto não, se importam nenhum pouco se a barra de ferramentas do programa está em cima ou embaixo na janela. Eles não se importam como o arquivo de ajuda está indexado. Eles não se importam com um monte de coisas, e é responsabilidade do designer fazer as escolhas para eles para que eles não tenham que fazer. Este é o peso da arrogância que um designer de software tenta provocar em uma escolha como esta para o usuário, simplesmente porque o designer não podia pensar o suficiente para decidir que opção realmente é a melhor. (É ainda pior quando você tenta encobrir o fato que está dando ao usuário uma escolha difícil por converter isto em um assistente, como o pessoal do WinHelp fez. Como se o usuário fosse um estúpido que precisasse passar por um mini-curso de dois passos na escolha que lhes está sendo oferecida para que eles possam tomar uma decisão educada.)

Diz-se que design é uma arte de fazer escolhas. Quando você faz o design de uma lixeira para o canto, você tem que fazer escolhas entre requisitos conflitantes. Precisa ser pesada para que não saía do lugar. Precisa ser leve para que o coletor de lixo possa ergue-lo. Precisa ser grande para que possa acomodar bastante lixo. Precisa ser pequeno para que não atrapalhe o caminho das pessoas. Quando você está desenvolvendo, e você tenta abdicar sua responsabilidade por forçar o usuário a decidir alguma coisa, você provavavelmente não está fazendo o seu trabalho. Alguém mais fará um programa mais fácil que realiza a mesma tarefa com menos intromissões, e a maioria dos usuário adorarão.

Quando o Microsoft Excel 3.0 foi lançado em 1990, era a primeira aplicação a mostrar uma característica nova chamada barra de ferramentas. Era uma característica sutil mas as pessoas adoraram, e todo mundo copiou -- até o ponto que não é mais comum ver uma aplicação sem uma barra de ferramentas.

A barra de ferramentas fez um sucesso tão grande que a equipe do Excel fez uma pesquisa de campo usando uma versão especial de Excel que eles distribuíram para um número pequeno de pessoas; esta versão armazenava estatisticamente quais eram os comandos mais frequentemente utilizados e relatava-os para a Microsoft. Para a próxima versão, eles adicionaram outra linha de botões na barra de ferramentas, desta vez contendo os comandos mais frequentemente utilizados. Muito bom.

O problema era, eles nunca se esforçaram em reestruturar a equipe da barra de ferramentas, que parecia não saber quando deixar a coisa boa o suficiente, quieta. Eles queriam ser capazes de personalizar sua barra de ferramentas. Eles queriam que você fosse capaz de arrastar a barra de ferramentas para qualquer lugar da janela. Então, eles começaram a pensar sobre como a barra de menus é realmente só uma barra de ferramentas glorificada com palavras ao inves de ícones, então eles deixaram você arrastar a barra de menus para qualquer lugar que você quisesse na tela, também. Personalização em esteróides. Problema: ninguém se importa! Eu nunca conheci ninguém que quisesse sua barra de menus em nenhum outro lugar do que no topo da janela. Mas aqui está a piada (ruim): se você tentar empurrar o menu Arquivo, e você acidentalmente pegar a barra de menu um pouquinho para a esquerda, você retira a barra de menu inteira, arrastando-a para o único lugar que você possivelmente não queria que estivesse: bloqueando o documento que você está trabalhando.

Quantas vezes você viu isto? E uma vez que você tenha feito isto por engano, não está claro o que você fez ou como consertá-lo. Então aqui nós temos uma opção (mover a barra de menu) que ninguém quer (ok, talvez 0.1% de todos os humanos querem isso) mas que fica no caminho para quase todo mundo.

Um dia uma amiga me ligou. Ela estava tendo problemas para enviar email. Metade da tela ficou cinza, ela disse. 

Metade da tela ficou cinza?

Eu levei cinco minutos no telefone para imaginar o que tinha acontecido. Ela tinha acidentalmente arrastado a barra de ferramentas do Windows para o lado direito da tela, então acidentalmente ampliou-a:

Este é o tipo de coisa que ninguém faz de propósito. E existem muitos usuários de computador por aí que não podem resolver este tipo de confusão; por definição, quando você acidentalmente reconfigura uma das opções no seu programa, e você não sabe como reconfigurá-lo. É quase chocante o número de pessoas que desinstalam e então re-instalam seus softwares quando as coisas começam a se comportar errado, porque pelo menos elas sabem como fazer aquilo. (Eles aprenderam a desinstalar primeiro, porque desta forma todas as customizações antigas provavavelmente vão voltar).

"Mas espere!" você diz. "É importante ter opções para usuários avançados que querem fazer pequenos ajustes em seus ambientes!" Na realidade, não é tão importante como você pensa. Isto me lembra de quando eu tentei mudar para um teclado Dvorak. O problema era, eu não uso um computador. Eu uso todos os tipos de computadores. Eu uso o computador de outras pessoas. Eu uso três computadores regularmente em casa e três no trabalho. Eu uso computadores no laboratório de teste do trabalho. O problema com ambiente personalizado é que ele não se propaga, então não vale o trabalho.

A maioria dos usuários avançados usam vários computadores regularmente; eles fazem o upgrade de seus computadores a cada dois anos, eles reinstalam seu sistema operacional a cada três semanas. É verdade que a primeira vez que eles perceberam que você podia remapear completamente o teclado no Word, eles alteravam tudo em volta para ser mais de seu gosto, mas tão logo que eles fizeram o upgrade para o Windows 95 aquelas configurações foram perdidas, e eles não eram o mesmo no trabalho, e eventualmente eles paravam de reconfigurar as coisas. Eu perguntei para muitos dos meus amigos "usuários potênciais" sobre isto; a maioria deles não fazem qualquer personalização além do mínimo necessário para fazer seus sistemas se comportarem razoavelmente.

Todo vez que você fornece uma opção, você está pedindo que o usuário tome uma decisão. Isto significa que eles terão que pensar sobre alguma coisa e decidir sobre isto. Não é necessariamente uma coisa ruim, mas, no geral, você deveria tentar minimizar o número de decisões que as pessoas têm que tomar.

Isto não significa eliminar todas as opções. Existem escolhas suficientes que os usuários terão que fazer de qualquer modo: a maneira que seus documentos parecerão, a maneira que seus web site se comportarão, ou qualquer coisa que faça parte do trabalho que o usuário está executando. Nestas áreas, vá a loucura:  é ótimo dar opções para as pessoas: isto quer dizer, quanto mais melhor. E existe outra categoria de opções que as pessoas gostam: a habilidade de alterar o visual das coisas, sem realmente alterar o seu comportamento. Todo mundo adora a aparência do WinAmp; todo mundo coloca uma figura de fundo no desktop. Desde que a escolha afete a aparência visual sem afetar a maneira que as coisas funcionam, e desde que os usuários estejam completamente livres para ignorar a opção e ter seu trabalho feito de qualquer maneira, este é um bom uso de opções.



> Capítulo 4

Esse artigo apareceu originalmente em Inglês com o título User Interface Design for Programmers Chapter 3: Choices  

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