Gabriela Trindade Perry: HCI, Design Cognition, Flex

A defesa foi em agosto, mas o canudo mesmo só saiu em novembro.

Noves fora o trabalhão insano que é fazer uma coisa dessas, o que fica é uma sensação de trabalho cumprido; não por ter entregue a tese, mas por ter conseguido atingir o objetivo de um doutorado: desenvolver a capacidade de fazer suas próprias perguntas.

Ainda me admiro de ter conseguido isso. Me lembro que quando eu terminei o mestrado e entrei no programa de doutorado (em 2006), tinha muito receio de terminar o curso e não conseguir trabalhar sozinha. Isso se explica: o meu mestrado só foi bacana por causa do meu orientador, [o grande] Dr. Fernando Gonçalves  Amaral, que sempre criticava as coisas que eu escrevia, e do meu co-orientador, o [também grande] Dr. Agostinho Serrano, que na real “bolou” toda a pesquisa. No final, a dissertação foi aprovada com estrelinhas, afinal cumpria o requisito de um mestrado.

Alias, foi do Fernando que eu tirei essa idéia: que o requisito de um mestrado é apenas te preparar para o doutorado; é um treino, uma iniciação ao método científico. Sendo assim, fazer mestrado sem fazer doutorado é pura perda de tempo.

E lá fui eu me inscrever. O orientador estava decidido, eu já conhecia o grupo com quem eu queria trabalhar. Mas eu já estava atormentada com esse medo: será que um dia eu vou conseguir trabalhar sozinha? Explico: assim como o mestrado, o doutorado tem um objetivo muito simples: capacitar um pesquisador a fazer suas próprias pesquisas. Dotorado não tem muito a ver com “aumentar o conhecimento da humanidade” ou com “ineditismo”. Isso são consequências. O que importa é que, ao final do curso, o doutor seja capaz de fazer pesquisas até o final de sua vida produtiva – sem precisar de apoiar num orientador.

E eu tinha muito medo disso: meu trabalho vinha sendo bom, mas sempre por causa da ajuda de outros… Primeiro o Amaral e o Agostinho, depois o [também grande] Fernando Schnaid. E eu?

Mas no final eu “desencantei”. Foi num momento bem particular: quando eu comecei a ler um livro que o Fernando me emprestou [Cognition in Design Education]. Cara, esse livro mudou tudo, pois foi aí que eu consegui me enxergar como pesquisadora. Sério, eu consegui me ver pesquisando isso durante – sei lá – os próximos 10 anos. A partir disso foi só engatar a quinta seguir em frente.

O resultado está aí. Está bem legal. Estou terminando de escrever o primeiro artigo da tese com o Schnaid, e acho que dá pra emplacar mais outros com tranquilidade. Além disso, consegui uma posição na UFRGS, o que sempre foi minha meta, e vou começar a trabalhar com pesquisa [de verdade!].

Então é isso: demora, mas uma hora dá certo. E se quiser ler a tese, baixa ela no 4share.

Atenção: antes de começar, saiba que este texto foi escrito por uma designer com “alguma” experiência em aplicações para web – uma pessoa que programa (modéstia à parte) bem e que tem um mestrado em ergonomia. Este texto mostra as mudanças em um projeto motivadas pelo compromisso da nossa personagem de aderir às “regras” do design de interfaces. Este foi o primeiro aplicativo para mobile que ela projetou, e é assim que ela se sente:

Vamos deixar então que nossa designer conte como foi…

Design de interfaces para mobile (no Brasil)

Conheci, ano passado, três caras que estavam a fim de desenvolver aplicativos para celular. Acho que formamos um excelente time, pois reunimos experiência e conhecimento técnico. Além disso, temos alguém no grupo com um “feeling para negócios” (sorry, Marco, não sei descrever de outra forma), o que é pré-condição para engrenar. Depois de muitas reuniões (do Marco), conseguimos vender um projeto, cujo briefing descrevo: criar um aplicativo para ser usado em eventos. As funcionalidades oferecidas são:

