Categorias

Desenvolvedores são de Marte, Designers são de Vênus

Cães e gatos. Caim e Abel. Flamenguistas e vascaínos. Designers e desenvolvedores. Estes são alguns dos grandes polos opostos da História da Humanidade. Alguns são irreconciliáveis e permanecerão assim até o final dos tempos. Outros tem solução.

Afinal, uma coisa designers e desenvolvedores tem em comum: eles querem que o trabalho seja bem feito e que o projeto seja um sucesso. Mas de formas diferentes. Desenvolvedores querem que o site funcione direito. Designers querem que o site apareça direito. Estas diferentes prioridades podem gerar conflitos, gracejos e até uma ocasional guerra de clipes de papel,  mas estas divergências são mais fáceis de resolver do que aparentam. Ou não.

Bronca 1: “Por que os designers querem criar tudo em Flash?”

O site é apenas um texto de dois parágrafos, uma imagem e um botão, mas o designer insiste em usar o Flash, mesmo que isso signifique triplicar o tempo de download, alienar uma parte dos usuários que nem tem o plugin instalado, dificultar o SEO e martelar aquela música irritante por todo o escritório. Por quê?

flash

Para alguns designers, ficar limitado às tecnologias básicas da internet como HTML, CSS e Javascript para criar uma página é um suplício: limita sua criatividade e os força a depender de um desenvolvedor para completar sua visão.

Com o Flash, o céu é o limite: ele escala para qualquer resolução (é responsivo!), aceita curvas, as fontes tem antialising, é possível utilizar qualquer tipografia, animação é fácil de fazer, dá para incorporar sons com facilidade etc. Se o designer conhece ActionScript, então, o desenvolvedor torna-se descartável. “Liberdade, afinal!”. Ou, pelo menos, essa é a sensação que fica.

Solução:

A primeira pergunta que deve ser feita pelo desenvolvedor em qualquer projeto é “qual é a melhor solução tecnológica para o problema?”. Podem ser as tecnologias básicas ou pode ser o Flash. Ter a mente aberta é importante. Para determinar qual a melhor abordagem, o desenvolvedor deve sentar com o designer e responder esta pergunta. E outras perguntas, também. Sem se matarem, de preferência.

Por exemplo, como fica a questão do SEO na página? Ela precisa carregar rapidamente? Qual é a velocidade média da conexão do público-alvo? É necessário utilizar uma fonte proprietária por questões de marketing? Animações adicionam valor emocional ao projeto? Aquela música bate-estaca agrega alguma coisa?

O desenvolvedor deve estar preparado para explicar ao designer sobre animações com jQuery, efeitos dinâmicos e interativos com DHTML ou AJAX, uso de webfonts e outras técnicas que podem atingir o mesmo resultado que o Flash, na maioria das necessidades. E aguentar a música, se ela for absolutamente necessária.

Bronca 2: “Por que o desenvolvedor não pode deixar a página igual ao modelo?”

O designer cria um layout sensacional e passa o modelo para o desenvolvedor, mas quando o site retorna parece mais um monstro de Frankenstein do que aquilo que foi montado no Photoshop, um filho bastardo do Geocities. Por quê?

Modelos não são páginas da Web, eles não são uma combinação (às vezes explosiva) de HTML, CSS e Javascript. Photoshop, Fireworks, Corel e Illustrator podem fazer uma série de coisas que são impossíveis (ou pelo menos impraticáveis) na Web, o que significa que os desenvolvedores precisam mexer em algumas coisas e serem criativos…

Solução:

O designer precisa conversar com o desenvolvedor enquanto está criando seu layout, não apenas depois (ou pior, nunca). Ele precisa perguntar ao desenvolvedor se determinado efeito será fácil de ser obtido ou se existem alternativas superiores. Também, na medida em que o designer entende mais sobre desenvolvimento para Web, será capaz de perceber a diferença entre um layout que é impossível de se obter e um desenvolvedor que apenas não quer ter muito trabalho.

Bronca 3: “O designer me passou um PSD com 2000 camadas sem nome e sem pastas!”

O desenvolvedor finalmente termina o download daquele documento de Photoshop com 150Mb. Ele espera o programa abrir e demora uns 5 minutos. Dá OK em cinco alertas de fonte não instalada. Tudo o que ele quer é recortar e editar um botão. E então, ele vê 2000 camadas sem nenhum nome, nenhuma pasta, nenhuma ordem. Por quê?

