HTML e e-mail: 6 erros comuns que você deve evitar

Criando e-mail com código HTML? Aqui estão 6 erros muito frequentes que você deve evitar, a fim de colher os benefícios de comunicações por e-mail simplificadas e limpas.

Erro 1. Usando código excessivamente detalhado

Sabemos que graças ao HTML e CSS podemos construir uma estrutura de e-mail e dar-lhe uma forma, ou melhor, um formato, que permite mostrar um determinado tipo de fonte, uma cor de fundo específica, imagens, etc.

Agora veremos como as tags HTML e CSS realizam a mesma função em alguns aspectos e acabam se sobrepondo. Vamos dar um exemplo prático: definir a cor de fundo de uma tabela tanto em HTML quanto em CSS.

O código é mostrado na imagem. Você pode ver que há dois pontos onde a cor de fundo é definida:

• bgcolor = “# e75c00” é o atributo da tabela de tags;
• background-color é o atributo CSS aplicado à tabela.

Ambos os atributos fazem a mesma coisa e, portanto, se sobrepõem: impõem a cor laranja (# e75c00 de acordo com o formato hexadecimal) no fundo da tabela.

O ponto crítico agora deve ser mais claro: as definições de propriedade HTML e CSS podem se acumular. Na verdade, ao retrabalhar ou variar o mesmo modelo de e-mail, o código pode muitas vezes ficar atolado por propriedades redundantes que executam a mesma função.

E isso não é tudo. Uma vez que os estilos embutidos podem ser aplicados a cada elemento, este caso (perverso) também pode ocorrer:

Um navegador (ou cliente de e-mail) leria o código mais ou menos assim:

• Aplique um fundo cinza ( bgcolor = “#efefef” ) à tabela
• Dez aplicam um fundo preto ( bgcolor = “# 000000” ) à linha
• Por fim, aplique um fundo laranja ( cor de fundo: # e75c00 ) à célula que contém o texto Hello World!

O resultado final é idêntico neste exemplo e no anterior: texto branco em um fundo laranja.

O problema é que três regras de fundo diferentes foram definidas no segundo caso. O visto pelo usuário é aquele definido em relação à célula, pois o navegador lê o código sequencialmente (tabela -> tr -> td). Como a última definição foi definida em <td> , é exatamente isso que será exibido.

É claro que muito do código não é necessário. Isso não ocorre apenas porque a única cor de fundo exibida é aquela aplicada ao celular, mas também porque um dos objetivos do bom e-mail marketing é manter a comunicação o mais leve possível. Um código redundante e muito detalhado não é um código leve.

Nossas recomendações:

• Mantenha o código o mais limpo possível
• Evite repetições desnecessárias ao formatar o código
• Dê preferência a estilos embutidos
• Tente construir uma estrutura modular para o código de comunicação
• Tente manter o código o mais ordenado possível através do recuo (existem vários serviços online que fazem isso, como HTMLformatter ou Clean CSS), para poder ter uma visão geral da estrutura da comunicação
• Acompanhe o histórico de alterações macro feitas em um modelo

Erro 2. Comentando excessivamente o código

Como na maioria dos idiomas, também é possível adicionar comentários ao HTML. O que é um comentário em um script HTML? É uma parte da listagem que é ignorada pelo programa que lê e executa o código.

Um exemplo de comentário é dado na figura abaixo:

Como você pode ver, tudo entre <! - e -> não é apenas uma cor diferente (dependendo do programa de edição), mais significativamente, não é exibido na tela.

Isso permite que “comunicações de serviço” sejam inseridas sobre o código que foi escrito, ou instruções para peças que ainda não foram concluídas ou que precisam ser melhoradas.

Também existe outra maneira de usar comentários. Como tudo o que está incluído entre os marcadores de abertura e fechamento não é mostrado, é possível ocultar partes inteiras da página com ele, conforme mostrado no exemplo a seguir. Na verdade, podemos ver que apenas três linhas são visíveis na tela, em vez das quatro que estão escritas no código.

É uma ferramenta útil, é claro, mas não devemos abusar dela. Embora seja verdade que o código comentado não é mostrado, ele permanece na comunicação enviada, pesando-o.

Nosso conselho:

• Use os comentários com sabedoria, por exemplo, para indicar o início e o fim das estruturas de comunicação, ou para inserir informações úteis para o desenvolvedor
• Não se prolongue nos comentários e, melhor ainda, escreva-os em inglês
• Exclua o código comentado antes de enviar, pois não é necessário para fins de comunicação

Erro 3. Gerenciamento incorreto de conteúdo de e-mail

Ao projetar um e-mail, antes mesmo de escrever uma única linha de código, é bom definir alguns parâmetros que não podem ser modificados na fase de realização posterior e, conseqüentemente, durante a produção.

Alguns desses parâmetros incluem:

• Largura do email
• Tamanho da imagem
• Número de imagens
• Tamanho da fonte usado no cabeçalho
• Tamanho da fonte da cópia do corpo

E assim por diante. Um parâmetro que geralmente é omitido é o do número máximo de pressionamentos de tecla para qualquer elemento de texto.

Neste ponto, você pode objetar que somos culpados de ser fanáticos com as regras, mas há duas boas razões para sermos tão rígidos. O primeiro é conceitual e o segundo operacional.

Em um nível conceitual, o conteúdo (texto, imagens, etc.) e o contêiner (estrutura HTML) são duas entidades separadas com uma hierarquia muito precisa que vê o primeiro subordinado ao segundo.

Na verdade, o conteúdo deve ser adaptado ao contêiner, e não vice-versa. A arquitetura da comunicação é construída ao escrever o código. Isso define o contêiner e, uma vez formado, o contêiner permanece assim, independentemente do conteúdo, mesmo que o e-mail tenha sido criado para ser responsivo.

Resumindo - parafraseando Bruce Lee - o conteúdo é como água: se você colocar água em um copo, ela se torna o copo; se você colocar água em uma garrafa, ela se tornará a garrafa; se você colocar água em um bule, ela se tornará o bule.

Você não pode esperar que uma xícara se transforme em uma garrafa, e um bule nunca será uma xícara. Portanto, o texto (ou imagem ou botão) deve se adaptar à estrutura que o contém, e não o contrário.

A segunda razão é mais operacional. Se todos os parâmetros para compor a comunicação forem conhecidos exatamente a priori, então não só é possível criar comunicações mais eficazes durante a fase de redação, mas também comunicações mais equilibradas.

Vamos dar um exemplo mais concreto: suponha que temos um DEM com dois produtos lado a lado. Um produto geralmente está associado a:

• Uma imagem
• O nome do produto
• A descrição do produto
• O preço
• O CTA que leva à página do produto

Agora, como os produtos estão lado a lado, as partes devem necessariamente estar balanceadas.

Isso significa que as imagens devem ter a mesma altura, os textos descritivos devem ter comprimento semelhante e os dois CTAs não devem ser muito diferentes.

Ignorar ou não respeitar esses princípios básicos pode levar a casos como o da imagem acima.

A simetria entre os dois elementos é quebrada porque o título do produto à esquerda é tão longo que cobre três linhas, enquanto o da direita é tão curto que preenche apenas uma linha. Uma discórdia foi introduzida, o que enfraquece toda a comunicação.

O cumprimento dessas regras torna-se ainda mais importante quando se pensa no mundo móvel, onde todos os vários dispositivos têm resoluções muito díspares: dos 1125 x 2436 px do iPhone X aos 1440 x 2960 px do Samsung Galaxy S8, passando pelo 768 x 1280 px do Microsoft Lumia 1020.

Quando essa enorme diversidade se sobrepõe à densa selva de clientes de e-mail, isso significa que não temos controle total da exibição do DEM, porque não existe um código definitivo que se adapte aos pixels em todos os casos. Portanto, se você não pode controlá-lo via código, deve tentar fazê-lo indiretamente, alterando as outras partes que compõem um e-mail, como o comprimento dos textos ou o tamanho das imagens.

Nossas recomendações:

• Defina todas as partes do modelo
• Mantenha a consistência entre as diferentes partes da comunicação
• Respeite as regras que você se deu
• As regras podem ser quebradas, mas isso deve ser feito com total consciência
• Se o modelo não atender às suas necessidades, você pode começar a pensar em definir um novo

Erro 4. Obtendo números de telefone e endereços interativos errados

Às vezes, os remetentes de e-mail adicionam suas informações de contato, especialmente no rodapé. Isso geralmente inclui um endereço e um número de telefone.

Embora um número de telefone e endereço possam ser informações padrão para e-mails de clientes de desktop, embora sejam raramente usados, esses elementos são particularmente importantes quando se trata do lado móvel.

Isso acontece principalmente por dois motivos:

• Você pode abrir um aplicativo que gerencia os dados com um clique (calendário, telefone, navegador)
• O espaço de exibição é reduzido, e como tal cada informação tem maior visibilidade, mesmo que localizada no rodapé

Portanto, é importante não esquecer também esses detalhes ao desenvolver a comunicação, pois seu comportamento varia entre os diferentes dispositivos.

Vamos tomar um momento para considerar o exemplo criado ad hoc por meio de uma simulação. Ambos os exemplos são exibidos pelo iPhone 6+ iOS 9.

A imagem à esquerda mostra a newsletter recebida pelo usuário com o texto inserido diretamente, sem nenhuma formatação.

Tudo está correto do ponto de vista técnico, mas devemos levar em consideração o fato de que o código é interpretado pelo próprio aplicativo de e-mail no celular. Ele “lê” o texto do e-mail e, ao reconhecer um texto na forma de data, endereço ou número de telefone, vincula automaticamente o link ativo ao respectivo aplicativo, ou seja, o Calendário, o Mapa ou o telefone.

Tudo isto é muito cómodo, pois com apenas um clique pode fazer uma chamada, agendar um evento ou abrir o mapa para definir um percurso. Os únicos que podem ficar tristes com isso são a arte e o desenvolvedor, que não gostam de ver os links em azul e o sublinhado. Então o que deveríamos fazer? Como devemos proceder?

Você pode usar uma pequena solução alternativa ou truque para fazer as coisas voltarem ao normal. Sejamos claros: embora quebrem as regras do HTML bem formatado, as soluções alternativas são indispensáveis ​​no vasto oceano de clientes de e-mail.

Se o objetivo principal de um desenvolvedor é tornar a comunicação visível para o maior número possível de clientes, ele precisa se comprometer e adotar as soluções alternativas.

Então, vamos ver como o código foi alterado.

Quando se trata de telefone, é simples: como o tag de âncora permite definir um número de telefone usando tel na propriedade href , adicionamos o número de telefone sem espaços ou linhas de separação.

Precisamos agir de maneira diferente para um endereço ou data, no entanto. Para isso, é necessário definir uma classe (.address) que imponha a tag âncora que irá inserir automaticamente a cor no cliente (color: #ffffff;). Acima de tudo, deve remover o sublinhado, que é uma característica padrão de cada link (decoração de texto: nenhum;).

Observe que ambos os atributos da classe de endereço têm ! Important , que deve ser aplicado pelo cliente independentemente da propriedade. Sem ele, não há garantia de que a solução alternativa fará seu trabalho.

Nossas recomendações:

• Sempre preste atenção em como a comunicação pode ser exibida em celulares (ou seja, fazendo testes)
• Sempre que possível, use micro-correções para tornar as comunicações compatíveis com dispositivos móveis
• Não presuma que o que é bom para desktop também é bom para celular
• Conheça o seu público: qual tecnologia eles usam? Quais dispositivos? Qual mídia?
• Use testes internos para experimentar suas próprias comunicações, especialmente quando há atualizações substanciais em aplicativos de cliente de e-mail

Erro 5. Não limpar tags abandonadas ou vazias

Continuando com o objetivo de tentar manter o peso geral da comunicação ao mínimo, precisamos prestar atenção às partes do código existente que foram esvaziadas de seu conteúdo natural.

Vamos dar um exemplo concreto imediatamente: uma tag <font> , talvez com uma série de estilos embutidos, que não contém nenhum texto. Obviamente, o lado do email não será capaz de ler nada, mas a tag de formatação <font> continua existindo e ocupando espaço físico no email.

Outro exemplo clássico são as <a> tags âncora que não têm objeto vinculado, então algo como: <a href=”http://www.mailup.com” style=”color:#00000;text-decoration:none”> </a>

Normalmente esses “erros” estão presentes naquele código que foi retrabalhado ou usado várias vezes, de forma que diferentes partes, como imagens, links e textos, foram inseridos, modificados ou excluídos. Como alternativa, pode ser uma indicação de uso incorreto de um editor WYSIWYG. Na verdade, se usados ​​de forma inadequada ou imprudente, esses editores têm o defeito de adicionar código ao código, já que todo elemento pré-definido normalmente tem uma parte do código definida a partir do momento em que o próprio editor foi criado.

O programa aplica o modelo de forma não crítica sempre que o elemento selecionado é inserido e, como resultado, esse problema pode surgir quando você reescreve a mesma parte do e-mail um número suficiente de vezes.

Nosso conselho:

• Ao escrever o código, sempre verifique se não há tags abandonadas ou vazias
• Se você usa um editor WYSIWYG e é possível acessar o código, faça uma verificação para garantir que tudo está em ordem e se não há nenhum desses tipos de erros

Erro 6. Usando HTML não validado

Falar sobre validação de código de e-mail é um tópico espinhoso.

“A maioria das páginas na World Wide Web é escrita em linguagens de computador (como HTML) que permitem aos autores da Web estruturar texto, adicionar conteúdo multimídia e especificar que aparência ou estilo o resultado deve ter.

Como acontece com todas as línguas, elas têm sua própria gramática , vocabulário e sintaxe , e todo documento escrito com essas linguagens de computador deve seguir essas regras. As linguagens (X) HTML, para todas as versões até XHTML 1.1, usam gramáticas legíveis por máquina chamadas DTDs, um mecanismo herdado do SGML.

No entanto, assim como os textos em uma linguagem natural podem incluir erros ortográficos ou gramaticais, os documentos que usam as linguagens de marcação podem (por vários motivos) não estar seguindo essas regras. O processo de verificar se um documento realmente segue as regras para os idiomas que usa é chamado de validação , e a ferramenta usada para isso é um validador. Um documento que passa com sucesso neste processo é denominado válido .

Com esses conceitos em mente, podemos definir “validação de marcação” como o processo de verificação de um documento da Web em relação à gramática (geralmente um DTD) que afirma estar usando ”.

Definizione W3C

O W3C nos ajuda como guardião e fiador do código, fornecendo uma ferramenta de validação de código cuja análise indica erros e sugere maneiras de corrigi-los. Graças a esta ferramenta, é possível identificar e corrigir erros estruturais maiores.

Vale lembrar que o Email Marketing tem uma situação dupla:

• Por um lado, HTML é uma linguagem padronizada com regras e estruturas muito precisas
• Por outro lado, uma série de soluções alternativas que não são padrão e muitas vezes são desaprovadas, mas que funcionam bem se você quiser ter uma visualização correta em clientes de e-mail

Esses dois aspectos são como um casal de idosos, onde a paixão há muito se esvaiu. Eles não sabem por que vivem juntos, mas são forçados a isso fazendo concessões.

Então, por que falar sobre validação de código? Isso faz sentido? Quais são os compromissos?

Faz sentido falar sobre validação de código quando ela é colocada em uma perspectiva mais ampla, sem entrar muito nos detalhes. Portanto, no que diz respeito à estrutura, aos módulos a partir dos quais o e-mail é composto e às tabelas que constituem a espinha dorsal da comunicação, faz todo o sentido ter um código tão limpo e próximo ao padrão ditado pelo W3C que possível.

Porém, temos que estar atentos à realidade, e por isso o compromisso consiste na criação de uma estrutura sólida e funcional, à qual as soluções alternativas se somam como uma espécie de sintonia fina para estender a visualização correta ao maior número de clientes possível.

Já sabemos que contornos nada mais são do que exceções à regra, ou seja, técnicas não perfeitamente ortodoxas, derivadas do conhecimento acumulado pela experiência, mas sua existência só faz sentido porque permitem que o código seja corretamente visualizado, sem qualquer despaginação.

Nosso conselho:

• Se você tiver dúvidas sobre o código, a validação pode servir como uma ferramenta rápida e eficaz de análise
• A validação de código pode ser uma boa ferramenta para identificar rapidamente os maiores erros em uma lista de códigos
• O código validado é sempre um excelente ponto de partida para posteriormente evoluir e adaptar a comunicação com soluções alternativas, para torná-lo o mais universal possível
• A validação pode ser vista como um "serviço" para o código, especialmente em modelos que têm sido frequentemente manipulados e retrabalhados
• Conforme você ganha experiência, construa uma pequena biblioteca de soluções ad hoc para vários clientes, a fim de economizar tempo na resolução de problemas