7 mitos do desenvolvimento de e-mail

O e-mail começou como um método de comunicação 1: 1 somente de texto em 1971, quando foi concebido por Ray Tomlinson. Ao longo das décadas, o e-mail evoluiu, mudando das versões somente texto dos primeiros e-mails para HTML. Empurrando o e-mail para o futuro estão os desenvolvedores de e-mail, usando técnicas criativas dentro de limites estritos.

Naquela época, os desenvolvedores de e-mail criaram todos os tipos de “melhores práticas” para ajudar outros a começar a codificação de e-mail ou para atuar como lembretes para aqueles que estão nas trincheiras do que os desenvolvedores de e-mail podem ou não fazer.

Estamos aqui hoje para lembrar aos desenvolvedores de e-mail que as melhores práticas não devem ser vistas como estáticas. Eles mudaram. O que era melhor para os desenvolvedores de e-mail no final da década de 1990 não parecia mais verdade em meados da década de 2010.

Aqui estão sete mitos de desenvolvimento de e-mail que existem há muito tempo e por que é hora de finalmente colocá-los para descansar:

• Mito nº 1: os e-mails devem ter 600 pixels de largura.
• Mito 2: você deve usar apenas fontes padrão do sistema.
• Mito # 3: Use apenas o DOCTYPE de transição.
• Mito nº 4: os seletores de atributos precisam ser usados.
• Mito 5: Todos os estilos em e-mails devem ser incorporados.
• Mito nº 6: Não use imagens de plano de fundo em e-mails.
• Mito nº 7: Os e-mails devem ser idênticos em todos os clientes de e-mail.

Mito nº 1: os e-mails devem ter 600 pixels de largura.

Antes que os telefones celulares e tablets se tornassem comuns e o e-mail fosse apenas um aplicativo de desktop, a prática recomendada ditava que todos os e-mails não deveriam ser mais largos ou estreitos que 600 pixels. Por que exatamente 600 pixels? O tamanho da janela de visualização dos clientes de e-mail mais comumente usados ​​naquela época (HoTMaiL, Yahoo e Outlook) era de cerca de 500-550 pixels. Definir a largura do e-mail como não maior que 600 pixels permitiria a menor rolagem horizontal possível no e-mail.

Essa regra de 600 pixels permaneceu. Mesmo que hoje haja mais dispositivos para atender, todos com tamanhos de tela variados, por que seguimos a regra dos 600 pixels?

É uma regra fácil de seguir, especialmente se seu fluxo de trabalho de email inclui a criação de um design no Adobe Photoshop ou Sketch - você precisa de uma largura física para iniciar o design de seu email. É verdade que um e-mail com 600 pixels de largura ainda será exibido muito bem entre os clientes de e-mail mais populares, em desktops. E usando consultas de mídia, os desenvolvedores de e-mail podem facilmente alterar a largura do e-mail, dependendo do dispositivo que os assinantes usam para abrir.

A largura fluida resolve o problema do grande número de dispositivos que os desenvolvedores de e-mail precisam suportar. Para fazer isso funcionar, use max-width para impedir que os e-mails fiquem muito largos e ilegíveis em janelas de exibição maiores, e instruções condicionais MSO para fazer o Outlook entender (pois não renderiza a propriedade CSS max-width).

Os e-mails de Zalando têm 450 pixels de largura - muito longe do padrão de 600 pixels que estamos acostumados a ver. Combinado com grandes CTAs, parece que os e-mails compatíveis com dispositivos móveis do Zalando atendem mais ao público móvel.

Enquanto isso, os e-mails da Email Weekly empregam a técnica fluida, com largura máxima de 960 pixels. Ele usa consultas de mídia para alterar normalmente a largura do e-mail, dependendo da largura do dispositivo.

Dependendo dos clientes e dispositivos que seus assinantes usam para abrir seu e-mail, pode fazer sentido definir a largura de seu e-mail para um máximo diferente de 600 pixels.

Onde seus assinantes estão abrindo seus e-mails? Com Email Analytics você pode descobrir em quais dispositivos e clientes de e-mail eles estão abrindo seus e-mails. Saiba mais →

Mito 2: você deve usar apenas fontes padrão do sistema.

As fontes do sistema são há muito tempo a opção segura para uso em e-mail. Bem, eles têm sido a única opção.

Por outro lado, os web designers têm experimentado o uso de fontes não padrão na web desde o início dos anos 2000. Em 2008, o CSS rule @ font-face finalmente teve o suporte de navegadores da web para web designers usarem fontes não padrão em seus sites. Em 2010, o Google lançou sua própria biblioteca de fontes da web, gratuita para os designers da web usarem.

Os designers de e-mail não tiveram essa sorte devido à falta de um método sólido para importar as fontes da web para um e-mail em HTML. Sem mencionar a falta de licenciamento: quando as fontes da web foram criadas pela primeira vez, ninguém pensou que elas seriam usadas em e-mails, então o licenciamento das fontes da web não abrangia o uso de e-mail.

