Gabriela Trindade Perry: HCI, Design Cognition, Flex

Recentemente houve um debate na FB sobre qual seria um valor justo a se pagar a um programador Flex. A pessoa que começou a thread pode até não ter se dado conta, mas mexeu num vespeiro. Muitas pessoas deram suas opiniões (eu também, lógico!) e parece que o saldo do debate ficou assim:

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!

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.

Durante anos estivemos dedicados ao desenvolvimento de Aplicações Ricas. Durante anos estivemos dedicados a tecnologias como o Adobe Flex, BlazeDS, LiveCycle Data Services, Zend AMF, AMF PHP, Adobe Flash Professional, Flash Media Server, etc. Mas, principalmente, durante anos estivemos dedicados a compartilhar o nosso conhecimento com a comunidade. Na Flex Brasil , na FlexDev e em nossos blogs é provável que você já tenha encontrado algo que procura. E nunca pedimos nada em troca.

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

/*    AS   IS     */

VIEW SOURCE

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.

Marquei o teste com usuários para quinta que vem. Vamos ver o que sai.  Para adiantar as coisas, já tenho os protótipos prontos.

Pra quem está interessado no código, tem os fontes disponíveis…. Só peço que lembrem do significado da palavra “protótipo”: o código está uma zona, nem venham me falar nada disso, beleza?

Protótipo DD (nova janela)
Tempo de desenvolvimento: 10 horas

• abrir nós da árvore ao clicar nos galhos
• item renderer para tree
• desabilitar itens de uma tree
• arrastar de tree para container
• identificar item da tree ao clicar no objeto do container
• atualizar itens da tree durante drag n drop
• verificar área de drop, verificar lixeira
• usar fade para remover item
• inserir item ao clicar na árvore
• verificar área de drop, se colocado sobre outro item ao clicar na árvore, reposiciona
• user fade para posicionar item se originado do click na árvore

Protótipo Tree (nova janela)
Tenpo de desenvolvimento: 2 horas

• abrir nós da árvore ao clicar nos galhos
• atualizar itens da tree durante uso do slider
• mostrar a slider quando clica nos itens
• feedback na árvore do valor da associação slider-tree
• mostrar a slider usando um fade

Era isso! Até o teste!

Seguimos então com a análise deste problema: como escolher entre duas interfaces que dão suporte à mesma tarefa? Para quem não está acompanhando, as interfaces em questão são mostradas nas figuras 1 e 2.

Figura 1, à esquerda. Interface com drag n´drop. O usuário arrasta um conceito para a área ao lado da tree, e o local (y) onde ele largou o conceito define o quanto o material está associado ao conceito.

Figura 2, à direita. Interface com HSlider. O usuário seleciona um item na Tree. Na tela ao lado, há uma HSlider, que o usuário usa para dizer o quanto o conceito se asssocia com o material. Na Tree se podem ser, ao lado dos conceitos que estão associados com o material, o quanto (%) o conceito se associa ao material.

Estas interfaces foram avaliadas utilizando um conjunto de heurísticas  e o KLM. Estes são dois métodos que pertencem mais ao design que ao desenvolvimento, e que são usados para informar a escolha. No entanto, eles não consideram a complexidade da implementação, que é um fator determinante na escolha. Por este motivo, pedi para alguns colegas avaliarem as duas interfaces e dizerem o quanto uma interface é mais trabalhosa que a outra. Além disso, pedi que, se possível, comentassem cada uma das propostas.

Pedi que a todos os avaliadores que considerassem a implementação na mesma linguagem de programação (AS3, usando Flex). Todos têm pelo menos 2 anos de experiência com a linguagem, e todos são desenvolvedores reconhecidos (à exceção de um, todos são moderadores de listas com mais de 2000 membros). Eles avaliaram o seguinte cenário:

/*******************************************************
CENÁRIO
O projeto é uma materioteca, usada para auxiliar no processo de seleção de materiais. Será usada por designers, arquitetos e eventualmente, por engenheiros.
A tela em questão é para associar conceitos a um dado material que está sendo criado pelo administrador da materioteca (você :0). Estes conceitos são palavras, e são características abstratas do material. Pense que isso pode ser importante para um designer fazer sua escolha. Exemplos de conceitos podem ser: inovador, sensual, moderno, vibrante, vulgar, barato etc.
Você não irá criar conceitos, apenas usar os que estão disponíveis.

As implementações possíveis estão nos pngs anexos*
*******************************************************/

