Ano ang Dapat Ninyong Malaman Tungkol sa HTML na Email

Ang Email ay kahanga-hangang paraan.  Ito ay diretsong pumupuntsa sa inbox at ang ROI nito ay laganap na iniuulat bilang nasa bubong ng 4000%.  Ito din ay habang-panahong hindi nauunawaan at lubhang madalas na masama ang pagkagawa.  Sa pamamagitan ng kamakailang pagsabog ng mga smartphone, mas madalas na binabasa natin ang ating email sa ating iPhone o Galaxy, ngunit sa kasamaang palad karamihan sa kalakalan ng email ang hindi nagtatagumpay na makasabay.  Nakikita ko na ito ay malaking pagkawala ng oportunidad dahil ang maayos na naisakatuparang email ay maaaring maging kasiya-siyang bukas at malaking tagumpay.

Ang Pagkocode ng HTML na Email ay Maaaring Maging Isang Hamon

Kung nasubukan na ninyo sa inyong kamay ang disenyo at pagbuo ng HTML na email, maaaring matatag na ang paniniwala ninyo na talagang mahirap ito.  At hindi ninyo ito guniguni —  talagang mahirap ito.  Narito ang dahilan:

Hindi Umiiral ang Pamantayan ng Email 

[Kami ay] patuloy na gagamit ng Word sa paglikha ng mga mensahe sa email dahil naniniwala kami na ito ang pinakamahusay na karanasan sa pagsulat ng email sa paligid.

Ang Pangkat ng Outlook

Kapag kayo nagcode para sa web, sa pinakamaliit ay maaari ninyong mabilang ang katotohanan na lahat ng pangunahing mga browser( Chrome, Firefox, Internet Explorer, Safari at Opera) ay sinusubukang umayon sa mga pamantayan ng web para sa paggagawad ng HTML and CSS.

Pag dating sa mga kliyente ng email, sinusubukan ninyo ang malaking kumpol ng luma at bagong mga programa.  Ang mga ito ay sumasaklawa sa pagitan ng mga bagong telepono na tumatakbo sa Android at iOS na IBM’s Lotus Notes o Microsoft Office 2007 (na nakakahiyang naggagawad sa inyong buong pagmamahal na nilikhang HTML sa pamamagitang ng Word HTML na naggagawad na makina.  Ang mga nakaraang mga bersyon ng Outlook ay gumamit ng browser upang igawad ang kanilang HTML —  na talagang makatwiran. Bakit lilipat sa tagaproseso ng word upang maggawad ng HTML itinatanong ninyo?  Siya, para sa “mga dahilang pangkaligtasan”, sabi nila).  At wala sa mga programang ito ang umaayon sa anumang mga pamantayan.  Ang lahat ng mga ito ay talagang ginawa lamang.  Makikita ninyo kung ano ang hitsura ng mga pamantayang suporta katulad ng ilan sa pinakatanyag na mga kliyente ng Email Standards Project.

Kung hindi pa sapat ang kasamaan nito, idagdag pa dito ang kasunod na katotohanan: mayroong halos isang milyong iba’t ibang mga kombinasyon ng mga paraan na ang email ay maaaring igawad sa desktop at mobayl.

Narito ang listahan ng ilan sa mga pinakakaraniwang mga kliyente ng email:

Mga Kliyente ng Mobayl:

• Android 2.3 at 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

Mga Kliyente ng 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

Mga Kliyente ng Webmail:

• AOL Mail (sa anumang browser)
• Gmail (sa anumang browser)
• Outlook.com (sa anumang browser)
• Yahoo! (sa anumang browser)

Iyon ay napakaraming mga aparato!

Kung alam na ninyo ang pagbuo ng web, kalimutan na ang lahat ng alam ninyo tungkol dito.

Upang timplahin ang lahat ng ito, ang kondisyonal nap ag-iistilo ay hindi din masyadong pagpipilian.  Mayroon kayong ilang mga bagay na maaaring gawin sa kondisyonal na mga komento, ngunit ito ay limitado sa pagtarget sa tiyak na mga bersyon ng Outlook, o lahat maliban sa tiyak na mga bersyon ng Outlook.

