Gabriela Trindade Perry: HCI, Design Cognition, Flex

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…

:***(