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 2: Descobrindo o que Eles Esperam


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

Quando um usuário novo se senta para usar um programa, ele não vem com um registro antigo de performance. Eles têm algumas expectativas sobre como o programa vai funcionar. Se eles usaram um software similar antes, eles deduzirão que este vai funcionar da mesma forma que o outro software. Se eles usaram qualquer software antes, eles vão pensar que o seu software está de acordo com certas convenções comuns. Eles podem ter suposições inteligentes sobre como a IU vai funcionar. Isto é chamado de modelo do usuário: é o entendimento intelectual do que o programa vai fazer por eles.

O programa, também, tem um "modelo intelectual," só que este modelo é codificado em bits e será fielmente executado pela CPU. Isto é chamado de modelo do programa, e isto é a Lei. Como nós aprendemos no Capítulo Um, se o modelo do programa corresponde ao modelo do usuário, você tem uma interface de usuário com sucesso.

Vamos olhar para um exemplo. No Microsoft Word (e na maioria dos processadores de texto), quando você coloca uma figura no seu documento, a figura é realmente anexada no mesmo arquivo do documento. Você pode criar a figura, arrastá-la para dentro do documento, e então apagar o arquivo da figura original, mas a figura permanecerá no documento.

Agora, o HTML não permite que você faça isto. Documentos em HTML devem armazenar as suas figuras em um arquivo separado. Se você pega um usuário que está acostumado com os processadores de texto, e não sabe nada sobre HTML, e senta-os em frente de um editor elegante de WYSIWYG HTML como o FrontPage, eles quase com certeza pensarão que a figura vai ser armazenada no arquivo. Chame isto de inércia de modelo para usuário, se você desejar.

Então nós temos um conflito infeliz de modelo de usuário (a figura será anexada) versus modelo de programa (a figura deve estar em um arquivo separado), e a IU está fadada a causar problemas.

Se você está projetando um programa como FrontPage, você acabou de encontrar seu primeiro problema de IU. Você realmente não pode alterar o HTML. Alguma coisa deve ser feita para que o modelo do programa seja compatível com o modelo do usuário.

Você tem duas opções. Você pode tentar alterar o modelo do usuário. Isto acaba sendo notavelmente difícil. Você poderia explicar coisas no manual, mas todo mundo sabe que os usuários não lêem manuais, e eles provavelmente não teriam que ler. Você pode exibir uma pequena caixa de diálogo explicando que o arquivo de imagem não será anexado, mas isto tem dois problemas: é irritante para usuários sofisticados, e usuários não lêem caixas de diálogo, também (nós falaremos mais sobre isto no Capítulo Seis). 

Então, se a montanha não vêm até Maóme ... sua melhor escolha quase sempre vai ser alterar o modelo do programa, e não o modelo do usuário. Talvez quando eles inserirem a figura, você poderia fazer uma cópia da figura em um subdiretório abaixo do arquivo do documento, então pelo menos você pode unir a idéia do usuário de que a figura é copiada (e o original pode ser apagado com segurança).

Como eu sei qual é o modelo do usuário?

A solução para isso é relativamente fácil. Simplesmente pergunte para eles! Pegue cinco pessoas aleatórias no seu escritório, ou amigos, ou família, e diga para eles o que o seu programa faz em termos gerais ("é um programa para construir páginas na web"). Então descreva a situação: "Você tem uma página na web que você está trabalhando, e um arquivo de figura chamado Picture.JPG. Você insere a figura na sua página da web." Então pergunte para eles algumas questões para experimentar e presuma o modelo de usuário deles. "Onde a figura está? Se você apagar o Picture.JPG, a página da web ainda será capaz de exibir a figura?"

Um amigo meu está trabalhando em uma aplicação de album para fotos. Depois que você insere as suas fotos, a aplicação exibe um grupo de thumbnails: pequenas cópias de cada figura. Agora, gerar estes thumbnails leva um tempo longo, especialmente se você tem muitas figuras, então ele quer armazenar os thumbnails em algum lugar do hard disk portanto eles têm que ser gerados uma vez. Existem muitas maneiras que ele poderia fazer isto. Eles poderiam ser todos armazenados em um arquivo grande chamado Thumbnails. Eles poderiam ser todos armazenados em arquivos separados, em um subdiretório chamado Thumbnails. Eles podem ser marcados como arquivos ocultos no sistema operacional então os usuários não tomariam conhecimento deles. Meu amigo escolheu uma maneira de fazer na qual ele pensou ser o melhor negócio: ele armazenou o thumbnail de cada figura picture.JPG em um arquivo chamado picture_t.JPG no mesmo diretório. Se você fizesse um album com 30 figuras, quando você terminasse, existiriam 60 arquivos no diretório incluindo as figuras thumbnail.

