HTML ve E-posta: Kaçınmanız Gereken 6 Yaygın Hata

HTML koduyla e-posta mı oluşturuyorsunuz? Kolaylaştırılmış, temiz e-posta iletişiminin avantajlarından yararlanmak için kaçınmanız gereken çok sık yapılan 6 hata.

Hata 1. Aşırı ayrıntılı kod kullanma

HTML ve CSS sayesinde bir e-posta yapısı oluşturabileceğimizi ve ona belirli bir yazı tipini, belirli bir arka plan rengini, görüntüleri vb. görüntülemeyi mümkün kılan bir form veya daha doğrusu bir biçim verebileceğimizi biliyoruz.

Şimdi hem HTML hem de CSS etiketlerinin bazı açılardan nasıl aynı işlevi yerine getirdiğini ve sonunda çakıştığını göreceğiz. Pratik bir örnek alalım: Hem HTML'de hem de CSS'de bir tablonun arka plan rengini tanımlama.

Kod resimde gösterilmiştir. Arka plan renginin tanımlandığı iki nokta olduğunu görebilirsiniz:

• bgcolor = “#e75c00” etiket tablosunun özelliğidir;
• background-color , tabloya uygulanan CSS özelliğidir.

Her iki nitelik de aynı şeyi yapar ve bu nedenle örtüşürler: tablonun arka planına turuncu rengi (onaltılık biçime göre #e75c00) empoze ederler.

Kritik nokta şimdi daha açık olmalıdır: HTML ve CSS özellik tanımları birbiri üzerine yığılabilir. Aslında, aynı e-posta modelini yeniden işlerken veya değiştirirken, kod genellikle aynı işlevi yerine getiren gereksiz özellikler tarafından tıkanabilir.

Ve hepsi bu değil. Satır içi stiller her bir öğeye uygulanabileceğinden, bu (sapkın) durum da ortaya çıkabilir:

Bir tarayıcı (veya e-posta istemcisi) kodu aşağı yukarı şu şekilde okurdu:

• Tabloya gri bir arka plan ( bgcolor = “#efefef” ) uygulayın
• On satıra siyah bir arka plan ( bgcolor = “#000000” ) uygular
• Son olarak, Hello World! metnini içeren hücreye turuncu bir arka plan ( background-color: #e75c00 ) uygulayın !

Nihai sonuç, hem bu örnekte hem de öncekinde aynıdır: turuncu bir arka plan üzerinde beyaz metin.

Sorun, ikinci durumda üç farklı arka plan kuralının tanımlanmış olmasıdır. Kullanıcı tarafından görülen, hücreyle ilişkili olarak tanımlanandır, çünkü tarayıcı kodu sırayla okur (table -> tr -> td). Son tanım <td> üzerinde ayarlandığından, tam olarak görüntülenecek olan budur.

Kodun çoğunun gerekli olmadığı açıktır. Bunun nedeni yalnızca görüntülenen arka plan renginin hücreye uygulanan renk olması değil, aynı zamanda iyi e-posta pazarlamasının amaçlarından birinin de iletişimi olabildiğince hafif tutmak olmasıdır. Çok ayrıntılı, gereksiz kod hafif kod değildir.

Önerilerimiz:

• Kodu olabildiğince temiz tutun
• Kodu biçimlendirirken gereksiz tekrarlardan kaçının
• Satır içi stilleri tercih edin
• İletişim kodu için modüler bir yapı oluşturmaya çalışın
• Girinti yoluyla kodu mümkün olduğunca sıralı tutmaya çalışın (bunu yapan HTMLformatter veya Clean CSS gibi birkaç çevrimiçi hizmet vardır), iletişimin yapısına genel bir bakış elde edebilmek için
• Bir modelde yapılan makro değişikliklerinin geçmişini takip edin

Hata 2. Kod hakkında aşırı yorum yapmak

Çoğu dilde olduğu gibi, HTML'ye de yorum eklemek mümkündür. HTML betiğindeki yorum nedir? Kodu okuyan ve yürüten program tarafından yok sayılan listenin bir kısmıdır.

Aşağıdaki şekilde bir yorum örneği verilmiştir:

Gördüğünüz gibi, <!- ve -> arasındaki her şey sadece farklı bir renk değil (düzenleme programına bağlı olarak), en önemlisi ekranda görüntülenmiyor.

Bu, yazılan koda veya henüz tamamlanmamış veya iyileştirilmesi gereken parçalara ilişkin talimatlara ilişkin “servis iletişimlerinin” eklenmesine olanak tanır.

Yorumları kullanmanın başka bir yolu da var. Açma ve kapama işaretleri arasında yer alan her şey gösterilmediğinden, aşağıdaki örnekte gösterildiği gibi tüm sayfa bölümlerini bununla gizlemek mümkündür. Aslında, kodda yazılan dört satır yerine ekranda sadece üç satırın göründüğünü görebiliriz.

Elbette faydalı bir araçtır, ancak onu kötüye kullanmamalıyız. Yorumlanan kodun gösterilmediği doğru olsa da, yine de gönderilen iletişimde kalır ve onu ağırlaştırır.

Bizim tavsiyemiz:

• Yorumları akıllıca kullanın, örneğin iletişim yapılarının başlangıcını ve sonunu belirtmek veya geliştirici için faydalı bilgiler eklemek için
• Yorumlarda uzun soluklu olmayın ve daha da iyisi İngilizce yazın
• İletişim amaçları için gerekli olmadığı için göndermeden önce yorumlanmış kodu silin

Hata 3. E-posta içeriğinin yanlış yönetilmesi

Bir e-posta tasarlarken, tek bir kod satırı yazmadan önce bile, sonraki gerçekleştirme aşamasında ve dolayısıyla üretim sırasında değiştirilemeyecek belirli parametreleri tanımlamak iyidir.

Bu parametrelerden bazıları şunlardır:

• E-posta genişliği
• Görüntü boyutu
• Görüntü sayısı
• Başlıkta kullanılan yazı tipi boyutu
• Gövde kopya yazı tipi boyutu

Ve bunun gibi. Genellikle atlanan bir parametre, herhangi bir metin öğesi için maksimum tuş vuruşu sayısıdır.

Bu noktada, kurallar konusunda fanatik olmaktan suçlu olduğumuza itiraz edebilirsiniz, ancak bu kadar katı olmamızın iki iyi nedeni var. Birincisi kavramsal, ikincisi operasyonel.

Kavramsal düzeyde, içerik (metin, resimler vb.) ve kapsayıcı (HTML yapısı), birincinin ikincisine tabi olduğunu gören çok kesin bir hiyerarşiye sahip iki ayrı varlıktır.

Aslında, içerik konteynere uyarlanmalıdır, tersi değil. Kod yazılırken iletişim mimarisi oluşturulur. Bu kapsayıcıyı tanımlar ve bir kez şekillendirildiğinde, e-posta yanıt verecek şekilde oluşturulmuş olsa bile, içerik ne olursa olsun kap öyle kalır.

Özetle - ve Bruce Lee'nin başka bir deyişle - içerik su gibidir: Bir bardağa su koyarsanız, bardağa dönüşür; bir şişeye su koyarsanız, o şişe olur; Çaydanlığa su koyarsanız çaydanlık olur.

Bir bardağın şişe olmasını bekleyemezsiniz ve bir çaydanlık asla bir bardak olmayacaktır. Bu nedenle, metin (veya resim veya düğme) onu içeren yapıya uyum sağlamalıdır, tersi değil.

İkinci neden daha işlevseldir. İletişimi oluşturmaya yönelik tüm parametreler önceden tam olarak biliniyorsa, yalnızca taslak aşamasında daha etkili iletişimler yaratmak değil, aynı zamanda daha dengeli iletişimler oluşturmak da mümkün olur.

Daha somut bir örnek verelim: Diyelim ki yan yana iki ürün içeren bir DEM'imiz var. Bir ürün genellikle şunlarla ilişkilendirilir:

• Bir şekil
• ürünün adı
• ürünün açıklaması
• Fiyat
• Ürün sayfasına yönlendiren CTA

Artık ürünler yan yana olduğu için parçaların mutlaka dengelenmesi gerekiyor.

Bu, resimlerin aynı yükseklikte olması, açıklayıcı metinlerin benzer uzunlukta olması ve iki CTA'nın çok farklı olmaması gerektiği anlamına gelir.

Bu temel ilkelerin göz ardı edilmesi veya bunlara uyulmaması, yukarıdaki görseldeki gibi durumlara yol açabilir.

Soldaki ürün başlığı üç satırı kaplayacak kadar uzun, sağdaki ise tek satırı dolduracak kadar kısa olduğu için iki öğe arasındaki simetri bozuluyor. Sonunda tüm iletişimi zayıflatan bir anlaşmazlık ortaya çıktı.

Tüm çeşitli cihazların çok farklı çözünürlüklere sahip olduğu mobil dünya düşünüldüğünde bu kurallara uyum daha da önemli hale geliyor: iPhone X'in 1125 x 2436 pikselinden Samsung Galaxy S8'in 1440 x 2960 piksel boyutuna kadar. 768 x 1280 piksel, Microsoft Lumia 1020.

Bu devasa çeşitlilik, yoğun e-posta istemcileri ormanıyla örtüştüğünde, DEM ekranı üzerinde tam kontrole sahip olmadığımız anlamına gelir, çünkü her durumda piksellere uyum sağlayan kesin bir kod yoktur. Bu nedenle, kod aracılığıyla kontrol edemiyorsanız, metinlerin uzunluğu veya görüntülerin boyutu gibi bir e-postayı oluşturan diğer bölümleri değiştirerek dolaylı olarak yapmaya çalışmalısınız.

Önerilerimiz:

• Şablonun tüm bölümlerini tanımlayın
• İletişimin farklı bölümleri arasında tutarlı kalın
• Kendinize koyduğunuz kurallara saygı gösterin
• Kurallar çiğnenebilir, ancak bu tam bir farkındalıkla yapılmalıdır.
• Şablon ihtiyaçlarınızı karşılamıyorsa, yeni bir şablon tanımlamayı düşünebilirsiniz.

Hata 4. Etkileşimli telefon numaralarını ve adresleri yanlış alma

Bazen, e-posta gönderenler iletişim bilgilerini, özellikle altbilgiye ekler. Bu genellikle bir adres ve bir telefon numarası içerir.

Bir telefon numarası ve adres, masaüstü istemci e-postaları için standart bilgiler olsa da, nadiren kullanılsalar da, bu öğeler özellikle mobil tarafta önemlidir.

Bu esas olarak iki nedenden dolayı olur:

• Verileri yöneten bir uygulamayı bir tıklamayla açabilirsiniz (takvim, telefon, tarayıcı)
• Görüntüleme alanı azalır ve bu nedenle her bilgi parçası, altbilgide bulunsa bile daha fazla görünürlüğe sahiptir.

Bu nedenle, davranışları farklı cihazlar arasında değiştiğinden, iletişimi geliştirirken bu ayrıntıları da unutmamak önemlidir.

Bir simülasyon yoluyla geçici olarak oluşturulmuş örneği ele almak için bir dakikanızı ayıralım. Her iki örnek de iPhone 6+ iOS 9 tarafından görüntülenir.

Soldaki resim, herhangi bir biçimlendirme olmadan doğrudan girilen metin ile kullanıcı tarafından alınan haber bültenini gösterir.

Teknik açıdan her şey doğru, ancak kodun mobilde e-posta uygulamasının kendisi tarafından yorumlandığını dikkate almalıyız. E-postanın metnini "okur" ve bir tarih, adres veya telefon numarası biçimindeki metni tanıdığında, etkin bağlantıyı otomatik olarak ilgili uygulamaya, yani Takvim, Harita veya telefona bağlar.

Tüm bunlar çok kullanışlıdır, çünkü tek bir tıklama bir telefon görüşmesi yapmanıza, bir etkinlik planlamanıza veya bir rota belirlemek için haritayı açmanıza olanak tanır. Bu konuda üzülebilecek olanlar, mavi bağlantıları ve alt çizgileri görmekten hoşlanmayan sanat ve geliştiricidir. Yani ne yapmalıyız? Nasıl devam etmeliyiz?

İşleri normale döndürmek için küçük bir geçici çözüm veya numara kullanabilirsiniz. Açık konuşalım: İyi biçimlendirilmiş HTML kurallarını çiğneseler de, uçsuz bucaksız e-posta istemcileri okyanusunda geçici çözümler vazgeçilmezdir.

Bir geliştiricinin ana hedefi, iletişimi mümkün olduğu kadar çok müşteride görünür kılmaksa, o zaman taviz vermesi ve geçici çözümleri benimsemesi gerekir.

Şimdi kodun nasıl değiştirildiğini görelim.

Telefon söz konusu olduğunda, basittir: Bağlantı etiketi, href özelliğinde tel kullanarak bir telefon numarası tanımlamayı mümkün kıldığı için, telefon numarasını boşluk veya satır ayırmadan ekleriz.

Ancak bir adres veya tarih için farklı bir şekilde hareket etmemiz gerekiyor. Bunlar için, rengi istemciye otomatik olarak ekleyecek bağlantı etiketini uygulayan bir sınıf (.address) tanımlamak gerekir (color: #ffffff;). Her şeyden önce, her bağlantının varsayılan bir özelliği olan alt çizgiyi kaldırmalıdır (metin-dekorasyon:yok;).

Adres sınıfının her iki özniteliğinin de, özellikten bağımsız olarak istemci tarafından uygulanması gereken !important değerine sahip olduğuna dikkat edin. Onsuz, geçici çözümün işini yapacağının garantisi yoktur.

Önerilerimiz:

• Her zaman iletişimin cep telefonlarında nasıl görüntülenebileceğine dikkat edin (yani testler yaparak)
• Mümkün olduğunda, iletişimi mobil uyumlu hale getirmek için mikro düzeltmeler kullanın
• Masaüstü için iyi olanın mobil için de iyi olduğunu düşünmeyin.
• Kitlenizi tanıyın: Hangi teknolojiyi kullanıyorlar? Hangi cihazlar? Hangi medya?
• Özellikle e-posta istemci uygulamalarında önemli güncellemeler olduğunda, kendi iletişimlerinizle denemeler yapmak için dahili testleri kullanın.

Hata 5. Terk edilmiş veya boş etiketleri temizlemiyor

İletişimin toplam ağırlığını minimumda tutmaya çalışmak amacı ile devam ederken, mevcut kodun doğal içeriğinden arındırılmış kısımlarına dikkat etmemiz gerekiyor.

Hemen somut bir örnek verelim: bir <font> etiketi, belki bir dizi satır içi stili olan ve herhangi bir metin içermeyen. Açıkçası, e-posta tarafı hiçbir şeyi okuyamayacak, ancak <font> biçimlendirme etiketi var olmaya ve e-postada fiziksel yer kaplamaya devam ediyor.

Başka bir klasik örnek, bağlantılı nesnesi olmayan <a> bağlantı etiketleridir, yani şuna benzer: <a href=”http://www.mailup.com” style=”color:#00000;text-decoration:none”> </a>.

Genellikle bu "hatalar", yeniden işlenmiş veya birçok kez kullanılmış olan kodda bulunur, böylece resimler, bağlantılar ve metinler gibi farklı parçalar eklenmiş, değiştirilmiş veya silinmiştir. Alternatif olarak, bir WYSIWYG düzenleyicisinin yanlış kullanıldığının bir göstergesi olabilir. Aslında, kötü veya tedbirsizce kullanılırsa, bu editörlerin koda kod ekleme kusuru vardır, çünkü önceden tanımlanmış her öğe normalde editörün oluşturulduğu andan itibaren tanımlanan kodun bir parçasına sahiptir.

Program, seçilen öğe her eklendiğinde modeli eleştirmeden uygular ve sonuç olarak, e-postanın aynı bölümünü yeterli sayıda yeniden yazdığınızda bu sorun ortaya çıkabilir.

Bizim tavsiyemiz:

• Kodu yazarken, her zaman terk edilmiş veya boş etiket olup olmadığını kontrol edin.
• Bir WYSIWYG editörü kullanıyorsanız ve koda erişmek mümkünse, her şeyin yolunda olduğundan ve bu tür hataların olmadığından emin olmak için bir kontrol yapın.

Hata 6. Doğrulanmamış HTML kullanma

E-posta kodunun doğrulanması hakkında konuşmak çetrefilli bir konudur.

“World Wide Web'deki çoğu sayfa, Web yazarlarının metin yapılandırmasına, multimedya içeriği eklemesine ve sonucun hangi görünüme veya stile sahip olması gerektiğini belirlemesine olanak tanıyan bilgisayar dillerinde (HTML gibi) yazılmıştır.

Her dilde olduğu gibi, bunların da kendi dilbilgisi , kelime dağarcığı ve sözdizimi vardır ve bu bilgisayar dilleriyle yazılan her belgenin bu kurallara uyması gerekir. (X)HTML dilleri, XHTML 1.1'e kadar olan tüm sürümler için, SGML'den devralınan bir mekanizma olan DTD'ler adı verilen makine tarafından okunabilen gramerleri kullanır.

Ancak, doğal bir dildeki metinler yazım veya dil bilgisi hataları içerebileceği gibi, İşaretleme dillerini kullanan belgeler de (çeşitli nedenlerle) bu kurallara uymuyor olabilir. Kullandığı bir belge aslında dil (s) için kuralları yönünden onaylanması işlemine doğrulama denir ve bunun için kullanılan bir araçtır bir doğrulayıcı mesafesindedir. Bu süreci başarıyla geçen bir belgeye geçerli denir.

Bu kavramları göz önünde bulundurarak, "biçimlendirme doğrulamasını" , bir Web belgesini kullandığını iddia ettiği dilbilgisine (genellikle bir DTD) karşı kontrol etme süreci olarak tanımlayabiliriz ".

Tanımlayıcı W3C

W3C, analizi hataları gösteren ve bunları düzeltmenin yollarını öneren bir kod doğrulama aracı sağlayarak kodun koruyucusu ve garantörü olarak bize yardımcı olur. Bu araç sayesinde daha büyük yapısal hataları tespit etmek ve düzeltmek mümkündür.

E-posta Pazarlamanın iki yönlü bir durumu olduğunu hatırlamakta fayda var:

• Bir yandan HTML, çok kesin kurallara ve yapılara sahip standartlaştırılmış bir dildir.
• Öte yandan, standart olmayan ve genellikle hoş karşılanmayan, ancak e-posta istemcilerinde doğru görselleştirmeye sahip olmak istiyorsanız iyi çalışan bir dizi geçici çözüm

Bu iki yön, tutkunun çoktan uçup gittiği yaşlı bir evli çift gibidir. Neden birlikte yaşadıklarını bilmiyorlar ama bunu tavizler vererek yapmak zorunda kalıyorlar.

Öyleyse neden kod doğrulama hakkında konuşalım? Mantıklı geliyor? Uzlaşmalar nelerdir?

Ayrıntılara fazla girmeden daha geniş bir perspektife yerleştirildiğinde kod doğrulama hakkında konuşmak mantıklıdır. Bu nedenle, yapı, e-postanın oluşturulduğu modüller ve iletişimin omurgasını oluşturan tablolar söz konusu olduğunda, W3C'nin dikte ettiği standarda yakın ve temiz bir koda sahip olmak son derece mantıklıdır. olabildiğince.

Bununla birlikte, gerçeğin farkında olmalıyız ve bu nedenle uzlaşma, doğru görselleştirmeyi mümkün olduğu kadar çok müşteriye genişletmek için bir tür ince ayar olarak geçici çözümlerin eklendiği sağlam ve işlevsel bir yapının yaratılmasından oluşur.

Geçici çözümlerin, kuralın istisnalarından başka bir şey olmadığını veya deneyim yoluyla biriken bilgiden türetilen tamamen ortodoks teknikler olmadığını zaten biliyoruz, ancak bunların varlığı yalnızca kodun sayfa ayrımı olmaksızın doğru şekilde görselleştirilmesine izin verdiği için anlamlıdır.

Bizim tavsiyemiz:

• Kod hakkında şüpheleriniz varsa doğrulama, analiz için hızlı ve etkili bir araç olarak hizmet edebilir.
• Kod doğrulama, bir kod listesindeki en büyük hataları hızla belirlemek için iyi bir araç olabilir.
• Doğrulanmış kod, iletişimi mümkün olduğunca evrensel hale getirmek için daha sonra geçici çözümlerle geliştirmek ve uyarlamak için her zaman mükemmel bir başlangıç ​​noktasıdır.
• Doğrulama, özellikle sık sık değiştirilen ve yeniden çalışılan modellerde, kod için "servis" olarak görülebilir.
• Deneyim kazandıkça, problem çözerken zamandan tasarruf etmek için çeşitli istemciler için küçük bir ad hoc çözümler kitaplığı oluşturun.