E-posta Geliştirmeyle İlgili 7 Mit

E-posta, 1971'de Ray Tomlinson tarafından tasarlandığında, salt metin, 1:1 iletişim yöntemi olarak başladı. On yıllar boyunca e-posta, erken e-postanın salt metin sürümlerinden HTML'ye geçerek gelişti. E-postayı geleceğe iten, yaratıcı teknikleri katı sınırlar içinde kullanan e-posta geliştiricileri olmuştur.

O zamanlar, e-posta geliştiricileri, diğerlerinin e-posta kodlamaya başlamasına yardımcı olmak veya e-posta geliştiricilerinin yapabilecekleri ve yapamayacakları konusunda siperlerde olanlara hatırlatıcı olarak hareket etmek için her türlü "en iyi uygulamayı" yarattı.

Bugün e-posta geliştiricilerine en iyi uygulamaların statik olarak görülmemesi gerektiğini hatırlatmak için buradayız. Onlar değişir. 1990'ların sonlarında e-posta geliştiricileri için en iyisi olan şey, 2010'ların ortalarında artık doğru gelmiyor.

İşte uzun zamandır ortalıkta dolaşan yedi e-posta geliştirme efsanesi ve neden onları bir kenara bırakmanın zamanı geldi:

• Efsane 1: E-postalar 600 piksel genişliğinde olmalıdır.
• Efsane #2: Yalnızca standart sistem yazı tiplerini kullanmalısınız.
• Efsane #3: Yalnızca Geçiş DOKTİPİNİ kullanın.
• Efsane #4: Nitelik seçicilerin kullanılması gerekir.
• Efsane #5: E-postalardaki tüm stiller satır içi olmalıdır.
• Efsane #6: E-postalarda arka plan resimleri kullanmayın.
• Efsane #7: E-postalar tüm e-posta istemcilerinde aynı görünmelidir.

Efsane 1: E-postalar 600 piksel genişliğinde olmalıdır.

Cep telefonları ve tabletler yaygın hale gelmeden ve e-posta yalnızca bir masaüstü uygulaması olmadan önce, en iyi uygulama, tüm e-postaların 600 pikselden daha geniş veya daha dar olmamasını gerektiriyordu. Neden tam olarak 600 piksel? O zamanlar en sık kullanılan e-posta istemcilerinin (HoTMaiL, Yahoo ve Outlook) görüntü alanı boyutu 500-550 piksel civarındaydı. E-posta genişliğini 600 pikselden daha geniş olmayacak şekilde ayarlamak, e-postada mümkün olduğunca az yatay kaydırmaya olanak tanır.

Bu 600 piksel kuralı etrafta kaldı. Bugün, hepsi değişen ekran boyutlarına sahip daha fazla cihaz olmasına rağmen, neden bu 600 piksel kuralına bağlı kalıyoruz?

Özellikle e-posta iş akışınız Adobe Photoshop veya Sketch'te bir tasarım oluşturmayı içeriyorsa, uyulması kolay bir kuraldır; e-posta tasarımınıza başlamak için fiziksel bir genişliğe ihtiyacınız vardır. 600 piksel genişliğinde bir e-postanın, masaüstlerinde daha popüler e-posta istemcileri arasında hala çok güzel bir şekilde görüntüleneceği doğrudur. Ve medya sorgularını kullanarak, e-posta geliştiricileri, abonelerin açmak için kullandıkları cihaza bağlı olarak e-postanın genişliğini kolayca değiştirebilir.

Değişken genişlik, e-posta geliştiricilerinin desteklemesi gereken çok sayıda cihaz sorununu çözer. Bu işi yapmak için, e-postaların daha büyük görünüm pencerelerinde çok geniş ve okunaksız hale gelmesini önlemek için maksimum genişlik ve Outlook'un anlamasını sağlamak için MSO koşullu ifadeleri kullanın (çünkü maksimum genişlikte CSS özelliğini oluşturmaz).

Zalando'nun e-postaları 450 piksel genişliğindedir; bu, görmeye alıştığımız 600 piksel standardından çok uzaktır. Büyük CTA'larla birleştiğinde, Zalando'nun mobil uyumlu e-postaları, mobil kalabalığa daha fazla hitap ediyor gibi görünüyor.

Bu arada, Email Weekly'nin e-postaları, maksimum 960 piksel genişlikle akıcı tekniği kullanır. Cihaz genişliğine bağlı olarak e-postanın genişliğini zarif bir şekilde değiştirmek için medya sorgularını kullanır.

