HTML & Email: 6 Kesalahan Umum yang Harus Anda Hindari

Membangun email dengan kode HTML? Berikut adalah 6 kesalahan yang terlalu sering Anda harus hindari, untuk menuai manfaat dari komunikasi email yang efisien dan bersih.

Kesalahan 1. Menggunakan kode yang terlalu bertele-tele

Kita tahu bahwa berkat HTML dan CSS kita dapat membangun struktur email dan memberikannya bentuk, atau lebih tepatnya format, yang memungkinkan untuk menampilkan jenis font tertentu, warna latar belakang tertentu, gambar, dan sebagainya.

Sekarang kita akan melihat bagaimana tag HTML dan CSS menjalankan fungsi yang sama dalam beberapa hal, dan akhirnya tumpang tindih. Mari kita ambil contoh praktis: mendefinisikan warna latar belakang untuk tabel di HTML dan CSS.

Kode ditunjukkan pada gambar. Anda dapat melihat bahwa ada dua titik di mana warna latar belakang ditentukan:

• bgcolor = “#e75c00” adalah atribut dari tabel tag;
• background-color adalah atribut CSS yang diterapkan ke tabel.

Kedua atribut melakukan hal yang sama, sehingga mereka tumpang tindih: mereka memaksakan warna oranye (#e75c00 menurut format heksadesimal) pada latar belakang tabel.

Titik kritis sekarang harus lebih jelas: definisi properti HTML dan CSS dapat menumpuk satu sama lain. Faktanya, saat mengerjakan ulang atau memvariasikan model email yang sama, kode sering kali dapat diblokir oleh properti redundan yang menjalankan fungsi yang sama.

Dan itu tidak semua. Karena gaya sebaris dapat diterapkan ke setiap elemen, kasus (sesat) ini juga dapat terjadi:

Peramban (atau klien email) akan membaca kode kurang lebih seperti ini:

• Terapkan latar belakang abu-abu ( bgcolor = “#efefef” ) ke tabel
• Sepuluh menerapkan latar belakang hitam ( bgcolor = "#000000" ) ke baris
• Terakhir, terapkan latar belakang oranye ( background-color: #e75c00 ) ke sel yang berisi teks Hello World!

Hasil akhirnya identik dalam contoh ini dan yang sebelumnya: teks putih dengan latar belakang oranye.

Masalahnya adalah bahwa tiga aturan latar belakang yang berbeda telah didefinisikan dalam kasus kedua. Yang dilihat oleh pengguna adalah yang didefinisikan dalam kaitannya dengan sel, karena browser membaca kode secara berurutan (tabel -> tr -> td). Karena definisi terakhir ditetapkan pada <td> , itulah yang akan ditampilkan.

Jelas bahwa sebagian besar kode tidak diperlukan. Ini bukan hanya karena satu-satunya warna latar belakang yang ditampilkan adalah warna yang diterapkan ke sel, tetapi juga karena salah satu tujuan pemasaran email yang baik adalah menjaga komunikasi seringan mungkin. Sangat bertele-tele, kode yang berlebihan bukanlah kode yang ringan.

Rekomendasi kami:

• Jaga kode sebersih mungkin
• Hindari pengulangan yang tidak perlu saat memformat kode
• Berikan preferensi untuk gaya sebaris
• Cobalah untuk membangun struktur modular untuk kode komunikasi
• Cobalah untuk menjaga kode seurut mungkin melalui lekukan (ada beberapa layanan online yang melakukan ini, seperti HTMLformatter atau Clean CSS), untuk dapat memiliki gambaran umum tentang struktur komunikasi
• Lacak riwayat perubahan makro yang dibuat pada model

Kesalahan 2. Mengomentari kode secara berlebihan

Seperti kebanyakan bahasa, Anda juga dapat menambahkan komentar ke HTML. Apa yang dimaksud dengan komentar dalam skrip HTML? Ini adalah bagian dari daftar yang diabaikan oleh program yang membaca dan mengeksekusi kode.

Contoh komentar diberikan pada gambar di bawah ini:

Seperti yang Anda lihat, semua yang ada di antara <!- dan -> tidak hanya memiliki warna yang berbeda (tergantung pada program pengeditan), yang terpenting, tidak ditampilkan di layar.

Hal ini memungkinkan "komunikasi layanan" untuk disisipkan mengenai kode yang telah ditulis, atau instruksi untuk bagian yang belum selesai atau yang perlu diperbaiki.

Ada juga cara lain untuk menggunakan komentar. Karena semua yang termasuk di antara penanda pembuka dan penutup tidak ditampilkan, dimungkinkan untuk menyembunyikan seluruh bagian halaman dengannya, seperti yang ditunjukkan pada contoh berikut. Faktanya, kita dapat melihat bahwa hanya tiga baris yang terlihat di layar, bukan empat yang tertulis dalam kode.

Ini adalah alat yang berguna, tentu saja, tetapi kita tidak boleh menyalahgunakannya. Meskipun benar bahwa kode yang dikomentari tidak ditampilkan, namun tetap dalam komunikasi yang dikirim, membebaninya.

Saran kami:

• Gunakan komentar dengan bijak, misalnya untuk menunjukkan awal dan akhir struktur komunikasi, atau untuk menyisipkan informasi yang berguna bagi pengembang
• Jangan bertele-tele dalam komentar, dan, lebih baik lagi, tulis dalam bahasa Inggris
• Hapus kode yang dikomentari sebelum mengirim, karena tidak perlu untuk tujuan komunikasi

Kesalahan 3. Salah mengelola konten email

Saat mendesain email, bahkan sebelum menulis satu baris kode pun, sebaiknya tentukan parameter tertentu yang tidak dapat diubah pada fase realisasi berikutnya, dan akibatnya selama produksi.

Beberapa parameter tersebut antara lain:

• Lebar email
• Ukuran gambar
• Jumlah gambar
• Ukuran font yang digunakan di header
• Ukuran font salinan badan

Dan seterusnya. Salah satu parameter yang sering dihilangkan adalah jumlah maksimum penekanan tombol untuk setiap elemen teks.

Pada titik ini, Anda dapat menolak bahwa kami bersalah karena fanatik dengan aturan, tetapi ada dua alasan bagus untuk bersikap begitu ketat. Yang pertama adalah konseptual dan yang kedua operasional.

Pada tingkat konseptual, konten (teks, gambar, dll.) dan wadah (struktur HTML) adalah dua entitas terpisah dengan hierarki yang sangat tepat yang melihat yang pertama disubordinasikan ke yang terakhir.

Padahal, isinya harus disesuaikan dengan wadahnya, bukan sebaliknya. Arsitektur komunikasi dibangun saat menulis kode. Ini mendefinisikan wadah dan, setelah dibentuk, wadah tetap seperti itu terlepas dari kontennya, bahkan jika email telah dibuat agar responsif.

Singkatnya – dan memparafrasekan Bruce Lee – isinya seperti air: jika Anda memasukkan air ke dalam cangkir, itu menjadi cangkir; jika Anda memasukkan air ke dalam botol, itu menjadi botol; jika Anda memasukkan air ke dalam teko, itu menjadi teko.

Anda tidak dapat mengharapkan cangkir menjadi botol, dan teko tidak akan pernah menjadi cangkir. Oleh karena itu, teks (atau gambar atau tombol) harus beradaptasi dengan struktur yang memuatnya, dan bukan sebaliknya.

Alasan kedua lebih operasional. Jika semua parameter untuk menyusun komunikasi diketahui secara apriori, maka tidak hanya dimungkinkan untuk menciptakan komunikasi yang lebih efektif selama fase penyusunan, tetapi juga komunikasi yang lebih seimbang.

Mari kita ambil contoh yang lebih konkret: misalkan kita memiliki DEM dengan dua produk berdampingan. Sebuah produk biasanya dikaitkan dengan:

• Sebuah gambar
• Nama produk
• Deskripsi produk
• Harga
• CTA yang mengarah ke halaman produk

Sekarang, karena produknya berdampingan, bagian-bagiannya tentu harus seimbang.

Artinya gambar harus memiliki tinggi yang sama, teks deskriptif harus memiliki panjang yang sama dan kedua CTA tidak boleh terlalu berbeda.

Mengabaikan atau tidak menghormati prinsip-prinsip dasar ini dapat menyebabkan kasus seperti gambar di atas.

Kesimetrisan antara kedua elemen tersebut terputus karena judul produk di sebelah kiri terlalu panjang sehingga mencakup tiga baris, sedangkan yang di sebelah kanan sangat pendek sehingga hanya memenuhi satu baris. Sebuah perselisihan telah diperkenalkan, yang pada akhirnya melemahkan seluruh komunikasi.

Kepatuhan terhadap aturan ini menjadi lebih penting ketika memikirkan dunia seluler, di mana semua perangkat yang berbeda memiliki resolusi yang sangat berbeda: dari iPhone X 1125 x 2436 px hingga 1440 x 2960 px pada Samsung Galaxy S8, melewati 768 x 1280 px dari Microsoft Lumia 1020.

Ketika keragaman besar ini tumpang tindih dengan hutan klien email yang lebat, itu berarti bahwa kami tidak memiliki kendali penuh atas tampilan DEM, karena tidak ada kode definitif yang beradaptasi dengan piksel dalam setiap kasus. Jadi, jika Anda tidak dapat mengontrolnya melalui kode, Anda harus mencoba melakukannya secara tidak langsung, dengan mengubah bagian lain yang membentuk email, seperti panjang teks atau ukuran gambar.

Rekomendasi kami:

• Tentukan semua bagian dari template
• Tetap konsisten di antara berbagai bagian komunikasi
• Hormati aturan yang telah kamu berikan pada dirimu sendiri
• Aturan bisa dilanggar, tapi ini harus dilakukan dengan kesadaran penuh
• Jika template tidak memenuhi kebutuhan Anda, Anda dapat mulai berpikir untuk menentukan yang baru

Kesalahan 4. Mendapatkan nomor telepon dan alamat interaktif yang salah

Terkadang, pengirim email menambahkan informasi kontak mereka, terutama di bagian footer. Ini biasanya mencakup alamat dan nomor telepon.

Meskipun nomor telepon dan alamat dapat menjadi informasi standar untuk email klien desktop, meskipun jarang digunakan, elemen-elemen ini sangat penting jika menyangkut sisi seluler.

Ini terutama terjadi karena dua alasan:

• Anda dapat membuka aplikasi yang mengelola data dengan satu klik (kalender, telepon, browser)
• Ruang tampilan berkurang, dan dengan demikian setiap informasi memiliki visibilitas yang lebih besar, bahkan jika terletak di footer

Oleh karena itu, penting untuk tidak melupakan juga detail ini saat mengembangkan komunikasi, karena perilaku mereka bervariasi di berbagai perangkat.

Mari luangkan waktu sejenak untuk mempertimbangkan contoh yang dibuat ad hoc melalui simulasi. Kedua contoh ditampilkan oleh iPhone 6+ iOS 9.

Gambar di sebelah kiri menunjukkan buletin yang diterima oleh pengguna dengan teks yang dimasukkan secara langsung, tanpa pemformatan apa pun.

Semuanya benar dari sudut pandang teknis, tetapi kita harus memperhitungkan fakta bahwa kode ditafsirkan oleh aplikasi email itu sendiri di ponsel. Ini "membaca" teks email, dan ketika mengenali teks dalam bentuk tanggal, alamat atau nomor telepon, secara otomatis menautkan tautan aktif ke aplikasi masing-masing, yaitu Kalender, Peta atau telepon.

Ini semua sangat nyaman, karena hanya dengan satu klik Anda dapat melakukan panggilan telepon, menjadwalkan acara, atau membuka peta untuk menetapkan rute. Satu-satunya yang bisa sedih tentang itu adalah seni dan pengembang, yang tidak suka melihat tautan biru dan garis bawah. Jadi apa yang harus kita lakukan? Bagaimana kita harus melanjutkan?

Anda dapat menggunakan solusi atau trik kecil untuk mengembalikan semuanya menjadi normal. Mari kita perjelas: meskipun mereka melanggar aturan HTML yang diformat dengan baik, solusi sangat diperlukan di lautan klien email yang luas.

Jika tujuan utama pengembang adalah membuat komunikasi terlihat di sebanyak mungkin klien, maka mereka perlu berkompromi dan merangkul solusi.

Jadi mari kita lihat bagaimana kode itu diubah.

Ketika datang ke telepon, itu sederhana: karena tag jangkar memungkinkan untuk menentukan nomor telepon dengan menggunakan tel di properti href , kami menambahkan nomor telepon tanpa spasi atau garis pemisah.

Namun, kita perlu bertindak dengan cara yang berbeda untuk sebuah alamat atau tanggal. Untuk ini, perlu untuk mendefinisikan kelas (.address) yang menerapkan tag jangkar yang secara otomatis akan memasukkan warna ke dalam klien (warna: #ffffff;). Di atas segalanya, itu harus menghapus garis bawah, yang merupakan fitur default dari setiap tautan (dekorasi teks: tidak ada;).

Perhatikan bahwa kedua atribut kelas alamat memiliki !important , yang harus diterapkan oleh klien terlepas dari propertinya. Tanpa itu, tidak ada jaminan bahwa solusi akan melakukan tugasnya.

Rekomendasi kami:

• Selalu perhatikan bagaimana komunikasi dapat ditampilkan di ponsel (yaitu dengan melakukan tes)
• Jika memungkinkan, gunakan perbaikan mikro untuk membuat komunikasi mobile-friendly
• Jangan berasumsi bahwa apa yang baik untuk desktop juga baik untuk seluler
• Kenali audiens Anda: teknologi apa yang mereka gunakan? Perangkat yang mana? media yang mana?
• Gunakan pengujian internal untuk bereksperimen dengan komunikasi Anda sendiri, terutama ketika ada pembaruan substansial untuk aplikasi klien email

Kesalahan 5. Tidak membersihkan tag yang ditinggalkan atau kosong

Melanjutkan tujuan mencoba untuk menjaga bobot keseluruhan komunikasi seminimal mungkin, kita perlu memperhatikan bagian-bagian dari kode yang ada yang telah dikosongkan dari konten alaminya.

Mari kita berikan contoh konkret segera: tag <font> , mungkin dengan serangkaian gaya sebaris, yang tidak berisi teks apa pun. Jelas, sisi email tidak akan dapat membaca apa pun, tetapi tag pemformatan <font> terus ada dan menempati ruang fisik di email.

Contoh klasik lainnya adalah tag jangkar <a> yang tidak memiliki objek tertaut, jadi kira-kira seperti: <a href=”http://www.mailup.com” style=”color:#00000;text-decoration:none”> </a>.

Biasanya "kesalahan" ini ada dalam kode yang telah dikerjakan ulang atau digunakan berkali-kali, sehingga bagian yang berbeda, seperti gambar, tautan, dan teks, telah dimasukkan, diubah, atau dihapus. Atau, ini bisa menjadi indikasi penggunaan editor WYSIWYG yang salah. Bahkan, jika digunakan dengan buruk atau tidak hati-hati, editor ini memiliki cacat dalam menambahkan kode ke kode, karena setiap elemen yang telah ditentukan biasanya memiliki bagian dari kode yang ditentukan sejak editor itu sendiri dibuat.

Program secara tidak kritis menerapkan model setiap kali elemen yang dipilih dimasukkan, dan akibatnya masalah ini dapat muncul ketika Anda menulis ulang bagian email yang sama beberapa kali.

Saran kami:

• Saat menulis kode, selalu periksa bahwa tidak ada tag yang ditinggalkan atau kosong
• Jika Anda menggunakan editor WYSIWYG dan memungkinkan untuk mengakses kode, lakukan pemeriksaan untuk memastikan semuanya beres dan tidak ada kesalahan semacam ini

Kesalahan 6. Menggunakan HTML yang tidak divalidasi

Berbicara tentang validasi untuk kode email adalah topik yang sulit.

“Sebagian besar halaman di World Wide Web ditulis dalam bahasa komputer (seperti HTML) yang memungkinkan penulis Web untuk menyusun teks, menambahkan konten multimedia, dan menentukan tampilan, atau gaya apa yang seharusnya dimiliki oleh hasilnya.

Adapun setiap bahasa, ini memiliki tata bahasa , kosa kata , dan sintaksnya sendiri , dan setiap dokumen yang ditulis dengan bahasa komputer ini seharusnya mengikuti aturan ini. Bahasa (X)HTML, untuk semua versi hingga XHTML 1.1, menggunakan tata bahasa yang dapat dibaca mesin yang disebut DTD, mekanisme yang diwarisi dari SGML.

Namun, Sama seperti teks dalam bahasa alami dapat menyertakan kesalahan ejaan atau tata bahasa, dokumen yang menggunakan bahasa Markup mungkin (karena berbagai alasan) tidak mengikuti aturan ini. Proses verifikasi apakah dokumen benar-benar mengikuti aturan untuk bahasa yang digunakannya disebut validasi , dan alat yang digunakan untuk itu adalah validator. Sebuah dokumen yang melewati proses ini dengan sukses disebut valid .

Dengan mengingat konsep-konsep ini, kita dapat mendefinisikan "validasi markup" sebagai proses pemeriksaan dokumen Web terhadap tata bahasa (umumnya DTD) yang diklaimnya digunakan".

Definisi W3C

W3C membantu kami sebagai penjaga dan penjamin kode dengan menyediakan alat validasi kode yang analisisnya menunjukkan kesalahan dan menyarankan cara untuk memperbaikinya. Berkat alat ini, dimungkinkan untuk mengidentifikasi dan memperbaiki kesalahan struktural yang lebih besar.

Perlu diingat bahwa Pemasaran Email memiliki dua situasi:

• Di satu sisi, HTML adalah bahasa standar dengan aturan dan struktur yang sangat tepat
• Di sisi lain, serangkaian solusi yang tidak standar, dan sering tidak disukai, tetapi berfungsi dengan baik jika Anda ingin memiliki visualisasi yang benar pada klien email

Kedua aspek ini seperti pasangan suami istri yang sudah tua, di mana gairah telah lama meredup. Mereka tidak tahu mengapa mereka hidup bersama, tetapi mereka terpaksa melakukannya dengan membuat kompromi.

Jadi mengapa berbicara tentang validasi kode? Apakah masuk akal? Apa komprominya?

Masuk akal untuk berbicara tentang validasi kode ketika ditempatkan dalam perspektif yang lebih luas, tanpa terlalu jauh ke rinciannya. Oleh karena itu, ketika menyangkut struktur, modul dari mana email disusun, dan tabel yang merupakan tulang punggung komunikasi, sangat masuk akal untuk memiliki kode yang sebersih dan sedekat standar yang ditentukan oleh W3C. mungkin.

Namun, kita harus menyadari kenyataan, dan kompromi terdiri dari penciptaan struktur yang solid dan fungsional, yang solusi ditambahkan sebagai semacam fine tuning untuk memperluas visualisasi yang benar untuk klien sebanyak mungkin.

Kita sudah tahu bahwa solusi tidak lebih dari pengecualian terhadap aturan, atau bukan teknik ortodoks yang sempurna, yang berasal dari pengetahuan yang dikumpulkan melalui pengalaman, tetapi keberadaannya hanya masuk akal karena memungkinkan kode divisualisasikan dengan benar, tanpa depagination.

Saran kami:

• Jika Anda ragu tentang kodenya, validasi dapat berfungsi sebagai alat analisis yang cepat dan efektif
• Validasi kode dapat menjadi alat yang baik untuk mengidentifikasi kesalahan terbesar dalam daftar kode dengan cepat
• Kode yang divalidasi selalu merupakan titik awal yang sangat baik untuk selanjutnya mengembangkan dan mengadaptasi komunikasi dengan solusi, untuk membuatnya seuniversal mungkin
• Validasi dapat dilihat sebagai "pelayanan" untuk kode, terutama pada model yang sering dimanipulasi dan dikerjakan ulang
• Saat Anda mendapatkan pengalaman, buatlah perpustakaan kecil solusi ad hoc untuk berbagai klien untuk menghemat waktu saat memecahkan masalah