Tableless - Desenvolvimento inteligente com Padrões Web

10/11/2010
Artigos

Responsabilidade de um dev client-side

Designer de web tem que saber codificar HTML/CSS/Javascript? Um desenvolvedor client-side tem que saber design?

Por

O reconhecimento do desenvolvedor client-side está maior do que nos anos passados. Isso é importante para nós. Anteriormente nenhuma empresa levava a sério esse setor, não porque ele era menos importante, porque na verdade ele não era, mas por falta de “inteligência” das próprias empresas e dos liderantes. O ponto é que esse mercado cresceu, se estruturou, passou por uma reforma natural como todo e qualquer novo mercado que surge e é prostituído com profissionais imaturos.

Com o crescimento deste mercado as responsabilidades do desenvolvedor client-side mudou. Na verdade, não apenas as responsabilidades, mas a estrutura da equipe que ele está inserido mudou completamente. Fica mais granulada. Fica se parecendo mais com uma linha de montagem, só que mais específica e menor. Vamos entender basicamente o processo:

Cada etapa deste processo pode ser completado por um ou mais profissionais. Podem haver processos antes do Design, como: planejamento, briefing, entrevistas, levantamento de informações e hipóteses entre outros.
Também podem haver processos posteriores ao server-side: testes de funcionalidades, usabilidade, SEO, otimização de banco e código, migrações etc.
Existem processos paralelos também, mas não vamos detalhar.

Sabemos que em Server-side, apenas um programador pode resolver o problema. Não adianta colocar um designer ou um dev client-side. Eles não sabem programar, não querem programar, não estão afim. Na parte do client-side é a mesma coisa. O programador não tem noção de design. Ele não tem noção das peculiaridades dos browsers. Não sabe quais as propriedades funcionam nos diversos browsers, não tem noção de acessibilidade, de design e outros pontos importantes. O dev de client-side tem as seguintes responsabilidades na minha opinião:

  1. Planejamento do HTML

    1. Mapeamento dos elementos do layout
    2. Estudo de SEO e semântica dos elementos
    3. Estrutura do HTML padrão
    4. Otimização do código
  2. Implementação do HTML
  3. Planejamento do CSS

    1. Estudo de escalabilidade do CSS
    2. Modularização dos arquivos
    3. Nomenclatura de classes e ids
    4. Nomenclatura e padronização código
    5. Otimização do código
  4. Comportamento dos elementos

    1. Definição do comportamento (junto ao designer)
    2. Criação e padrão de funções e aplicação
    3. Modularização dos arquivos

Veja que dividimos basicamente alguns pontos relacionados às camadas de desenvolvimento: informação, formatação e comportamento. Lembrando que na camada de comportamento o dev client-side só precisa saber a manipulação de elementos. Não precisa aprender a programar profundamente em Javascript. Basta saber um pouco de JQuery ou outra biblioteca da linguagem. Para ocasiões mais complexas há o programador client-side que é o especialista em Javascript. O cara que programa em Javascript como ninguém outro e que vai fazer funções mais complexas do que fazer um DIV aparecer e desaparecer.

Mas quem vai fazer o HTML, CSS e Javascript do projeto? Depende e é aqui que entra a polêmica: em algumas empresas é preferível que o designer seja o coder client-side. Ele já vai ter feito o design dentro dos limites das compatibilidades e possibilidades do HTML/CSS/Javascript. Ele terá a autonomia de retirar ou colocar elementos no layout.
Já em outras empresas o processo é separado: o designer cria o layout e depois de pronto e aprovado pelo cliente (no melhor dos mundos) o dev client-side senta e codifica o layout. Pode ser que nessa fase ainda haja uma divisão, entrando dois profissionais: um para HTML/CSS e outro para Javascript.

Eu não aconselho uma granulação maior, ou seja, um profissional para HTML, outro para CSS e outro para Javascript. Não é necessário. Quem escreveu o HTML já tem em sua cabeça toda a estrutura e já entende como o CSS poderá ser escrito e por isso o processo pode ser mais demorado se outro profissional for fazer o CSS.

É interessante que o designer conheça profundamente HTML e CSS. Uma por que ele conhecerá os limites de cada uma das linguagens e outra porque ele poderá codificar seus layouts em momentos que os projetos precisarem de um reforço. Não recomendo que ele conheça Javascript, não é necessário.
Já o dev que fará o HTML/CSS não precisa ser um designer excelente, mas ele precisa ter noções do belo. Ser perfeccionista em distâncias, tamanhos, cores e fontes. Entender como fazer para que um browser antigo degrade o layout harmoniosamente e assim por diante.

