Programação e Interfaces com o Utilizador 03/Mar/2010
O meu caminho pela programação de sistemas computacionais tem sido o normal, se bem que mais lento do que a tecnologia tem evoluído: comecei por programação imperativa de aplicações em modo linha de comando e tenho-me mantido mais dentro das componentes servidor das soluções que tenho desenvolvido ou mantido.
No entanto, de cada vez que faço uma incursão na programação de aplicações em modo GUI sofro sempre de demasiado atrito e impedância. E mesmo quando consigo chegar ao fim, na maioria das vezes não é o que o utilizador esperava desde o começo.
Pondo de parte as questões ligados com NPP - Non-Programming Programmers – e com os desafios habituais à volta da programação – Software Craftsmanship – este artigo aborda dois temas: porque é difícil para os programadores codificar boas interfaces com o utilizador e uma possível resposta para minimizar essa impedância ( Paper Prototyping ).
Em primeiro lugar, já aprendi que 80% ( ou mais ) do valor de uma aplicação avaliado pelo utilizador está sobre a interface com o utilizador dessa aplicação.
O Jeff Atwood, no seu artigo “The User Interface Is The Application“, diz que não importa quantos diagramas espectaculares da arquitectura existem para uma aplicação porque que, no que diz respeito ao utilizador dessa aplicação, a UserInterface é a aplicação. É verdade que a tarefa de construir uma boa UserInterface é árdua mas para se ser levado mesmo a sério tem que se construir uma UserInterface impressionante. E chega mesmo a citar o Yukihiro Matsumoto, criador da linguagem Ruby:
If you have a good interface on your system, and a budget of money and time, you can work on your system. If your system has bugs or is too slow, you can improve it. But if your system has a bad interface, you basically have nothing. It won’t matter if it is a work of the highest craftsmanship on the inside. If your system has a bad interface, no one will use it. So the interface or surface of the system, whether to users or other machines, is very important.
No pressuposto de que construir uma boa UserInterface é difícil, será razoável esperar que qualquer programador sem formação ou experiência em UI Design consiga construir e manter uma boa UserInterface?
Algumas respostas vieram também de um outro artigo do Jeff Atwood, “UI is Hard“, onde escreve que em parte são os próprios programadores os primeiros culpados pois – tal como acontece comigo – a maioria dos programadores começa por pensar no código e lógica do negócio em vez de começar por pensar na interface com o utilizador. E essa maioria está representada em parte nos comentários a este seu artigo.
Outras respostas semelhantes vieram de outros artigos, “UI Design” no blog Buggin’ My Life Away do Rick Schaut e “Can Programmers Do Interaction Design?” do Kim Goodwin no Cooper Journal.
O que o Rick salienta é que quando se trabalha em software para o utilizador, seja uma aplicação web ou desktop, seja adicionar novas funcionalidades, que então o foco inicial seja no desenho da interface com o utilizador – primeiro que tudo. E tal é complicado porque em primeiro lugar os programadores estão habituados a implementar algoritmos eficientes para problemas comuns da ciência da computação mas não aprenderam nem têm experiência suficiente sobre como desenhar uma boa interface com o utilizador. Em segundo lugar, a maioria das ferramentas facilita a criação rápida de interfaces com o utilizador para a maioria dos problemas simples de Usability mas têm tendência para ficarem aquém do que é preciso para facilitar também o criação rápida de interfaces para um conjunto de cenários de utilização mais complexos.
Num outro artigo interessante, “The Rise and Fall of Homo Logicus“, o Jeff Atwood cita um trecho do livro The Inmates Are Running the Aslum do Alan Cooper: existe uma grande a impedância ao se permitir que um qualquer programador desenhe a interface com o utilizador. Porque enquanto a maioria dos programadores tem um pensamento mais virado para o conhecimento sobre como tudo funciona, a maioria dos utilizadores tem um mais pensamento virado para o sucesso de uma tarefa. E termina o artigo dizendo que temos que parar de pensar como Homo Logicus e pensar mais como o Homo Sapiens.
No artigo do Kim é dito que ao invés de ter mais baixo custo ao utilizador programadores para desenhar a interface com o utilizador se tem o oposto: é mais ineficiente, mais custoso e com maiores hipóteses de ser um falhanço. E falhanços é do que se está mais habituado na programação, certo?
Então, como evitar a impedância entre o que o programador é capaz de criar e o que o utilizador está normalmente à espera?
Em primeiro lugar, vários artigos recomendam começar-se o desenvolvimento pela criação da interface com o utilizador, até mesmo ao ponto ( extremo e irónico ) de nomear uma metodologia a seguir: FAD.
Em segundo lugar, recorrer à prototipagem do papel – que além de outras vantagens evita grande parte dos percalços na prototipagem de aplicações – devido a mitigar melhor os riscos normalmente inerentes a se ter o feedback dos utilizadores somente após laboriosas tarefas de programação
- Posted in : doCoding
- Author : José Carlos Monteiro
Comments»
Março
? O artigo está porreiro mas tens de escrever mais aqui e menos no Facebook, eheh…