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 7: Projetando para Pessoas Que Têm Coisas Melhores para Fazer Com Suas Vidas, Parte Dois


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

Quando o Macintosh era novo, Bruce "Tog" Tognazzini escreveu uma coluna na revista para desenvolvedores Apple sobre Interface com Usuário na IU. Na sua coluna, as pessoas escreveram bastante sobre problemas interessantes de design de IU, o qual ele discutia. Estas colunas continuam até hoje no seu site. Ele também colecionou e melhorou em alguns bons livros, como Tog on Software Design, que é muito divertido e uma boa introdução ao design de IU. (Tog on Interface era ainda melhor, mas não está mais sendo impresso.)

Tog inventou o conceito da barra de menus de uma milha de distância para explicar porque a barra de menus no Macintosh, que está sempre fixada no topo da tela, é bem mais fácil de usar do que as barras de menus no Windows, que aparecem dentro de cada janela da aplicação. Quando você quer apontar para o Menu Arquivo no Windows, você tem um alvo aproximadamente com meia polegada de largura e um quarto de polegada de altura para acertar. Você deve mover e posicionar o mouse quase precisamente em ambas as dimensões vertical e horizontal.

Mas no Macintosh, você pode arrastar o mouse para o topo da tela, sem se preocupar o quão alto você o arrasta, e ele parará na borda da tela - a posição vertical correta para usar o menu. Portanto, efetivamente, você tem um alvo que ainda está a meia polegada de largura, mas uma milha de distância. Agora você precisa somente se preocupar com o posicionamento horizontal do cursor, não vertical, portanto a tarefa de clicar no item de menu é muito mais fácil.

Baseado neste princípio, o Tog tem uma pergunta popular: Quais são os cinco pontos na tela que são mais fáceis de acessar (apontar) com o mouse? A resposta: todos os quatro cantos da tela (onde você pode literalmente arrastar o mouse próximo ao local de uma vez sem apontar de forma nenhuma), mais, a posição corrente do mouse, porque já está lá.

O princípio da barra de menus de uma milha de distância é razoavelmente conhecida, mas não deve ser inteiramente óbvio, porque a equipe do Windows 95 perdeu o ponto completamente com o botão de Start, situado quase no canto esquerdo inferior da tela, mas não exatamente. De fato, está aproximadamente 2 pontos distante da parte inferior e 2 pontos da esquerda da tela. Portanto, por causa de uns pares de pontos, a Microsoft literalmente "lançou mão de vencer das garras da vitória", Tog escreveu, e fez disto muito mais difícil de acessar o botão start. Poderia ter sido uma milha quadrada, absolutamente trivial de acertar com o mouse. Por alguma coisa, eu não sei o que. Deus nos ajude.

No capítulo anterior, nós falamos sobre como os usuários detestam ler, e evitarão isto a menos que eles absolutamente não possam realizar suas tarefas. Similarmente:

Usuários não podem controlar o mouse muito bem. 

Eu não quero dizer isto literalmente. O que eu quero dizer é, você deveria projetar o seu programa para que ele não requeira uma quantidade tremenda de agilidade do mouse para usá-lo corretamente. Seis principais razões:

  1. Algumas vezes as pessoas estão usando componentes para apontar, como trackballs, trackpads, e o pequeno dispositivo vermelho no ThinkPad, que são mais difíceis de controlar do que o mouse verdadeiro.
  2. Algumas vezes as pessoas estão usando mouses sob condições ruins: uma mesa tumultuada; uma bolinha suja que faz o mouse pular; ou o mouse propriamente dito que é um clone de $5 que não funciona direito.
  3. Algumas pessoas são novas em computadores e não desenvolveram ainda a habilidade motora para usar mouses precisamente.
  4. Algumas pessoas literalmente não têm as habilidades motoras para usar mouses precisamente, e nunca terão. Elas podem ter artrite, tremores, tendinite; elas podem ser muito jovens ou muito velhas; ou qualquer outro número de desabilidades.
  5. Muitas pessoas acham que é extremamente difícil dar o duplo-clique sem suavemente mover o mouse. Como resultado elas frequentemente arrastam as coisas em volta da tela quando elas queriam iniciar aplicativos. Você pode falar destas pessoas porque seus desktops são uma bagunça porque na metade do tempo elas tentam iniciar alguma coisa ao invés disto elas acabam movendo-as.
  6. Até mesmo na melhor das situações, usar o mouse demais parece um atraso para as pessoas. Se você forçar as pessoas a executar uma operação com vários passos usando o mouse, elas podem sentir como se elas estivessem sendo interrompidas que em contrapartida faz com que a IU pareça não responder, que, como você deveria saber agora, faz delas pessoas infelizes.