Com a divulgação e adoção do HTML5 e CSS3, o mercado de client-side deixa de ser restrito ao trio HTML/CSS/Javascript. Muitos especialistas em SVG, Canvas, XML e etc surgirão. O mercado cresceu e mudou muito. Quanto mais o mercado cresce, mas se torna necessário especializar-se em vez de ser um canivete suiço.

Por Diego Eis

Diego Eis criou o Tableless para disseminar os padrões web no Brasil. Como consultor já treinou equipes de empresas como Nokia, Globo.com, Yahoo! e iG. É palestrante e empreendedor.

http://twitter.com/diegoeis/

Veja os outros posts de

  • Pingback: Tweets that mention Responsabilidade de um dev client-side | Boas práticas de Desenvolvimento com Padrões Web -- Topsy.com

  • http://www.arieperini.com.br Ariê Perini

    Esta visão está bem detalhada do mercado profissional.

    Conheço a estrutura de empresas como IG, Estadão, Agência Click, UOL e Abril.

    Nelas existe o Designer para a criação e depois o Programador de interface que nessas empresas são chamados que aqui vc chama de dev client-side.

    Só na Abril que muda eles chamam de Webmaster, pq tem que ser alem de interface entender de php, banco de dados e Ajax. Ainda se você vacilar tem que animar e criar tmbm.

    Mas a estrutura da Abril Digital é bem dividida e mais estruturada.

    Sou contra o designer programar o client-site, mas sou totalmente a favor ele conhecer bem como fazer, assim na hora da criação evita colocar no texto propriedades do photoshop coisas que não rola no CSS.

    O Mercado de programação de interface tem salários iniciando no 3000 até 5000.

    Claro que tem ainda os que ganham 1500, fui esses tempos em uma agência muito legal, mas os caras tem uma outra visão ainda, esses problemas ocorrem normalmente.

    Abraços!

  • http://hajaluz.webluz.net Luiz Aquino

    Hei Diego, seus textos são muito bacanas. Outro dia gravei um podcast sobre isso e concordo muito com o que vc disse. Porém, mesmo que ainda seja muito empregada, essa nomenclatura “DESIGN” confunde muito os leigos que associam o processo com o de DESIGNER DIGITAL ou pior, chamam o profissional de WEBDESIGNER.

    O que ocorre é que esse “DESIGN” que você se refere tem mais a ver com o projeto da interface web, como você bem explanou nos tópicos. Logo não é exagero chama-lo de Gestor de Projeto, Projetista, e em trabalhos de maior expressão, Arquiteto.

    O que você acha?

  • http://muriloazevedo.com Murilo Azevedo

    Isso é extremamente importante e mal difundido, por que muitas vezes desenvolvedores usam frameworks client-side(em nome da “produtividade”) que gospem HTML. O código fica inflexível, sujo e ainda por cima não é semântico.

    Mas obviamente existem maneiras corretas de usá-los, mas ainda falta muita conscientização sobre isso.

  • http://acazsouza.com/ @acazsouza

    Nossa, qual a diferença de dev client-side e programador cliente-side no seu artigo, num entendi!

    Separa HTML, CSS p/ uma pessoa e JavaScript p/ a outra é a maior merda que se pode fazer.

    Especalização pode ser bom para produção em massa, mas se você quer qualidade, especialização é uma merda, manter e dar manutenção num único produto, um portal por exemplo é mil vezes preferível que as pessoas tenham conhecimentos ampliados em várias áreas, vai sair um produto muito melhor do que se tivesse especialistas. Não dá pra negar, uma área entra na outra, HTML, CSS e JavaScript entra na parte de Design, o server-side também entra no HTML e no Javascript, eu defendo conhecimentos ampliados se você quer ser um bom profissional.

    ÁLIAS, você se especializa em alguma tecnologia, se amanhã sai uma tecnologia nova que derruba a antiga, você se f*deu. Do jeito que ta hoje o risco de isso acontecer é grande.

    Fica ai minha opinião.

  • http://raelmax.info Rael Max

    Olá Diego, participo da lista frontend-br e ultimamente discutimos sobre isso, sobre as qualidades de um desenvolvedor frontend, e entre elas estava um javascript mais avançado e não um “aparecer e desaparecer de uma div”. E acredito que tanta separação entre as tarefas não seja tão bom para a equipe.

  • http://twitter.com/alyssonfranklin Alysson Franklin

    Ola Acaz, tudo bem?

    Cara, eu concordo em partes com seu comentario. Concordo que precisamos conhecer varias tecnologias, porque na montagem do seu produto – site institucional flat ou um portal multimidia – um desenvolvedor front-end precisará conhecer tecnologias que podera utilizar (ou nao) de acordo com as necessidades do cliente.

    As necessidades do cliente que devem orientar como o desenvolvimento será feito, e a usabilidade de um portal passa por esse conhecimento. Por isso, qto maior seu leque de conhecimento, melhor. E vale lembrar, conhecimento nao é especializacao. Ruby e Phyton ainda nao sao o meu forte (ainda) mas se necessario com um guia de referencia a gente chega na lua.

    Agora, discordo que o processo de producao de um website nao deva ser segmentado. Veja o cenario acima aonde temos conhecimento de muita coisa. E desconsidere o front-end. Sabemos o quao marginalizado é o conhecimento de HTML, e hoje em dia qualquer um fala que trabalha com HTML. Mas um desenvolvedor java, que trabalha no middleware, que tem um grande conhecimento na sua area core, provavelmente tem algum conhecimento em HTML. Mas voce acha justo fazer com que esse desenvolvedor, que tem a responsabilidade de fazer os webservices e databases conversar direitinho com a aplicacao do portal ser o cara responsavel com que o design seja acessivel em todas as versoes de IE, Firefox e Safari? O desenvolvimento de objetos e templates acontecera na mesma velocidade? Voce terá menos erros?

    Acredito que nao. Considerando todo o lifecycle de um projeto, refatoração e redesign sao tarefas que tomam tempo e dinheiro, e as vezes impactam 2 ou mais areas. Trabalhei a pouco em um projeto que entrei quase na epoca da entrega, porque o desenvolvimento das paginas do portal ficou a cargo dos desenvolvedores java. Os caras fizeram um trabalho magnifico no middleware. Mas nao posso dizer a mesma coisa do front-end. Funcoes que faziam a mesma coisa, plugins com trocentas versoes diferentes, de acordo com a area que se estava acessando, erros de severidade media por causa de falhas de design, impacto nas financas do projeto para resolver esse problema. Para nao impactar muito nos financials, tiveram que liberar 2 Project Manager Assistant, responsaveis pela comunicacao de um time de 85 pessoas, para me colocar la e resolver os problemas de design. Se tivessemos desde o inicio um cara responsavel por montar o HTML e os templates, montando um wireframe navegavel de todas as telas, o cara de java so ia chegar depois e encapsular os valores que ele busca dos objetos, do banco, etc. Esse “cara do HTML” pode tambem ser o cara do javascript. Mas tambem temos o cenario que muitos devs, que tem background sensacional em CSS/HTML, nao tem a mesma expertise em javascript. Quantos devs ja gastaram um tempo lendo o source do jQuery antes de implementar um plugin? Quantos devs ja desenvolveram um plugin em cima de outro? Ter um cara especificamente para javascript, dependendo da necessidade do site (imagine um site montado totalmente no jQuery, com grande customizacao de plugins) um cara com esse perfil pode ser mais util q termos apenas um cara de design fazendo tudo.

    Mais uma vez, todo esse cenario depende das necessidades do projeto e a grana que voce tem em maos para executa-lo, mas apesar de concordar que temos q conhecer o maior numero de tecnologias possiveis, defendo que temos que buscar especializacao em uma (ou algumas) delas, para deixarmos de ser um cara faz-tudo de modo “capenga” para ser um cara que faz determinada coisa muito bem feita, state-of-the-art.

    Um abraco;

    Alysson Franklin

  • Pingback: Tropeçando 35 | Rafael Bernard Araujo

  • http://www.somusica10.com Wellington

    Muito bom cara…Parabéns!

  • http://www.manoeldossantos.com Manoel dos Santos

    Escrevi um post bem parecido com este sob o ponto de vista de um designer saber codificar o front-end. http://www.manoeldossantos.com/blog/porque-designers-devem-saber-implementar-as-interfaces/

    Acho muito importante esta relação entre as duas áreas e vejo que o maior problema mesmo é a comunicação. Dev tem muito preconceito e desconsideração (muitas vezes) pelo trabalho do designer e o designer não se interessar em entender as limitações técnicas e o que envolve o trabalho do dev.

  • Fabio Munhóz

    Muito bom seu artigo.

    Comecei minha carreira como DA e como trabalhei um bom tempo em agencias e houses pequenas, eu mesmo fazia o HTML/CSS/JS e depois ainda o flash e actionscript.

    Com o tempo, fui me especializando e não trabalhei mais com flash para poder me especializar nas outras 2 áreas.

    Tive a experiência recente de gerenciar projetos e equipe em um agencia de médio porte ( 50-70 func.) e brigava muuuuito com a direção e a gerência de tecnologia para que o time de interface fosse valorizado e entendido.

    Fico feliz em ver o mercado mudando e que minha luta não foi em vão..rs

    abs

  • http://twitter.com/jardel_xavier Jardel Xavier

    Artigo muito Bom, dicas muito uteis, já trabalho com CSS a algum tempo, e algumas dicas irei utilizar de imediato, pois trabalhar com mais pessoas em um projeto requer sobre tudo uma cois “PADRÕES”, documentar o padrão de codificação do CSS é uma idéia ótima para melhorar a produtividade durante o desenvolvimento do projeto e facilita as manutenções. Parabéns pelo artigo, todas as dicas são ótimas.

  • http://www.thiagocolares.com.br Thiago Colares

    Parabéns Talita! Mais um excelente post ;)

  • http://www.ivinidesigner.com.br johnatan

    Eu uso algumas propiedades, porém não me limito ao IE !

  • http://twitter.com/diegoeis/ Diego Eis

    testandod

  • http://www.wendesign.com.br Wenderlan Web Design

    Concordo plenamente que o designer deva conhecer muito bem HTML e CSS, pois este conhecimento orienta o designer na produção de layouts coerentes com o que vai ser feio no HTML.

  • http://twitter.com/hafael_ Rafael Almeida

    Eae Diego!
    Sou como voce chama de Dev Client-side.
    Tenho um certo impasse com o Designer, pois por ele não ter conhecimento técnico sobre programação, as vezes acabo optando por ignorar os padrões web para ter uma página consistente.
    Apesar dele ser um puta artista, nem tudo que é pensado cabe a ser desenvolvido o que acaba esticando o tempo do projeto.
    Acredito que esse é o problema de muitos desenvolvedores por ai…

    ótima matéria! Ta de parabéns hehe
    vou mostrar isso ao designer! :D

  • http://tcelestino.com.br Tiago Celestino

    O certo é saber de tudo um pouco e ser forte na área que for forte.

  • http://www.nerdhead.com.br/ Rafael Cirolini

    Onde trabalho, no Terra, e em projetos freelances em geral temos um designer e um coder client-side que faz o HTML/CSS/JS. Acreito que seja por grau de especialização.

    Mas um dia quem sabe eu gostaria de aprender design…. =D

  • http://wbruno.com.br William

    Na minha opinião, é idiotice querer ter um cara especializado em js.
    Quem codifica HTML e CSS, tem que saber programar! tem que saber js.

    o pensamento é diferente, na web, js sozinho não faz nada. Qualquer animação que vc vá fazer com js, depende de css! Então, se o cara de css não precisa saber js, vc vai me dizer que o cara de js não precisa saber css?

    Se o cara de js não souber css, ele não faz absolutamente nada!
    Opiniões são bacanas, mas opiniões tendenciosas, são perigosas demais.

    Esse meu artigo vai meio de encontro com oque vc expos:
    http://www.wbruno.com.br/blog/2011/03/29/diferenca-entre-cara-programa-um-programador/

    []s!

  • Pingback: Responsabilidade de um dev client-side | Inove! – Blog

  • http://www.diegocuruma.com.br Diego

    é realmente complicado, as pessoas pensam que é apenas mexer m pouquinho e pronto..

    otimo post!

  • Vivaldreams

    JS sozinho não faz nada?
    Já ouviu falar em ExtJS?
    HTML e CSS é visual.. JS é programação.. também sou a favor de que um designer não precise dominar programação.. se ter uma noção do que é possível fazer com a linguagem já está bom, senão é somente ser visto com o programador no detalhamento do projeto.
    Quem faz tudo não faz nada direito, isso é fato.