HTML ईमेल के बारे में आपको क्या पता होना चाहिए

ईमेल एक बहुत बढ़िया माध्यम है। यह सीधे इनबॉक्स में जाता है और इसकी ROI को 4000% रूफ के माध्यम से व्यापक रूप से बताया जाता है। यह भी हमेशा गलत समझा जाता है और अक्सर यह बुरी तरह से किया जाता है। स्मार्टफोन्स के हालिया विस्फोट के साथ, हम अक्सर हमारे आईफोन या गैलेक्सी पर हमारी मेल पढ़ रहे हैं, लेकिन दुर्भाग्य से बहुत सारे ई-मेल मार्केटिंग को जारी रखने में असफल रहे है। मैं इसे एक विशाल चूक के अवसर के रूप में देखता हूं क्योंकि एक अच्छी तरह से निष्पादित ईमेल खुले और बेहद सफल भी हो सकता है।

HTML ईमेल कोडिंग एक चुनौती हो सकती है

यदि आप पहले से ही HTML ईमेल डिज़ाइन और डेवलपमेंट में अपना हाथ आजमा चुके हैं, तो संभवतः आपने पहले ही स्थापित किया है कि यह बहुत मुश्किल हो सकता है। और आप इसकी कल्पना नहीं कर रहे हैं - यह काफी कठिन है। यहाँ पर क्यों:

ईमेल मानक मौजूद नहीं है

[हम ई-मेल संदेशों को बनाने के लिए शब्द का उपयोग करना जारी रखेंगे] क्योंकि हमें लगता है कि यह सबसे अच्छा ई-मेल संलेखन अनुभव है।

The Outlook Team

जब आप वेब के लिए कोड करते हैं, तो आप कम से कम इस तथ्य पर भरोसा कर सकते हैं कि सभी प्रमुख ब्राउज़रों (Chrome, Firefox, Internet Explorer, Safari और Opera) HTML और CSS के लिए वेब मानकों का पालन करने का प्रयास कर रहे हैं।

जब यह ईमेल क्लाइंट की बात आती है, तो आप पुराने और नए कार्यक्रमों की एक बड़ी झुंड पर परीक्षण कर रहे हैं। वे IBM के लोटस नोट्स या Microsoft Office 2007 (जो आपके Word HTML rendering engine के साथ अपने प्यार-रूप से निर्मित HTML को बदनाम करते हैं। Android और iOS पर चलने वाले नए फोन से लेकर हैं। आउटलुक के पिछले संस्करणों ने अपने HTML के लिए एक ब्राउज़र का इस्तेमाल किया - जो वास्तव में है तार्किक। HTML को प्रस्तुत करने के लिए एक वर्ड प्रोसेसर को क्यों स्विच करना चाहिए? ठीक है, "security reasons" के लिए, वे कहते हैं)। और इन कार्यक्रमों में से कोई भी किसी मानदंड का पालन नहीं करना है। वे मूल रूप से सभी बस इसे ऊपर बनाते हैं। आप देख सकते हैं कि मानकों का समर्थन Email Standards Project के कुछ सबसे लोकप्रिय ईमेल क्लाइंट के लिए कैसा दिखता है।

यदि यह काफी बुरा नहीं है, तो जोड़े जो कि अगले तथ्य के साथ: लगभग दस लाख अलग-अलग तरीके हैं जो ईमेल डेस्कटॉप और मोबाइल पर रेंडर कर सकते हैं।

यहां कुछ सबसे आम ईमेल क्लाइंट की सूची है:मोबाइल ग्राहक:

Mobile clients:

• 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

Desktop clients:

• 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

Webmail clients:

• AOL Mail (on any browser)
• Gmail (on any browser)
• Outlook.com (on any browser)
• Yahoo! (on any browser)

यह बहुत सारे डिवाइस हैं!

यदि आप पहले से ही वेब डेवलपमेंट से परिचित हैं, तो इसके बारे में सब कुछ भूल जाओ।

इस सब को परिसर करने के लिए, नियमबद्ध स्टाइल एक विकल्प का अधिकतर नहीं है। ऐसी कुछ चीजें हैं जो आप नियमबद्ध टिप्पणियों के साथ कर सकते हैं, लेकिन आउटलुक के कुछ निश्चित संस्करणों को लक्षित करने के लिए सीमित है, या Outlook के कुछ खास संस्करणों को छोड़कर।

