Este artigo é uma continuação deste.

***

Não é só porque você precisa fazer seus e-mails utilizando tabelas que você vai desdenhar das boas práticas que você aprendeu na escola. O código final de uma newsletter vai ficar muito maior e tão complexo quanto o código de um site institucional simples. Outro ponto importante é que você vai fazer muitas e muitas alterações até esse e-mail ser publicado e, muito provavelmente, vai precisar duplicá-lo quando alguém tiver a necessidade de enviar novos e-mails.

A estratégia que eu uso aqui é usar as tabelas como usamos os divs. As tabelas são necessárias e não tem por onde fugir. Isso já é um desconforto muito grande, por causa da quantidade de código gerada. Abaixo, seguem duas maneiras que uso aqui na Locaweb e nos projetos do Tableless.

CSS Inliner

Alguns clientes de e-mail (estou olhando pra você, Gmail) simplesmente ignoram a tag style no HEAD ou no BODY. Eu não os culpo: como você mostraria um layout dentro do seu próprio layout, sem que o CSS e o código desse layout pirata não quebrasse o layout do seu sistema? Esse é um desafio para galera dos clientes de e-mail baseados em web, como é o caso do Yahoo! Mail e do Gmail. Por isso, para acabar com o problema pela raiz, eles simplesmente estripam a tag style do HTML do e-mail marketing, aceitando apenas o atributo style diretamente nos elementos.

O problema é que, se o seu trabalho é fazer newsletters ou você faz muitas newsletters por semana, a necessidade de reutilizar código é importante. Por isso, o fluxo de desenvolvimento de e-mails precisa ser muito parecido com o desenvolvimento em ambientes normais, usando um CSS externo, provavelmente dividido por módulos etc. Embora o HTML fique um horror de fazer manutenção por causa das tabelas, o CSS é a parte na qual você vai passar mais tempo, por isso precisa ser o lugar mais organizado.

Para resolver esse problema, existem serviços online que pegam seu código CSS externo e colocam diretamente nas tags do seu HTML. Dependendo do seu layout, o HTML final vai ficar um horror, mas isso não importa aqui. Você não vai se preocupar com o HTML final, porque a utilidade dele é simplesmente ser bem renderizado nos clientes.

Existem três serviços que fazem a mesma coisa: o Inliner do PutsMail, o CSS Inliner Tool do MailChimp e o Inliner do Campaing Monitor.

Essas ferramentas já te ajudam um bocado. Mas ainda não é o fluxo ideal. Se você tem 10 e-mails para fazer, sua produtividade já fica prejudicada com esses serviços. Por isso, eu passei a usar um plugin de Gulp no build local dos e-mails para fazer esse trabalho: é o Gulp Inline CSS.

Se você prefere Grunt, tem um plugin que faz a mesma coisa, chamado Grunt Inline CSS. O problema é que, até a escrita deste artigo, esse plugin dependia de outro chamado Juice, que faz a mágica por baixo dos panos, mas que estava dando uns paus loucos no Mac. Se você tiver paciência para testar, existem vários outros lá no NPM.

Como usamos o Middleman aqui, coloquei pra chamar a task do Gulp para ser executada depois do build do Middleman, e pronto! O Build já me devolve os e-mails com o código direto no atributo style dos e-mails. Para comparar, o código de desenvolvimento fica assim:

    <table cellpadding="10">
        <tr>
            <td class="lw-text">
     
                <h3><strong>O período de teste está chegando ao fim!</strong></h3>
     
                <p>Olá </p>
     
                <p>Não perca tempo e mantenha o seu site no ar agora mesmo com 10% de desconto no primeiro mês. </p>
     
                <br>
                    <center>
                        <a href="###"><img alt="Quero manter meu site" src="2014-11-21-c.png"></a>
                    </center>
     
            </td>
        </tr>
    </table>

E o código buildado fica assim:

    <table class="lw-wrapper" bgcolor="#e7e2dc" style="background-color: #e7e2dc; font-family: arial, helvetica, sans-serif; padding: 20px; width: 100%;">
    <tr>
        <td>
     
            <table align="center" class="lw-container" style="background-color: #fff; border: none; border-collapse: collapse; margin: 0 auto; width: 630px;" bgcolor="#ffffff">
                <tr>
                    <td class="lw-content" style="background-color: #fff; margin: 0 auto; width: 630px;">
                            <img src="2014-11-21-5.jpg" style="border: none; text-decoration: none;" width="630">
     
                            <table cellpadding="10">
        <tr>
            <td class="lw-text" style="margin: 0 20px;">
     
                <h3><strong>O período de teste está chegando ao fim!</strong></h3>
     
                <p style="font-family: arial, helvetica, sans-serif; font-size: 14px;">Olá </p>
     
                <p style="font-family: arial, helvetica, sans-serif; font-size: 14px;">Não perca tempo e mantenha o seu site no ar agora mesmo com 10% de desconto no primeiro mês. </p>
     
                <br>
                    <center>
                        <a href="###"><img alt="Quero manter meu site" src="2014-11-21-c.png"></a>
                    </center>
     
            </td>
        </tr>
    </table>

Além disso tudo, nós usamos SASS para escrever o CSS. Lembre-se: a ideia é tentar ganhar velocidade no desenvolvimento, aproximando o ambiente que você está acostumado para a criação de e-mails. O problema é que, embora você consiga produzir código rapidamente, você vai precisar testar esse layout, e não poderá fazer isso o tempo inteiro olhando para seu browser comum. Os usuários verão isso em diversos clientes de e-mail, e você precisa testar nesses clientes. É aí que entra outra ferramenta: Litmus.

Testando com o Litmus

O Litmus é um ambiente de testes e análise de e-mail marketing que surgiu em 2005. Além de testar seus e-mails, você consegue ter uma série de informações sobre taxa de abertura, forwards, deleções e outras análises. Basicamente o que os outros caras do mercado fazem, ele faz também. O grande diferencial dele é que você consegue submeter o código do seu e-mail e ele mostra como o layout fica em praticamente todos os clientes de e-mail do mercado, inclusive nos clientes mobile.

Além disso, você consegue criar ou modificar o código do seu e-mail diretamente pelo sistema deles, facilitando MUITO a adequação do código, principalmente porque eles tem um syntax checker que verifica se você está usando alguma regra que não funciona nos clientes de e-mail do mercado.

Há uma feature chamada Interactive Testing. Esse negócio se conecta a uma máquina virtual com o seu layout aberto no cliente de e-mail e um lugar para você modificar seu código. Quando você muda alguma coisa no código, ele muda no cliente de e-mail! Pensa na utilidade desse negócio.

PutsMail

O PutsMail é um sisteminha de testes avulso. Ele é muito fácil de usar e nem precisa de cadastro. Basta jogar seu código no campo e mandar testar. Ele foi desenvolvido por um cara chamado Pablo Cantero, aí o Litmus comprou o sistema dele em 2014 e continuou o desenvolvimento.

Concluindo

E-mail bom é e-mail em Plain Text. Não escondo isso de ninguém. Quando fazemos e-mails, voltamos a trabalhar como nos tempos antigos, e isso não é bom. Você precisa alinhar muito bem as expectativas do designer, precisa testar muito bem cada cliente de e-mail importante, precisa escrever código ruim para que funcione em todo lugar. Mas não é impossível. Com a experiência e as ferramentas que surgiram nos últimos anos, conseguimos passar pelo vale da sombra e da morte mais facilmente. Mas ainda assim nos machucamos bastante (ó, fiz até um final filosófico! ;-D ).