Há uns tempos atrás quando eu trabalhava no Excel, os laptops não vinham com mouse neles, então a Microsoft fez um trackball que se prendia do lado do teclado. Agora, um mouse é controlado com o pulso e a maioria dos dedos. Isto é mais parecido com escrever, e você provavelmente desenvolveu habilidades motoras muito precisas para escrever no primário. Mas um trackball é controlado totalmente com o polegar. Como resultado, é muito mais difícil controlar um trackball no mesmo grau de precisão que um mouse. A maioria das pessoas acham que podem controlar um mouse dentro de um ou dois pixels, mas podem somente controlar um trackball dentro de 3 ou 4 pontos. Na equipe do Excel, eu sempre aconselhava as pessoas a testarem suas novas IUs com o trackball, ao invés de somente com um mouse, para ver como ele se comportaria com pessoas que não são capazes de fazer com que o mouse vá exatamente onde elas querem.

Um dos elementos de IU que mais me aborrecem é a caixa de listagem tipo combobox. Que é uma que se parece com isto:

Quando você clica na seta para baixo, ela expande:

Pense sobre quantos cliques de mouse vai levar para escolher, digamos, Times New Roman. Primeiro, você tem que clicar na seta para baixo. Então, usando uma barra de rolagem, você tem que cuidadosamente rolar até que o Times New Roman esteja visível. Muitos destes dropdowns são cuidadosamente projetados para exibir somente dois ou três itens de uma vez, portanto esta rolagem não é muito fácil, especialmente se você tem várias fontes. Isto envolve puxar o polegar cuidadosamente (com um pequeno movimento, isto provavelmente é pouco provável que vá funcionar), ou clicar repetidamente na segunda seta para baixo, ou tentar clicar na área entre o polegar e a área de baixo -- que provavelmente parará de funcionar quando o polegar ficar cansado, aborrecendo-o mais tarde. Finalmente, se você realmente conseguir tornar o Times New Roman visível, você tem que clicar nele. Se você perder, você tem que começar tudo novamente. Agora multiplique por 10, se, digamos, você quer usar uma fonte extravagante para a primeira letra em cada um dos seus capítulos, e você está realmente infeliz. 

O controle combo dropdown é até mesmo mais irritante porque existe uma solução até fácil: faça o dropdown longo o suficiente para conter todas as opções. 90% das caixas combo por aí não usam todo o espaço disponível para fazer o dropdown, o que é uma sina. Se não existe espaço suficiente entre a caixa principal de edição e o final da tela, o dropdown deveria crescer até que se ajuste todos os itens, até mesmo se tiver que ir por todo o caminho do topo da tela até a parte inferior da tela. E então, se ainda houver mais itens para ajustar, deixe a caixa combo rolar automaticamente a medida que o mouse se aproxima da borda, ao invés de exigir que o pobre usuário se atrapalhe com uma minúscula barra de rolagem.

Além disso, não me faça clicarem uma pequena seta para a direita da caixa de edição até exibir a caixa combo: deixe me clicar em qualquer lugar da caixa combo. Isso aumenta o alvo do clique aproximadamente dez vezes e faz com que fique muito mais fácil acertar o alvo com o ponteiro do mouse.

Vamos olhar para um outro problema com o mouse: caixas de edição. Você deve ter notado que quase toda caixa de edição no Macintosh usa uma fonte em negrito, larga chamada Chicago que parece com um designer gráfico feio e pobre sem finalidade. Os designers gráficos (ao contrário dos designers de IU) foram ensinados que fontes estreitas e de espaço variado são muito mais graciosas, tem uma aparência melhor, e são mais fáceis de ler. Tudo isto é verdade. Mas os designers gráficos aprenderam suas habilidades no papel, não na tela. Quando você precisa editar texto, monoespaço tem uma grande vantagem sobre as fontes de espaços variáveis: é fácil de ver e de selecionar letras estreitas como "l" e "i". Eu aprendi esta lição depois de observar um senhor de sessenta anos em um teste de usabilidade dolorosamente tentando editar o nome da sua rua, que era alguma coisa como Fillmore Street. Nós estávamos usando o Arial de 8 pontos, então a caixa de edição se pareceu com isto:

