Designers e Developers podem ser amigos
Um estudo de caso que mostra porque TI e Design não precisam ser inimigos e porque boas práticas e soluções não precisam ser sempre too techy.
A comunicação entre as equipes de comunicação e TI é importantíssima em empresas das mais variadas áreas. Meu background é em portais de conteúdo e e-commerce, mas tenho certeza que isto pode se aplicar para qualquer empresa.
A utilização de tecnologias que facilitam o desenvolvimento Front-End é fundamental e os desenvolvedores já se acostumaram — e não conseguem viver sem — às linguagens, frameworks, compiladores e transpiladores que agilizam o tempo de codificação.
Apenas para citar algumas opções disponíveis atualmente, temos os task e build runners (Gulp a Grunt, por exemplo), pré-processadores de HTML, JavaScript e CSS (CoffeeScript, Haml, Jade, LESS, Sass etc.), sem falar em ferramentas que possibilitam trazer o futuro para o hoje, como Babel ou até fazer uma salada de linguagens em prol de velocidade e facilidade de manutenção (ReactJS e sua inovadora sintaxe JSX).
Estes temas são comuns aos desenvolvedores, mas e quando existe um departamento na sala do lado que é responsável apenas pelo visual? O time de Design/Marketing/Comunicação precisa ter a velocidade de lançar novas campanhas sem depender da atuação de TI. Eles são craques em criatividade, HTML e CSS, mas o pessoal de TI utilizou LESS ou Sass para definir toda a arquitetura de interfaces, repleta de variáveis, funções e mixins.
O que fazer? Ensinar Node.JS para o pessoal que prefere usar mais o lado direito do cérebro? É claro que sempre haverá aquele designer que gosta de aprender código e aquele codificador que curte “brincar” com UI, mas estes são exceção. Em minha opinião, é função de quem provê as soluções técnicas facilitar a vida de quem é responsável pelas soluções criativas.
Meu caso de estudo é um cenário interessante. A tecnologia é .NET, ou seja, estações de desenvolvimento Windows com Visual Studio, servidores IIS… Como não abro mão do meu MacBook, utilizo Parallels. Assim como eu, os designers do time de marketing também usam Mac. Isto significa que teremos de instalar Parallels, Visual Studio, SQL Server na máquina de cada designer? Estranho, certo?
Isto já seria o suficiente para começar um tumulto (risos).
A solução aqui foi utilizarmos um ambiente compartilhado em que os designers têm acesso ao sistema de arquivos e podem alterar os HTML e CSS que desejarem. Ou seja, em seus MacOS eles acessam este servidor Windows pelo protocolo Samba (SMB/CIFS) e têm acesso aos arquivos do projeto Web da aplicação.
Mas o seu framework usa LESS!
Já decidimos que eles não precisam aprender Node.JS. Mas queremos que eles tenham acesso às facilidades oferecidas pelo pré-processador de CSS. O primeiro passo foi criar uma estrutura de arquivos LESS e iniciar o diálogo:
- Só mudou a extensão de .CSS para .LESS. O resto é igual :)
- Como igual? Acabei de salvar o arquivo .LESS, atualizei a página e não vi as alterações!
Agora tenho duas opções. A trivial é pedir que ele rode o compilador, seja pelo binário do LESS compiler ou usando Gulp, por exemplo. Mas aí o designer já poderia criar certa aversão por ser algo um pouco mais técnico.
Antes de facilitar a vida do designer, bato um papo com uma listinha dos benefícios de seguirmos este approach:
- Desta forma todo o sistema utilizará a mesma arquitetura de interfaces.
- As definições de estilos são compartilhadas.
- Poderemos criar com agilidade temas específicos para campanhas.
- Vocês poderão abandonar 95% do copy and paste de CSS.
Depois deste bate-papo, percebo que ganhei o designer de volta. A cereja do bolo vem com minha persistência e meu altruísmo (risos). Quero facilitar ainda mais a vida dos designers. Criar um serviço no Windows que rode automaticamente sempre que a máquina for iniciada e que executa minha task de Gulp.watch, por exemplo. Desta forma, o designer vai criar o arquivo .less e, assim que salvar, verá as atualizações refletidas no navegador.
- Agora você trabalha com LESS como se estivesse trabalhando com CSS!
- Awesome!
Como fiz isso?
Finalmente uma linha de código (risos). Veja que simples:
nssm.exe install watch-less “C:\Program Files\nodejs\node.exe” ..\..\InfoPages\run-gulp-watch.js
nssm.exe (Non-Sucking Service Manager)
Tem um ótimo nome esta ferramenta. Basicamente, cria serviços no Windows que podem executar qualquer coisa. No nosso caso, vai rodar o NodeJS e chamar uma Gulp task que roda o Gulp.watch.
install
É o comando enviado ao NSSM (“instale este serviço no Windows, por favor”).
watch-less
O nome do serviço que quero criar. Pode ser qualquer nome.
“C:\Program Files\nodejs\node.exe”
O caminho absoluto até o NodeJS.
..\..\marketing-pages\run-gulp-watch.js
O caminho relativo até o JavaScript que será executado pelo NodeJS.
Ao executar esta única linha, verá que o serviço será adicionado ao Windows. Simples assim. O conteúdo do run-gulp-watch.js é bem simples também. Veja:
var gulp = require(“gulp”);
require(“./gulpfile.js”);
gulp.start(“watch-less”);
Uma boa interação entre times distintos facilita muito o trabalho da empresa como um todo. O departamento de Marketing terá facilidades no dia a dia e agilidade na entrega das campanhas e o departamento de TI terá a satisfação de ver uma arquitetura de UI seguida e compartilhada ;)
E todos ficarão felizes!
PS: Este foi realmente um simples exemplo de como equipes podem trabalhar em conjunto para atingir sempre os melhores resultados. Existem detalhes técnicos nesta solução que não mencionei aqui mas terei o maior prazer em compartilhá-los caso tenha interesse ;)