O resultado até agora é:

• Desenvolvedor 1 -> Interface A(Drag n´ Drop)=2 * Interface B (HSlider)
• Desenvolvedor 2 -> Interface A(Drag n´ Drop)=10 * Interface B (HSlider)
• Desenvolvedor 3 -> Interface A(Drag n´ Drop)=4 * Interface B (HSlider)
• Desenvolvedor 4 -> Interface A(Drag n´ Drop)=3 * Interface B (HSlider)

Além disso, alguns ainda enviaram comentários:

Desenvolvedor 1

• “Preferiria implementar a segunda forma, acho que é bem mais intuitiva para o usuario”.
• “[...] Ok… pode ser até mais dificil de implementar, mas a real importancia não é a dificuldade da implementação mas a experiencia do usuario em usar essa app”.

No email de resposta ainda haviam exemplos de interfaces que suportam a mesma tarefa, referidos pelo Desenvolvedor 1 como sendo de pior qualidade. Os dois exemplos estão mostrados abaixo.

—————————————————–
| Conceito A      |  <combo box de %> |  Selecione o valor percentual de associação
—————————————————–
| Conceito B      |  <combo box de %> |
—————————————————–
| Conceito G      |  <combo box de %> |
—————————————————–

Ou pior ainda… :
——————————————————————
| Conceito A      |  <textInput / NumericStepper> |  Digite o valor percentual de associação
——————————————————————
| Conceito B      |  <textInput / NumericStepper> |
——————————————————————
| Conceito G      |  <textInput / NumericStepper> |
——————————————————————

Desenvolvedor 3

• “Então, olhando as duas opções, a primeira usando um HSlider me parece muito ‘tradicional’, mais fácil de manipular mas mais difícil de analisar o todo. Gosto mais da segunda opção, apesar de mais complexa para o usuário final manipular”.
• “Obviamente que o usuário final não está tão acostumado com o drag and drop nos softwares como ele usa no sistema operacional, mas dá uma dimensão muito melhor, acredito até que ele acharia ruim essa opção em um primeiro momento, mas depois de começar usar se sentiria mais confortável em poder analisar todos os conceitos de determinado material de uma única vez.”
• Em uma conversa via MSN, este desenvolvedor sugeriu uma “solução intermediária”, na qual ao arrastar o conceito para o Canvas, uma janela é criada, com uma barra deslizante, usada para definir a associação ao conceito.

Desenvolvedor 4

• “Usaria o hslider/vslider em vez do cenário do canvas”.
• “Bem, colocaria os itens em ordem decrescente de %, facilitando assim ao usuário a associação visual.”**
• “Uma sugestão também é em vez de usar um slider, usar um itemRenderer que mostre um NumericStepper. Na minha opinião usaria o NumericStepper, porque daria menos trabalho sem perder a funcionalidade e agregando maior agilidade para o usuário. Usando NumericStepper como itemRenderer acredito que levaria menos tempo ainda que o slider, talvez 0.6x, além que área que deixaria de ser usada pelo slider poderia ser usada para outra coisa.”

Dois desenvolvedores manifestaram preferência pela interface com Drag n´Drop, um pela interface com HSlider e um não manifestou preferência. No entanto, todos afirmaram que a interface com Drag n´Drop é mais demorada.

Assim como as avaliações anteriores, estes pareceres não foram conclusivos em favor de nenhuma das opções, pois, mesmo que dois desenvolvedores tenham manifestado clara preferência pela interface com Drag n´Drop, é preciso avaliar se o tempo de implementação é um fator importante.

Cada vez mais acho que vou precisar de um protótipo para dar o veredicto :0)

Acompanhe!

PS: Se você também quer mandar sua estimativa e seus comentários, comente aqui ou mande por email. Vou incorporar no post.

* As imagens do início deste post, com descrições sobre detalhes da implementação e sugestões para os algoritmos.

** No HSlider

