True or false? Beware of the wording of your controls. Download the english version.

Eu sempre tenho essa sensação quando estou escrevendo os rótuolos dos meus controls (no caso, checkbox). Sempre chega um momento em que eu “travo”. Se não deu pra entender meu problema, veja a imagem abaixo:

Considere a checkbox no topo: o que ela diz? Você concorda?

E a de baixo: você concorda?

Pois é isso que me trava. Não é uma tarefa fácil, o próprio Shneiderman*falou. Eu acho que tem muito a ver com o rótulo: se é positivo, normalmente é mais fácil marcar o estado desejado (concordo / não concordo).

Mas desta vez a coisa era um pouco mais complicada…..

Eu tenho uma checkbox que deve habilitar / desabilitar a edição de uma propriedade. Se esta propriedade “não se aplica”, então não tem sentido editá-la. Como a figura abaixo mostra:

Se “Coeficiente de atrito” se aplica, então você pode atribuir um valor a ela. Mas considere as opções na imagem acima: o que elas significam?

O que eu quero que o usuário entenda? “Se a propriedade NÃO SE APLICA, então NÃO EDITE”.

Então, embora tenha parecido esquisito no início, vou usar a sentença negativa. Eu achei que poderia ser confuso, porque se a propriedade for aplicável, então você teria que desmarcar o checkbox, o que é equivalente a uma dupla negação: “Não não se aplica, i.e. se aplica”. Mas eu também acho que ter o control selecionado no início é importante, para que o usuário veja que ele está desabilitado porque “não se aplica”.

Então a coisa ficou assim:

* Se ele disse, deve ser verdade ;0) Leia, é um clássico: Software Psychology: Human Factors in Computer and Information Systems;

I prototype! Drops of avoided problems and discovered solutions. Download the english version.

Estou aqui novamente para falar sobre design. A idéia agora é documentar o processo de proejto de uma aplicação que deve auxiliar na seleção de materiais. Estou projetando a interface, com o precioso auxílio do prof. André Canal Marques  e do prof. Celso Scalestksy,ambos excelentes designers. O projeto é da Unisinos, e esparamos ter algo conreto para mostrar em alguns meses :0)

Bem, seleção de materiais é um assunto vasto. Há pessoas que fazem pós graduação nisso (como o prof. Marques fez). Você tem que saber Química e um monte de Engenharia. De forma resumida, um dos objetivos é responder a pergunta: “de que material este objeto pode/deve ser feito”? Há muitas variáveis nesta questão, e para projetar uma aplicação que efetivamente ajude, é preciso conhecê-las.

A questão é que eu não sou uma especialista no assunto…. E não vou me tornar uma especialista em algumas semanas. Nem os especialistas em seleção de materiais irão se tornar especialistas em design de interface… E aí, o que fazer?

Nós prototipamos*! Claro, houveram reuniões prévias para que eu tivesse um pouco mais de enetndimento da área (ele beirava o zero), para conhecer algunas cases e para ver o que nossos vizinhos estão fazendo. Algumas das coisas importantes que eu aprendi:

1. Registrar um material leva tempo. Há muitos valores a associar com um material.
2. Pode haver dois materiais com composição química idêntica, mas com propriedades diferentes.
3. Há livros e softwares onde você pode conseguir o valor das propriedades de engenharia de um material. Por exemplo, eles podem te fornecer os dados sobre o Polietileno. Mas se o fabricante muda o processo de fabricação do material, as propriedades do livro/software não estão “corretas”.
4. ÀS vezes, o fabricante dá uma amostra do material, mas não dá a descriçao completa. Ele informa as propriedades mais relevantes, mas as demais devem ser pesquisadas (no web site, por exemplo).
5. Há propriedades que não são relevantes para alguns materiais.

Também fiquei sabendo que a materioteca tinha uma ficha para registrar as amostras, e recebi uma cóipa desta ficha.

Depois destas reuniões, eu comecei com modelos de papel e caneta. A idéia é criar um layout básico, testar algumas funcionalidades e ver como elas se comportam juntas. E isso já me economizou muito tempo e me deu algumas boas idéias :0)

Figura 1. Os promeiros desenhos.

Por exemplo: a tela “Tipo”.  Cada material deve ser classificado de acordo com seu tipo. Mas há mais de uma taxonomia para isso. Estas taxonomias consideram diferentes aspectos dos materiais, como composição química. Estamos usando a mesma da materioteca. Eu estava desenhando essa tela (figura 2, à direita) e pensei: “ei, será que um polímero não pode ser natural? Tipo, proteínas são anturais…” Então eu desenhei a tela que está à esquerda na figura 2. Mostrei para o prof. Marques, que disse: “é, está certo, mas neste sistema de classificação, um material só pode ser associado a um tipo”. Ok, beleza.

Figure 2. Como os tipos podem ser atribuídos?