यदि आप पहले से ही वेब डेवलपमेंट से परिचित हैं, तो इसके बारे में सब कुछ भूल जाओ। आपके लिए सबसे बड़ी बाधा, 'normal' वेब डेवलपमेंट की तरह काम करने की उम्मीद कर रही है। यह आपको निराश करेगा और आपको वापस पकड़ देगा। सबसे बुरी बात आप कर सकते हैं गुस्से में है कि आप DIVs का उपयोग नहीं कर सकते हैं या वह margin पूरी तरह से समर्थित नहीं है। तो आपको सिमेंटिक HTML और नवीनतम CSS स्पेक के बारे में सब कुछ पता है। मुझ पर भरोसा करे, इससे मदद मिलेगी।

अपना काम कैसे करें

आइए कुछ ईमेल-निर्माण वर्कफ़्लो सुझावों पर एक नज़र डालें।

संरचनात्मक रूप से पहले कार्य करें

अपने ईमेल की संरचना का निर्माण पहले आपको ट्रैक के नीचे कई बग और मुद्दों से बचने में मदद कर सकता है। कभी भी पूरी चीज का निर्माण न करें और फिर परीक्षण करें - आप अक्सर निपटने के लिए बहुत से बगों के साथ खत्म हो सकते हैं, और वे सभी एक-दूसरे को प्रभावित कर सकते हैं।

टेस्ट अक्सर

काम जब तक आप एक मामूली डेवलपमेंट मील का पत्थर (उदाहरण के लिए, जब आप बुनियादी संरचना खत्म) तक पहुँचने और फिर एक परीक्षण चलाने। परीक्षण करने का सबसे अच्छा तरीका Litmus या Email on Acid का प्रयोग कर रहे है। मैं इन कंपनियों में से किसी के साथ एक असीमित योजना लेने की सलाह देता हूं।क्योंकि अक्सर परीक्षण करने में सक्षम होने के नाते वास्तव में महत्वपूर्ण है।

मैं भी वास्तव में मेरी सारी टेबल बॉर्डर्स में छोड़ना पसंद करता हूं ताकि मैं देख सकूं कि मैं क्या बना रहा हूं, फिर मैं उन्हें अंत में बंद कर देता हूं। आप यह भी देख सकते हैं कि कौन सा वर्ग हैं। मेरे आदर्श वर्कफ़्लो को कंकाल बनाना, परीक्षण करना है, फिर मेरी कंटेंट, टेस्ट, शैली को रंग और फोंट जोड़ना है, फिर से परीक्षण करना और अंत में मेरे बॉर्डर्स निकालने और भेजने से पहले फिर से परीक्षण करना है।

अक्सर पूछें

जितनी बार संभवतः आप W3C Validator का उपयोग करके इसे मान्य करें। यह आपको छोटे विवरणों को बाहर करने में मदद करेगा और यह लापता या खुले टैग की गलतियों पर उठाएगा।

आपका ईमेल भेजना

आपके ईमेल भेजने की बात आती है तो बड़ी संख्या में विकल्प होते हैं। दो सेवाओं जो मैं सबसे ज्यादा इस्तेमाल करता हूँ, MailChnimp और Campaig Monitor हैं। वे प्रतिस्पर्धी मूल्य की पेशकश करते हैं और वे उपयोग करने में बहुत आसान हैं। वाणिज्यिक प्लेटफार्मों का भार भी है - यह सब आपकी ज़रूरतों पर निर्भर करता है। इन दोनों में से किसी एक के साथ एक निशुल्क खाता के लिए साइन अप करें और अपने सिस्टम में एक टिंकर रखे, यह देखने के लिए कि आपको कौन पसंद है। सुनिश्चित करें कि आप उपयोगी डेटा का उपयोग करते हैं जो दोनों सेवाओं को आपके ईमेल के बारे में इकट्ठा करती हैं, जैसे कि खुले समय और ईमेल क्लाइंट उपयोग अगली बार जब आप भेजते हैं। तो यह सही क्षेत्र में आपके प्रयासों को ध्यान में रखकर आपकी मदद कर सकता है।

कंटेंट, डेवलपमेंट और स्पैम स्कोर