Realizar uma avaliação através de heurísticas significa seguir uma estratégia baseada em parâmetros. Assim, para realizar uma avaliação heurística, deve-se escolher este conjunto de parâmetros. Esta é a grande diferença entre guidelines e heurísticas, pois as primeiras são regras para resolver um problema, como se fossem uma receita para construir uma boa interface. As segundas, por sua vez, são mais flexíveis, permitindo que o designer encontre sua própria solução. Provavelmente o conjunto mais conhecido seha o de Molich e Nielsen (1990)*, que originalmente continha nove heurísticas,  atualizadas em 1994*, contando dez heurísticas. Para chegar ao conjunto original, Molich e Nielsen realizaram uma pesquisa com 77 designers e programadores, da indústria e acadêmicos, investigando se eles conseguiam encontrar problemas de usabilidade em uma interface.  Sobre a avaliação com heurísticas, Nielsen e Molich afirmam que o sucesso da análise está intimamente relacionado à qualidade do avaliador, e profissionais experientes e com formação em ergonomia têm melhor performance que especialistas em computação. Além disso, afirmam que algumas interfaces são mais difíceis da avaliar heuristicamente do que outras, e que esta diferença acentua ainda mais a importância de avaliadores experientes. Também afirmam que este tipo de avaliação não deve ser feito por um único avaliador (recomendam de três a cinco profissionais). Ainda citam algumas vantagens do uso deste método: é rápido e barato; é fácil motivar a equipe a conduzir um experimento deste tipo e pode ser usado desde cedo no processo de desenvolvimento.

A lista atualizada (a de 1994) está abaixo**:

1. Visão do estado do sistema: O sistema deve sempre manter os utilizadores informados acerca do que é que se está a passar através de feedback apropriado.
2. Ligação entre o sistema e o mundo real: O sistema deve falar a linguagem dos utilizadores, usar palavras, frases e conceitos familiares para o utilizador.
3. Liberdade e Controle: Pode acontecer que o utilizador escolha alguma função por engano e necessite de cancelar ou simplesmente “Sair sem gravar alterações”. Sempre que possível deve implementar-se undo e redo.
4. Consistência e Standards: Devem seguir-se convenções, normas definidas e normas de facto estabelecidas, de maneira a que o utilizador se sinta familiarizado com a forma de interagir com o sistema em qualquer parte deste.
5. Prevenção de Erros: Melhor do que boas mensagens de erro é o desenho cuidado que previne que esses erros aconteçam. Não deixar que seja possível cometer o erro.
6. Reconhecer em vez Recordar: Minimizar a necessidade do utilizador ter de se lembrar de algo (ex: qual a tecla para ver o documento X), disponibilizando visualmente objectos, opções ou acções. Não deve ser necessário decorar nada de uma janela para outra. As instruções devem estar acessiveis fácilmente e sempre que necessário.
7. Flexibilidade e eficiência na utilização: Teclas de atalho (que normalmete não são usadas por utilizadores novatos). Estas poderão aumentar a velocidade de interacção para utilizadores mais experientes. Permitir aos utilizadores criar atalhos para acções mais frequentes.
8. Design Simples: As janelas não devem conter informação irrelevante ou raramente necessária. Todas as informações extra disponibilizadas, competem com a informação relevante, diminuindo a sua visibilidade.
9. Ajudar os utilizadores a reconhecer, diagnosticar e recuperar dos erros: As mensagens de erro devem ser expressas numa linguagem comum (sem códigos). Devem indicar precisamente qual o problema e a sugestão para a sua solução.
10. Ajuda e Documentação: Mesmo que seja melhor que o sistema possa ser usado sem documentação, esta pode ser necessária. Deve ser possível pesquisar qualquer informação. Focar a ajuda mediante a tarefa que o utilizador pretende executar. A documentação deve ser simples (passo-a-passo) e não extensa.

Segundo Stanton e Young (2003), a avaliação através de heurísticas é um método extremamente simples e rápido de aplicar, podendo ser empregada em qualquer estágio do desenvolvimento do produto. Os autores recomendam apenas que o avaliador esteja familiarizado com o produto em análise. Por outro lado, os autores ressaltam a carga subjetiva da análise, o que resulta em baixa confiabilidade: avaliadores diferentes produzem resultados diferentes. Este não é o caso do KLM (veja o post sobre KLM aqui), que, segundo Stanton e  Young tem alta confiabilidade.

