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.

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?

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.

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.

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.

A estrutura da argumentação de Goel é mais ou menos esta:

• O modelo computacional para a cognição humana é o melhor modelo desenvolvido até agora, logo, ele precisa explicar toda atividade cognitiva humana. “Cognição pode ser mais que computação mas é, pelo menos, computação”.
• Este modelo deve especificar propriedades das representações interpretadas pela nossa mente, já que “associar crenças e desejos a um organismo é atribuir representações mentais a este organismo”. Em outras palavras, deve ser possível, a partir desta teoria, construir um sistema simbólico que satisfaça estas propriedades. Este(s) sistemas simbólicos deveriam ser capazes de suportar (servir de meio) para qualquer atividade (cognitiva) humana. ¹
• Todavia, as propriedades que um sistema simbólico deve ter para satisfazer as restrições impostas por este corpo teórico não permite certas formas de raciocínio: aquelas que são vagas, fluídas e ambíguas. Assim, o modelo falha ao não explicar como tais formas de pensar poderiam ser possíveis.
• Estas formas de pensar representam atividade / processos cognitivos genuínos; não podem ser “relegadas a um plano não mental”.

Este encadeamento deixa com Goel a responsabilidade de

• Identificar as propriedades (implícitas) nas teorias computacionais da cognição que inviabilizam tais formas de raciocínio;
• Definir que formas de raciocínio são estas e
• Como um sistema simbólico que satisfaz outro conjunto de propriedades viabilizaria tal tipo de atividade cognitiva.

O primeiro ponto é construído nos capítulos 1, 2 e 3. Fiz alguns slides sobre eles, que podem ser baixados nestes links:  resumo da introdução.ppt, cap2.pt, cap2_continuação.ppt, cap3.ppt, cap3_continuação.ppt e cap4.ppt. Também fiz um resumo (muito mal acabado) em um .doc

O segundo ponto – e é aí que começa a discussão sobre cognição em design – é debatido nos capítulos 4 e 5.

O terceiro (e mais importante, na minha opinião, o mais importante) é desenvolvido nos capítulos finais (6 a 9). Vamos então olhar como estas três questões são resolvidas.

Ambiguidade, fluidez, indefinição de estados: Design

A investigação conduzida por Goel está baseada no framework de Newell e Simon – citados anteriormente como dois dos autores mais importantes da área – colocado na Teoria de Processamento da Informação (ilustrada de forma resumida na imagem abaixo). A título de ilustração, o paradigma de análise de Akin também está baseado nesta visão.

• Especificar características salientes do designer.
• Especificar as características salientes do ambiente da tarefa.
• Mostrar que esta combinação não se encontra em outros ambientes de tarefas bem estruturadas.
• Ver como o espaço do problema é moldado pela tarefa e pelo IPS.
• Construir conexões sobre a estrutura de um e a interação dos outros.
• Mostrar que a estrutura de alguns espaços de problema é diferente da de espaços de problema de design (não precisa mostrar de todos; se mostrar de um é suficiente).
• Se o IPS for constante (e é: ele é o designer), qualquer mudança no espaço do problema é função do ambiente da tarefa.
• Concluir que estas características do espaço do problema são características de problemas de design.

Em primeiro lugar, Goel elicitou doze características que seriam comuns (invariantes) à todas as tarefas de design.²

1. Disponibilidade de informação: sempre faltando ou incompleta.
2. Natureza das restrições: éticas, sociais, econômicas. Não são lógicas / científicas.
3. Tamanho e complexidade dos problemas: grande.
4. Partes componentes: a estrutura do problema não deixa claro como subdividi-lo em partes menores. Esta divisão é feita com base na experiência.
5. Interconectividade das partes: não é lógica – não há uma relação lógica entre as divisões do problema.
6. Respostas certas ou erradas: não existem.
7. Input/output: a entrada é o briefing³, a saída é o documento de especificação.
8. Loop de realimentação: não há retorno do “mundo” durante o projeto. Não é como um programa de computador, que se pode compilar.
9. Custo dos erros: alto.
10. Funcionamento independente do artefato: independente do designer, o artefato tem que funcionar.
11. Distinção entre especificação e entrega: a especificação é distinta da construção e entrega do artefato.
12. Especificação temporal entre especificação e entrega: separadas no tempo.

Talvez, como o próprio Goel pontua, estas não sejam características que descrevam completamente o ambiente da tarefa (eu, por exemplo, acho que algumas nesta lista são mais significativas que outras). Porém o objetivo é usar estas características para fazer o estudo de como elas interferem no espaço do problema.4

