blz galera, muito interessante tudo que vcs falaram, considero até uma continuação do Além dos Cruds que foi um tópico tbm muito bom aqui no flexdev...
minha humilde opnião. Sempre vai existir clientes(Usuários) como o Kraus falou, o que importa é o produto fazer tudo que ele quer, sem frescura, sem flash aqui e sem efeito ali, muitos pagam e pagam bem por esse tipo de solução. Existe outros tantos em que a regra do dominio tbm é o layout, o que importa é que a interface seja muito bonita, cheio de frescura e coisa e tal... Resumindo: Se eu fosse fazer um site(ou sistema na web, que seja) meu para vender meus produtos contrataria o estilo do Beck, não quero nada que apenas funciona, o meu tem que ser diferente, o meu tem que ser personalizado, o cliente meu tem que se sentir agradável no meu site ou sistema, o layout diferenciado(Show) seria uma exigencia... agora... Se fosse contratar um sistema para resolver algumas soluções internas, cujo não afetaria meu negócio ser bonito ou não, contratario o estilo de Kraus, e chorar por um bom preço é claro :) Tem usuário que vai te ajudar a desenvolver, tem usuários que nem sabem o que querem direito, só querem, tá pagando e vc se vira para fazer o que ele quer do jeito que nem ele sabe direito. Se o catalyst ajuda? para mim deveria ser tratada como a filha dos olhos da adobe, vai resolver um grande problema de quem trabalha com tercerização ou de uma forma remota, deixe o layout para quem entende de layout, e obrige para que o layout já esteja pronto para aí sim começar a programar, não tem nada mais desgastante que programar e vir um Desiegner da vida e mexer e estragar tudo(desculpem a sinceridade :) ) o Código que o catalyst gera é ruim? vai ver o seu código html + ajax que vc fazia aos 3 anos atrás, aquilo que era bagunça por mais organizado que vc fosse. Aproveitando o que a gabriela disse e ajudando ela nas aulas ;) , há uma diferença de mentalidade muito grande entre developer e designer começando pela forma de desenvolvimento programador -> Rascunhas classes e tabelas, começa criando as tabelas ou as classes que vão gerar as tabelas, depois em serviços, arquiteturas, padrões e framework que podem auxiliar, manutenção e funcionalidade(no sentido de estar funcionando). designer-> Rascunhas telas, começa com wireframes para criar a arte ou já cria a arte, depois em efeitos, usabilidade, identidade visual, marketing, manutenção(não fazem um layout pensando que ele vai ser alterado, minha arte ninguém mexe :) ) se vc é um programador o catalyst não é para vc, para vc vai ser uma ferramenta chata, sem utilidade nenhuma, mais se vc é da turma do layout, se segura que o negócio é bom de brincar. e por último imagine o seguinte já que fizeram bastante metáforas com carros e tal Um notebook MAC com uma configuração de deixar com queixo no chão, com usuário que só usa "MSN e Orkut" essa é a impressão que tenho com o FLEX, uma excelente ferramenta para "LAYOUT" a qual programadores conseguem deixar com a mesma cara que um programa desktop um um site feito em Flash. Está na hora sim de mudar a mentalidade, dar asas a imaginação e ver que vc pode ir muito além que seguir metodologias e padrões, de deixar de fazer algo diferente pq vai fugir do padrão, use e abuse, FLEX é para isso. Cumps. On 20 ago, 18:39, Eduardo Kraus <eduardokr...@gmail.com> wrote: > 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.comhttp://blog.mxml.com.brhttp://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 > > ... > > mais » --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
