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.

A mesa que eu assisti (metodologia) estava bem legal. Uma pena que a Janet Murray não foi… Não entendi que “complicações políticas” ela citou como justificativa para não ter aparecido… Deve ter sido uma piada, porque muita gete riu

Fora isso, espero que nas próximas edições sejam apresentados mais artigos que saiam do feijão com arroz em que a pesquisa em design se transformou: gráfico, tipografia, ergonomia, produto, digital, história, gestão. Sério gente, ainda tem o que falar sobre isso? Deixa isso pros TCCs, huahuahua. E ainda por cima ergonomia/digital têm seus próprios congressos (ergodesign+ usihc, sem falar no da abergo). Não que esses tópicos não sejam importantes, mas acho que é hora de procurar outras coisas pra pesquisar.

Fora esses assuntos que (eu acho) que já estão “meio” batidos, teve muita coisa legal: moda (gente nova, uêba!), serviços, afetividade/emoção/experiência e um – UM – artigo sobre cognição. Gentem! Se olhar a Design Studies, Design Issues; é só isso que se faz.

Meus dois artigos foram sobre assuntos bem feijão-com-arroz, mas são resultados de pesquisas antiiiigas. Eu, daqui pra frente, só Design Cognition, chique-no-úrtimo!

O Desenvolvedor-Designer e o Design da Interação

Reflexões sobre a escolha entre duas interfaces: relato de um processo

E aí embaixo duas fotos: uma panorâmica e uma do pessoal da EDU (que eu consegui juntar pra “bater a foto”).

E pra fechar o post, uma provocação: só tem gente linda e magra no Design!

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?

1. Programadores ganham pouco porque a profissão não é regulamentada.
2. Programadores em Flex ganham pouco porque há muitos newbies.

Eu, pessoalmente, não estou competindo com nenhum newbie… Não há um projeto onde eu tenha trabalhado que pudesse ser tocado por eles (menos quando eu era newbie, haha).

Mas eu não estou escrevendo para quem está fazendo a vida em cima do Flex, que ganha bem e entende o framework. Eu queria escrever para aqueles que estão aprendendo Flex e estão entrando num emprego ou aceitando um free-lance.

Eu até ia fazer uma compilação das perguntas absurdamente sem noção que aparecem na FB e na FD, de pessoas que estão trabalhando (e provavelmente desenvolvendo uma gastrite, coitados…), mas isso seria antiético. Então, pegue um lápis e um papel e faça o checklist:

1. Sei exportar um projeto de forma correta.
2. Sei debuggar um projeto em Flex/AIR.
3. Sei a diferença entre Flex e AIR.
4. Entendo os prós e contras de trabalhar com módulos e RSLs.
5. Sei disparar e capturar eventos. Entendo as propriedades .currentTarget, o parâmetro bubbles e os métodos da classe EventDispatcher.
6. Sei o que é deferred instantiation.
7. Sei escolher os containers de forma a otimizar aplicações.
8. Sei popular os data controls com coleções do Flex.
9. Sei recuperar e modificar itens dentro das coleções do Flex.
10. Sei usar os métodos das coleções do Flex.
11. Sei recuperar dados de RadioButtons, CheckBox e Repeaters.
12. Sei construir um ItemRenderer.
13. Passo objetos entre views (por exemplo, módulos ou seus custom components).
14. Sei usar um swc de terceiros.
15. Sei usar o HTTPService, RemoteObjects, WebServices ou a tecnologia que você está usando.
16. Entendo o que significa assincronismo e aceito que isso não é ruim; é uma característica do framework.
17. Sei quando o que procuro é uma propriedade, um estilo, um método ou um evento.
18. Sei ler a documentação.
19. Sei pesquisar meus problemas na internet (google, flex forums,etc)
20. Sei elaborar uma questão para alguns dos forums Flex e não espero uma solução pronta com código pra só copiar/colar.

Se você aceitou um freela ou não é estagiário e não passou em TODOS estes itens, saiba que as chances de você ter dificuldades muito grandes durante o seu projeto são enormes. E que você vai ter que depender da boa vontade / paciência / disponibilidade de outras pessoas te ajudarem.

Se você está aprendendo ou é estagiário: você está estudando – PARABÉNS PELO SEU BOM SENSO!

Você pode estudar Flex e encontrar diversos exemplos nestes locais:

1. Flex Quick Starts: eu comecei ali!
2. Flex Examples: como o site diz, tem muitos exemplos :0)
3. Tour de Flex: running code sempre é bom!
4. E se o seu inglês está em dia, assista ao Video Training da Adobe :0)
5. E não esqueça que  a documentação é sua melhor amiga :0)

E aos que deram risada desse checklist: aceito sugestões!

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.

O que nos move não é nada material, mas sim a paixão pelo que fazemos e a convicção de que ao nos doar um pouco para a comunidade estamos ajudando e evoluindo conseqüentemente. Por estes mesmos motivos, estaremos todos reunidos dia 06 de fevereiro de 2010.

Temos muitas coisas que amamos para compartilhar com vocês. Porém, desta vez, queremos algo em troca. Algo que com certeza não lhe fará falta, mas que fará a diferença na vida das crianças do Cotolengo . Ganham vocês. Ganhamos nós. E, principalmente, ganham as crianças do Cololengo .

Assinam o Manifesto:
Beck Novaes, Carlos Eduardo, Daniel Lopes, Ebertom Consolim, Eric Cavalcanti, Fabio Vedovelli, Gabriela Perry, Igor Costa, Igor Musardo, Mario Junior e Vicente Maciel Junior.

Registre-se agora no Flex for Kids e ajude as crianças do Cotolengo . Porque alguém, já ajudou você um dia (e de quebra assista palestras que estão sendo preparadas com a mesma paixão de sempre).

VIEW SOURCE

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.