Nas páginas seguintes (88 a 90), Goel analiza estas mesmas características em relação a problemas bem estruturados (puzzles criptaritméticos).

O resultado destas doze características no espaço do problema (p. 91) são as seguintes (os números entre parênteses são anotações minhas, e se referem aos itens indetificados como salientes no ambiente da tarefa):

1. Regras pessoais para parar (de resolver um sub-problema) e para avaliar as soluções: porque não há respostas certas ou erradas (6) nem retorno do mundo (8).
2. Predominância da lembrança (retrieval) e inferências não demonstrativas:  porque há poucas restrições lógicas (2).
3. Reversão de direção das tranformações: como o problema não é especificado, o designer pode negociar os parâmetros do problema (7).
4. Modularidade / decomposição: como os problemas são grandes (3) e não há uma forma lógica de dividir o problema em partes menores (4), o designer escolhe a quais  conexões atender, podendo ignorar outras. Esta característica é bastante refernciada na listeratura de cognição em design, conhecida como decomposição em “leaky modules” (p.103); módulos conectados parcialmente. Goel, no protocolo do arquiteto (no livro há a descrição de três experimentos envolvendo design, e um deles era com um arquiteto) , destaca que “quatro módulos e 32 submódulos”. Para ver como as relações de conectividade eram construídas pelo arquiteto, Goel que é mais fácil ver – dado um módulo qualquer – com quais módulos ele não tem conectividade (referência). Goel sugere que três indicadores são “interessantes” (p.105) para verificar conectividade:
   • o designer trata cada módulo apenas uma vez,
   • ele não se refere a qualquer outro módulo quando “dentro” de um dado módulo e
   • o designer pode atender aos módulos numa ordem arbitrária.
5. Desenvolvimento incremental do artefato: as idéias são desenvolvidas incrementalmente, e raramente são descartadas ou substituídas (3, 6).
6. Estratégias de controle:  uso de um “modo de compromisso limitado” (LCM – limited commitement mode) que permite que designers gerem alternativas e testem em diversos contextos. Esta é outra proposição importante de Goel (importante dentro da literatura, pois é bem aceita e bastante citada). Também é importante lembrar que estas estratégias de pouco compromisso se referem às soluções geradas dentro dos módulos. Como Goel lembra à página109, as estratégias de controle podem estar em níveis mais baixos (frases individuadas). Investigando neste nível (que compõe os submódulos) , Goel nota que há um movimento de retorno à módulos usados anteriormente. Isso é diferento do que se observa em resolução de problemas bem estruturados: a maior parte da resolução acontece dentro do módulo. A hipótese é que, nestes casos, voltar a outro módulo seria como voltar atrás no estado de resolução do problema. Se ele efetivamente faz isso, é porque percebeu que o caminho que tomou para resolver o problema não leva a lugar algum – isso não “enriquece” o conhecimento sobre o problema.
7. Fazer e progagar comprometimentos: através do processo de projeto até a especificação.
8. Fases distintas de resolução de problemas: provavelmente por causa do tamanho (3) e das mudanças nas naturezas dos sistemas simbólicos manipulados ao longo do processo (7).
9. Hierarquias de abstração: manipulação e criação de sistemas simbólicos de diferentes naturezas (7).
10. Construção e manipulação de modelos: modelos do mundo, pois não podemos “testar” as idéias (8 e 10).
11. Uso de sistemas simbólicos distintos 5.
12. Diferentes símbolos se relacionam com diferentes atividades cognitivas.

Sobre o item 8 – fases distintas de resolução de problema – Goel complementa com uma descrição um pouco mais detalhada das quatro etapas:

• Estruturação do problema: processo de recuperar conhecimento de várias fontes para compensar informações que faltam na declaração do problema, e usá-las para contruir o espaço do problema. Goel coloca que esta fase representa cerca 18% a 30% do processo. E que quase não se observa esta fase em resolução de problemas bem-estruturados. As duas imagens abaixo são do livro mesmo, da página 115. A primeira mostra a distribuição das etapas do processo ao longo do tempo. A de baixo mostra a frequência das quatro etapas.
• Resolução do problema (p.118), dividido entre design preliminar, refinamento e detalhamento. Daí somam-se quatro fases.

A imagem abaixo mostra a compreensão de Goel sobre o processo. Alguns aspectos dela serão melhor explicados mas abaixo no post. Mas atenção que esta imagem está no artigo que Goel publicou no livro organizado por Eastman.

A tabela abaixo mostra as diferenças que Goel apontou entre a resolução de problemas de design e problemas bem estruturados.

Análise das representações usadas pelos designers