जब यह स्पैम की बात आती है; कंटेंट, डिजाइन और डेवलपमेंट सभी हैंड इन हैंड हैं। अपने विषय पंक्ति में सभी कैप्स और विस्मयादिबोधक बिंदुओं का उपयोग करने जैसी विशिष्ट स्पैमिक रणनीति से बचने के लिए महत्वपूर्ण है। ऐसे कुछ शब्द हैं जो स्पैम फ़िल्टर को भी ट्रिगर करने की संभावना रखते हैं (जैसे 'free' और 'invest')। क्लीनर आपका कोड, आपके ईमेल को स्पैम के रूप में चिह्नित करने की संभावना कम है, और इमेजेज के टेक्स्ट के अनुपात का भी प्रभाव पड़ता है। कोई टेक्स्ट के साथ इमेज-निर्भर ईमेल अधिक स्पैम के रूप में चिह्नित होने की संभावना है और इसलिए वास्तव में लंबी इमेज फ़ाइल नाम वाली ईमेल हैं।

स्पैम स्कोर की दुनिया एक बहुत मुश्किल है और यह सुनिश्चित करने के लिए कि आपके सभी कड़ी मेहनत सीधे जंक फ़ोल्डर के लिए नहीं हैं, लिमिट्स के साथ अपने परीक्षण खाते या एसिड पर ईमेल के जरिए स्पैम परीक्षण चलाने के लिए महत्वपूर्ण है।

डेवलपमेंट में डाइविंग

अब, ई-मेल के डेवलपमेंट के निट्टी-ग्रिटी के लिए ..

व्यापार के उपकरण

आपको एक टेक्स्ट एडिटर की आवश्यकता होगी जो आपको पसंद है (मैं Sublime Text का उपयोग कर रहा हूं) और लिटमस या एसिड पर ईमेल वाला टेस्ट अकाउंट। मैं अत्यधिक इन कंपनियों में से किसी के साथ एक असीमित टेस्ट अकाउंट रखने की सलाह देता हूं क्योंकि इससे आपका जीवन इतना आसान होगा। यदि आप मासिक शुल्क का भुगतान नहीं करते हैं, तो आप प्रति टेस्ट $3 और $5 के बीच का भुगतान करेंगे, जो कि बहुत जल्दी से जोड़ सकते हैं।

एक अच्छे आधार के साथ शुरू

मुझे लगता है कि यह एक खाली स्लेट के साथ शुरू करना अच्छा है। HTML Email  Boilerplate की तरह फ़्रेमवर्क अद्भुत चीजें और स्निपेट्स से भरे हुए हैं जिन्हें आप पीस ब्य पीस को लागू कर सकते हैं। हालांकि, यदि आप अभी शुरू कर रहे हैं तो मैं इसे एक प्रारंभिक बिंदु के रूप में प्रयोग करने की अनुशंसा नहीं करता क्योंकि इसमें बहुत सारे तत्व हैं जिनकी आपको आवश्यकता नहीं होगी। Boilerplates अक्सर किसी भी समस्या का निवारण करना अधिक कठिन बना सकता है अगर आपकी फ़ाइल में बहुत अधिक अप्रयुक्त कोड है।

Note: क्योंकि यह किसी भी प्रकार के एडिटर (विशेषकर जब समस्या निवारण का समय आ सकता है) का उपयोग करने के लिए बहुत अनिश्चित हो सकता है, तो आपको कभी भी एक WYSIWYG एडिटर या किसी भी प्रकार का एडिटर का उपयोग नहीं करना चाहिए जो आपके स्वरूपित डिजाइन को लेने का वादा करता है और उसे वैध HTML में बदल देता है। ईमेल के लिए यह सामान अभी काम नहीं करता है!

!DOCTYPE

इससे शुरू करना तकनीकी विवरण की तरह लग सकता है, लेकिन आप के साथ काम करना शुरू करने के लिए खाली टेम्पलेट की आवश्यकता है, और उस टेम्पलेट को डॉकटाइप की आवश्यकता है। एक सिद्धांत अनिवार्य रूप से कोड की एक पंक्ति है जो इसे प्रोग्राम को पढ़ने के लिए सूचित करता है जो HTML टैग की अपेक्षा करता है और जो HTML और CSS नियमों का पालन करते हैं। बहुत सारे कुछ क्लाइंट अपने डॉकटाइप को बाहर कर देते हैं, और कुछ स्वयं को लागू करते हैं। कई ग्राहक आपके सिद्धांत का सम्मान करते हैं और अगर आप डॉकटाइप के खिलाफ लगातार पुष्टि कर सकते हैं तो इससे चीजें बहुत आसान हो सकती हैं।