• Receber avisos dos organizadores (por exemplo: alteração na agenda).
• Receber avisos promocionais dos patrocinadores.
• Fazer perguntas aos palestrantes.
• Trocar cartões de visita virtuais.
• Enviar convites para meetings dentro da área do evento.

O rationale é: pessoas que vão a eventos têm interesses comuns, mas nem sempre se conhecem – aliás, muitos vão a estes eventos para se conhecerem.  Porém, o sistema de crachás de identificação tem dois problemas: algumas pessoas simplesmente não os usam e é constrangedor ficar lendo o crachá dos outros. O aplicativo seria uma forma de fazer com que as apresentações fossem mais eficientes, permitindo que os participantes escolham com quem querem manter contato.

A restrição explícita: deve funcionar na maior parte dos aparelhos. Minha restrição explícita: deve ser boa usabilidade. Lógico.

Claro, eu nunca havia feito nada para mobile, mas tinha uma idéia de mais algumas restrições:

• Interação pelas teclas de direção; seleção pela tecla do meio. Sem touch.
• Otimizar a transmissão de dados. Toda vez que você envia ou recebe dados, vê uma mensagem desagradável avisando da conexão. Isso, mais importante do que o custo em reais, gera desconfiança: “porque estou toda a hora sendo avisado disso?”.

Ok, vamos para o Balsamiq (que só tem iPhone como modelo, mas abstrai, ok?) ver como fica. Veja aí como eu desenhei a área das “Perguntas”.

Para você entender meu raciocínio, vou colocar o processo em forma de diálogo: eu e um Balde de Água Fria.

Eu – Vamos usar tabs, certo? Isso permite que o usuário veja em que sessão ele está. Quando ele quiser fazer “perguntas” (por isso o título, entende?), escolhe a palestra e clica nela (com o botão do meio). Isso faz com que ele veja a tela da direita: ali ele pode enviar uma pergunta para o palestrante.

Balde de Água Fria – Hummm, mas ele também pode enviar respostas para enquetes e a avaliação da palestra. Você sabia disso desde o início, não foi idéia do cliente na última hora.

Eu – Certo. Quem sabe então a gente coloca uma barra de botões?

BAF – Não cabe… Muito texto nos labels…

Eu – Vamos colocar uns ícones…

BAF – Esses ícones do Balsamiq são uma caca…

Eu – É eu sei. Mas a gente vê uns legais depois…

BAF – Ok, mas você está com um problema de coerência…

Eu – O QUÊ? DE COERÊNCIA?

BAF – Pois é… Você está usando tabs para alternar entre telas. E sua barra de botões tem o mesmo comportamento. Além disso, na tela de “Convites recebidos”, por exemplo, você está usando uma barra de botões com ícones para operar sobre um dado (o cartão de apresentação). Quer dizer que em uma área a barra de botões troca de tela e na outra ela sinaliza operações possíveis sobre um dado.

BAF – E não é só isso. Olhando bem, parece que você também tem um problema de consistência.

Eu – O QUÊ? DE CONSISTÊNCIA?

BAF – Sim. Veja a tela “Perguntar”. Aqui você usa texto no botão. Afinal, é texto ou ícone?

Eu – P*** m***, é verdade.

Eu – Ah, já sei! Vamos fazer assim, ô:

EU – Quando o usuário clicar na palestra para fazer uma pergunta (ou enquete ou avaliação), as tabs vão mudar de label, e para ele voltar, é só clicar na tab bem à esquerda que diz “<<”.

BAF – Nossa… Você realmente se preocupa com a coerência. O problema foi mesmo resolvido, afinal agora você só tem tabs. Só que agora você tem dois níveis de hierarquia que parecem ser um só. Além disso, você alterou o comportamento esperado de um componente (o tab).

Eu – P*** m***, HIERARQUIA e MUDANÇA DE COMPORTAMENTO? Dá um descanso, BAF!

BAF – Sorry, mas você pediu par eu ser chato…

Eu – Tá bom.