Abonelerinizin e-postanızı açmak için kullandığı istemcilere ve cihazlara bağlı olarak, e-postanızın genişliğini 600 piksel dışında bir maksimuma ayarlamak mantıklı olabilir.

Aboneleriniz e-postalarınızı nerede açıyor? E-posta Analizi ile e-postalarınızı hangi cihazlarda ve e-posta istemcilerinde açtıklarını öğrenebilirsiniz. Daha fazla bilgi edinin →

Efsane #2: Yalnızca standart sistem yazı tiplerini kullanmalısınız.

Sistem yazı tipleri, uzun süredir e-postada kullanım için güvenli bir seçenek olmuştur. Eh, onlar tek seçenekti.

Öte yandan, web tasarımcıları 2000'lerin başından beri web'de standart olmayan yazı tiplerini kullanmayı deniyorlar. 2008'de, @font-face CSS kuralı nihayet web tarayıcılarından web tasarımcılarının web sitelerinde standart olmayan yazı tiplerini kullanmaları için destek aldı. 2010 yılında Google, web tasarımcılarının kullanması için ücretsiz olan kendi web fontları kitaplığını başlattı.

Web yazı tiplerini bir HTML e-postasına aktarmak için sağlam bir yöntemin olmaması nedeniyle e-posta tasarımcıları için böyle bir şans yok. Lisans eksikliğinden bahsetmiyorum bile: web yazı tipleri ilk oluşturulduğunda, hiç kimse bunların e-postalarda kullanılacağını düşünmemişti, bu nedenle web yazı tiplerinin lisanslanması e-posta kullanımını kapsamıyor.

E-postalarınızda standart sistem yazı tiplerini önermemize rağmen, bu, web yazı tiplerini aşamalı bir geliştirme tekniği olarak kullanamayacağınız anlamına gelmez. Çevrimiçi yazı tipi depoları, lisanslarında e-posta kullanımını kapsamaya başlıyor. 800 ücretsiz web yazı tipiyle Google Fonts, artık e-postalarında standart olmayan web yazı tiplerini kullanmak isteyen e-posta tasarımcıları için başvurulacak kitaplık haline geliyor.

Google Android 4.4, iPhone, iPad ve Mac için Apple Mail ve OS X'te Outlook 2011 ve 2016'da web yazı tipleri için destek mevcuttur. Bu çok fazla görünmeyebilir, ancak bu yılın Eylül ayı itibariyle en iyi beş e-posta istemcisinden dördü , pazar payında, web yazı tiplerini destekler – iPhone, iPad, Google Android ve Apple Mail. Bu, tüm e-postaların %50'den fazlası Eylül'de açılıyor! Tabii ki, kendi abone tabanınıza bakmanız gerekir, ancak bu, potansiyel olarak kaç kişinin e-postalarınızda web yazı tiplerini görebileceğinin iyi bir göstergesidir.

Bu iki e-posta arasındaki ince farkları görebiliyor musunuz? Soldaki web yazı tiplerini kullanırken, sağdaki web yazı tiplerini devre dışı bırakır. Outnet, web yazı tiplerine görünüm ve his açısından çok yakın olan harika bir yedek yazı tipi seçti ve bugün e-postanızda web yazı tiplerini nasıl tutarlı bir şekilde kullanabileceğinizi gösteriyor.

Efsane #3: Yalnızca Geçiş DOKTİPİNİ kullanın.

Bir HTML belgesinin DOCTYPE'ı, tarayıcıya sayfanın nasıl oluşturulacağını söyler ve belgenin HTML'sini doğrulamak için kullanılır.

E-postada en sık kullanılan DOCTYPE:

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

E-posta geliştiricileri, bazı e-posta istemcileri DOCTYPE'ı tamamen ortadan kaldırsa veya başka bir tane ile değiştirse de, bir DOCTYPE'a sahip olma alışkanlığı edindiler. Gmail, Outlook.com ve Yahoo! Posta, e-postanızda bulunan DOCTYPE'ı çıkaran ve onu HTML5 DOCTYPE ile değiştiren e-posta istemcileri arasındadır.

Web'de, farklı DOCTYPE'lar, bazı CSS özelliklerinin ve HTML öğelerinin nasıl oluşturulacağını değiştirir. Yukarıdaki DOCTYPE, e-postada kullanılan <font> gibi kullanımdan kaldırılmış öğeler de dahil olmak üzere en geniş HTML öğeleri yelpazesine izin verir. Geçmiş testlerde, bu DOCTYPE'ın e-posta için en güvenilir olduğu kanıtlanmıştır. Kanıtlanmış - geçmiş zaman.