XHTML के सिद्धांत का प्रयोग आम तौर पर डाक्यूमेंट्स के बीच सबसे कम क्विर्ट और विसंगतियां होती है। मैं XHTML 1.0 ट्रांस्क्रिप्शनल का उपयोग करता हूं क्योंकि यह अपने अनुभव में सबसे विश्वसनीय सिद्धवादी सिद्ध हो गया है। निम्नलिखित ट्यूटोरियल में, जिसके दौरान हम एक पूर्ण HTML ईमेल टेम्पलेट बनाएंगे, हम अपने डॉक्यूमेंट को शुरू करने के लिए निम्न कोड का उपयोग करेंगे:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
<title>Demystifying Email Design</title>
<meta name="viewport" content="width=device-width, initial-scale=1.0"/>
</head>

content-Type मेटा टैग गंतव्य रेंडरिंग इंजन को कहने के लिए है कि टेक्स्ट और विशेष वर्णों को कैसे संसाधित किया जाए। वास्तव में, आपको अपने सभी विशेष वर्णों को भी सांकेतिक शब्दों में बदलना होगा (उदाहरण के लिए, और ऐंपरसेंड के लिए & amp;) लेकिन यह लाइन वैसे भी रखने योग्य है।

viewport meta tag डिवाइस को स्क्रीन के क्षेत्र की चौड़ाई में देखने योग्य क्षेत्र सेट करने के लिए डिवाइस को बता रहा है। यह प्रारंभिक पैमाने को 'normal' पर सेट करता है जो न तो ज़ूम और न ही बाहर है। यदि आप इसे निर्दिष्ट नहीं करते हैं, तो कई स्मार्टफोन आपकी कंटेंट को नीचे बढ़ा सकते हैं ताकि कंटेंट को देखने योग्य क्षेत्र में फिट हो, लेकिन इसके किसी भी पैडिंग या मार्जिन में नहीं। इसके परिणामस्वरूप स्क्रीन के किनारे के ऊपर टेक्स्ट और इमेजेज बचे हैं।

अंत में, हमेशा एक अर्थपूर्ण शीर्षक दर्ज करें क्योंकि यह वह व्यक्ति है, जब वह किसी ब्राउज़र में ईमेल देखेगा, या अपने दोस्तों के साथ साझा करेगा।

ईमेल नेस्टिंग टेबल्स के बारे में सब कुछ

ईमेल में मानकों के समर्थन की कमी के कारण, divs, sections या articles का उपयोग करना संभव नहीं है - इसके बजाय आपको tables का उपयोग करना पड़ता है। इसके अलावा, आपको बहुत से और नेस्टेड टेबल्स का उपयोग करने की आवश्यकता है क्योंकि न तो colspan और न ही rowspan भी ठीक से समर्थित हैं।

पैराग्राफ या सेल?

फिर से, मानकों के समर्थन की कमी के कारण, यह h1, h2, h3 या p जैसे मानक टैगों का उपयोग करने के लिए एक महान विचार नहीं है। मुझे लगता है कि ये ई-मेल क्लाइंट्स में वास्तव में असंगत रूप से प्रस्तुत कर सकते हैं और कुछ बहुत बड़े सिरदर्द बना सकते हैं।

आपका सबसे अच्छा शर्त यह है कि टेक्स्ट के प्रत्येक ब्लॉक को अपने सेल में रखा जाए और उस सेल में इनलाइन स्टाइल लागू हो, उदाहरण के लिए:

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

इनलाइन स्टाइल्स या स्टाइलशीट्स?