Você poderia argumentar por semanas sobre os méritos e deméritos de vários esquemas de armazenar figuras, mas como vimos, existe uma maneira mais científica de fazer isto. Apenas pergunte a um grupo de usuários onde eles pensam que os thumbnails deveriam ser armazenados. Naturalmente, muitos deles não saberão ou não se importarão, ou eles não terão pensado sobre isto, mas se você perguntar para muitas pessoas, você começará a ver algum tipo de consenso. A escolha popular é o melhor modelo de usuário, e depende de você fazer o modelo do programa de acordo com isto.

Em seguida, você tem que testar as suas teorias. Construa um modelo ou faça um protótipo da sua interface de usuário e dê para algumas pessoas a tarefa de completar. A medida que eles trabalham nas tarefas, pergunte a eles o que eles pensam que está acontecendo. Seu objetivo é descobrir o que eles esperam. Se a tarefa é "inserir uma figura," e você vê que eles estão tentando arrastar a figura para dentro do seu programa, você perceberá que é melhor você inserir o recurso arrasta-solta. Se eles vão para o menu Inserir, você perceberá que é melhor você ter a opção de Figura no menu Inserir. Se eles vão para a barra de ferramentas de Fonte e recolocam a palavra "Times New Roman" com as palavras "Inserir Figura", você encontrou uma relíquia que não foi introduzida no GUIs ainda e está esperando uma interface de comando de linha.

Quantos usuários você precisa para testar a sua interface? Seu instinto pode ser "quanto mais, melhor," que faz sentido para experimentos científicos. Mas este instinto está errado. Quase todo mundo que faz teste de usabilidade para viver parece pensar que cinco ou seis usuários é o suficiente. Depois disto, você começa a ver o mesmo resultado de novo e de novo, e quaisquer usuários adicionais são somente uma perda de tempo.

Você não precisa de um laboratório formal de usabilidade, e você realmente não precisa trazer usuários "da rua" -- você pode fazer "o teste de usabilidade de 50 centavos" onde você simplesmente pega a próxima pessoa que você vê e pede que elas façam um teste rápido de usabilidade. Esteja certo que você não influencie e diga a elas como fazer as coisas. Peça para elas "pensarem em voz alta" e entreviste-as usando perguntas claras para tentar descobrir o modelo intelectual delas.

Se o seu modelo de programa não é trivial, provavelmente não é o modelo do usuário.

Quando eu tinha 6 anos e o meu pai trouxe para casa uma das primeiras calculadoras do mundo, uma HP-35, ele tentou me convencer que havia um computador dentro dela. Eu pensei que aquilo era improvável. Todos os computadores no Jornada nas Estrelas eram do tamanho de um quarto e tinham grandes gravadores de fita magnética. Eu pensei que havia somente um correlação inteligente entre as teclas no teclado e os elementos individuais do display de LED que por acaso produzia resultados matematicamente corretos. (Ei, eu tinha 6 anos).

Uma regra importante baseada na experiência é que os modelos do usuário não são muito complexos. Quando as pessoas têm que supor como um programa vai funcionar, elas tendem a pensar em coisas simples, ao invés de coisas complicadas. 

Sente-se em frente a um Macintosh. Abra dois arquivos de planilhas do Excel e um arquivo de documento do Word. Quase todo usuário novato pensaria que as janelas eram independentes. Elas parecem independentes:

O modelo do usuário diz que clicando na Planilha 1 traria aquela janela para frente. O que realmente acontece é que a Planilha 2 vem para frente, uma surpresa frustrante para quase todo mundo:

Como isto resulta, o modelo de programa do Microsoft Excel diz que "você tem estas pastas invisíveis, uma para cada aplicação, e as janelas são 'coladas' naquelas pastas invisíveis. Quando você o traz para o primeiro plano, todas outras janelas se moverão para a frente, também."

Ceeeerto. Pastas invisíveis. Quais são as chances que o modelo do usuário incluísse o conceito de pastas invisíveis? Provavelmente zero. Então usuários novos serão surpreendidos por este comportamento.

Um outro exemplo do mundo da Microsoft Windows é a combinação das teclas Alt+Tab que chaveia para a "próxima" janela. A maioria dos usuários provavelmente assumiriam que ela simplesmente rotaciona entre todas as janelas disponíveis. Se você tem a janela A, B, e C, com A ativa, Alt+Tab levaria você para B. Alt+Tab novamente levaria você para C. De fato, o que acontece é que o segundo Alt+Tab leva você de volta para A. A única maneira de ir para C é segurar Alt e pressionar Tab duas vezes. É uma maneira elegante para alternar entre duas aplicações, mas quase ninguém imagina isto, porque é um modelo ligeiramente mais complicado do que o modelo de rotacionar entre janelas disponíveis.

É difícil fazer o modelo do programa conforme o modelo do usuário quando os modelos são simples. Quando os modelos se tornam complexos, é muito mais improvável. Então pegue o modelo mais simples possível.



> Capítulo 3

Esse artigo apareceu originalmente em Inglês com o título User Interface Design for Programmers Chapter 2: Figuring Out What They Expected  

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