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!

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

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

E faça um designer feliz!!!!

http://www.fivesecondtest.com/

This post is in portuguese only because you can find plenty of information on KML on the internet.

O Keystroke Level Model (ou KLM) é uma forma rápida e segura* de avaliarmos diferentes interfaces que suportam a mesma tarefa. Este método irá retornar um valor que corresponde à predição de tempo que um usuário que não erra leva para realizar a tarefa com a interface em questão.

Minha intenção não é ensinar a usar o KLM. Para isso, você deve buscar outras fontes, como por exemplo este do David Kieras, que é muito didático.  O que eu pretendo com este post é comparar alguns interfaces que suportam a mesma tarefa, e usar o fator “tempo” como um dos parâmetros para informar minha decisão sobre qual delas eu devo usar.

A tarefa em questão é associar um conceito a um material, num espaço de criação/edição de materiais, em uma biblioteca virtual de materiais. Cada conceito pertence a uma e apenas uma biblioteca de conceitos. Além de associar o conceito a um material, o usuário deve especificar o quanto (em termos numéricos), esteb conceito está associado ao material que está sendo criado/editado. Por exemplo: o conceito “Inovação” está relacionado “87%” com o material  “Polietileno”.

As interfaces em julgamento sã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.

Estou assumindo que o usuário é novato no sistema (precisa refletir sobre as ações e precisa procurar os elementos na interface). Vamos aos cálculos**:

Interface Drag n´drop – Tool tip aparece logo que o conceito está sobre a área – Tree aberta sem rolagem

TOTAL = 7M + 2P + 2B = 10.8 segundos

Ainda para esta mesma interface, temos que considerar que o usuário decide mudar o valor da associação. Neste caso, ficaria assim:

TOTAL = 6M + 1P + 2B = 8.5 segundos

Interface HSlider – Tool tip aparece sempre na HSlider – Tree aberta sem rolagem

TOTAL = 6M + 1P + 4B = 11 segundos

Ainda para esta mesma interface, temos que considerar que o usuário decide mudar o valor da associação. Neste caso, ficaria assim:

TOTAL = 6M + 1P + 2B = 9.7 segundos

Concluí que com a interface com Drag n´Drop leva-se cerca e 7% menos tempo que com a interface HSlider. Eu nao acho que esta diferença de tempo seja significativa, por isso precisaria de mais critérios para decidir. Neste ponto, eu recomendaria um teste com (5) usuários. Acompanhe aqui para saber como foi.

* Aqui neste (excelente) livro, você encontra uma breve descirção de diversos métodos ergonômicos, além de uma avaliação de parâmetros como confiabilidade, rapidez no treinamento e na aplicação. Eu comprei e gostei :0) Ah, e fiquei sabendo neste blog: “o design e a ergonomia”

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

** O KLM prescreve operadores (tanto a nível operacional quanto mental) e tempos para cada um deles. Para ver como cheguei a estes resultados, veja o artigo do David Kieras. Estes “tempos” foram medidos em experimentos em laboratório. Para ver mais detalhes, veja o original: Card, S.K.; T.P. Thomas & A. Newall (1983), written at London, The Psychology of Human-Computer Interaction, Lawrence Erbaum Associates, ISBN 0-89859-243-7

Bem, vai ficar complicado traduzir o título deste post, mas acho que deu pra entender o que eu quis dizer com ele ;0)
Trees são um dos meus data controls favoritos, porque dá pra colocar montes de informação dentro deles, organizadas em categorias. Elas também são otimizadas para visualização, já que o usuário pode facilmente setar o que ele quer e o que não quer ver. Por isso eu uso bastante :0)

Neste novo projeto em que estou trabalhando, andei desenhando trees para um monte de casos de uso (sim, eu desenho meus casos de uso), e, quando me dei conta, tinha apenas um caos que não tinha uma tree…. Uma parte dele está na imagem abaixo (à esquerda).