Eu – Olha só, podemos usar janelas modais! Quando o usuário for enviar a pergunta, por exemplo, uma nova janela será aberta. A gente pode deixar o que está atrás meio transparente, com um blur, sabe? Aí o usuário saberia que foi para outro nível de edição.

BAF – Entendo. Assim você não muda o comportamento dos tabs e preserva a hierarquia.

Eu – Isso mesmo. Sabia que você iria entender.

BAF - Como fica quando houver três níveis de hierarquia?

Eu – Não haverá.

BAF – Você sabe que não deve dizer isso…

Eu – Vá à merda, BAF.

BAF – Ok. Você sabe que a luminosidade pode atrapalhar a leitura destas janelas com transparência, não sabe?

Eu – Vá à merda, BAF.

E esta é a história da primeira versão do layout no Balsamiq. Algum tempo depois, o João (nosso desenvolvedor-java-rulez) fez a seguinte observação:

João – Sabe, Gabi, essa tela de buscar aqui está complicada de navegar… Acho que tem problemas de usabilidade… O usuário tem que clicar várias vezes até chegar no botão de buscar. Daí eu consertei isso colocando um menuzinho-aqui-assim.

OK, PARA TUDO.

BAF, COMO É QUE VOCÊ NÃO ME AVISOU???

BAF – Bem, não me dei conta disso.

EU – Mas “menu”? O usuário não tem como ver o que tem no menu. Depois, ele precisa DESPERDIÇAR um clique só par ver o que tem no menu. E se o menu tiver mais de um nível, ele vai ter que desperdiçar outros cliques só pra inspecionar o menu. ISSO NÃO PODE!

BAF – Pois é, é muito ruim, eu sei. Mas sabe que o João está certo? Dá uma olhada nessa tela aqui.

BAF – Imagina que a pessoa está no primeiro item da lista, ok? E que ela quer enviar um cartão de apresentação. Quantos cliques ela tem que dar?

Eu – Nove para chegar até “Networking” e um para selecionar. Que m****.

Eu – É… Acho que estou negligenciando as softkeys… Vou fazer o seguinte: usar a softkey da esquerda para abrir um menu, e a da direita para outras ações.

Eu – Tipo assim: o usuário pode continuar navegando com os direcionais e selecionando os itens da lista (tela da esquerda). Quando ele clicar numa palestra, ele vai para a tela que está à direita. Ali eu vou usar um título com breadcumbs, pra mostrar onde ele está e de onde ele veio (só que não pode ser feio que nem esse do Balsamiq!). E nas softkeys tem o menu (na esquerda) e um botão, quando necessário (na direita). E para minimizar essa coisa de desperdiçar cliques inspecionando o menu, vamos tentar usar as mesmas opções sempre que possível, ok?

BAF – É, agora parece bom.

Eu – Vamos ver o que os guris acham.

E AÍ, GURIS, O QUE VOCÊS ACHAM?

Linko is meant to help you build linkographies, which were made popular amongst design researchers after the work of Gabriela (:0) Goldschmidt.

There´s really not much to a linkography: it´s a map of links. But it has a great power to illustrate protocol data. To illustrate how linkographies are well acepted in this research filed, follow this search on Science Direct´s database.

I am using linkographies to depict some of my data, and that was the drive behind my decision of writting a software to do this. They are hard to draw by hand, as you have to focus your attention on a procedural task: linking protocol segments. As I´m not trying to reach Nirvana, I didn´t even gave it a try :0)

So here´s where Linko comes to play. The idea is to feed it with a csv file exported from excel, and voila, you have your graphs.

You can of course use it, but you´ll need to compile it with Flex 3.5. I could write a version that loads a local file, so there won´t be the need to re-compile it to build every graph, but I´ll do that later (now I have to re-turn my attention to the analysys, the coding fun is over!).

The images bellow shows two image generated by Linko, with the useTime parameter to true (the first) and false (the second).

And you see the software in action here (I suggest you turn fullscreen on, by hitting F11 on your keyboard).

And you can download the source here.

