Unlimited Wordpress themes, plugins, graphics & courses! Unlimited asset downloads! From $16.50/m
Advertisement
  1. Web Design
  2. Email

Yang HArus Anda Ketahui Mengenai Email HTML

by
Difficulty:BeginnerLength:LongLanguages:

Indonesian (Bahasa Indonesia) translation by Dwi Bagus Nurrohman (you can also view the original English article)

Email adalah media yang luar biasa. Ini langsung masuk ke kotak masuk dan ROI dilaporkan secara luas melalui atap pada 4000%. Itu juga terus disalahpahami dan sering kali itu dilakukan dengan buruk. Dengan ledakan ponsel cerdas baru-baru ini, kami lebih sering membaca email kami di iPhone atau Galaxy, tetapi sayangnya banyak pemasaran email gagal mengikutinya. Saya melihat ini sebagai peluang besar yang terlewatkan karena email yang dieksekusi dengan baik dapat menyenangkan untuk dibuka dan sangat sukses.

Coding HTML Email Dapat Menjadi Tantangan

Jika Anda sudah mencoba tangan Anda di desain dan pengembangan email HTML, Anda mungkin sudah menetapkan bahwa itu bisa sangat sulit. Dan Anda tidak membayangkannya - itu cukup sulit. Inilah Mengapa:

Standar Email Tidak Ada

[Kami akan] terus menggunakan Word untuk membuat pesan e-mail karena kami percaya itu adalah pengalaman menulis e-mail terbaik.

Saat Anda membuat kode untuk web, Anda setidaknya dapat mengandalkan fakta bahwa semua browser utama (Chrome, Firefox, Internet Explorer, Safari, dan Opera) mencoba untuk mematuhi standar web untuk rendering HTML dan CSS.

Saat berurusan dengan klien email, Anda menguji pada sekelompok besar program lama dan baru. Mulai dari ponsel baru yang dijalankan di Android dan iOS hingga IBM Lotus Notes atau Microsoft Office 2007 (yang secara tidak sengaja menjadikan HTML buatan Anda dengan HTML render engine. Versi Outlook sebelumnya menggunakan browser untuk merender HTML mereka - yang sebenarnya logis. Mengapa beralih ke pengolah kata untuk merender HTML yang Anda minta? Nah, untuk "alasan keamanan", kata mereka). Dan tidak satu pun dari program ini harus mematuhi standar apa pun. Mereka pada dasarnya semua hanya mengada-ada. Anda dapat melihat seperti apa dukungan standar bagi beberapa klien email paling populer di Proyek Standar Email.

Jika itu tidak cukup buruk, pasangkan dengan fakta berikutnya: ada sekitar sejuta kombinasi cara email yang berbeda yang dapat ditampilkan di desktop dan seluler.

demystifying-email-rendering
Kemungkinan rendering (hampir) tidak ada habisnya.

Berikut ini daftar beberapa klien email yang paling umum:

Klien seluler:

  • Android 2.3 & 4.0
  • iPhone 5 iOS 6
  • iPhone 4S iOS 6
  • iPhone 3GS iOS 5
  • iPad 2 iOS 6
  • BlackBerry OS 4 & 5
  • Symbian S60
  • Windows Phone 7.5

Klien desktop:

  • Apple Mail 4, 5, 6
  • Lotus Notes 8.5
  • Lotus Notes 8
  • Thunderbird
  • Windows Live Mail
  • Outlook 2013
  • Outlook 2011 for Mac
  • Outlook 2010
  • Outlook 2007
  • Outlook 2003
  • Outlook 2002/XP
  • Outlook 2000

Klien email web:

  • AOL Mail (pada browser apa saja)
  • Gmail (di browser apa saja)
  • Outlook.com (di browser apa pun)
  • Yahoo! (di browser apa saja)

Itu banyak perangkat!

Jika Anda sudah akrab dengan pengembangan web, lupakan semua yang Anda ketahui tentang itu.

Untuk menggabungkan semua ini, gaya kondisional juga bukan pilihan. Ada beberapa hal yang dapat Anda lakukan dengan komentar bersyarat, tetapi terbatas pada penargetan versi Outlook tertentu, atau semuanya kecuali versi Outlook tertentu.