Toda esta parte anterior, de descrição do processo de design, com os experimentos e a comparação entre os processos de resoluçao de problemas bem e mal estruturados é muito interessante – e certamente contribui para aumentar a compreensão do que é design. Como frisei nos parágrafos anteriores, Goel teve alguns insights preciosos sobre o processo: a Estratégia de Comprometimento Limitado – LCM -  e a conexão entre os sub-módulos do problema de forma “fraca” – os Leaky Modules. Sendo assim, os capítulos 4 e 5 do livro já seriam suficientes para declarar a importância do livro de Goel – porém ele foi muito além.

Na minha opinião (e se eu realmente entendi direito tudo o que ele escreveu), o mais importante foi a tese que, para resolver problemas mal estruturados, utilizamos outros sistemas simbólicos, sistemas que não possuem as propriedades elencadas pela Teoria Computacional da Mente (doravante CTM).

O início da exposição do argumento é um silogismo: os sistemas definidos pela CTM não suportam raciocínio vago e ambíguo;  este tipo de raciocínio é necessário para resolver problemas mal estruturados, e a resolução de problemas mal estruturados representa atividade cognitiva. Dito isto, Goel fica com as atribuições de:

• Especificar quais as propriedades destes sistemas simbólicos e
• Explicar como eles ajudam a conduzir este tipo de raciocínio.

Puza vida, isso é muita coisa! Entender isso foi quase como uma luz para mim. Se ele conseguisse demonstrar que outros sistemas simbólicos são usados, ficaria muito mais fácil transitar entre os diferentes tipos de atividade de projeto.

Esta “empreitada” começa no capítulo 6, onde ele mostra as limitações no esquema de calssificação baseado nos conceitos de equivalência informacional e computacional6. Como ele conclui que não será possível usar este esquema de classificação (que, afinal de contas, foi pensado pelos “partidários” da CTM), continuamos sem responder aos pontos colocados acima. É neste ponto que entra o sistema de classificação de Goodman.

Teoria da notacionalidade de Goodman – Theory of Notationality

A teoria da notacionalidade (acho que inventei esta palavra) busca um sistema de classificação para sistemas simbólicos. O problema de Goodman é semelhante ao de Goel: como “entender” a arte e suas diferentes manifestações a partir de um sistema simbólico baseado em atributos “computacionais”? O sistema simbólico usado por um pintor ou um escultor é o mesmo usado para “escrever” um programa de computador e resolver uma equação de segundo grau? Esta foi a motivação da teoria.

Ela coloca 5 propriedades de um sistema simbólico, além de duas categorias extras de classificação: repleteness e densidade.

1. Deslocamento7 sintático.
2. Diferenciação sintática finita.
3. Deslocamento semântico.
4. Diferenciação semântica finita.
5. Não ambiguidade.

Deslocamento sintático

Todas as inscrições do mesmo caracter são cópias verdadeiras de si mesmas; qualquer inscrição é tão válida quanto qualquer outra.

Diferenciação sintática finita

É possível diferenciar um caracter do outro, e esta diferenciação é finita. Um exemplo do livro são as frações em algarismos arábicos:  há infinitas frações (1/3 = 3/9), mas a diferenciação entre eles é finita. Um esquema que não atende a este requisito poderia ser um onde todas as marcas com mais de um centímetro de altura correspondem a um caracter, e com menos de um centímetro correspondem a outro. Ressalta-se que este mesmo sistema satisfaz ao primeiro requisito (deslocamento sintático), pois as marcas são diferenciadas entre si.

Deslocamento semântico

É similar ao critério sintático, porém refere-se às classes (que instanciam os caracteres). Para satisfazer este critério, dois caracteres não podem ter classes em comum (p.165). Por exemplo: “médico” e “homem” – há médicos que são homens e vice-versa. Logo, o mesmo caracter (por exemplo, “homem”) pode estar inscrito em duas classes. Goel nota que este é um critério bastante rígido, pois especifica uma relação 1:1 entre caracter e significado.

Diferenciação semântica finita

As classes devem ser diferenciadas entre si. Por exemplo: um sistema onde frações (em algarismos arábicos) reduzidas se relacionam com o peso de objetos.

Não ambiguidade

Todas as inscrições de um caracter têm a mesma classe. Por exemplo: “banco” é ambíguo porque pode pertencer a duas classes (instutuição financeira e objeto para sentar).

Densidade

Quanto menos finitamente diferenciado, mais denso o sistema.

Repletness

