Você falou em carro, vou te dar um exemplo de carro. Quando fui ver um para comprar, eu olhei Air-Bag, Ar-Condionado, Freios-ABS, Motor-Flex, estado de conservação, e outros mais. e por ultimo sentei para ver se era confortável, isso após a filtragem dos itens acima.
Com software meu cliente faz o mesmo, ele não olha o sistema, faz toda entrevista, ou seja, resolverá meu problema? Ai eu ligo o notebook e mostro a interface. 1° Pense na TI; 2° Pense no problema; 2° Pense no usuário. PS: Esta entrevista é sempre feita pelo responsável de TI e por algum diretor que só ouve. O de TI fará as perguntas e normalmente ele quem solicita. não sei os seus, mais os meus são assim... Os meus e os das empresas que trabalhei... *Eduardo Kraus* Desenvolvedor eduardokr...@gmail.com http://blog.mxml.com.br http://twitter.com/EduardoKraus 2009/8/20 Beck Novaes <beck.nov...@gmail.com> > > 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 <eduardokr...@gmail.com> 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 > > eduardokr...@gmail.comhttp://blog.mxml.com.brhttp:// > twitter.com/EduardoKraus > > > > 2009/8/19 GuiSjlender <guisjlen...@gmail.com> > > > > > > > > > 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 <eduardokr...@gmail.com> 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 > > > > eduardokr...@gmail.comhttp://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 flexdev@googlegroups.com Para sair da lista, envie um email em branco para flexdev-unsubscr...@googlegroups.com Mais opções estão disponíveis em http://groups.google.com/group/flexdev -~----------~----~----~----~------~----~------~--~---