Jika Anda sudah akrab dengan pengembangan web, lupakan semua yang Anda ketahui tentang itu. Satu hambatan terbesar bagi Anda adalah mengharapkan hal-hal berfungsi seperti pengembangan web 'normal'. Ini akan membuat Anda frustrasi dan menahan Anda. Hal terburuk yang dapat Anda lakukan adalah marah karena Anda tidak dapat menggunakan DIV atau margin tersebut tidak sepenuhnya didukung. Jadi, lupakan semua yang Anda ketahui tentang semantik HTML dan spesifikasi CSS terbaru. Percayalah padaku, itu akan membantu.

Cara Mendekati Pekerjaan Anda

Mari kita lihat beberapa saran alur kerja pembuatan email.

Bekerja Secara Struktural Pertama

Membangun struktur email Anda terlebih dahulu dapat membantu Anda menghindari banyak bug dan masalah nanti di trek. Jangan pernah membangun semuanya dan kemudian uji - Anda sering dapat berakhir dengan terlalu banyak bug yang harus dihadapi, dan mereka semua dapat saling mempengaruhi.

Uji Seringkali

Bekerja sampai Anda mencapai tonggak pengembangan kecil (misalnya, ketika Anda menyelesaikan struktur dasar) dan kemudian jalankan tes. Cara terbaik untuk menguji adalah menggunakan Litmus atau Email on Acid. Saya merekomendasikan mengambil rencana tanpa batas dengan salah satu dari perusahaan-perusahaan ini karena dapat menguji sering sangat penting.

Saya juga sangat suka meninggalkan di semua perbatasan meja saya sehingga saya bisa melihat apa yang saya ciptakan, kemudian saya matikan semuanya di akhir. Anda juga dapat mewarnai latar belakang sel-sel tertentu untuk membantu melihat bagian mana berada. Alur kerja ideal saya adalah membuat kerangka, menguji, lalu menambahkan konten, menguji, menata warna dan font, menguji lagi dan akhirnya menghapus batas saya dan menguji lagi sebelum mengirim.

Validasi Seringkali

Validasikan menggunakan W3C Validator sesering mungkin. Ini akan membantu Anda menyetrika detail-detail kecil dan akan mengambil kesalahan-kesalahan seperti tag yang hilang atau terbuka.

Mengirim Email Anda

Ada sejumlah besar pilihan ketika datang untuk mengirim email Anda. Dua layanan yang paling saya gunakan adalah MailChimp dan Campaign Monitor. Mereka menawarkan harga yang kompetitif dan mereka sangat mudah digunakan. Ada banyak platform komersial juga - semuanya tergantung pada kebutuhan Anda. Mendaftarlah untuk mendapatkan akun gratis dengan salah satu dari ini dan miliki tinker di sistem mereka untuk melihat mana yang Anda sukai. Pastikan Anda memanfaatkan data bermanfaat yang dikumpulkan oleh kedua layanan tentang email Anda, seperti waktu buka dan penggunaan klien email. Ini benar-benar dapat membantu Anda memfokuskan upaya Anda di area yang tepat pada saat Anda mengirim.

Konten, Pengembangan, dan Skor SPAM

Ketika datang ke SPAM; konten, desain, dan pengembangan semuanya berjalan seiring. Penting untuk menghindari taktik spam yang tipikal seperti menggunakan huruf besar dan banyak tanda seru di baris subjek Anda. Ada kata-kata tertentu yang cenderung memicu filter SPAM juga (seperti 'gratis' dan 'invest'). Semakin bersih kode Anda, semakin kecil kemungkinan email Anda ditandai sebagai SPAM, dan rasio gambar ke teks juga memiliki efek. Email yang bergantung pada gambar tanpa teks lebih mungkin ditandai sebagai SPAM dan begitu juga email dengan nama file gambar yang sangat panjang.

Dunia skor SPAM adalah salah satu yang rumit dan penting untuk menjalankan tes SPAM melalui akun pengujian Anda dengan Litmus atau Email on Acid sebelum mengirim email Anda, untuk memastikan semua kerja keras Anda tidak langsung menuju folder Sampah.