Seria legal se todos os casoso tivessem o mesmo jeito de mostrar e interagir com informação – se eu uso trees em todo lugar, porque não usar neste caso de uso também? A resposta é simples, você consegue descobri-la?

O grupo à esquerda é parte de uma tela onde você escohe o tipo de um material. Estas categorias são mutualmente exclusivas (você só pode escolher uma) e coletivamente exaustivas (elas, como grupo, descrevem todos os tipos possíveis; qualquer material tem que estr em uma delas). Na direita, temos processos industriais. Um único material pode “ter” mais de um processo, tanto na mesma categoria como em categorias diferentes. Então, se eu usasse trees à esquerda, quando um “galho” estivesse fechado, o usuário não veria uma informação vital (coletivamente exaustiva, lembra?). Neste caso, ele não estaria apto a escoher. Por outro lado, usar tree para mostrar processos permite que o usuário “esconda” processos que não lhe interessam.

Hehe, e agora, o que você vai fazer? Como você deve ter notado, o post é sobre deletar itens inadvertidamente. Meu argumento é que este pode ser um erro que o usuário irá cometer (mesmoq ue a gente siga a lei de Fitt). Como nós, desenvolvedores (e designers) cuidadosos podemos evitar isso? Nós os “alertamos” :0)

Nós jogamos um Alert (o control) que diz algo do tipo: “ei, tem certeza que quer deletar isso?”

E o que o usuário faz? Ele não lê e clica ok. – “M****!”. Você diz: – “eu avisei”.

Bem, e se – e se e se – tentássemos algo diferente? E se ao invés de “alertar” o usuário, mudássemos o estado de um item e colocássemos um botão de undo?

Se o usuário inadvertidamente deleta o “Item F”, ele vê que o estado do item mudou. Se ele realmente quer deletar, ok, então quando ele sair* o tiem será deletado. Mas, se ele comete um erro, ele pode desfaze-lo logo que percebe.

* É claro, temos o problema de saber quando o usuário sai…

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

Eu sempre tenho essa sensação quando estou escrevendo os rótuolos dos meus controls (no caso, checkbox). Sempre chega um momento em que eu “travo”. Se não deu pra entender meu problema, veja a imagem abaixo:

Considere a checkbox no topo: o que ela diz? Você concorda?

E a de baixo: você concorda?

Pois é isso que me trava. Não é uma tarefa fácil, o próprio Shneiderman*falou. Eu acho que tem muito a ver com o rótulo: se é positivo, normalmente é mais fácil marcar o estado desejado (concordo / não concordo).

Mas desta vez a coisa era um pouco mais complicada…..

Eu tenho uma checkbox que deve habilitar / desabilitar a edição de uma propriedade. Se esta propriedade “não se aplica”, então não tem sentido editá-la. Como a figura abaixo mostra:

Se “Coeficiente de atrito” se aplica, então você pode atribuir um valor a ela. Mas considere as opções na imagem acima: o que elas significam?

O que eu quero que o usuário entenda? “Se a propriedade NÃO SE APLICA, então NÃO EDITE”.

Então, embora tenha parecido esquisito no início, vou usar a sentença negativa. Eu achei que poderia ser confuso, porque se a propriedade for aplicável, então você teria que desmarcar o checkbox, o que é equivalente a uma dupla negação: “Não não se aplica, i.e. se aplica”. Mas eu também acho que ter o control selecionado no início é importante, para que o usuário veja que ele está desabilitado porque “não se aplica”.

Então a coisa ficou assim:

* Se ele disse, deve ser verdade ;0) Leia, é um clássico: Software Psychology: Human Factors in Computer and Information Systems;

Estou aqui novamente para falar sobre design. A idéia agora é documentar o processo de proejto de uma aplicação que deve auxiliar na seleção de materiais. Estou projetando a interface, com o precioso auxílio do prof. André Canal Marques  e do prof. Celso Scalestksy,ambos excelentes designers. O projeto é da Unisinos, e esparamos ter algo conreto para mostrar em alguns meses :0)