Porém, a avaliação heurística tem uma funçao diferente da avaliação com o KLM: ela informa a qualidade da interface de uma forma mais geral, abrangendo outros aspectos além do tempo de execução da tarefa. Desta forma, ela se contitui numa referência importante para a escolha entre duas interfaces. Sendo assim, as interfaces mostradas nas figuras 1 e 2 serão submetidas à avaliação.

Figura 1. Interface com drag n´drop. O usuário arrasta um conceito para a área ao lado da tree, e o local (y) onde ele largou o conceito define o quanto o material está associado ao conceito.

Figura 2. Interface com HSlider. O usuário seleciona um item na Tree. Na tela ao lado, há uma HSlider, que o usuário usa para dizer o quanto o conceito se asssocia com o material. Na Tree se podem ser, ao lado dos conceitos que estão associados com o material, o quanto (%) o conceito se associa ao material.

A avaliação das duas interfaces é apresentada nas tabelas 1 e 2. Para cada item do conjunto de heurísticas foi atribuído um valor de -3 a 3. Ao final, os valores são somados para gerar uma “pontuação”.

Tabela 1. Avaliação da Inteface A, que sugere a implementação de um comportamento de Drag n´Drop.

Tabela 2. Avaliação da Inteface B, que sugere a implementação de uma barra deslizante.

A pontuação das interfaces A e B foi, respectivamente, 14 e 12. Os itens em que a interface A teve desempenho melhor foram “Visão do estado do sistema” e “Reconhecer em vez Recordar“. Já a interface B se saiu melhor no item “Consistência e Standards“. Como a diferença – mais uma vez – foi pequena (cerca de 15%) em favor da interface A, o teste com usuários e um protótipo funcional é recomendado.

Acompanhe!

* MOLICH, R.; NIELSEN, J. Improving a Human-Computer Dialogue: What designers Know About Traditional Interface Design. Communications of the ACM, v. 33, p. 338-342, 1990.

* Para ver as dez heurísticas: http://www.useit.com/papers/heuristic/heuristic_list.html

** Tradução de bartolom.eu

*** Stanton, N. & Young, M. (2003). A Guide to Methodology in Ergonomics: Designing for Human Use. 2nd edition, Taylor & Francis. ISBN: 0-7484-0703-0

Gentle ItemEditor: design suggestion. Download the english version.

Agora é hora de ItemEditors.  Para os que não estão familizarizados com eles, veja este exemplo (Flex docs: http://livedocs.adobe.com/flex/3/html/movies/DropInNumStepper.swf)

ItemEditors são um tipo de ItemRenderer, como o nome diz: são uma view para um item. Pense num Tree, num List, num DataGrid… Normalmente, itens são mostrados como texto, mas, às vezes, queremos usar imagens e até mesmo outros controls. E se você precisa editar itens no local, você usa um ItemEditor :0)

Bem simples, hein? Mas e quanto à usabilidade deles? Pense que você não é um desenvolvedor, ok? Você não está familizarizado com eles. Entao, como você muda o conteúdo de um item? Você vai esperar que seu usuário explore a interface? Eu não :0)

Então estou sugerindo o uso de ItemEditors como este da imagem abaixo:

O usuário vê, ao laod de cada item, dois botões: um para deletar e um para editar. Quando ele pressiona o botão de editar, o ItemRenderer muda, e agora ele mostra um TextInput com um botão de “tick”, ok. Qual a diferença? O usuário sabe o que esperar (e se ele for muito novato, pelo menos vai ter uma pista que precisa clicar em alguma coisa), e se ele clica no botão de editar, ele vê a interface mudar. “Ah… então é aqui que eu mudo o conteúdo… Ok” :0)

PS: Se você for um desenvolvedor, me diga uma estimativa de tempo para fazer este ItemEditor e um como o do site da documentação do Flex (quantas horas você levaria para implementar cada um deles). Se eu tiver retorno, vou publicar a estimativa (anonimamente, claro).

Normalmente, trabalhar com coleções nativas do Flex do Flex não responde às minhas necessidades… Eu costumo extender estas coleções para ter certeza que estou trabalhando com o tipo correto (meus VOs). E eu sempre preciso saber qual o “estado” da coleççao, ou seja, ter um cursor. Eu faço isso usando um Iterator.

Esta app tem uitas classes e interfaces, por isso não fica prático mostrar o código aqui, por isso dê uma olha a no código, ok?

Se você tiver sugestões (não dúvidas), comente.

View source here.