Note que o I e o Ls são literalmente de um ponto de largura. A diferença entre o I minúsculo e o L minúsculo é literalmente um pixel. (Similarmente, é quase impossível ver a diferença entre "RN" e "M" em minúsculo, portanto esta caixa de edição pode realmente dizer Fillrnore.)

Existem muito poucas pessoas que notariam se elas digitaram Flilmore ou Fiilmore ou Fillrnore, e mesmo se elas notassem, elas levariam um tempo absurdo tentando usar o mouse para selecionar a letra incorreta e corrigi-la. Na verdade, elas até mesmo levariam um tempo árduo usando o cursor piscante, que possui dois pontos de largura, para selecionar uma única letra. Olhe como seria muito mais fácil se tivéssemos usado uma fonte larga (mostrada aqui com Courier em negrito)

Ótimo, OK, então isto ocupa mais espaço e não parece tão bom para seus designers gráfico. Lide com isto! É muito mais fácil para usar; isto até mesmo parece melhor para usar porque a medida que o usuário digita, o texto fica detalhado, claro, e é tão mais fácil de editar.


Aqui está o pensamento padrão de um programador comum: existem somente três números: 0, 1, e n. Se n é permitido, todos n's são igualmente prováveis. Este padrão de pensamento vem da crença (provavelmente verdadeira) que você não deveria ter nenhuma constante numérica no seu código exceto pelo 0 e 1. (Constantes diferentes de 0 e 1 são referenciadas como "números mágicos". Eu nem quero entrar nesta questão filosófica.)

Assim, por exemplo, programadores tendem a pensar que se o seu programa permite que você abra múltiplos documentos, deve permitir que você abra infinitamente muitos documentos (tanto quanto a memória permita), ou pelo menos 2^32, o único número mágico que os programadores admitem. Um programador tenderia a olhar com desdém para um programa que limitasse você a abertura de 20 documentos. O que 20? Por que 20? Não é nem mesmo potência de 2!

Uma outra implicação de todos n's que são igualmente prováveis é que programadores tendiam a pensar que se os usuários podem redimensionar e mover as janelas, eles deveriam ter a flexibilidade completa para onde essas janelas vão, embaixo do último ponto. Afinal de contas, posicionar uma janela 2 pontos do topo da tela é "igualmente provável" como posicionar uma janela exatamente no topo da tela.

Mas isto não é verdade. Como parece, existem muitas boas razões porque você pode querer uma janela exatamente no topo da tela (ela maximiza o real estado da tela), mas não existe nenhuma razão para deixar 2 pontos entre o topo da tela e o topo da janela. Então, na verdade, 0 é muito mais provável do que 2.

Os programadores da Nullsoft, criadores do WinAmp, gerenciaram de alguma forma para evitar o pensamento do programador que tem encarcerado o resto de nós por uma década. WinAmp tem uma grande característica. Quando você começa a arrastar a janela próximo da borda da tela, vindo dentro de uns poucos pontos, ela automaticamente se ajusta na borda da tela perfeitamente. Que é provavelmente exatamente o que você queria, desde que 0 é muito mais provável que 2. (A janela principal do Juno tinha uma característica similar: é a única aplicação que eu tenho visto que é "encaixada" na tela e não pode ser arrastada além da borda.)

Você perde um pouco de flexibilidade, mas em troca, você tem uma interface de usuário que reconhece que controlar o mouse precisamente é difícil, então porque você deveria ter que faze-lo? Esta inovação (que todo programa poderia usar) facilita a carga do gerenciamento de janela de um modo inteligente. Olhe atentamente para a sua interface de usuário, e nos dê todas falhas. Faça de conta que nós somos gorilas, ou talvez orangotangos espertos, e nós realmente teremos problemas com o mouse.



> Capítulo 8

Esse artigo apareceu originalmente em Inglês com o título User Interface Design for Programmers Chapter 7: Designing for People Who Have Better Things To Do With Their Lives, Part Two  

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