Tableless

Busca Menu

Email Marketing – Testes e CSS Inliner – Parte 2

Seja o primeiro a comentar por

Não é só porque você precisa fazer seus emails utilizando tabelas, 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 email ser publicado e muito provavelmente vai precisar duplicá-lo quando alguém ter a necessidade de enviar novos emails.

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 email (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 email 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 email marketing, aceitando apenas o atributo style diretamente nos elementos.

O problema é que 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 emails precisa ser muito parecido com o desenvolvimento em ambientes normais, usando um CSS externo, provavelmente dividido por módulos e etc. Embora o HTML fique um horror de fazer manutenção por causa das tabelas, o CSS é a parte onde 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. O HTML final você não vai se preocupar, 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.

Estas ferramentas já te ajudam um bocado. Mas ainda não é o fluxo ideal. Se você tem 10 emails para fazer, sua produtividade já fica prejudicada com estes serviços. Por isso eu passei a usar um plugin de Gulp no build local dos emails 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 emails com o código direto no atributo style dos emails. 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 emails. O problema é que embora você consiga produzir código rapidamente, você vai precisar testar esse layout e você não poderá fazer isso o tempo inteiro olhando para seu browser comum. Os usuários verão isso em diversos clientes de email 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 email marketing que surgiu em 2005. Além de testar seus emails, 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 email e ele mostra como o layout fica em praticamente todos os clientes de email do mercado, inclusive nos clientes mobile.

Além disso, você consegue criar ou modificar o código do seu email 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 email do mercado.

litmus-editor

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

litmus-interactive-testing

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

Email bom é email em Plain Text. Não escondo isso de ninguém. Quando fazemos emails, voltar a trabalhar como nos tempos antigos e isso não é bom. Você precis alinhar muito bem as expectativas do designer, precisa testar muito bem cada cliente de email 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 )

Publicado no dia