Kung alam na ninyo ang pagbuo ng web, kalimutan na ang lahat ng alam ninyo tungkol dito. Ang isa sa pinakamalaking sagabal sa inyo ay ang pag-asa na ang lahat ng bagay ay gagana katulad ng ‘normal’ na pagbuo ng web.  Ito ay bibigo sa inyo at pipigil sa inyo.  Ang pinakamasamang bagay na maaari ninyong gawin ay magalit na hindi ninyo magamit ang mga DIV o iyong ang puwang sa gilid ay hindi ganap na suportado.  Kaya kalimutan lahat ng alam ninyo tungkol sa semantic na HTML at ang pinakahuling spec ng CSS.  Pagkatiwalaan ninyo ako, makatutulong ito.

Paano Lapitan ang Inyong Trabaho

Tinganan natin ang ilan sa mga mungkahi sa daloy ng trabaho sa paggawa ng email.

Magsimula Muna ng Istruktural

Ang paggawa ng istruktura muna ng istruktura ng inyong email ang unang makakatulong sa inyo upang maiwasan ang madaming mga bug at mga problema mamaya pababa sa daan.  Huwag kailanman gawin ang buong bagay at pagkatapos ay subukin – maaaring madalas kayong magtapos na masyaong maraming mga bug na dapat harapin, at maaaring lahat ng ito ay umepekto sa bawat isa.

Subukin ng Madalas

Magtrabaho hanggang marating ninyo ang maliit na milyahe sa pagbuo (halimbawa, kapag natapos na ninyo ang batayang istruktura) at pagkataposa ay subukang paandarin. Ang pinakamahusay na paraan ay subukin gamit ang Litmus o Email sa Acid. Ipinapayo ko ang pagkuha ng walang hangganang plano maging alinman sa mga kumpanyang ito dahil ang kakayahang masubok ng madalas ay talagang mahalaga.

Talagang gusto ko ring iwan sa lahat ang mga hangganan ng talaan ko upang makita ko kung ano ang nililikha ko, pagkatapos ay pinapatay ko silang lahat sa huliI.  Maaari niyo rin marahil kulayan ang likuran ng tiyak na mga cell upang makatulong na Makita kung aling mga seksyon ang nasaan. Ang uliran kong daloy na trabaho ay ang lumikha ng balangkas, subukan, pagkatapos idagdag ang mga nilalaman ko, subukan, iistilo ang mga kulay at mga font, subukang muli at panghuli tanggalin ang mga hangganan at subukang muli bago ipadala.

Patunayan ng Madalas

Patunayan ito gamit ang W3C Validator kasing dalas ng posibleng kaya ninyo. Ito ay makakatulong sa inyong plantsahin ang maliliit na mga detalye at ito ay pipiliin ang mga mali katulad ng nawawala o bukas na mga panandas.

Pagpapadala ng Inyong Email

Mayroong malaking bilang ng mga pagpipilian pagdating sa pagpapadala ng inyong email.  Ang dalawang mga serbisyo na ginagamit ko ng madalas ay ang MailChimp at Campaign Monitor. Ang mga ito ay naghahandog ng nakikipagpaligsahang presyo at ang mga ito ay napakadaling gamitin.  Mayroon ding mga nagdadala ng komersyal na mga plataporma – ang lahat ng ito ay depende sa inyong mga pangangailangan.  Mag-sign up para sa libreng account maging alinman sa mga ito at magkaroon ng paghihinang sa kanilang mga sistema upang Makita kung alin ang isang gusto ninyo.  Siguraduhing nagagamit ninyo ang kapaki-pakinabang na datos na kinokolekta ng parehong mga serbisyo tungkol sa inyong mga email, katulad ng bukas na mga oras at paggamit ng kliyente sa email.  Ito ay talagang makakatulong sa inyo na itutok ang inyong mga paghihirap sa tamang lugar sa sunod na panahon na magpadala kayo.

Nilalaman, Pagbuo at Mga Puntos ng SPAM