Sério, eu precisava de uma folga. Já faz um tempo que minha vida gira em torno da análise: design de interfaces, programação e toda a construção da minha tese. Então achei que eu merecia tirar umas horas de folga e ver se eu ainda tinha mão pra fazer uma coisa realmente bonita, sem usar artifícios de brushes e photoshops. O problema é que eu fiquei com a sensação de ter feito “mais do mesmo”, ou seja, foi um resultado seguro que eu sabia que iria conseguir. Tenho que sair dessa…

Vi este video no site do Mauro Martins, e fiquei mesmo impressionada com os primeiros 10 minutos da palestra.

Grant Skinner – sem dúvida um dos mais experiente e reconhecido profissional da comunidade Flash – fala sobre expertise em programação, de como se evolui de um script até um arquiteto, sobre qual o perfil e qual o objetivo de cada um deles. Em paralelo, ele conta sua própria história, como ele deixou de ser um scripter para ser um arquiteto. E ele termina esta parte dizendo que um arquiteto quebra as regras porque ele conhece as regras.

Achei este trecho tão fantástico porque ele se aplica a qualquer atividade de design.

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.

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 »

Então tá. Terminei meu programa sobre carros. Agora, se você, como eu, não consegue escolher qual o melhor carro pra você, use este programa, hehe.
Bem, claro que a maioria das características não está implementada… Só tem ano de fabricação e consumo… Mas, vamos combinar, o resto é moleza!
Quem for olhar o programa e dizer que está feio porque não segue MVC, eu digo: isso era só pra fazer o programa funcionando… Não pretendo mexer nele de novo… Até porque, eu não gosto de mexer em programa velho… Pior que comer feijão frio (sei que tem gente que gosta, mas… eca!).
Enfim… está tudo comentado: quem quiser ver como faz essa coisa bonitinha de drag n drop é só baixar / instalar e procurar a pasta srcview dentro do seu micro. Ou então clique aqui para ver o source da versão AIR…
Me diverti fazendo isso…

O programa é para AIR. Para quem não sabe o que é AIR, é um runtime que permite fornecer facilmente um único instalador de aplicativo que funcione em todos os sistemas operacionais (pra fazer os arquios feitos no Flash e no Flex serem instalados como um programa no seu Desktop e poderem acessar o sistema de arquivos, o clipboard, o system tray e outras coisas que não podemos acessar no browser).

It´s all about the task. Download the english version.

Estou envolvida com um projeto pessoal, cuja motivação foi a dificuldade que estou passando para escolher um carro novo. Muito complicado para quem não é expert. Até agora estou com a sensação que não fiz a escolha certa. Então, o projeto que propous a mim mesma: como eu poderia criar um software que poderia realmente ajudar as pessoas a escolher um carro?

Todas as minhas dificuldade forma causadas pela forma como a informação é disposta. Os sites onde você busca opções (como, no Rio Grande do Sul; sul do Brasil, www.autocarro.com.br ewww.panambra.com.br) não ajudam você em nada. Esses sites de revendas, por exemplo, mostram diversos dados sobre os carros, todos ao mesmo tempo… Mas e daí? Eu não pretendo formar uma base enciclopédica de conheciemtno sobre carros. Eu apenas quero saber qual o melhor carro para mim.

Veja as imagens abaixo.

De um ponto de vista cognitivo, o que precisamo fazer?Precisamos percorrer toda a lista, armazenando um dado (digamos, preço), e comparando com o seguinte. Se o carro seguinte tiver um preço melhor, substituimos o anterior pelo atual. E assim até terminar a lista. Se dois ou mais fatores são igualmente importantes, precisamos computar a razão entre estes fatores. Se dois ou mais fatores não são igualmente importantes, fica mais difícil. Aliás, acho que não conseguiríamos tratar este problema, usando apenas a cabeça… E se nossos recursos ($$) não compram o carro que queremos, precisamo abrir mão de algumas coisas (diração hidráulica? rodas de liga?). Mas do que?