Layers Sem Nome

Desenvolvedores tendem (ou pelo menos deveriam tender) a manter seus documentos bem organizados, ou não serão muito eficientes. Entretanto, se o layout esta legal na área de visualização do Photoshop, frequentemente já está bom para o designer. Para um desenvolvedor acostumado com orientação a objetos e ordem lógica de código, é a visão do inferno!

Solução:

Desenvolvedores devem esclarecer esta questão com os designers o mais rápido possível. Se por um lado o desenvolvedor ganha tempo com camadas nomeadas e bem organizadas, o designer pode perder um tempo ainda maior se tiver que fazer isso com todas elas. Um mínimo denominador comum deve ser atingido. O mínimo de organização pode até mesmo facilitar o trabalho do designer em uma eventual revisão do trabalho.

Um truque interessante para desenvolvedores é usar Ctrl+Click para selecionar a camada exata de um objeto usando a ferramenta Move (v). Se a aba de Camadas (Layers) estiver aberta, a camada correta será selecionada.

Este tipo de atrito também pode ser um bom momento para o designer descobrir o poder dos Smart Objects do Photoshop. Não é o escopo deste artigo, mas vale dizer que este recurso permite que sejam coletadas várias camadas para formar um objeto (por exemplo, as camadas que formam um botão) em um arquivo discreto embutido dentro do arquivo principal no Photoshop.

Smart Objects são simples de usar e tem muitos benefícios, entre eles a capacidade de reduzir o número de camadas no documento-pai.

Bronca 4: “O desenvolvedor errou todas as cores!”

Teoria da Cor, emoções, roda de cores, complementação, cores não são escolhidas aleatoriamente, mas desenvolvedores parecem pensar que vermelho e azul combinam bem ou que uma determinada cor está “bem parecida”. Por quê?

Chameleon

Desenvolvedores vieram de um ambiente onde a tela era negra e o texto era branco para um ambiente de desenvolvimento onde a tela é branca e o texto é negro. Isso é o que importa. A sutil diferença entre um #F00 e um #C00 vai além de uma letra, mas “vermelho é vermelho, larga de ser chato”.

Solução:

Se o designer quer que todas as cores estejam corretas, o ideal seria anotar todos os valores de cores na página. Nem sempre o desenvolvedor terá a paciência de coletar o valor exato a partir do Photoshop.

O designer também precisa considerar a possibilidade de que o problema não esteja no desenvolvedor, mas em seu próprio ambiente de trabalho! Cores são diferentes em um Mac e em CMYK (que não é o adequado para o padrão web, vale lembrar). O designer tem que ter certeza de estar usando o modo de cor certo no documento, geralmente o RGB.

Bronca 5: “O designer não se preparou para conteúdo real”

O sistema de atualização do site dá controle total de conteúdo para o cliente. O layout, porém, é bastante rígido: apenas uma linha de texto para chamadas e um parágrafo para sumários. O que o cliente quer inserir não está cabendo no modelo. Por quê?

O designer calculou uma estrutura balanceada de altura de texto e colunas, mas não conseguiu antecipar a quantidade de texto que precisaria caber ali.

O famoso “Lorem Ipsum” é um método clássico para adicionar conteúdo que parece real, na falta do texto final do site. Entretanto, uma vez que não é conteúdo de verdade, ele pode levar o designer a tirar conclusões erradas sobre o design final da página.

Solução:

Layouts são estáticos, mas páginas da Web do mundo real precisam ser fluídas e dinâmicas. Designers devem reconhecer isso e cobrir todos os cenários possíveis. Esta é uma das limitações conhecidas de se criar modelos estáticos: eles não são a coisa verdadeira.

O designer precisa estar preparado para alternativas quando o conteúdo extrapola a área inicialmente prevista, uma chamada de duas linhas, um sumário um pouco maior. Às vezes, acontece o exato oposto: o conteúdo é insuficiente para preencher todo o espaço reservado. É preciso entender que a altura não deve ser dada como certa.

O ideal neste caso seria ter uma noção bastante próxima do que o cliente tem em mente para cada região da diagramação. Não é culpa do designer, nem do desenvolvedor se “A Oftalmotorrinolaringologista Tamara Taiana Elis Regina Satiko Harumi Clelia Cristina Bethania Angelica Amelia Catarina Rafaela Denis Berenice Lidia Clementina Magnolia Branca Galdino” (o nome é real) não está cabendo na legenda da foto.

