Gabriela Trindade Perry: HCI, Design Cognition, Flex

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.

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…

:***(

Como eu pensei, não foi difícil, apesar de algumas coisas esquisitas que tive que fazer:

• Não queria sobrescrever nenhum control do LFex, só pra implementar esse estilo simples… Então, para passar a classe (br.com.gabi.skins.TiledBG) como estilo para os HBoxes no app, eu tive que passar atrvé de um estilo existente, que aceitasse um Object como ponto de entrada. Por isso escolhi backgroundImage. Malsss

• Como não é um estilo padrão, ele não sabe quando a HBox muda de tamanho, entaõ tive que fazer o pai o estilo ouvir um resize. Malsss
• Não achei lugar melhor para colocar este handler, por isso usei o updateDisplayList, que no skin roda só uma vez. Malsss

Bem na maioria das vezes, essas esquisitices são porque eu não fiz alguma coisa direito… Provavelmente não me dei conta de alguma coisa… Se você souber onde foi que eu errie, por favro me avise.

De qualquer forma, funioan e muito bem

VIEW SOURCE

Então lá vai um post só em Português, para variar. Achei que poderia ser bacana postar sobre UCD aqui, já que tivemos um debate muito bacana na flexdev sobre suporte ao usuários e tals.

Ainda que eu não ache que o perfil de designer e de programador possam ser incorporados (tipo baixar o santo) ao mesmo tempo na mesma pessoa, me parece positivo ter tantos programadores se preocupando com o tema.

Por isso disponibilizei aqui uma das aulas que dou no Design da Unisinos, sobre UCD – User Centered Design. Quem está fazendo TCC e tal não cite este material, certo? Isso não é fonte de pesquisa :0P (não custa avisar…)

Bom  proveito.

Super simples. Tão simples que eu nem precisava escrever este post, de tantos exemplos que tem an web.

Mas eu estão tããããão entediada hoje, que resolvi me dar uma folga. Então aí está. Aproveite :0)

No zip você vai encontar os fontes do Flex e o fla com os dois MC, como mostra na imagem abaixo.

As imagens mostram a biblioteca do fla

E este é o script do frame 1 da timeline do fla. Não tem documetn class, mas poderia ter…

O código no Flex também é super simples…

Baixe os fontes aqui

PS. Esta solução não usa o método addFrameScript. Se você quer tentar usá-lo, veja http://blog.tygate.com/?p=194

I have – as lots of people do – the “intuition” that designers shouldn´t design alone: we should be followed closely by our engineering counterparts. This is something pretty easy to stand for – as long as we´re on paper (or on screen, as is my case).

It´s no secret that we don´t get along well: we don´t agree, don´t trust and sometimes we dislike each other. If you could hear engineers talk about designers and vice versa (add architects x engineers; digital designers x coders to the tale) and you´ll get the picture.

Oh, but well, as I said: it´s not a secret. And I will not bother to talk about something everyone knows.

I´ll talk – briefly, because I have an UI to specify :0( – about something concrete: a case were a design decision was supported by an engineering constraint. I think this is important because when we stand for interdisciplinarity (I hope this word exists) – in front of less experienced co-workers or students, as is my case – we should have examples of what we´re saying.

I´ve been advocating for interdisciplinarity inside the teams I work, and I think it´s been a valuable experience, but the concrete knowledge of why is it that good sometimes is missed or shared as a valuable (though not easy) experience. Maybe it´s because of my professional background experience – I am a designer, an human factors specialist AND a coder. I feel the bitter and the sweet of being in all those fronts.

So, as I was saying, I am detailing an UI. It´s going to be a car pool software, for the university I work for. I stated we should have callouts to represent the passengers. The idea is that the driver, after placing a route, will see all the people he could pick up. Those people would be represented as callouts. When the user-driver passes the mouse over the callout, it´s going to expand, showing the name of the person. When the user clicks the name, the callout expands once more, to show a button asking if you accept the passenger. If you do, the callout will show a picture and contacts of that person.

Pretty well. So, drawing, I made the callouts rectangular. Why did it do that?

• It would be easire to expand. Visually, the transformation would be more natural: from square to rectangle.
• I worked – years ago – on the implementation of this kind of callout. So this is the callout shape I know best.

But this shape has a problem. Can you spot it?

I couldn´t untill I started writting the use case for the “system actor” called   “Retrieving passengers”. What did I found out? Placing assymetrical callouts over the route would require aditional logic. Each callout would have to “know” the best position: turned left or ritgh; upside down or heads up.

I only realized it when drawing: how would I ask for the devs to work this out?

So turned me back to google maps callout. I found them ugly and uninteresting. But they are much easier to place. They do not need that extra work.

Now the questions are:

• Are those differences in the callout shape relevant?
• Is the placement logic that difficult to implement?

My answer – based on my knowledge as design and coder – is: the differences are not that relevant and the logic is really difficult to implement.

So this decisions poses another issues:

• The shape morphing (from circle do rounded rectangle) is feasible?
• How will the user-driver notice the difference between route-spots-callouts (the places he said he has to pass by) and the passenger-callouts?

In this figure, you see the green “circle like” callout (which is a google maps callout) representing a point the user-driver set in his rout – he IS going to pass that spot. I stated that because sometimes you are not willing to take the route the computer advises to: you have to pick up you sister in her work, you´re going to cash money, you think the best route is not the faster, it could be crowed and the list goes on and on. That´s why the user-driver will have the freedom to specify the route. And maybe he will like to see if a passenger is near a place he is going to pass by. You have to remember that maybe the driver dont know the passenger, so, I could be an additional aid for him to know that: Ill be picking Sonia near that street / avenue / place.

So, thar leads me to a dead end… I cant tell whats more important. I realized the trades I have to make, but I think I dont have enough information to make a decision. So, what will I do? I will specify the harder-to-do-callouts, which will solve the interaction problem – I think – Ill have if they are symetrical (as google´s), and ask for user tests on this feature. If it´s really necessary – if Im right – we´ll have the budget. If it´s not, my dev team will be pleased with me worring for not to waste their time.

So, to finish, I made a picture showing the pathway from the problem discovery to the solution specification.