Gabriela Trindade Perry: HCI, Design Cognition, Flex

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.

Two “Flex” posts in a row! Maybe today will be the day Im having more than 40 visitors!

Read the rest of this entry »

Estou escrevendo estes posts conforme leio:estão em ordem cronológica. Os livros/artigos que estão aqui serão a base da bibliografia da minha tese, que será sobre ensino de projeto de interfaces de softwares educacionais. Se você quiser disutir esses assuntos comigo, entre em contato. Estou usando isso para a revisao bibliografica da minha tese. Se voce acha esse material interessante, procure ler os artigos.

NÃO USE ESTE MATERIAL COMO FONTE DE PESQUISA!!!! APENAS COMO FONTE DE ESTUDO.

Acabei de ler Sketches of thought, de Vinod Goel. Minha intenção é começar a formar uma base teórica para poder discutir projeto de interfaces para softwares educacionais – e por isso, Goel é um excelente autor para começar. Podemos pensar em outros autores e livros que estão inscritos na categoria “de base”: Akin (Psychology of Architectural Design); Simon (Sciences of the Artificial) e Newell e Simon (Human Problem Solving). Porém, acho que Goel traz uma novidade, pois “linka” os universos da psicologia cognitiva e da computação com a compreensão do “fazer design” em baixo nível.

Este formato de argumentação só poderia ser possível para um pesquisador educado dentro das ciências cognitivas (Goel foi orientado por Searle), e isso traz uma riqueza (e força) impressionante à estruturação do problema.

Não achei um livro fácil – acho que li os primeiros capítulos quatro vezes, descansei três meses e li os últimos quatro capítulos em um mês – mas será essencial na minha construção da compreensão do que é design.

Read the rest of this entry »

Este é o terceiro de uma série de três vídeos com o tema da palestra que fiz na FlexMania (onde as gravações de todas as apresentações estão disponíveis).

Fique à vontade para comentar, concordar ou discordar. Dúvidas, poste nas listas (FlexBrasil || FlexDev).

Tópicos do vídeo:

• Criando um theme com imagens e classes embutidas
• Usando -include-file para inserir arquivos no swc do theme
• Usando -include-class para inserir classes no swc do theme
• Compilando o theme
• Usando themes em projetos MXML

Este é o segundo de uma série de três vídeos com o tema da palestra que fiz na FlexMania (onde as gravações de todas as apresentações estão disponíveis).

Fique à vontade para comentar, concordar ou discordar. Dúvidas, poste nas listas (FlexBrasil || FlexDev).

Tópicos do vídeo:

• Extendendo ProgrammaticSkin
• Skinning Button com uma imagem de fundo
• Resolvendo problemas com skins compartilhados (Button e ComboBox)
• Usando o arquivo defaults.css para descobrir as configurações de skin