यह एक व्यक्तिगत पसंद है। मैं अपने सभी स्टाइल्स इनलाइन (यानी: HTML टैग्स के भीतर खुद को) रखना पसंद करता हूं क्योंकि मुझे यह जानना अच्छा लगता है कि सबकुछ क्या है और जो कुछ भी प्रभावित कर रहा है। आप स्टाइल्स का उपयोग कर कोड कर सकते हैं और फिर उन्हें अंत में सभी को इनलाइन खींच सकते हैं (अभियान मॉनिटर और MailChimp आपके लिए यह स्वचालित रूप से कर सकता है, आप Premailer या कुछ इसी तरह का भी उपयोग कर सकते हैं) लेकिन इसका कारण मुझे यह पसंद नहीं है क्योंकि आपको पता चल जाता है आपके कोड, इसे एक इनलाइनर के माध्यम से चलाएं, और फिर आपके कोड कुछ अज्ञात हो सकते है। मुझे लगता है कि इससे समस्या निवारण करना कठिन होता है। यह कहकर, अगर आप जिस तरीके से काम करना चाहते हैं, तो ठीक है; कोई तकनीकी कारण नहीं है कि आपको ऐसा क्यों नहीं करना चाहिए।

भूल न करें: आप HTML ईमेल में चीजों के लिए एकाधिक क्लासेज लागू नहीं कर सकते हैं क्योंकि यह समर्थित नहीं है। प्रत्येक तत्व में अधिकतम एक क्लास हो सकती है। प्रत्येक तत्व में अधिकतम एक क्लास हो सकती है।

इसके अलावा यह भी मत भूलें: आप फ़ॉन्ट आकार (जैसे स्टाइल = "font: 8px / 14px Arial, sans-serif;") जैसी चीज़ों के लिए लघुकोड का उपयोग नहीं कर सकते क्योंकि यह समर्थित नहीं है।

इमेज नाम और स्पैम स्कोर

इमेजेज को सेव करते समय याद रखें कि आपकी इमेजेज के नामों को देना अच्छा है जो छोटे और सार्थक हैं क्योंकि यह आपके स्पैम स्कोर को बेहतर बनाता है। जैसे नाम "campaign_054_design_0x0_v6_email-link.gif" "email.gif" की तुलना में बहुत अधिक स्पैम स्कोर होने की संभावना है।

इमेज का आकार

मानव जाति के रूप में अपने संपूर्ण ईमेल को छोटा रखने का प्रयास करने के लिए यह वास्तव में एक महान विचार है: 100kb के नीचे आदर्श है लेकिन हमेशा संभव नहीं, 250kb के तहत बहुत मानक है। JPEGmini या tinyPNG जैसे एक कम्प्रेशन  ऐप का उपयोग करें, अपनी सभी इमेजेज को आकार भेजने के लिए जितना संभव हो सके, इससे पहले कि आप भेज दें। धीमी लोड बार, विशेष रूप से मोबाइल पर, आपके ईमेल को बना या तोड़ सकता है यदि समग्र फ़ाइल आकार बहुत बड़ा है।

अन्य गोचः

ईमेल क्लाइंट तक कुछ भी मत छोड़ें। अपनी सभी चौड़ाई निर्दिष्ट करें, क्योंकि अन्यथा आप अनपेक्षित परिणामों के साथ समाप्त कर सकते हैं। आपके मुख्य कंटेनर तत्वों के लिए हमेशा आकार पिक्सल में सेट करे। यदि आप चाहते हैं तो आप अपने युक्त तत्व के भीतर प्रतिशत का उपयोग कर सकते हैं।

निष्कर्ष

HTML ईमेल डिज़ाइन और विकसित करते समय खाते में बहुत कुछ लेना पड़ता है, जिनमें से अधिकांश में "un-learning" मानकों को शामिल किया गया है जो आपको वर्षों में वेब डिज़ाइन के लिए अभ्यास करने के लिए प्रोत्साहित किया गया है। हालांकि, इस ट्यूटोरियल से आपको काम करने के लिए एक ठोस आधार देना चाहिए था, और अब आप वास्तविक निर्माण प्रक्रिया में कूदने के लिए तैयार हैं। आगे!

उपयोगी कड़ियाँ

मैंने इस ट्यूटोरियल के दौरान कुछ चीजों का संदर्भ दिया - तो ये फिर से, सभी एक स्थान पर हैं।

• Litmus testing tools
• Email on Acid testing tools
• The Outlook Team Blog
• The Litmus Team Blog
• The Email Standards Project
• W3C Validator
• MailChimp
• Campaign Monitor
• Premailer, preflight check for emails
• JPEGmini image compression tool
• tinyPNG image compression tool
• Sublime Text, my preferred editor
• Say Hello to the HTML Email Boilerplate
• Don’t Forget the Viewport Meta Tag
• Thumbnail icon by Pierre Borodin