Menyelam ke dalam Pembangunan

Sekarang, untuk seluk beluk pengembangan email ..

Alat Penukar

Anda memerlukan editor teks yang Anda sukai (saya menggunakan Teks Sublime) dan akun uji dengan Litmus atau Email on Acid. Saya sangat merekomendasikan memiliki akun tes tanpa batas dengan salah satu perusahaan ini karena akan membuat hidup Anda lebih mudah. Jika Anda tidak membayar biaya bulanan, Anda akan membayar antara $ 3 dan $ 5 per tes yang dapat bertambah dengan sangat cepat.

Mulai Dengan Basis Yang Baik

Saya pikir itu baik untuk memulai dengan lembaran kosong. Kerangka kerja seperti HTML Email Boilerplate penuh dengan trik dan cuplikan hebat yang dapat Anda terapkan sepotong demi sepotong. Namun, jika Anda baru memulai, saya tidak menyarankan untuk menggunakannya sebagai titik awal karena berisi banyak elemen yang tidak Anda perlukan. Boilerplates seringkali dapat membuatnya lebih sulit untuk memecahkan masalah jika ada banyak kode yang tidak digunakan dalam file Anda.

Catatan: Karena sangat sulit menggunakan editor apa pun (terutama ketika saatnya untuk memecahkan masalah), Anda tidak boleh menggunakan editor WYSIWYG, atau editor apa pun yang berjanji untuk menggunakan desain Anda yang diformat dan secara ajaib mengubahnya menjadi HTML yang valid untuk mengirim email. Hal-hal ini tidak pernah berhasil.

!DOCTYPE

Ini mungkin tampak seperti detail teknis untuk memulai, tetapi Anda memerlukan template kosong untuk mulai bekerja dengan, dan template itu membutuhkan Doctype. Sebuah doctype pada dasarnya adalah sebuah baris kode yang menginformasikan program yang membacanya tag HTML mana yang diharapkan dan kumpulan aturan mana yang mematuhi HTML dan CSS. Cukup beberapa klien menghapus Doctype Anda, dan beberapa bahkan menerapkannya sendiri. Banyak klien yang menghormati doctype Anda dan itu dapat membuat segala sesuatunya menjadi lebih mudah jika Anda dapat memvalidasi secara konstan melawan Doctype.

Menggunakan doctype XHTML umumnya memiliki quirks paling sedikit dan inkonsistensi antara dokumen. Saya menggunakan XHTML 1.0 Transitional karena telah terbukti menjadi doctype yang paling dapat diandalkan dalam pengalaman saya. Dalam tutorial berikut, selama itu kami akan membuat template email HTML lengkap, kami akan menggunakan kode berikut untuk memulai dokumen kami:

Tag meta Content-Type adalah untuk memberitahukan mesin render tujuan bagaimana memproses teks dan karakter khusus. Pada kenyataannya, Anda harus menyandikan semua karakter khusus Anda (mis., & Menjadi & amp; untuk ampersand) agar aman, tetapi sebaiknya tetap gunakan baris ini di sana.

Tag meta area pandang memberi tahu perangkat untuk mengatur area yang dapat dilihat ke lebar layar perangkat. Ini juga menetapkan skala awal ke 'normal' yang tidak diperbesar maupun yang tidak diperbesar. Jika Anda tidak menentukan ini, banyak ponsel cerdas dapat mengurangi konten Anda sehingga konten cocok dalam area yang dapat dilihat, tetapi tidak ada lapisan atau marginnya. Ini dapat menyebabkan teks dan gambar menyeruduk ke tepi layar.

Akhirnya, selalu masukkan judul yang bermakna karena ini adalah apa yang akan dilihat orang ketika mereka melihat email di browser, atau membagikannya dengan teman-teman mereka.

Email adalah Semua Tentang Tabel Bersarang

Karena kurangnya dukungan standar dalam email, tidak mungkin menggunakan div, bagian, atau artikel - sebagai gantinya Anda harus menggunakan tabel. Selain itu, Anda perlu menggunakan banyak dan banyak tabel bersarang karena atribut colspan atau rowspan tidak didukung dengan benar.