Pagdating sa SPAM; ang nilalaman, disensyo at pagbuo ay pumupunta lahat ng sabay-sabay.  Mahalagang iwasan ang karaniwang ma-spam na mga taktika katulad ng paggamit ng malalaking titik at madaming mga tandang pandamdam sa inyong linya ng paksa. Mayroong tiyak na mga salita na malamang nakakalabit din sa mga salaan ng SPAM (katulad ng ‘libre’ at ‘mamuhunan’).  Kapag mas malinis ang inyong code, mas malamang na hindi mamamarkahang SPAM ang inyong email, at ang proporsyon ng mga larawan sa teksto ay mayroon ding epekto.  Ang umaasa sa larawang mga email na walang teksto ay mas malamang na mamarkahang SPAM at pati na rin ang mga email na may talagang mahabang mga pangalan ng file ng larawan.

Ang mundo ng mga puntos ng SPAM ay isang mapaglalang at mahalagang magpatakbo ng pagsubok sa SPAM sa pamamagitan ng pagsubok sa inyong account sa Litmus o Email sa Asido bago ipadala ang inyong email, upang masiguradong lahat ng inyong pinaghirapan ay hindi papunta diretso sa folder ng Junk.

Pagsisid sa Pagbuo

Ngayon, para sa pinakamahalang bahagi ng pagbuo ng email..

Mga Kasangkapan para sa Kalakalan

Kakailanganin ninyo ng tagapagnugot ng teksto na gusto ninyo katulad ng (ginagamit ko ang Sublime na Teksto) at ang pagsubok ng account sa pamamagitan ng Litmus o Email sa Acid.  Labis kong ipanapayo ang pagkakaroon ng walang hangganang account ng pagsubok sa alinman sa mga kumpanyang ito sapagkat ito ay magpapadali ng sobra sa buhay ninyo.  Kapag hindi kayo nagbayad ng buwanang singil, hahantong kayo sa pagbabayad sa pagitan ng $3 at $5 sa bawat pagsubok na maaaring magdagdag ng mabilis.

Pagsisimula sa Mabuting Batayan

Sa palagay ko ay mabuting magsimula sa sa walang lamang talaan.  Ang mga balangkas katulad ng HTML Email Boilerplate ay puno ng kahanga-hangang mga paglalalang at mga piraso na maaari ninyong isagawa ng piraso bawat piraso. Ngunit, kung kayo ay nagsisimula pa lamang hindi ko ipinapayong gamitin ito bilang panimulang punto sapagkat naglalaman ito ng napakaraming mga element na hindi ninyo kakailanganin.  Ang mga Boilerplate ay maaaring gawin itong mas mahirap ayusin ang anumang mga probleama kung mayroong napakaraming hindi nagamit na code sa inyong file.

Itala: Dahil maaaring maging napakawalang katiyakan ang paggamit ng anumang uri ng tagapamatnugot (lalo na pagdating ng panahon ng pagsasaayos), hindi ninyo dapat gamitin kailanman ang WYSIWYG na tagapamatnugot, o anumang uri ng tagapamatnugot na nangangako na dalhin ang inyong nakaayos na disenyo at nakapagtatakang gawin itong makatwirang HTML para sa pag-eemail.  Ang bagay na ito ay hindi kailanman gumagana.

!DOCTYPE

Ito ay maaaring magmukhang teknikal na detalye na maaaring pagsimulan, ngunit kailangan ninyo ng walang lamang template upang makapagsimulang magtrabaho, at ang template na iyon ay kailangang Doctype. Ang doctype ay mahalagang linya ng code na nagpapaala, sa programang nagbabasa nito kung aling mga pananda ng HTML ang dapat asahan at kung aling pangkat ng mga tuntunin ang aayunan ng HTML at CSS.  Sadyang ilang mga kliyente ang tinatanggal ang inyong Doctype, at maging ang ilan ay ginagamit ang kanilang sarili.  Madaming mga kliyente ang kumikilala sa inyong doctype at ito ay gagawing mas napakadali ng mga bagay kung kaya mong palaging patunayan laban sa Doctype.