Quando cada elemento da inscrição é importante para manter seu significado. Por exemplo: numa pintura, pouco se pode retirar (cores, textura da tela, textura das pinceladas, brilho da tinta). Já em um termômetro não graduado, pode-se retirar vários elementos (brilho do material do termômetro, tamanho e peso do termômetro) sem prejudicar a construção do significado da mensagem.

Na imagem acima  (p.166) vemos a classificação feita por Goodman de alguns sistemas simbólicos, de acordo com a teoria da notacionalidade.

Abaixo, a classificação dos mesmos sistemas, usando os critérios de densidade e repletness (p.168) e de acordo com os elemtnos da teoria da notacionalidade (p. 182).

Este sistema de classificação permite classificar as produções dos designers desde o início até o final do processo. Assim, nos primeiros momentos – estruturação do problema – usa-se um sistema simbólico não-notacional, denso e repleto. À medida que o processoavança, o uso de representações repletas diminui. Quando chega perto do final – detalhamento – nota-se o uso de sistemas cujas propriedades se aproximam da CTM, até chegar ao documento de especificação (uma planta baixa, um diagrama de classe). Este moviemtno está na figura abaixo, retirada do livro de Goel (p.180)

Esta classificação “resolve” o primeiro problema – especificar quais as propriedades destes sistemas simbólicos. Agora, é preciso ver como eles ajudam a conduzir este tipo de raciocínio.

Virtudes de sistemas não notacionais

Agora fica mais fácil entender a figura abaixo:

Nele vemos que, na etapa de projeto (que vivenciamos mais intensamente e que associamos aos momentos criativos) preliminar, fazemos maior uso de representações não estruturadas (não notacionais); que o sistema simbólico preferido é o sketch e que as transformações são laterais (uma idéia se transforma em outra). A imagem abaixo (retirada do artigo, não do livro), mostra um exemplo do que são estas transformações. O caso é que, à medida que se avança no problema, as representações ficam cada vez mais “notacionais”, mais “CTM”. Outro detalhe importante desta imagem é que o espaço do problema é represnetado como um triângulo invertido. Em problemas bem estruturados, é o contrário, pois começamos com um problema (definido) e avançamos em direção à várias soluções possíveis. Em problemas mal estruturados, não sabemos definir o problema (por isso a “base no topo”). A quantidade de possíveis soluções aumenta até certo ponto, após o qual ela encolhe até chegar num ponto: a solução projetada. O espaço do problema começa a diminuir quando começamos a especificar a solução.

Estou misturando aqui um artigo e o livro porque acho que o artigo tem algumas imagens interessantes. E uma delas é esta aqui embaixo.

Ela ilustra, de modo informal, diferenças em relação a problemas bem (esquerda) e mal estruturados (direita).

Nos problemas mal estruturados, os estados i, j e k estão muito próximos. Eles permitem que se cubra todas as possibilidades, facilitando a transformações de um estado em outro. Já os estados que se sobrepõe, f e g, permitem que várias idéias sejam instanciadas, sem se comprometer com nenhuma. No livro (p.191), Goel traz mais detalhes de como sistemas simbólicos não notacionais, repletos e densos auxiliam a solucionar problemas mal-estruturados:

1. Não ser deslocado sintaticamente (não há como garantir que duas inscrições sejam do mesmo tipo) dá aos traços pouca fidedignidade, pouca precisão, de forma que um traço pode pertencer a vários tipos.
2. Não ser sintaticamente finito faz com que cada distinçao conte como uma marca diferente. Cada mudança no traço conta. Isso facilita transformar um caracter em outro.
3. A ambiguidade permite que os traços – e isso é importante no início – sejam indeterminados. A idéia é impedir a cristalização das idéias nas fases iniciais.
4. Não ser deslocado semanticamente permite que um caracter possa pertencer a várias classes. Não há uma relação 1:1 entre tipo e classe. Cada tipo pode pertencer a mais de uma classe.
5. Não ser semanticamente finito permite que existam várias classes, o que é importante para não excluir possibilidades.

O designer, no entanto, deve se mover em direção a sistemas notacionais à medida que o processo se desenrola, porque ele precisa terminar.

Tendo a concordar com Goel, até de forma entusiasmada. Porém, achei que o experimento que ele fez para demonstar não foi muito bem concebido. No capítulo 9, ele relata que pediu para designers experientes projetarem algumas coisas, em design gráfico e de produto. Um grupo podia usar papel e caneta, e o outro tinha que usar um programa de computador onde só poderiam usar primitivas (linhas, elipses, retângulos etc). O programa de computador seria um sistema menos denso, o que prejudicaria o andamento. Goel afirma que o resultado foi este mesmo, e corrobora suas predições. Porém, há um fator (e falo com experiência de causa) que Goel não contou, que é a falta de agilidade dos computadores. Não conseguimos acompanhar nossas idéias usando um computador. E isso talvez tenha sido uma fonte de frustração maior do que a pouca liberdade com as formas. Acho que, se o grupo do “draft” tivesse ficado restrito a primitivas, porém tivesse sido liberado o desenho, o resultado poderia não ser tão dramático em favor dos que puderam rafear.