demystifying-email-nesting

Paragraf atau Sel?

Sekali lagi, karena kurangnya dukungan standar, bukanlah ide bagus untuk menggunakan tag standar seperti h1, h2, h3 atau p. Saya menemukan bahwa ini dapat membuat benar-benar tidak konsisten di seluruh klien email dan dapat membuat beberapa sakit kepala yang cukup besar.

Taruhan terbaik Anda adalah menempatkan setiap blok teks ke dalam selnya sendiri dan menerapkan gaya sebaris ke sel itu, misalnya:

Gaya Inline atau Stylesheet?

Yang ini lebih merupakan pilihan pribadi. Saya lebih suka menyimpan semua style inline saya (yaitu: dalam tag HTML itu sendiri) karena saya ingin tahu di mana tepatnya semuanya dan apa yang mempengaruhi apa. Anda dapat mengkodekan menggunakan gaya dan kemudian menarik mereka semua sebaris di akhir (Monitor Kampanye dan MailChimp dapat melakukan ini untuk Anda secara otomatis, Anda juga dapat menggunakan Premailer atau yang serupa) tetapi alasan saya tidak menyukai ini adalah karena Anda mengenal kode Anda, jalankan melalui inliner, dan kemudian kode Anda dapat menjadi agak tidak dapat dikenali. Saya menemukan bahwa ini membuatnya lebih sulit untuk memecahkan masalah. Mengatakan itu, jika ini adalah cara Anda ingin bekerja, itu bagus; tidak ada alasan teknis mengapa Anda tidak boleh melakukannya.

Jangan lupa: Anda tidak dapat menerapkan banyak kelas ke berbagai hal di email HTML karena tidak didukung. Setiap elemen dapat memiliki maksimal satu kelas.

Jangan lupa: Anda tidak dapat menggunakan singkatan untuk hal-hal seperti ukuran font (yaitu style = "font: 8px / 14px Arial, sans-serif;") karena tidak didukung.

Nama Gambar dan Skor SPAM

Saat menyimpan gambar, ingat bahwa sebaiknya Anda memberikan nama gambar yang pendek dan bermakna karena akan meningkatkan skor spam Anda. Nama seperti "campaign_054_design_0x0_v6_email-link.gif" cenderung memiliki skor SPAM yang jauh lebih tinggi daripada "email.gif".

Ukuran gambar

Ini juga merupakan ide bagus untuk mencoba menjaga seluruh email Anda sekecil mungkin secara manusiawi: di bawah 100kb ideal tetapi tidak selalu mungkin, di bawah 250kb cukup standar. Gunakan aplikasi kompresi seperti JPEGmini atau tinyPNG untuk memotong semua gambar Anda ke ukuran sebanyak mungkin sebelum Anda mengirim. Waktu pemuatan yang lebih lambat, terutama di seluler, dapat membuat atau menghancurkan email Anda jika ukuran file secara keseluruhan terlalu besar.

Gotchas lainnya

Jangan tinggalkan apa pun kepada klien email. Tentukan semua lebar Anda, karena jika tidak, Anda dapat berakhir dengan hasil yang tidak diharapkan. Untuk elemen penampung utama Anda, selalu tetapkan ukuran dalam piksel. Anda kemudian dapat menggunakan persentase di dalam elemen yang mengandung Anda jika Anda mau.

Kesimpulan

Ada banyak hal yang perlu dipertimbangkan ketika merancang dan mengembangkan email HTML, yang sebagian besar melibatkan standar "tidak belajar" yang telah Anda dorong untuk praktikkan untuk desain web selama bertahun-tahun. Namun, tutorial ini seharusnya memberi Anda dasar yang kuat untuk bekerja, dan Anda sekarang siap untuk terjun ke proses pembuatan yang sebenarnya. Dan seterusnya!

Link yang berguna

Saya mereferensikan beberapa hal selama tutorial ini - jadi di sini mereka lagi, semua di satu tempat.

Advertisement
Advertisement
Advertisement
Advertisement
Looking for something to help kick start your next project?
Envato Market has a range of items for sale to help get you started.