Embora recomendemos fontes de sistema padrão em seus e-mails, isso não significa que você não pode empregar fontes da web como uma técnica de aprimoramento progressivo. Os repositórios de fontes online estão começando a cobrir o uso de e-mail em seu licenciamento. E o Google Fonts, com suas 800 fontes da web gratuitas, agora está se tornando a biblioteca de referência para designers de e-mail que desejam usar fontes da web fora do padrão em seus e-mails.

O suporte para fontes da web existe no Google Android 4.4, Apple Mail para iPhone, iPad e Mac e Outlook 2011 e 2016 no OS X. Isso pode não parecer muito, mas em setembro deste ano quatro dos cinco principais clientes de e-mail , em participação de mercado, oferece suporte a fontes da web - iPhone, iPad, Google Android e Apple Mail. Isso é mais de 50% de todos os e-mails abertos em setembro! Claro, você precisa olhar para sua própria base de assinantes, mas este é um bom indicador de quantas pessoas serão capazes de ver as fontes da web em seus e-mails.

Você pode ver as diferenças sutis entre esses dois e-mails? O da esquerda está usando fontes da web, enquanto o da direita está com as fontes da web desativadas. O Outnet escolheu uma ótima fonte alternativa que é muito parecida com a sua fonte da web, mostrando como você pode usar fontes da web de forma consistente em seu e-mail hoje.

Mito # 3: Use apenas o DOCTYPE de transição.

O DOCTYPE de um documento HTML informa ao navegador como renderizar a página e é usado para validar o HTML do documento.

O DOCTYPE mais comumente usado em e-mail é:

 <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional //EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

Os desenvolvedores de e-mail adquiriram o bom hábito de ter um DOCTYPE, embora alguns clientes de e-mail retirem o DOCTYPE completamente ou o substituam por um diferente. Gmail, Outlook.com e Yahoo! Mail está entre os clientes de e-mail que eliminam qualquer DOCTYPE presente em seu e-mail e o substituem por HTML5 DOCTYPE.

Na web, diferentes DOCTYPEs alteram a forma como algumas propriedades CSS e elementos HTML são renderizados. O DOCTYPE acima permite a mais ampla variedade de elementos HTML, incluindo elementos obsoletos como <font>, que foram usados ​​em e-mail. Em testes anteriores, este DOCTYPE provou ser o mais confiável para e-mail. FOI comprovado - tempo passado.

Isso foi antes de HTML5 se tornar o padrão que é agora:

 <!DOCTYPE html>

O HTML5 DOCTYPE permite o uso de elementos HTML5 mais novos, por exemplo <video>, que podem ser usados ​​em e-mail. Embora nem todos os clientes possam renderizar os novos elementos ou propriedades, não há razão para não levar seu e-mail para o futuro atualizando seu DOCTYPE. Você ainda pode usar código obsoleto com um DOCTYPE HTML5, mas o código não será mais válido quando verificado por meio de um serviço de validação. Embora não haja impacto em seu e-mail em termos de capacidade de entrega ou desempenho se seu código for válido ou não, pode ser uma boa ideia verificar se há tags HTML abertas em sua marcação HTML, o que pode afetar como seu e-mail é processado.

Mito nº 4: os seletores de atributos precisam ser usados.

