Bem... ... a questão do bonito ser importante para mim é simples. Usuários são antes de tudo pessoas e pessoas gostam de coisas bonitas e ponto final.
Ninguém compra um carro apenas por causa do motor. Muitas pessoas que têm carros não buscan apenas resolver seu problema de transporte. Ninguém compra um celular só porque ele "funciona". Em minha opinião o que acontece com software é que, ao contrário das outras áreas (egenharia, construção civil, arquitetura, etc) que já existem há muitos anos, ainda é uma área relativamente nova. Em todas estas áreas num primeiro instante as coisas tendem a ser feias, toscas, por uma questão de prioridade: prioriza-se a solução do problema essencial. Mas passada esta fase (que acredito que estamos chegando próximo no que diz respeito ao desenvolvimento de software) começa a pesar os fatores humanos, os fatores psicológicos, etc. Como diria Donald Norman "As coisas mais bonitas funcionam melhor". Por que? Porque somos seres humanos e as coisas mais bonitas colocam nosso cérebro num estado muito mais propicio para uma determinada atividade: seja dirigir um carro, manusear um celular ou usar uma aplicação. Aqui entra uma outra tese minha junto com o TI-Centrismo que é o tradeoff com foco no valor agregado. (F E R R O U!!! Vou escrever pra caramba agora) Desenvolver softwares é também saber tomar as decições certas com foco no todo e não em partes isoladas. E este conceito é sutil mas poderoso. Daí a importância do Tradeoff - que para quem não sabe é você escolher entre uma coisa e outra mas sempre sair perdendo umas coisas e ganhando outras. Mas o grande problema do Tradeoff em desenvolvimento do Software é que ele é guiado pelo TI-Centrismo. Vejam exemplos: Tabela de Tradeoff Atual nas empresas que desenvolvem Software =================================================== Estética VS. Simplicidade de Implementação = O vencedor é Simplicidade de Implementação Estética VS. Não fazer POG (ver POG do Bem no meu post sobre TI- Centrismo) = O vencedor é "Não fazer POG" E, mais recente: Estética VS. Usabilidade = O vencedor é usabilidade Ou seja, a visão TI-Centrista faz a estética sempre perder. Vou explicar agora porque isso é ruim visando o sofware como um todo. Se a informática fosse uma ciência exata literalmente a regra acima poderia ser aplicada em todas as situações - como é de fato feito na maioria das empresas que desenvolvem software. Mas e se a minha premissa de que a estética é importante por que somos seres humanos estiver certa? Será que, visando o produto final, visando a experiência como um todo, não seria interessante considerar eventualmente fazer um POG para oferecer uma melhor estética pois o usuário vai se sentir melhor na sua aplicação? Será que você não deveria considerar que a Usabilidade não precisa ser a melhor do mundo num dado contexto para deixar o Designer Gráfico mais livre para trabalhar a estética (sim, a Usabilidade cria restrições para o Design Visual)? Vamos a um exemplo real de Usabilidade Vs. Estética para ficar claro o que eu chamo de Tradeoff com foco no valor agregado: Antigamente na DClick os arquitetos de informação definiam a usabilidade e depois restava ao Designer colorir os wireframes. Toda e qualquer alteração proposta pelo designer era recusada com argumentos dos arquitetos do tipo: "isso é ruim. o usuário terá que dar dois cliques no lugar de um". Mas espere um pouco? Com que frequencia ele terá que dar dois cliques? Não muita - disseram os arquitetos. Então isso é realmente um problema? - perguntou Beck Novaes. Não, não é um problema grande! Então vamos priorizar a estética que no final das contas vai agregar mais à solução visto que não é com frequencia que o usuário terá que dar dois cliques. Isto é Tradeoff com foco no valor agregado! Você precisa abstrair e pensar num contexto maior: o produto final. Assim, não se deve tomar como regra nenhum dos itens descritos na tabela de tradeoff acima. O que temos que ter em mente que nosso cérebro (novamente ele) não avalia nada isoladamente. Assim, o usuário falar se uma app é boa ou não vai depender do conjunto da obra. Você precisa encontrar um equilibrio entre a estética e a parte funcional. As vezes você deve deixar de fazer algo assim tão performático pois é algo que não acontece com frequencia para dedicar mais tempo a fazer algo mais bonito numa parte do software que o usuário passa a maior parte do tempo. As vezes você deve deixar de querer a melhor usabilidade do mundo se o problema de usabilidade não for assim tão grave e, por outro lado, isto deixa o designer livre para fazer algo realmente mais bonito. Por que? Porque é disso que o usuário vai lembrar quando ele pensar sobre o software. Não digo que ele vai lembra APENAS da estética. Não digo que ele vai lembrar APENAS do funcional. Ele vai lembrar do conjunto da obra (já ouviram falar de Gestalt?). Ele vai lembrar das animações e isso o fará pensar que, junto com outras coisas, o software é bom. Ele vai lembrar do que ele pode fazer (funcionalidades) e isso o fara pensar que o softeware, em conjunto com a estética, é bom. Então, permitam-me refazer a tabelinha de tradeoff: Tabela de Tradeoff que eu gosto de usar nos projetos que participo =================================================== Estética VS. Simplicidade de Implementação = O vencedor depende do que agrega mais valor para o usuário Estética VS. Não fazer POG do Bem (ver meu post sobre TI-Centrismo) = O vencedor depende do que agrega mais valor para o usuário Estética VS. Usabilidade = O vencedor depende do que agrega mais valor para o usuário Isto é Tradeoff com foco no valor agregado e não em paradgmas irraigados na cultura das organizações devido ao TI-Centrismo. []'s Beck Novaes On 19 ago, 23:16, Eduardo Kraus <[email protected]> wrote: > Diferente de site, sistema o cliente nunca comprou o meus pelas belezas. Se > os sistemas se vendessem por beleza, os softwares da SAP estariam falidos. > > Os da PeopleSoft nem se fala. > > O Cliente quer saber de um sistema que atenda os requisitos dele. que > resolva o problema dele e quer saber se você terá condições de dar suporte > rapido ao problema dele. Se beleza fosse quesito de venda, todos adorariam o > Vista..... > > O Cliente paga beleza quando precisa apresentar aos outros, tipo o painel de > entrada. Agora um sistema ele quer saber que irá resolver os problemas dele. > > Eu posso dizer que o cliente de sistema preza muito mais pela resolução do > problema que da usabilidade dele. É muito subjetivo, você ter um sistema com > milhares de atalhos, altamente usuál e didático, mais se não resolver o > problema o cliente não quer. > > Todos, todos os meus clientes querem saber se o meu sistema resolverá o > problema, mais nada. Eu já ganhei de muitos outras empresas que ofereciam > sistemas mais complexos, e mais bonitos, mais não resolviam o problema. > > Isso também se refere a sites, quantos sites feios vendem mais que o seu, ou > o meu... Porque será? Eles atendem a minha solicitação.... Resolvem o meu > problema... E o seu.... > > *Eduardo Kraus* > Desenvolvedor > [email protected]http://blog.mxml.com.brhttp://twitter.com/EduardoKraus > > 2009/8/19 GuiSjlender <[email protected]> > > > > > Não podemos esquecer do seguinte... > > > Quem irá usar o nosso sistema final é o usuário, o cliente... ou > > seja... pra quem não faz idéia do que é uma TAG ou coisa do tipo... o > > layout é um fator muito apreciado pelo mesmo. > > > Usando o Catalyst o código fica bem comprido e aparentemente poluido, > > mas, fazer transações e animações no muque igual ao Catalyst não é bem > > assim não é?! > > > Sou do seguinte pensamento... > > > Vale estudar um pouco a estrutura do Catalyst e poder criar um sistema > > 100% completo tanto na parte backend quanto frontend do que não ser > > reconhecido o seu sistema ótimo pelo fato de não ser agradável aos > > olhos do cliente. > > > É isso! hehehe > > > Abraços > > > On 19 ago, 12:31, Eduardo Kraus <[email protected]> wrote: > > > O Catalyst é uma ferramenta que esta vindo para que o designer trabalhem > > em > > > Flex e montar as telas para o programador. > > > > Mais será que irá ajudar? > > > > Sou da teoria que o programador deve saber o básico de designer, o > > > suficiente para abrir Photoshop ou Fireworks e exportar as imagens para > > usar > > > no aplicativo. > > > > O Catalyst com certeza irá fazer com que o design trabalhe em Flex, mais > > o > > > quanto isso será util? Quanto irá atrapalhar o desenvolvimento com > > geração > > > de códigos que não são meus, e que terei que entender primeiro, visto que > > o > > > Catalyst gerará o código visual, mais não o código de interação. > > > > Então agora pensando, quase 80% das minhas linhas de código são AS, e > > apenas > > > 20% são MXML de layout. Será que vale a pena inserir um código não meu, > > não > > > seguindo meu padrão, no meu Projeto. > > > > Neste caso estou sim pensando no TI-Centrismo, mais nesta parte do > > projeto > > > tenho que pensar em quem dará manutenção no software, ou memso em quem > > > programará o software . . . > > > > Será que ajudará? > > > > *Eduardo Kraus* > > > Desenvolvedor > > > [email protected]http://blog.mxml.com.brhttp:// > > twitter.com/EduardoKraus --~--~---------~--~----~------------~-------~--~----~ Você recebeu esta mensagem porque está inscrito na lista "flexdev" Para enviar uma mensagem, envie um e-mail para [email protected] Para sair da lista, envie um email em branco para [email protected] Mais opções estão disponíveis em http://groups.google.com/group/flexdev -~----------~----~----~----~------~----~------~--~---
