HTML și e-mail: 6 greșeli frecvente pe care ar trebui să le evitați

Creați e-mail cu cod HTML? Iată 6 greșeli prea frecvente pe care ar trebui să le evitați, pentru a beneficia de avantajele comunicării e-mail raționalizate și curate.

Eroare 1. Utilizarea unui cod prea pronunțat

Știm că datorită HTML și CSS putem construi o structură de e-mail și îi putem oferi o formă, sau mai degrabă un format, care să facă posibilă afișarea unui anumit tip de font, o anumită culoare de fundal, imagini și așa mai departe.

Acum vom vedea cum ambele etichete HTML și CSS îndeplinesc aceeași funcție în anumite privințe și ajung să se suprapună. Să luăm un exemplu practic: definirea culorii de fundal pentru un tabel atât în ​​HTML, cât și în CSS.

Codul este afișat în imagine. Puteți vedea că există două puncte în care este definită culoarea de fundal:

• bgcolor = „#e75c00” este atributul tabelului de etichete;
• background-color este atributul CSS aplicat tabelului.

Ambele atribute fac același lucru și astfel se suprapun: impun culoarea portocalie (#e75c00 conform formatului hexazecimal) pe fundalul tabelului.

Punctul critic ar trebui să fie acum mai clar: definițiile proprietăților HTML și CSS se pot acumula una pe alta. De fapt, atunci când reluați sau modificați același model de e-mail, codul poate fi adesea blocat de proprietăți redundante care îndeplinesc aceeași funcție.

Și asta nu este tot. Deoarece stilurile inline pot fi aplicate fiecărui element, acest caz (pervers) poate apărea și:

Un browser (sau client de e-mail) ar citi codul mai mult sau mai puțin astfel:

• Aplicați un fundal gri ( bgcolor = „#efefef” ) tabelului
• Zece aplică un fundal negru ( bgcolor = „#000000” ) la rând
• În cele din urmă, aplicați un fundal portocaliu ( culoarea de fundal: #e75c00 ) pe celula care conține textul Hello World!

Rezultatul final este identic atât în ​​acest exemplu, cât și în cel precedent: text alb pe fond portocaliu.

Problema este că în al doilea caz au fost definite trei reguli de fundal diferite. Cel văzut de utilizator este cel definit în raport cu celula, deoarece browserul citește secvențial codul (tabel -> tr -> td). Deoarece ultima definiție a fost setată pe <td> , tocmai asta va fi afișat.

Este clar că o mare parte din cod nu este necesară. Acest lucru nu se datorează numai faptului că singura culoare de fundal afișată este cea aplicată celulei, ci și pentru că unul dintre scopurile unui bun marketing prin e-mail este acela de a menține comunicațiile cât mai ușoare. Foarte verbos, codul redundant nu este un cod ușor.

Recomandările noastre:

• Păstrați codul cât mai curat posibil
• Evitați repetările inutile atunci când formatați codul
• Dați preferință stilurilor inline
• Încercați să construiți o structură modulară pentru codul de comunicare
• Încercați să păstrați codul cât mai ordonat prin indentare (există mai multe servicii online care fac acest lucru, precum HTMLformatter sau Clean CSS), pentru a putea avea o imagine de ansamblu asupra structurii comunicării
• Urmăriți istoricul modificărilor macro efectuate asupra unui model

Eroare 2. Comentarea excesivă a codului

Ca și în majoritatea limbilor, este, de asemenea, posibil să adăugați comentarii la HTML. Ce este un comentariu într-un script HTML? Este o parte a listei care este ignorată de programul care citește și execută codul.

Un exemplu de comentariu este dat în figura de mai jos:

După cum puteți vedea, totul între <!- și -> nu este doar o culoare diferită (în funcție de programul de editare), cel mai important, nu este afișat pe ecran.

Acest lucru permite inserarea „comunicațiilor de service” referitoare la codul care a fost scris sau la instrucțiuni pentru piesele care nu au fost încă finalizate sau care trebuie îmbunătățite.

Există și o altă modalitate de a folosi comentariile. Deoarece tot ceea ce este inclus între marcatorii de deschidere și de închidere nu este afișat, este posibil să ascundeți părți întregi de pagină cu acesta, așa cum se arată în exemplul următor. De fapt, putem vedea că doar trei linii sunt vizibile pe ecran în loc de cele patru care sunt scrise în cod.

Este un instrument util, desigur, dar nu trebuie să abuzăm de el. Deși este adevărat că codul comentat nu este afișat, acesta rămâne totuși în comunicarea transmisă, împovărându-l.

Sfatul nostru:

• Folosiți comentariile cu înțelepciune, de exemplu pentru a indica începutul și sfârșitul structurilor de comunicare sau pentru a introduce informații utile dezvoltatorului
• Nu fi prea lung în comentarii și, mai bine, scrie-le în engleză
• Ștergeți codul comentat înainte de trimitere, deoarece nu este necesar în scopuri de comunicare

Eroare 3. Gestionarea greșită a conținutului de e-mail

La proiectarea unui email, chiar înainte de a scrie o singură linie de cod, este bine să definiți anumiți parametri care nu pot fi modificați în faza ulterioară de realizare și, în consecință, în timpul producției.

Unii dintre acești parametri includ:

• Lățimea e-mailului
• Marimea imaginii
• Numărul de imagini
• Dimensiunea fontului folosită în antet
• Dimensiunea fontului pentru copierea corpului

Si asa mai departe. Un parametru care este adesea omis este cel al numărului maxim de taste pentru orice element de text.

În acest moment, ați putea obiecta că suntem vinovați că suntem fanatici cu regulile, dar există două motive bune pentru a fi atât de stricti. Prima este conceptuală, iar a doua operațională.

La nivel conceptual, conținutul (text, imagini etc.) și containerul (structură HTML) sunt două entități separate, cu o ierarhie foarte precisă, care îl vede pe primul subordonat celui din urmă.

De fapt, conținutul ar trebui adaptat recipientului, și nu invers. Arhitectura comunicării este construită la scrierea codului. Aceasta definește containerul și, odată modelat, containerul rămâne astfel indiferent de conținut, chiar dacă e-mailul a fost creat pentru a fi receptiv.

În rezumat – și parafrazându-l pe Bruce Lee – conținutul este ca apa: dacă pui apă într-o cană, aceasta devine ceașcă; daca pui apa intr-o sticla, aceasta devine sticla; dacă pui apă într-un ceainic, aceasta devine ceainic.

Nu te poți aștepta ca o ceașcă să devină o sticlă, iar un ceainic nu va fi niciodată o ceașcă. Prin urmare, textul (sau imaginea sau butonul) trebuie să se adapteze structurii care îl conține, și nu invers.

Al doilea motiv este mai operațional. Dacă toți parametrii pentru alcătuirea comunicării sunt cunoscuți exact a priori, atunci nu numai că este posibil să se creeze comunicări mai eficiente în faza de redactare, ci și comunicări mai echilibrate.

Să luăm un exemplu mai concret: să presupunem că avem un DEM cu două produse unul lângă altul. Un produs este de obicei asociat cu:

• O imagine
• Numele produsului
• Descrierea produsului
• Pretul
• CTA care duce la pagina produsului

Acum, deoarece produsele sunt una lângă alta, piesele trebuie neapărat echilibrate.

Aceasta înseamnă că imaginile trebuie să aibă aceeași înălțime, textele descriptive trebuie să aibă o lungime similară și cele două CTA-uri nu trebuie să fie prea diferite.

Ignorarea sau nerespectarea acestor principii de bază poate duce la cazuri precum imaginea de mai sus.

Simetria dintre cele două elemente este întreruptă deoarece titlul produsului din stânga este atât de lung încât acoperă trei linii, în timp ce cel din dreapta este atât de scurt încât umple doar o singură linie. A fost introdusă o discordie, care în cele din urmă slăbește întreaga comunicare.

Respectarea acestor reguli devine și mai importantă atunci când ne gândim la lumea mobilă, unde toate dispozitivele variate au rezoluții foarte disparate: de la 1125 x 2436 px ale iPhone X la 1440 x 2960 px ale Samsung Galaxy S8, trecând prin 768 x 1280 px ale Microsoft Lumia 1020.

Când această diversitate uriașă se suprapune cu jungla densă a clienților de e-mail, înseamnă că nu avem control total asupra afișajului DEM, deoarece nu există un cod definitiv care să se adapteze pixelilor în fiecare caz. Deci, dacă nu îl puteți controla prin cod, trebuie să încercați să o faceți indirect, modificând celelalte părți care cuprind un e-mail, cum ar fi lungimea textelor sau dimensiunea imaginilor.

Recomandările noastre:

• Definiți toate părțile șablonului
• Rămâneți consecvent între diferitele părți ale comunicării
• Respectați regulile pe care vi le-ați dat
• Regulile pot fi încălcate, dar acest lucru trebuie făcut cu deplină conștientizare
• Dacă șablonul nu corespunde nevoilor dvs., puteți începe să vă gândiți să definiți unul nou

Eroare 4. Obținerea greșită a numerelor de telefon interactive și a adreselor

Uneori, expeditorii de e-mail adaugă informațiile lor de contact, în special în subsol. Aceasta include de obicei o adresă și un număr de telefon.

În timp ce un număr de telefon și o adresă pot fi informații standard pentru e-mailurile clientului desktop, deși sunt rar utilizate, aceste elemente sunt deosebit de importante atunci când vine vorba de partea mobilă.

Acest lucru se întâmplă în principal din două motive:

• Puteți deschide o aplicație care gestionează datele cu un clic (calendar, telefon, browser)
• Spațiul de afișare este redus și, ca atare, fiecare informație are o vizibilitate mai mare, chiar dacă este situată în subsol

Prin urmare, este important să nu uităm și aceste detalii atunci când dezvoltați comunicarea, deoarece comportamentul lor variază de la diferite dispozitive.

Să luăm un moment în considerare un exemplu creat ad-hoc printr-o simulare. Ambele exemple sunt afișate de iPhone 6+ iOS 9.

Imaginea din stânga arată newsletter-ul primit de utilizator cu textul introdus direct, fără nicio formatare.

Totul este corect din punct de vedere tehnic, dar trebuie să ținem cont de faptul că codul este interpretat chiar de aplicația de email de pe mobil. „Citește” textul e-mailului, iar atunci când recunoaște text sub forma unei date, a unei adrese sau a unui număr de telefon, leagă automat linkul activ la aplicația respectivă, adică Calendarul, Harta sau telefonul.

Toate acestea sunt foarte convenabile, deoarece un singur clic vă permite să efectuați un apel telefonic, să programați un eveniment sau să deschideți harta pentru a stabili o rută. Singurii care pot fi triști sunt arta și dezvoltatorul, cărora nu le place să vadă linkurile albastre și sublinierea. Deci ce ar trebui sa facem? Cum ar trebui să procedăm?

Puteți folosi o mică soluție sau un truc pentru a readuce lucrurile la normal. Să fim clari: deși încalcă regulile HTML-ului bine formatat, soluțiile alternative sunt indispensabile în oceanul vast de clienți de e-mail.

Dacă scopul principal al unui dezvoltator este să facă comunicarea vizibilă pentru cât mai mulți clienți posibil, atunci aceștia trebuie să facă compromisuri și să accepte soluțiile alternative.

Deci, să vedem cum a fost modificat codul.

Când vine vorba de telefon, este simplu: deoarece eticheta de ancorare face posibilă definirea unui număr de telefon folosind tel în proprietatea href , adăugăm numărul de telefon fără spații sau linii de separare.

Totuși, trebuie să acționăm într-un mod diferit pentru o adresă sau o dată. Pentru acestea este necesară definirea unei clase (.address) care impune eticheta de ancorare care va introduce automat culoarea în interiorul clientului (culoare: #ffffff;). Mai presus de toate, ar trebui să elimine sublinierea, care este o caracteristică implicită a fiecărui link (text-decoration:none;).

Rețineți că ambele atribute ale clasei de adresă au !important , care trebuie aplicată de client indiferent de proprietate. Fără el, nu există nicio garanție că soluția de soluție își va face treaba.

Recomandările noastre:

• Acordați întotdeauna atenție modului în care comunicarea poate fi afișată pe telefoane mobile (adică făcând teste)
• Acolo unde este posibil, utilizați micro-remedieri pentru a face comunicațiile prietenoase cu dispozitivele mobile
• Nu presupuneți că ceea ce este bun pentru desktop este bun și pentru mobil
• Cunoaște-ți publicul: ce tehnologie folosesc? Ce dispozitive? Care media?
• Utilizați teste interne pentru a experimenta propriile comunicații, mai ales atunci când există actualizări substanțiale ale aplicațiilor client de e-mail

Eroare 5. Nu se curăță etichetele abandonate sau goale

Continuând cu obiectivul de a încerca să menținem ponderea globală a comunicării la minimum, trebuie să acordăm atenție părților din codul existent care au fost golite de conținutul lor natural.

Să dăm imediat un exemplu concret: o etichetă <font> , poate cu o serie de stiluri inline, care nu conține niciun text. Evident, partea de e-mail nu va putea citi nimic, dar eticheta de formatare <font> continuă să existe și să ocupe spațiu fizic în e-mail.

Un alt exemplu clasic sunt etichetele de ancorare <a> care nu au niciun obiect legat, deci ceva de genul: <a href="http://www.mailup.com” style="color:#00000;text-decoration:none"> </a>.

De obicei, aceste „erori” sunt prezente în acel cod care a fost reluat sau folosit de multe ori, astfel încât diferite părți, precum imagini, linkuri și texte, au fost inserate, modificate sau șterse. Alternativ, ar putea fi un indiciu al utilizării incorecte a unui editor WYSIWYG. De fapt, dacă sunt folosite prost sau imprudent, acești editori au defectul de a adăuga cod la cod, deoarece fiecare element predefinit are în mod normal o parte din cod definită din momentul în care editorul însuși a fost creat.

Programul aplică necritic modelul de fiecare dată când elementul selectat este inserat și, ca urmare, această problemă poate apărea atunci când rescrieți aceeași parte a e-mailului de un număr suficient de ori.

Sfatul nostru:

• Când scrieți codul, verificați întotdeauna că nu există etichete abandonate sau goale
• Dacă utilizați un editor WYSIWYG și este posibil să accesați codul, efectuați o verificare pentru a vă asigura că totul este în ordine și că nu există niciuna dintre aceste tipuri de erori

Eroare 6. Utilizarea HTML nevalidat

A vorbi despre validarea codului de e-mail este un subiect spinos.

„Majoritatea paginilor de pe World Wide Web sunt scrise în limbaje informatice (cum ar fi HTML) care permit autorilor web să structureze text, să adauge conținut multimedia și să specifice ce aspect sau stil ar trebui să aibă rezultatul.

Ca și pentru fiecare limbă, acestea au propria lor gramatică , vocabular și sintaxă , iar fiecare document scris cu aceste limbaje informatice trebuie să respecte aceste reguli. Limbile (X)HTML, pentru toate versiunile până la XHTML 1.1, folosesc gramatici care pot fi citite de mașină numite DTD, un mecanism moștenit de la SGML.

Cu toate acestea, la fel cum textele într-un limbaj natural pot include greșeli de ortografie sau gramaticale, documentele care folosesc limbaje de marcare pot (din diferite motive) să nu respecte aceste reguli. Procesul de verificare dacă un document respectă de fapt regulile pentru limba (limbile) pe care le folosește se numește validare , iar instrumentul folosit pentru aceasta este un validator. Un document care trece acest proces cu succes se numește valid .

Având în vedere aceste concepte, putem defini „validarea marcajului” ca fiind procesul de verificare a unui document Web față de gramatica (în general, un DTD) pe care pretinde că îl folosește”.

Definiție W3C

W3C ne ajută în calitate de gardian și garant al codului furnizând un instrument de validare a codului a cărui analiză indică erori și sugerează modalități de corectare a acestora. Datorită acestui instrument, este posibilă identificarea și corectarea erorilor structurale mai mari.

Merită să ne amintim că Email Marketingul are o dublă situație:

• Pe de o parte, HTML este un limbaj standardizat cu reguli și structuri foarte precise
• Pe de altă parte, o serie de soluții care nu sunt standard și sunt adesea respinse, dar care funcționează bine dacă doriți să aveți o vizualizare corectă pe clienții de e-mail

Aceste două aspecte sunt ca un cuplu de bătrâni căsătoriți, unde pasiunea s-a stins de mult. Ei nu știu de ce trăiesc împreună, dar sunt forțați să facă acest lucru făcând compromisuri.

Deci, de ce să vorbim despre validarea codului? Are sens? Care sunt compromisurile?

Este logic să vorbim despre validarea codului atunci când este plasată într-o perspectivă mai largă, fără a intra prea departe în detalii. Prin urmare, când vine vorba de structură, modulele din care este compus e-mailul și tabelele care constituie coloana vertebrală a comunicării, are perfect sens să avem un cod cât mai curat și cât mai apropiat de standardul dictat de W3C. pe cat posibil.

Totuși, trebuie să fim conștienți de realitate, și astfel compromisul constă în crearea unei structuri solide și funcționale, la care se adaugă soluțiile ca un fel de reglaj fin pentru a extinde vizualizarea corectă la cât mai mulți clienți.

Știm deja că soluțiile alternative nu sunt altceva decât excepții de la regulă, sau tehnici nu perfect ortodoxe, derivate din cunoștințele acumulate prin experiență, dar existența lor are sens doar pentru că permit vizualizarea corectă a codului, fără nicio depaginare.

Sfatul nostru:

• Dacă aveți îndoieli cu privire la cod, validarea poate servi ca un instrument rapid și eficient pentru analiză
• Validarea codului poate fi un instrument bun pentru identificarea rapidă a celor mai mari erori dintr-o listă de coduri
• Codul validat este întotdeauna un excelent punct de plecare pentru evoluția ulterioară și adaptarea comunicării cu soluții de soluționare, pentru a o face cât mai universală posibil
• Validarea poate fi văzută ca „serviciu” pentru cod, în special pe modelele care au fost frecvent manipulate și reproiectate
• Pe măsură ce câștigați experiență, construiți o bibliotecă mică de soluții ad-hoc pentru diverși clienți, pentru a economisi timp la rezolvarea problemelor