Bronca 6: “Desenvolvedores tem alguma ideia sobre o que espaço em branco significa?”

O designer deixou um bocado de espaço em torno dos elementos para que eles possam respirar e criar um caminho fluido para a leitura, mas o desenvolvedor socou tudo junto e falou que “era o único jeito de caber tudo”. Por quê?

Apertado

Pode acontecer deste problema surgir justamente por conta da bronca acima, quando o designer não pensou sobre o espaço necessário para o conteúdo real. Mas algumas vezes a culpa é mesmo do desenvolvedor, que esbarrou em alguma funcionalidade não prevista no layout ou algum tipo de feedback não contemplado antes e não hesitou em usar o seu bom-senso: “se eu consigo ler, qualquer um consegue”, “tinha um espaço em branco sobrando ali e eu aproveitei”. Infelizmente, ainda não amadureceu a ideia de que um layout é composto não apenas por aquilo que você coloca, mas também pelo que você deixa vazio.

E espaço em branco na web é grátis, pode usar à vontade!

Solução:

Se o designer realmente deseja que seu layout seja preciso, ele não deve oferecer simplesmente o PSD para o desenvolvedor e esperar que ele meça com uma régua os pixels que separam os elementos. Ele deve especificar textualmente as larguras, alturas e espaçamentos em um documento de especificação. Isso servirá como um manual que tanto ele quanto o desenvolvedor (e futuros profissionais envolvidos no projeto) deverão seguir.

Pelo menos, devem ser marcadas regras gerais para margins e paddings. Por exemplo, “todos os módulos devem ter um mínimo de 10 pixels de padding entre o conteúdo e a borda”.

Bronca 7: “O designer espera que eu adivinhe que estilos foram usados!”

O designer passa para o desenvolvedor um layout sem nenhuma especificação e espera que que ele identifique família de fontes, altura das linhas, cores, larguras, espaçamentos, bordas e margens. Por quê?

Ao contrário de criar um modelo no editor de imagens, desenvolvimento para web geralmente não é feito em um ambiente  WYSIWYG (“What You See Is What You Get). O programa de desenvolvimento pode até ter essa opção, mas o desenvolvedor vai preferir colocar a mão no código-fonte e ter o máximo de controle sobre a codificação gerada. O FrontPage deixou traumas incuráveis em toda uma geração de desenvolvedores… O desenvolvedor precisa de números, dados, valores.

Solução:

Este é um impasse mais complicado. Mesmo quando o designer utiliza um modelo com uma grade pré-definida, ainda assim o desenvolvedor frequentemente precisa extrair os outros estilos um a um. A solução ideal seria o designer criar um guia de estilo em forma de documento, que servirá como um manual para o desenvolvedor aplicar o layout do jeito desejado e reduzir a possibilidade de confusão ou “chutes”.

Bronca 8: “O desenvolvedor falou que vai demorar uma eternidade para ficar pronto”

O designer trabalhou até altas horas para completar o layout e cumprir sua parte no cronograma, apenas para ver o gerente de projeto passar o layout para o desenvolvedor e receber uma data de término para o futuro remoto, muito remoto. Por quê?

Designers podem passar por bloqueios criativos ocasionalmente, mas essencialmente sua ferramenta de trabalho é a tela em branco onde quase tudo é permitido. Desenvolvedores esbarram em impossibilidades, em desafios, em bugs que passam despercebidos, em técnicas que precisam ser pesquisadas etc. Seu trabalho envolve pesquisa, tentativa, erro, debugGoogle, e café, fartas doses de café.

Solução:

Desenvolvedores sabem que irão encontrar problemas pela frente e tendem a acrescentar uma dose de “gordura” nos prazos para garantir. O projeto pode ficar pronto bem antes, se nada der errado no caminho. Ou bem depois, se muita, muita coisa der errado. É importante perceber que ambos são profissionais e ambos estão dispostos a trabalhar até altas horas para completar sua parte.

Pode ser meio frustrante ter que aguardar pelo resultado final, mas o designer deve manter em mente que é bem possível que o desenvolvedor tenha ficado esperando e matutando: “cadê o designer que não termina esse layout logo?”.