Bu, HTML5'in standart hale gelmesinden önceydi, şimdiki hali:

 <!DOCTYPE html>

HTML5 DOCTYPE, e-postada kullanılabilen <video> gibi daha yeni HTML5 öğelerinin kullanımına izin verir. Tüm istemciler yeni öğeleri veya özellikleri oluşturamayabilirken, DOCTYPE'ınızı güncelleyerek e-postanızı geleceğe yönlendirmemek için hiçbir neden yoktur. Kullanımdan kaldırılmış kodu bir HTML5 DOCTYPE ile kullanmaya devam edebilirsiniz, ancak bir doğrulama hizmeti aracılığıyla kontrol edildiğinde kod artık geçerli olmayacaktır. Kodunuz geçerli olsun veya olmasın, teslim edilebilirlik veya performans açısından e-postanız üzerinde hiçbir etkisi olmasa da, e-postanızın nasıl oluşturulacağını etkileyebilecek açık HTML etiketleri için HTML işaretlemenizi kontrol etmek iyi bir fikir olabilir.

Efsane #4: Nitelik seçicilerin kullanılması gerekir.

Yahoo! Mail, örneğin Outlook için geliştirmek için biraz daha nazik bir e-posta istemcisi oldu. Hatırlayabildiğimiz sürece kafadaki stili destekledi. Bir tuhaflık Yahoo! Mail'in sunduğu şey, medya sorgularındaki herhangi bir CSS ifadesini, medya sorgularının dışındaki herhangi bir CSS'nin yanında oluşturmasıydı. Bunun için basit düzeltme, CSS deyimini bir nitelik seçici olarak yazmaktı:

 *[class=”foo”] {color:#000000; font-family: sans-serif;}

Bunun gibi e-postaların başına CSS yazmak, aynı zamanda kafadaki stili de okuyan diğer e-posta istemcilerinin yukarıdaki örnekte olduğu gibi basit nitelik seçicilerini okumada sorun yaşamaması nedeniyle standart hale geldi.

2015'in başlarında Yahoo! Mail, herhangi bir "normal" e-posta istemcisinin yapacağı gibi okuma stilini sağlayan bir güncelleme yayınladı:

 .foo {color:#000000; font-family: sans-serif;}

Ancak, öznitelik seçiciler e-posta geliştirmede çok kök salmış olduğundan, bunların hala e-posta koduyla uğraştığını görmek şaşırtıcı değildi. E-posta geliştiricileri bunları kullanmaya alışmıştı ve genellikle e-posta şablonları güncellenmedi.

Önceden zararsız olan özellik seçiciler, eğer kodunuzda varsa, artık e-postanıza biraz zarar verebilir. E-postanızın stili Gmail'de çalışmıyorsa, stilinizde hala özellik seçicileri kullanıp kullanmadığınızı kontrol edin. Gmail, öznitelik seçicileri desteklemez, ancak artık (nihayet!) <head> içindeki stili desteklemektedir.

Yahoo! için öznitelik seçiciler artık gerekli değildir. Mail ve Gmail'in bunları desteklememesi nedeniyle, e-postalarınızda CSS'de özellik seçicileri kullanmanıza gerek yoktur.

Efsane #5: E-postalardaki tüm stiller satır içi olmalıdır.

Düzen ve satır içi stiller için tablolar, sonsuza dek e-posta geliştirmenin temel taşı olmuştur. E-posta ve web geliştirme arasındaki farkı tanımlarlar. Satır içi stiller artık e-posta geliştiricileri için çok yaygın, stillerin neden satır içi olması gerektiği konusunda biraz bulanıklaştı.

Şaşırtıcı bir şekilde, bazı siteler satır içi stillerin gerekli olmasının nedeninin Outlook ve Gmail olduğunu iddia ediyor. Hangisi çok yanlış. [Bunu tweetle]

Outlook, e-postanın başındaki stille hiçbir zaman sorun yaşamadı. Öte yandan, Gmail yaptı. Gmail, e-posta geliştiricilerinin CSS'lerini satır içi olarak kullanmalarının en büyük nedeni olmuştur (Eylül 2016 itibariyle %16'lık bir pazar payıyla).

Eylül ayının sonunda, Gmail kafa stilini desteklemeye başladı. Yani artık tüm stilleri satır içi yapmamız gerekiyor mu?

Aboneleriniz çoğunlukla Gmail, iOS ve hatta Outlook kullanıyorsa, stillerinizi öne çıkarmanın şimdi tam zamanı olduğunu güvenle söyleyebiliriz. Ancak, abonelerinizin çoğu, belirsiz e-posta istemcileri veya satır içi stillere dayanan uluslararası e-posta istemcileri (Yandex, Libero, Terra) kullanıyorsa, bunları kullanmaya devam etmeniz gerekebilir. Her zaman olduğu gibi, e-postanızda herhangi bir büyük değişiklik yaptığınızda e-postanızı test etmeyi savunuyoruz.

Efsane #6: E-postalarda arka plan resimleri kullanmayın.

Arka plan resimlerini doğrudan e-postaya almak çok zordu. E-posta geliştiricileri, Outlook'un birçok sürümünde oluşturmaları için karmaşık VML kodu kullanır ve diğer e-posta istemcilerinde de arka plan görüntüleri için destek eksikliği vardır.

Sorun şu: arka plan resimleri e-postada çalışabilir ve çalışabilir, ancak e-postanızın tasarımına bu şekilde dahil edilirler. Sınırlı destekle, arka plan resimlerini e-postanızın tasarımında önemli bir öğe olarak kullanmamalısınız, çünkü bu, abonenizin deneyimini artırır veya bozar. Ancak bunları, web yazı tiplerini kullandığınıza benzer şekilde, aşamalı bir geliştirme olarak e-postanızda kullanabilirsiniz.

E-postada arka plan resimleri kullanmamanın en büyük nedenlerinden biri, Gmail'in arka plan boyutu ve arka plan konumu için CSS özelliklerini desteklememesiydi. Bu CSS özellikleri, arka plan görüntülerinin nasıl boyutlandırılacağı ve yerleştirileceği konusunda belirli bir miktarda kontrolün yapılması gereken yüksek piksel yoğunluklu ekranlar ve hibrit/akışkan/yanıt veren e-posta için önemlidir. Her ikisi de artık Gmail'de ve Inbox by Gmail'de destekleniyor, bu nedenle e-postada arka plan resimlerini kullanmayı denememek için daha da az neden var.

TWO Digital Marketing'de Baş E-posta Geliştiricisi ve E-posta Tasarım Konferansı 2016 konuşmacısı Kristian Robinson, e-postadaki arka plan resimlerini derinlemesine inceliyor, eğer bunlarla mücadele etmek için ilham alıyorsanız.

Efsane #7: E-postalar tüm e-posta istemcilerinde aynı görünmelidir.

E-posta istemcilerinin hepsinin HTML e-postalarını oluşturmanın biraz farklı yolları vardır. Bunu kabul etmek yerine, e-posta geliştiricileri çok sayıda e-posta istemcisinde aynı e-postalara ulaşma yollarını hacklemeye çalıştılar. Üstlenilmesi çok onurlu bir görev, ancak yönetmek ve güncel tutmak için bir kabus olabilen şişirilmiş ve sahte HTML koduna neden olabilir.

E-posta mükemmelliğini arayan e-posta geliştiricisi değil, müşteri veya diğer paydaşlar olabilir. Ancak, e-posta geliştirmenin tuzaklarını - e-posta istemcilerinin neden farklı görüntülendiğini ve bir e-posta istemcisindeki bir şeyin diğerine kıyasla 1 piksel daha yüksek olmasının neden önemli olmadığını- anlamaları için çevrelerindekileri eğitmek e-posta geliştiricisinin sorumluluğundadır.

"E-postaların piksel açısından mükemmel olması gerektiği zamanlar çok geride kaldı." @ericlepetitsf #LitmusLive

- Çad S. Beyaz (@chadswhite) 16 Ağustos 2016

Bu efsane, e-postada, örneğin web yazı tipleri ve arka plan resimleri gibi, e-posta istemcilerinin %100'ünde görüntülenemeyebilecek yeni teknikleri kullanmaya çalışırken özellikle zararlıdır. Her ikisi de e-postanızı geliştirmenin harika yollarıdır. Ve e-postalarımızda yeni teknikleri benimsemeye ve denemeye çalışmasaydık endüstri olarak nerede olurduk?

Bir şeyin yıllardır belirli bir şekilde yapılmış olması, onu yapmanın daha iyi bir yolu olmadığı anlamına gelmez. Artık e-posta pazarlama endüstrisinin onlarca yıldır üzerinde çalıştığı kuralları ve en iyi uygulamaları sorgulamanın zamanı geldi.

Builder ile e-postaları daha hızlı ve daha kolay kodlayın

E-posta için özel olarak oluşturulmuş tek kod düzenleyici olan Builder ile e-posta geliştirme iş akışınızı hızlandırın. Ve ücretsiz!

Builder'ı kullanmaya başlayın →