Entenderam? Talvez eu seja meio neurótica… Mas eu queria fazer a escolha certa, e não desistir do problema e comprar qualquer coisa.

Bom, o caso é que parece que ninguém se preocupa com isso… Todos os designers parecem ter colocado em nós – usuários indefesos e cognitivamente limitados – a carga de armazenar, computar e comparar listas intermináveis de itens. Claro! Nós humanos somos ótimos com isso…

Alguns exemplos de jogos, começando com Grand Turismo 4 (PS2). Eles são todos baseados no mesmo princípio: você conhece os carros. Se não, então você terá que lembrar de todas as características e comparar com o próximo carro da lista.  A segunda imagem logo abaixo, mostrando um modelo da Chrysler, é um exemplo deste visão: você pode ver algumas imagens, e, na parte de baixo, uma lista de características. Além disso, GT adiciona uma dificuldade inesperada: você tem que saber qual a comntadora do carro. Ok, você está num jogo de corrida, então espera-se que você conheça carros. Mas estou analizando de um ponto de vista do design da tarefa. Para um usuário comum, isso aumentaria a dificuldade em realizar a tarefa.

Veja esse exemplo do Mário Kart (MK).

Entende o que estou dizendo? A aparência está ok, é legal (na minha opinião, poderia ser melhorada, quero dizer, porque aqueles volumes e gradientes esquisitos, as listras grandes e com volume e aquele troféu 3d cromado??), um pouco fora de moda. Mas, de qualquer jeito, o problema ainda está la: qual o melhor carro pra você?

Eu perguntei pro meu filho (11 anos) como ele fazia pra escolher o carro, e ele disse que simplesmente testa todos até encontrar o que ele mais gosta. Se você argumentar que os designers do MK tiveram essa intenção, que eles deliberadamente tornam difícil achar (descobrir) o melhor carro só pra você jogar mais, então ok. Mas eu ainda acho que é um equívoco de design de interação.

Sabe o que eu penso? QUAL É A TAREFA???

A tarefa, você pode dizer, é escolher um carro. Mas quais são os passos que você provavelmente irá percorrer até chegar à resposta: “o melhor carro para mim é …”. No meu ponto de vista, esta é a verdadeira questão. Uma possível resposta seria:

1. Tenho alguma restrição de recursos para comprar um carro?
2. Quais são as características que importantes em um carro?
3. Será que estas características têm a mesma importância?
4. Existe alguma característica da qual eu poderia abir mão, no caso da minha escolha estar muito difícil?
5. Qual carro tem a melhor razão entre as funcionalidade , considerando que tenho uma restrição (dinheiro) e que algumas características são mais importantes do que outras?

Agora acho que a coisa foi alterada … Você vê, em vez de “qual é o melhor carro para mim”, a questão é “qual carro tem a melhor razão entre as funcionalidade , considerando que tenho uma restrição (dinheiro) e que algumas características são mais importantes do que outras”. Uau! Muito mais difícil!

Então, vamos passar à tarefa. Suponha que você tenha a pior interface em todo o mundo, ok (este é um grande exercício!)? Eu proponho que você tem uma interface com cartões que representam todas as possíveis características listadas. Embora os cartões estejam “soltos”, ou seja, não ligados ou agrupados por qualquer meio, os recursos são enumerados em ordem alfabética ou categórica (por isso a pesquisa no cartão seria mais fácil);e da mesma forma por todos os cartões; utilizando uma fonte com boa legibilidade e tamanho; o cartão teria muita contraste com o texto. A interface também teria botões “próximo” e “anterior”.

Permita que o usuário utilize esses cartões para escolher. O que ele faz? Acho que ele iria responder às três primeiros perguntas (a quarta seria necessário se as limitações impõe grandes restrições à escolha, de modo que o usuário teria que pesá-las novamente). Portanto, vamos segui-lo:

As respostas são

