To tree or not to tree? Download the english version.

Bem, vai ficar complicado traduzir o título deste post, mas acho que deu pra entender o que eu quis dizer com ele ;0)
Trees são um dos meus data controls favoritos, porque dá pra colocar montes de informação dentro deles, organizadas em categorias. Elas também são otimizadas para visualização, já que o usuário pode facilmente setar o que ele quer e o que não quer ver. Por isso eu uso bastante :0)

Neste novo projeto em que estou trabalhando, andei desenhando trees para um monte de casos de uso (sim, eu desenho meus casos de uso), e, quando me dei conta, tinha apenas um caos que não tinha uma tree…. Uma parte dele está na imagem abaixo (à esquerda).

Seria legal se todos os casoso tivessem o mesmo jeito de mostrar e interagir com informação – se eu uso trees em todo lugar, porque não usar neste caso de uso também? A resposta é simples, você consegue descobri-la?

O grupo à esquerda é parte de uma tela onde você escohe o tipo de um material. Estas categorias são mutualmente exclusivas (você só pode escolher uma) e coletivamente exaustivas (elas, como grupo, descrevem todos os tipos possíveis; qualquer material tem que estr em uma delas). Na direita, temos processos industriais. Um único material pode “ter” mais de um processo, tanto na mesma categoria como em categorias diferentes. Então, se eu usasse trees à esquerda, quando um “galho” estivesse fechado, o usuário não veria uma informação vital (coletivamente exaustiva, lembra?). Neste caso, ele não estaria apto a escoher. Por outro lado, usar tree para mostrar processos permite que o usuário “esconda” processos que não lhe interessam.

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;

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.

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…

:***(