Ang paggamit ng XHTML na doctype sa pangkalahatan ay may pinakakaunting mga biro at mga pagkakasalungatan sa pagitan ng mga dokumento.  Ginagamit ko ang XHTML 1.0 Transitional dahil napatunayan na nito ang sarili nito bilang pinakamapagkakatiwalaang doctype sa karanasan ko.  Sa sumusunod na tutoryal, sa pagkakataong gagawa tayo ng buong HTML na email na template, gagamitin nating ang sumusunod na code upang simulant ang ating dokumento:

1

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

2

<html xmlns="http://www.w3.org/1999/xhtml">

3

<head>

4

<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />

5

<title>Demystifying Email Design</title>

6

<meta name="viewport" content="width=device-width, initial-scale=1.0"/>

7

</head>

Ang Content-Type ng meta na pananda ay para sa pagsasabi sa pupuntahang maggagawad na makina kung paano iproseso ang teksto at espesyal na mga titik.  Sa katotohanan, kailangan ninyong tipahin ang lahat ng inyong espesyal na titik gayon pa man (halimbawa, & becomes & para sa ampersand)  upang maging ligtas, ngunit gayon pa man karapat-dapat panatilihin ang linyang ito doon.

Ang viewport meta na pananda ay nagsasabing ang aparato na iayos sa nakikitang lugar sa lapad na screen ng aparato. Ito din ang nagtatakda ng panimulang iskala sa ‘normal’ na hindi nakazoom paloob o palabas.  Ito din ang nagtatakda ng panimulang iskala sa ‘normal’ na hindi nakazoom paloob o palabas.  Kapag hindi ninyo tinukoy ito, maraming mga smartphone ang maaaring mag-isakala pababa ng inyong nilalaman upang magkasya ang nilalaman sa loob ng nakikitang lugar, ngunit hindi ang anuman sa mga palaman o hangganan nito.  Ito ay maaaring magdulot ng teksto at mga larawan na hanggang gilid ng screen.

Panghuli, palaging ipasok ang makabuluhang titulo dahil ito amg makikita ng mga tao kapag tiningnan nila ang email sa browser, o ibahagi sa kanilang mga kaibigan.

Ang Email ay Tungkol Lahat sa Pagpupugad ng Talaan

Dahil sa kakulangan ng pamantayang suporta sa email, hindi posibleng gumamit ng mga div, mga seksyon o mga artikulo – sa halip dapat kayong gumamit ng mga talaan. Dagdag pa dito, kailangan ninyong gumamit ng napakarami at napakaraming nagpupugad na mga talaan dahil wala anuman sa colspan o rowspan na mga katangian ang suportado ng tama.

Mga Talata o Mga Cell?

Muli, dahil sa kakulangan sa pamantayang suporta, hindi magandang ideya na gumamit ng pamantayang mga pananda katulad ng h1, h2, h3 o p. Natagpuan ko na ang mga ito ay kayang gawaran ng talagang walang katiyakan sa kabila ng email sa mga kliyente at kayang makalikha ng ilang malalaking sakit sa ulo.

Ang pinakamahusay ninyong taya ay ilagay ang bawat bloke ng teksto sa sarili nitong cell at gamitin ang nasa linyang pag-iistilo sa cell na iyo, halimbawa:

1

<tr>

2

 <td style=“font-size: 12px; font-family: Arial, sans-serif; color: #666666;”>

3

   Text

4

 </td>

5

</tr>

Nasa Linyang mga Istilo o Mga Pilas ng Istilo?

Ang isang ito ay mas personal na pili.  Gusto kong panatilihin ang lahat ng mga istilo ko na nasa linya (halimbaw: sa loob ng mga HTML na mga pananda sa sarili nila) dahil gusto kong malaman nang ganap kung nasaan ang lahat at kung ano ang nakakaapekto sa kung ano. Maaari kayong magcode gamit ang mga istilo at pagkatapos ay hilahin lahat ang mga ito sa huli sa nasa linya (Campaign Monitor and MailChimp ay kayang gawin ito para sa inyo ng awtomatiko, maaari din ninyong gamitin ang Premailer o bagay na katulad) ngunit ang dahilan kung bakit ayaw ko to ay dahil makikiala ninyo ang inyong code, papatakbuhin ninyo ito sa inliner, at pagkatapos ang inyong code ang maaaring maging medyo mahirap kilalanin.  Natagpuan ko na ito ay mas nagpapahirap sap ag-aayos.  Nang nasabi iyan, kung ito ang paraan na gusto ninyong gamitin, ayos lamang ito; walang teknikal na dahil kung bakit hindi ninyo dapat gawin ito.

