Recentemente, participei de uma reunião em uma grande empresa para discutir a substituição de um aplicativo in-house cujas deficiências já estavam começando a prejudicar o trabalho por outro mais coerente com as necessidades atuais da empresa.
Para contextualizar, o programa antigo foi inicialmente desenvolvido há mais de vinte anos sendo atualizado basicamente só durante mudanças de plataformas. A versão atual tem mais que oito anos e foi desenvolvida em uma ferramenta de programação já descontinuada e em um banco de dados mono-usuário.
Durante a reunião, a aplicação mais moderna foi apresentada. Ela atende de maneira quase perfeita as novas necessidades e possui um bom caminho de atualização futuro. A grande diferença: a aplicação antiga é standalone e envia dados de importação à cópia central usando texto enquanto a atual é uma aplicação centralizada via Web.
Vale dizer também que os usuários da aplicação, embora versados no uso de computadores, como evidenciado pela proficiência dos mesmos em resolver problemas de instalação e execução da mesma, são relativamente inexperientes no que tange a Web.
O que mais me impressionou em relação à apresentação foi como os usuários sentiram dificuldade em mapear o fluxo da aplicação tradicional para o novo paradigma da Web. Embora a maioria das funções fosse basicamente idêntica em termos de funcionalidade geral, o modo com uma aplicação Web se comporta, com passos entre o servidor e o cliente confundiu completamente alguns usuários.
A interface Web, sem menus ou botões organizados em barras como em aplicações tradicionais, também foi outro ponto de contenção. Não importava que em muitos casos o workflow fosse bem mais simplificado: a interface era simplesmente alienígena.
Depois da reunião, eu comecei a pensar que, para determinados tipos de aplicações, as metáforas usuais de interface realmente são melhores. Mesmo com a flexibilidade que uma aplicação Web provê, determinados problemas são mais amenáveis ao modelo tradicional de interface.
Uma solução para o problema seria, obviamente, reeducar os usuários. Mas nem sempre isso gera os melhores resultados. Embora eventualmene os usuários provavelmente se acostumem com o novo modo de fazer as coisas, a perda de produtividade já terá sido alta.
Por causa disso, eu acredito que exista um ponto em que o Adobe Air e o Silverlight podem entrar com bastante sucesso. De um ponto de vista inteiramente pragmático, essas duas ferramentas permitem uma interação mais usual com o sistema que torna o processo de reacquisição da interface mais tranqüilo.
Com o Prism, esse processo talvez se torne ainda mais interessante, mas dependeria do uso de um toolkit mais interessante–como o Ext JS.
De qualquer forma, foi bom ser lembrado de que nem todos usuários possuem a facilidade de uso com a Web que nós, desenvolvedores, possuímos. E não existe Web 2.0 que resolva isso.
Olá Ronaldo. Interessante esse post, já passei por uma situação semelhante. No caso, o lado visual nem foi o problema, mas o fato de que os funcionários estavam habituados com o uso de teclas já memorizadas (setas, enter, f1..f12 …) e a nova aplicação web trouxe um desconforto e uma sensação de que eles se tornariam “menos produtivos”, consumiriam mais tempo para realizar a mesma tarefa, e isso foi suficiente para que a aplicação fosse classificada como “ruim” e “insatisfatória” sem que fosse levado em conta outros aspectos. Mesmo que estes funcionários já tivessem uma certa fluência com a web por usarem constantemente e-mail e internet banking, a aplicação era diferente. A solução foi melhorar o máximo possível essa interação com JS, e a empresa acabou impondo aos funcionários o novo modelo web. Nesse momento toda a preocupação e rigor com uma página enxuta, limpinha e dentro dos padrões cai por terra diante de pessoas que apenas querem continuar fazendo o que faziam antes sem preocupação com mais nada. Talvez a solução fosse mesmo uma outra interface que não parecesse, pra eles, um navegador. Talvez um ambiente único (web) em que seja possível fazer de tudo ainda não tenha sido compreendido.
Opa, Valdir. Tudo bom?
A descrição desse problema seu é exatamente a sensação que eu percebi naqueles usuários. Uma das frases que eu escutei foi “não teria como manter os ícones do jeito que estão hoje”. Essa sensação de familiaridade é perdida quando você migra para algo que é completamente diferente em múltiplos níveis.
Pelo menos hoje, com mais possibilidades em JS, é possível criar interfaces mais próximas. Mas, realmente, o cliente não dá a mínima para padrões se as coisas não estão funcionando como funcionavam antes.