Bem, era isso

Espero que este texto tenha ajudado. Para mim, como falei no início, não foi fácil. Dá pra dizer que fiquei mais de meio ano lendo esse livro, que foi meio “pedreira”.

Se você não concorda, ou se tem qualquer comentário, entre em contato. Será a primeira vez. Ninguém lê estes textos sobre cognição…

1 Aqui temos uma discussão interessante. Os “partidários” da solução computacional afirmam que o fato de não termos ainda conseguido construir uma linguagem ou máquina que apresenta funções cognitvas, não quer dizer que a teoria está no caminho errado. Já os “opositores” desta visão afirmam que um dispositivo que realiza computação não apresenta as características suficientes para exibir inteligência. Ver o “Argumento da sala chinesa“,  a palestra de Searle no IBM Research’s Almaden Institute Conference on Cognitive Computing (Google Video) e “Robot Reply“. De toda forma, Goel se alinha com aqueles (a começar por Searle) que pontuam que a computação não explica, por exemplo: dependência de contexto, metáforas, ficção, opacidade… Nada disso tem contrapartida em sistemas computacionais. Além disso, Goel lembra que, em sistemas computacionais, a atribuição de conteúdo (novamente a semântica) é inerente ao sistema. Já, em humanos, ela está relacionada à primeira pessoa, a estados mentais (intencionalidade, novamente).

2 …todas as tarefas de design de práticas (disciplines) prototípicas, i.e. arquitetura e engenharia. Além disso, Goel afirma, com todas as letras (p. 87) que não se propõe a exaurir as características de um ambiente de tarefas de design. Ele apenas quer identificar características salientes para verificar como elas impactam no espaço do problema.

3 Briefing é como chamamos (nós, os designers :0) a descrição do projeto a ser executado.

4 E isso também é um aviso para quem está lendo não usar esta lista de características e dizer, por exemplo, que “Goel lista as características das tarefas de design”. Não é essa a intenção dele, gente!

5 Ver adiante

6 Mais detalhes no livro ou na sua biblioteca

7 No original em inglês: disjointness. Não sei como traduzir.

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).

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.

A atividade (o problema de design) veio de uma coisa que tem sido bem difícil: a escolha de um carro novo. Eu e meu marido já consideramos seriamente uns 4 modelos diferentes, e após visitas à  revendas e diversas projeções de gasto para os próximos meses, não chegamos nem perto de uma conclusão. Quem já passou por isso sabe que a forma como a informação é disposta na web não ajuda muito a decidir. Então pensei em fazer um aplicativo para isso (claro, quem não pensaria nisso?).

Tive a idéia antes do almoço. A filmagem, sobre a mesa da cozinha, foi feita depois do almoço. Por isso, o protooclo não é confiável (do meu ponto de vista). Mas já deu para ter uns insigths sobre a metodologia:

1. Falar enquanto pensa atrapalha muito. Eu quase ouvia minha mente se desorganizando cada vez que eu estava pensando num aspecto novo do problema – eu sentia que estava pegando a idéia pelo rabo – e tinha que organizar esses pensamentos – fugidios – em palavras (considere que meu motor é 1.0, hehe). O problema é que não dá para ficar quieto, porque senão como vamos analisar o sujeito?
2. As representações internas e as estratégias de busca e de avaliação que eu uso para resolver o problema me parecem completamente inacessí­veis. Eu olhei o vídeo a tarde inteira ontem, e não conseguia saber no que eu estava pensando. Não conseguia traçar uma reta do “pensamento A” até a “decisão x”. Também não sei como esses “pensamentos” brotaram na minha cabeça. Quero dizer que, se eles brotaram, em algum lugar (em em alguma forma) eles existem, mas porque “aquele” pensamento surgiu?

Enfim, aí­ embaixo está um pedacinho do vídeo. Separei este exemplo porque mostra um trecho onde não parece haver conexão entre o que estou desenhando e o pensamento que me atravessou enquanto eu desenhava. De onde saiu aquilo?
[See post to watch Flash video] ]]> http://www.gabriela.trindade.nom.br/2009/03/mas-se-a-pessoa-estiver-comparando-carros/feed/ 2