Huwag kalimutan: Hindi kayo maaaring gumamit ng maramihang mga uri sa mga bagay sa HTML na mail dahil hindi ito suportado.  Bawat element ay maaaring magkaroon ng pinakamataas na isang uri.

At huwag ding kalimutan: Hindi kayo maaaring gumamit ng pinaikling sulat para sa mga bagay katulad ng sukat ng font (halimbawa style="font: 8px/14px Arial, sans-serif;") dahil hindi ito suportado.

Mga Pangalan ng Larawan at Mga Puntos ng SPAM

Kapag nagsesave ng mga larawan tandaan na mabuting bigyan ang inyong mga larawan ng pangalan na maikli at makabuluhan dahil ito ay magpapaunlad sa inyong puntos sa spam. Ang mga pangalan katulad ng "kampanya_054_disenyo_0x0_v6_email-link.gif" ay malamang magkaroon ng mas mataas na puntos sa SPAM kaysa sa "email.gif".

Sukat ng Larawan

Matinding ideya din na subukang panatilihin ang inyong buong email na pinakamaliit na kaya ng tao: mababa sa 100kb ang uliran ngunit hindi laging possible, mababa sa 250kb ay pamantayan.  Gumamit ng pampigang app katulad ng JPEGmini o tinyPNG upang putulin lahat ng inyong mga larawan pababa sa sukat hangga’t maaari bago ninyo ipadala.  Ang mas mabagal na mga oras ng pagloload, lalo na sa mobayl, ay maaaring makabuo o makasira sa inyong email kung ang kabuuang sukat ng file ay masyadong malaki.

Ibang mga Gotcha

Huwag iwan ang anumang bagay sa kliyente ng email.   Tukuyin lahat ng inyong mga lapad, dahil kung hindi maaari kayong magwakas sa hindi inaasahang mga resulta. Para sa inyong pangunahing mga lalagyan ng mga element palaging isaayos ang sukat sa mga pixel.  Maaari kayong gumamit ng mga porsiyento sa loob ng inyong naglalamang element kung gusto ninyo.

Konklusyon

Mayroon napakaraming dapat isaalang-alang kapag nagdidisenyo at nagbubuo ng HTML na email, karamihan sa mga ito ay may kasamang “pagkalimot” sa mga pamantayang hinimok kayong sanayin para sa pagdidisenyo ng web sa paglipas ng mga taon.  Ngunit, ang tutoryal na ito dapat ay nagbigay sa inyo ng matatag na batayan na pagtatrabahuhan, at ngayon ay handa na kayong tumalon sa tunay na proseso ng paggawa.  Pasulong!

Kapaki-pakinabang na mga Link

Isinangguni ko ang ilang mga bagay sa panahon ng tutoryal na ito – kaya nandito muli ang mga ito, sa isang lugar.

• Litmus na mga kasangkapan sa pagsubok
• Email sa Acid na mga kasangkapan sa pagsubok
• Ang Outlook Team Blog
• Ang Litmus Team Blog
• Ang Email Standards Project
• W3C Validator
• MailChimp
• Campaign Monitor
• Premailer, pagsusuri bago ang paglipad para sa mga email
• JPEGmini na kasangkapan sa pagpiga ng larawan
• tinyPNG na kasangkapan sa pagpiga ng larawan
• Sublime na Teksto, ang mas gusto kong tagapamatnugot
• Magsabi ng Hello sa HTML Email Boilerplate
• Huwag Kalimutan ang Viewport Meta Tag
• Icon ng Thumbnail ng Pierre Borodin