Yahoo! O Mail tem sido um cliente de e-mail ligeiramente mais amável de desenvolver do que, digamos, o Outlook. Suportou estilo na cabeça desde que nos lembramos. Uma peculiaridade do Yahoo! Mail ofereceu foi que renderizou qualquer instrução CSS em uma consulta de mídia ao lado de qualquer CSS fora das consultas de mídia. A solução simples para isso era escrever a instrução CSS como um seletor de atributo:

 *[class=”foo”] {color:#000000; font-family: sans-serif;}

Escrever CSS na cabeça de e-mails como esse se tornou o padrão, pois outros clientes de e-mail, que também lêem estilo na cabeça, não tiveram problemas para ler seletores de atributos simples, como o exemplo acima.

No início de 2015, o Yahoo! O Mail lançou uma atualização que o habilitou a ler o estilo como qualquer cliente de e-mail “normal” faria:

 .foo {color:#000000; font-family: sans-serif;}

No entanto, como os seletores de atributo eram tão arraigados no desenvolvimento de e-mail, não era surpreendente vê-los ainda mexendo no código de e-mail. Os desenvolvedores de e-mail estavam simplesmente acostumados a usá-los e, muitas vezes, os modelos de e-mail não eram atualizados.

Antes inofensivos, os seletores de atributo agora podem causar um pouco de dano ao seu e-mail, se você os tiver em seu código. Se o estilo do seu e-mail não parece estar funcionando no Gmail, verifique se você ainda está usando seletores de atributo no seu estilo. O Gmail não oferece suporte a seletores de atributos, mas agora (finalmente!) Oferece suporte a estilo no <head>.

Com os seletores de atributo não mais necessários para o Yahoo! Mail e a falta de suporte do Gmail para eles, não há necessidade de usar seletores de atributos no CSS em seus e-mails.

Mito 5: Todos os estilos em e-mails devem ser incorporados.

As tabelas para layout e estilos inlining têm sido a base do desenvolvimento de e-mail desde ... para sempre. Eles definem a diferença entre e-mail e desenvolvimento web. Estilos embutidos agora são tão comuns para desenvolvedores de e-mail que ficou um pouco confuso o motivo de os estilos terem que ser embutidos em primeiro lugar.

Surpreendentemente, alguns sites afirmam que a razão pela qual os estilos embutidos são necessários é o Outlook e o Gmail. O que é simplesmente errado. [Tweet isto]

O Outlook nunca teve problemas com o estilo no cabeçalho do e-mail. Por outro lado, o Gmail sim. O Gmail foi literalmente o maior motivo (com uma participação de mercado de 16% em setembro de 2016) para os desenvolvedores de e-mail embutirem seus CSS.

No final de setembro, o Gmail começou a oferecer suporte a estilo na cabeça. Então, precisamos mais embutir todos os estilos?

Se seus assinantes usam principalmente Gmail, iOS ou até mesmo Outlook, podemos dizer com segurança que agora é a hora de mover seus estilos para a cabeça. No entanto, se a maioria dos seus assinantes usa clientes de email obscuros ou clientes de email internacionais (Yandex, Libero, Terra) que dependem de estilos inline, você pode ter que continuar a usá-los. Como sempre, recomendamos que você teste seu e-mail sempre que fizer alterações importantes nele.

Mito nº 6: Não use imagens de plano de fundo em e-mails.

As imagens de plano de fundo são notoriamente difíceis de obter diretamente no e-mail. Os desenvolvedores de e-mail usam código VML complicado para renderizar em muitas versões do Outlook, e também tem havido uma falta de suporte para imagens de fundo em outros clientes de e-mail.

O negócio é o seguinte: as imagens de fundo podem funcionar e funcionam no e-mail, mas é assim que são incorporadas ao design do seu e-mail. Com suporte limitado, você não deve usar imagens de plano de fundo como um elemento-chave no design de seu e-mail, porque isso faz ou quebra a experiência de seu assinante. Mas você pode usá-los em seu e-mail da mesma forma que usaria fontes da web - como um aprimoramento progressivo.

Um dos maiores motivos para não usar imagens de fundo no e-mail foi a falta de suporte do Gmail para as propriedades de CSS background-size e background-position. Essas propriedades CSS são importantes para telas de alta densidade de pixel e e-mail híbrido / fluido / responsivo, onde uma certa quantidade de controle precisa ser colocada sobre como as imagens de fundo são dimensionadas e colocadas. Ambos agora são compatíveis com o Gmail e o Inbox by Gmail, então há ainda menos razão para não tentar usar imagens de plano de fundo em e-mails.

Kristian Robinson, desenvolvedor-chefe de e-mail da TWO Digital marketing e palestrante da The Email Design Conference 2016, se aprofunda nas imagens de fundo do e-mail, se estiver se sentindo inspirado para enfrentá-las.

Mito nº 7: Os e-mails devem ser idênticos em todos os clientes de e-mail.

Todos os clientes de e-mail têm maneiras ligeiramente diferentes de processar e-mails em HTML. Em vez de aceitar isso, os desenvolvedores de e-mail tentaram hackear e-mails idênticos em uma infinidade de clientes de e-mail. Uma tarefa muito honrosa de realizar, mas pode resultar em código HTML inchado e hackeado, o que pode ser um pesadelo de gerenciar e manter atualizado.

Pode não ser o desenvolvedor de email em busca da perfeição de email, mas o cliente ou outras partes interessadas. No entanto, é responsabilidade do desenvolvedor de e-mail educar as pessoas ao seu redor para entender as armadilhas do desenvolvimento de e-mail - por que os clientes de e-mail são renderizados de maneira diferente e por que não importa se algo está 1 pixel a mais em um cliente de e-mail em comparação com outro.

"O tempo em que os e-mails tinham que ser perfeitos como pixels ficou para trás." @ericlepetitsf #LitmusLive

- Chad S. White (@chadswhite) 16 de agosto de 2016

Esse mito é especialmente prejudicial quando se tenta empregar novas técnicas em e-mail, que podem não ser processadas em 100% dos clientes de e-mail, por exemplo, fontes da web e imagens de fundo. Ambos são maneiras fantásticas de aprimorar seu e-mail. E onde estaríamos como indústria se não tentássemos adotar e experimentar novas técnicas em nossos e-mails?

Só porque algo foi feito de uma maneira particular durante anos, não significa que não haja melhor maneira de fazer isso. Agora é a hora de questionar as regras e melhores práticas com as quais a indústria de marketing por e-mail vem trabalhando há décadas.

Codifique e-mails mais rápido e mais fácil com o Builder

Acelere seu fluxo de trabalho de desenvolvimento de e-mail com Builder, o único editor de código construído especificamente para e-mail. E é grátis!

Comece a usar o Builder →