O segundo exemplo de benefício de usar “protótipos*” tem a ver com a tarefa de registrar um novo material. Como você pode ver na figra 3, há propriedades sensoriais (mais à esquerda, no topo), propriedades de engenharia (à direita) e uma visão geral (à esquerda, embaixo) de propriedades comuns.  Como elas estão duplicadas na aba “Propriedades de engenharia”, pensei que talvez o sistema pudesse usar estas propriedades para gerar esta “visão geral”, que é importante para  o usuário. “Sim, é uma boa idéia”, meus colegas disseram. POis será implementado :0)

Figura 3. Uma amostra das propriedades que um material pode ter.

Seguindo esta linha de raciocínio, eu pensei: “hei, pode ser uma boa idéia melhorar a tarefa ainda mais, fazê-la mais rápido, se, dado o tipo, o sistema pudesse reconhecer alguns valores padrão de propriedades”. A resposta foi: “é plausível e é uma boa idéia. Mas vai demorar para compilar estas propriedades”.

O caso é: para papel e caneta, e para uma sessão de uma hora de desenho, eu consegui entender a aplicação muito melhor.

Você deveria tentar :0)

* Certo, não são protótipos. Não são nem mock-ups… São mais modelos, de tão simples que são. Mas são de uma grande ajuda.

O debate pegou fogo mais uma vez na FB… Foi só falar em “Flex para  website” que estamos indo para os 50 replies. O caso é que a argumentação mais eloquente foi do Beck Novaes, que, apesar de não ter participado do debate, parece ter (finalmente) colocado um ponto final nesta (aborrecida) questão.

Aqui você vai para o post original da DClick.

Maps: could they be easier to use? Download the english version.

Este é outro post sobre usabilidade, e, mas i uam vez, o tema é o musue virtual que eu estou ajudando a projetar. Ele tem uma rolagem 2D horizontal, de forma que o usuário pode rotacionar a sala e ver as imagens. Este tipo de navegaçao é bem conchecido, por isso não epsero que haja dificuldade.

As sals têm mapas, mostrando a planta de cima, como numa planta baixa, o que também é bem típico. Mas eu estava me perguntando: quem deveria rotacionar? A sala ou o observador? Abaixo há exemplos dos dois casos:

Figura 1. Preesiona play para ver o observador rotacionando, e a sala se mantém fixa.

Figura 2. Pressione play para ver a sala rotacionando, enquanto o observador se mantém fixo.

A favor da opção “observador rotaciona – sala fixa”, temos os argumentos:

• é mais bem conhecida
• tem menos volumes girando, o que pode ser confuso.

A desvantagem é:

• o mapeamento não é tão direto, porque é preciso rotacionar a sala mentalmente, para descobrir a posição atual. Numa situação real, a sala é fixa, mas no mundo virtual, ela se move! O observador está parado.

Par o mapa alternativo (”sala rotaciona – observador parado”), a vantagem é:

• o mapeamento entre a posição real e no mapa do observador é direta.

Os contras são:

• menos conhecida,
• tem mais voumes girando, o que pode ser confuso,
• como a sala não é simétrica, às vezes o observador fica muito perto das paredes, dando a impressão que ele não está no centro da sala.

E você, o que acha? Quala  melhor opção e porque? Qualquer que seja  resposta,a lição é esta: você deve sempre tentar melhorar seus controls de navegação. Como se faz isso, é assunto pra outro post.

Using opacity in navigation. Download the english version.

Post rápido :0)

Estou projetando a interface de um museu virtual, que vai tre uma mostra de Mineralogia.

E eu tenho uma “queda”, uma preferência pessoal por “alphas”, imagens com um grau de opacidade. Para quem não sabe o que é, são imagens translúcidas, semi-transparentes.

Mas elas parecem não estar “funcionando” no meu principal, ainda wu estajm bem no menu de scrolling…

O caso é que, no menu de scrolling (a imagem mais à direita),a  opacidade permite ver o que está embaixo do botão. Isso é importante porque a tela rola embaixo dele, de forma que pode ser que tenha uma imagem ali. Também está funcionando bem para controls que mostram o nome de uma determinada imagem, quando se deixa o maouse sobre ela (também conhecida como data tip)

A vantagem deste efeito se perde no caso do menu principal: debaixo dos botões sempre tem a mesma coisa: uma faixa preta. Quando o menu se abre (como na imagem mais à esquerda), não irá ficar aberto por muito tempo, e enquanto está aberto, você não se interessa pelo que está embaixo. Além do mais, como o que está embaixo varia conforme a sala gira, os botões do menu ficam com um fundo diferente a cada vez que abrem…

Bobagens pseudo-cognitivistas, você diria. Sim, mas está “quebrando” a aparência dos botões… Memso um nvato sabe que os controls de uma apliação devem ter uma alto grau de coerência, ou seja: eles se parecem e se comportam da mesma forma, para que o usuário possa prever o que via acontecer quando interagir com o control.

Contudo, como as transparências estão mesmo atrapalhando no caso do menu, vou removê-las dali, e manter nos demais controls.

Adeus aos botões com alpha…

:***(