1. Tenho alguma restrição de recursos para comprar um carro? Sim! R $ 24,000
2. Quais são as características que são importantes em um carro? Ar condicionado; poder ultrapassar rapidamente e com segurança de um carro indo em 90 km / h; o consumo seja igual ou inferior a 10Km por litro; o mais novo possível; custo de manutenção abaixo R $ 1.000 por ano; custo de seguro abaixo R $ 1,5000 por ano. Seria bom se fosse bonito.
3. Será que estas características têm a mesma importância? Não. Ar condicionado é um imprescindível. Consumo baixo é muito importante. Novo é muito desejável. Seguro pode ser superior a R $ 1,500. Custo de manutenção não é assim tão importante, mas não deve ser muito elevado. O motor em si não é assim tão importante – afinal de contas, eu não viajo muito. Eu adoraria ter um carro bonito, mas com todas essas restrições, eu não acho que vou ter um …

1. Veja o primeiro carro
2. Verifica se o carro está dentro do orçamento. Se estiver…
3. Verifique se ele tem ar condicionado. Se ele tiver…
4. O carro é bonito?
5. Pesar as características que são importantes.
6. Armazenar os dados.
7. Ir para o próximo carro (botão “Avançar”).
8. Vá através de passos 2 .-5. novamente.
9. Compare com o carro anterior.
10. Este carro é muito melhor que o anterior?
    1. Se for, rejeitar o carro anterior, ou seja, esqueça.
    2. Em caso de serem semelhantes, agrupe-o com o anterior, de modo que, se outro carro superá-los, o usuário poderá desfazer todo o grupo, isto é, esquecê-lo.
    3. Se for pior, esquecer o carro atual.

Ah … Essa é uma tarefa difícil para os seres humanos. Nossa mente não está preparado para fazer os passos 5 e 6 desta sequencia! Como é que vamos fazer este cálculo? Como vamos armazenar montes de dados?

Outra dificuldade é que esse processo supõe que o usuário tem livre acesso e controle de sua STM … Sim, certo …

Então, vamos voltar ao nosso estudo de caso interfaces: “www.autocarro.com.br“, “www.panambra.com.br” e MK’s. Como eles ajudam os nossos pobres usuário equipados para fazer a tarefa?

Autocarro

1. Mostra todos os carros de um modelo (o usuário já sabe o carro para comprar!). Também mostra preço, ano e uma foto, com dados extra.
2. O usuário vê uma lista paginada
3. Avança através de 2 a 10 do nossa lista.

O “Autocarro” está assumindo: o usuário já sabe o carro para comprar.

Panambra

1. Solicita ao usuário a marca do carro (GM, Ford, etc.)
2. O usuário vê uma lista paginada
3. Avança através de 2 a 10 do nossa lista.

Que “Panambra” está assumindo: o usuário já sabe a marca que o carro deve ter.

MK’s

1. MK’s é, na verdade, o pior … É a nossa “pior-de interface possível”, com sombras e chromes …

Mas eu tenho notícias de um exmeplo excelente: Volkswagen´s used car locator, em http://www.volkswagen.co.uk/used/search

Você diz que carro prefere (baseado num conhecimento prévio, mas acho que está ok), e depois você adiciona restrições: quanto poderia custar? o que precisa ter? quais seriam a quilometragem e idade máximas? depois, você dá um CEP e busca. Ele traz todas as opçoes para você.

Que tal esse design? É meio que comlementar ao anterior, com a diferença que a aplicação vai dizer qual o melhor carro pra você, baseado na importância relativa que você acabou de atribuir.

Está feio, eu sei. Mas seria mais fácil escolher. Não precisa IA nem nada. Um algoritmo bobalhão.

Isso é design de interação.

Tive a idéia de fazer uma filmagem de mim mesma, para aplicar alguns dos esquemas de codificação que aparecem na literatura de Design Cognition. Eu só precisava esperar ter um problema de design que me ocorresse na hora em que eu tivesse uma filmadora à mão (é importante que o sujeito não saiba nada sobre o problema antes, para que a filmagem capte o processo de estruturação do problema).
O resultado foi um vídeo de 17 minutos, porque não tinha drive para mais…

Read the rest of this entry »