Quando se fala de bens tem dois itens Os que tu pode mostar e os que não podem
Carro, celular você compra para mostrar para os outros. Por exemplo, tem gente que compra celular motorola V8 que só tem telefone e paga R$1000,00. Por que? Para mostar.... o inconciente pensa na inveja que vai causar, mais não aceita cartão extra, e nem tem rádio. Só fala.... */* Este exempo me basiei no lançamento do primeiro V8 */* Agora ontem fui comprar carne para churrasco. Tinha uns pedaços lindos na bandeja, todo enfeitado, mais eu e a grande maioria vai até o açougue emanda cortar um baita pedaço de Alcatra. */* Desculpe os vejetárianos, mais estava otíma */* Veja a diferença, o churrasco é o sistema que as empresas compram. Tem que resolver o problema da melhor maneira. Você bem sabe disso, deve ter vários.... Não estou aqui para defender que sistemas devem ser feios, mais sistemas devem antes de tudo partirem para resolver problemas. Não se pode abandonar o TI-Centrismo por ele ser util. POG gera BUG que gera erro que gera falhas. E falhas é a principal causa de abandono de um sistema por uma empresa. Eu sou Programador Autodidata, e tenho conhecimentos de básicos de Designer e médios de Usabilidade. Com isso tendo a pensar mais no TI-Centrismo, e quando preciso contrato um Designer freelancer. Ele se preocupa com o Usuário, a organização dos botões e a melhor forma de apresentar os itens. Se eu abandonar o TI-Centrismo meus sistemas serão abandonados. Eu falo com orgulho que conheço cada um dos mais de 50 sistemas que tenho em meu servidor e se precisar dar manutenção, tenho a grande maioria deles com uma estrutura muito bem organizada. Esta organização faz com que eu ganhe tempo no suporte e dininua o número de BUG e bug é prejuizo. SE EU ABANDONAR O TI-CENTRISMO ESTOU FERRADO. Veja, meu Blog por exemplo. Se tentares injetar HTTP via URL dará erro 500. Se você enviar um SPAM o sistema retornará erro 500, e se tentar enviar arquivosa maliciosos dará erro 500. http://blog.mxml.com.br/wp-admin/login.php http://blog.mxml.com.br/wp-admin/login.php?load=* http://aboutav.com//o/id1.txt???*<http://blog.mxml.com.br/wp-admin/login.php?load=http://aboutav.com//o/id1.txt???> Veja acima que o segundo não passa, só por causa do segundo *http://* Esta bloqueado. É isso que os clientes esperam de um sistema. Segurança. E a propósito, você sabe o que acontece com seus sistemas??????? Desde 2005 tive apenas um sistema invadido e deletado completamente, mais graças ao backup diário só me fez perder tempo. Agora muitas empresas por ai, não se preocupam nem com TI-Centrismo nem com Usuário-Centrismo. E ai, ele são melhores? Eu confio cegamente no Google, Você certamente também "* [email protected]*", mais o Google só creaceu por que é uma empresa que tem uma TI invejada. Hoje que eles tão melhorando a usabilidade. Eu confio 100% dos meus E-mail, sem backup la. Seu clientes confiam tanto assim em você???? Em mim ainda não, mais estou trabalhando muito para que cada vês mais confiem. Cliente são baseados em Amizade e amizade é baseado em *confiançã*, e confiança é dado pela TI. Você prefere que o sistema do seu banco seja desenvolvido por pessoas que pensam na TI ou no Usuário? Eu prefiro o de TI.... Eu acho um saco ter que liberar os computradores para poder fazer transações bancárias, mais nunca me ouvirás reclamar de etr que liberar. *Eduardo Kraus* Desenvolvedor [email protected] http://blog.mxml.com.br http://twitter.com/EduardoKraus 2009/8/20 Beck Novaes <[email protected]> > > 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 -~----------~----~----~----~------~----~------~--~---