Bem, seleção de materiais é um assunto vasto. Há pessoas que fazem pós graduação nisso (como o prof. Marques fez). Você tem que saber Química e um monte de Engenharia. De forma resumida, um dos objetivos é responder a pergunta: “de que material este objeto pode/deve ser feito”? Há muitas variáveis nesta questão, e para projetar uma aplicação que efetivamente ajude, é preciso conhecê-las.

A questão é que eu não sou uma especialista no assunto…. E não vou me tornar uma especialista em algumas semanas. Nem os especialistas em seleção de materiais irão se tornar especialistas em design de interface… E aí, o que fazer?

Nós prototipamos*! Claro, houveram reuniões prévias para que eu tivesse um pouco mais de enetndimento da área (ele beirava o zero), para conhecer algunas cases e para ver o que nossos vizinhos estão fazendo. Algumas das coisas importantes que eu aprendi:

1. Registrar um material leva tempo. Há muitos valores a associar com um material.
2. Pode haver dois materiais com composição química idêntica, mas com propriedades diferentes.
3. Há livros e softwares onde você pode conseguir o valor das propriedades de engenharia de um material. Por exemplo, eles podem te fornecer os dados sobre o Polietileno. Mas se o fabricante muda o processo de fabricação do material, as propriedades do livro/software não estão “corretas”.
4. ÀS vezes, o fabricante dá uma amostra do material, mas não dá a descriçao completa. Ele informa as propriedades mais relevantes, mas as demais devem ser pesquisadas (no web site, por exemplo).
5. Há propriedades que não são relevantes para alguns materiais.

Também fiquei sabendo que a materioteca tinha uma ficha para registrar as amostras, e recebi uma cóipa desta ficha.

Depois destas reuniões, eu comecei com modelos de papel e caneta. A idéia é criar um layout básico, testar algumas funcionalidades e ver como elas se comportam juntas. E isso já me economizou muito tempo e me deu algumas boas idéias :0)

Figura 1. Os promeiros desenhos.

Por exemplo: a tela “Tipo”.  Cada material deve ser classificado de acordo com seu tipo. Mas há mais de uma taxonomia para isso. Estas taxonomias consideram diferentes aspectos dos materiais, como composição química. Estamos usando a mesma da materioteca. Eu estava desenhando essa tela (figura 2, à direita) e pensei: “ei, será que um polímero não pode ser natural? Tipo, proteínas são anturais…” Então eu desenhei a tela que está à esquerda na figura 2. Mostrei para o prof. Marques, que disse: “é, está certo, mas neste sistema de classificação, um material só pode ser associado a um tipo”. Ok, beleza.

Figure 2. Como os tipos podem ser atribuídos?

O segundo exemplo de benefício de usar “protótipos*” tem a ver com a tarefa de registrar um novo material. Como você pode ver na figra 3, há propriedades sensoriais (mais à esquerda, no topo), propriedades de engenharia (à direita) e uma visão geral (à esquerda, embaixo) de propriedades comuns.  Como elas estão duplicadas na aba “Propriedades de engenharia”, pensei que talvez o sistema pudesse usar estas propriedades para gerar esta “visão geral”, que é importante para  o usuário. “Sim, é uma boa idéia”, meus colegas disseram. POis será implementado :0)

Figura 3. Uma amostra das propriedades que um material pode ter.

Seguindo esta linha de raciocínio, eu pensei: “hei, pode ser uma boa idéia melhorar a tarefa ainda mais, fazê-la mais rápido, se, dado o tipo, o sistema pudesse reconhecer alguns valores padrão de propriedades”. A resposta foi: “é plausível e é uma boa idéia. Mas vai demorar para compilar estas propriedades”.

O caso é: para papel e caneta, e para uma sessão de uma hora de desenho, eu consegui entender a aplicação muito melhor.

Você deveria tentar :0)

* Certo, não são protótipos. Não são nem mock-ups… São mais modelos, de tão simples que são. Mas são de uma grande ajuda.