Gabriela Trindade Perry: HCI, Design Cognition, Flex

F***! I deleted it! Download the english version.

Hehe, e agora, o que você vai fazer? Como você deve ter notado, o post é sobre deletar itens inadvertidamente. Meu argumento é que este pode ser um erro que o usuário irá cometer (mesmoq ue a gente siga a lei de Fitt). Como nós, desenvolvedores (e designers) cuidadosos podemos evitar isso? Nós os “alertamos” :0)

Nós jogamos um Alert (o control) que diz algo do tipo: “ei, tem certeza que quer deletar isso?”

E o que o usuário faz? Ele não lê e clica ok. – “M****!”. Você diz: – “eu avisei”.

Bem, e se – e se e se – tentássemos algo diferente? E se ao invés de “alertar” o usuário, mudássemos o estado de um item e colocássemos um botão de undo?

Se o usuário inadvertidamente deleta o “Item F”, ele vê que o estado do item mudou. Se ele realmente quer deletar, ok, então quando ele sair* o tiem será deletado. Mas, se ele comete um erro, ele pode desfaze-lo logo que percebe.

* É claro, temos o problema de saber quando o usuário sai…

Gentle ItemEditor: design suggestion. Download the english version.

Agora é hora de ItemEditors.  Para os que não estão familizarizados com eles, veja este exemplo (Flex docs: http://livedocs.adobe.com/flex/3/html/movies/DropInNumStepper.swf)

ItemEditors são um tipo de ItemRenderer, como o nome diz: são uma view para um item. Pense num Tree, num List, num DataGrid… Normalmente, itens são mostrados como texto, mas, às vezes, queremos usar imagens e até mesmo outros controls. E se você precisa editar itens no local, você usa um ItemEditor :0)

Bem simples, hein? Mas e quanto à usabilidade deles? Pense que você não é um desenvolvedor, ok? Você não está familizarizado com eles. Entao, como você muda o conteúdo de um item? Você vai esperar que seu usuário explore a interface? Eu não :0)

Então estou sugerindo o uso de ItemEditors como este da imagem abaixo:

O usuário vê, ao laod de cada item, dois botões: um para deletar e um para editar. Quando ele pressiona o botão de editar, o ItemRenderer muda, e agora ele mostra um TextInput com um botão de “tick”, ok. Qual a diferença? O usuário sabe o que esperar (e se ele for muito novato, pelo menos vai ter uma pista que precisa clicar em alguma coisa), e se ele clica no botão de editar, ele vê a interface mudar. “Ah… então é aqui que eu mudo o conteúdo… Ok” :0)

PS: Se você for um desenvolvedor, me diga uma estimativa de tempo para fazer este ItemEditor e um como o do site da documentação do Flex (quantas horas você levaria para implementar cada um deles). Se eu tiver retorno, vou publicar a estimativa (anonimamente, claro).

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.

Normalmente, trabalhar com coleções nativas do Flex do Flex não responde às minhas necessidades… Eu costumo extender estas coleções para ter certeza que estou trabalhando com o tipo correto (meus VOs). E eu sempre preciso saber qual o “estado” da coleççao, ou seja, ter um cursor. Eu faço isso usando um Iterator.

Esta app tem uitas classes e interfaces, por isso não fica prático mostrar o código aqui, por isso dê uma olha a no código, ok?

Se você tiver sugestões (não dúvidas), comente.

View source here.