7 mitów na temat rozwoju poczty e-mail

Poczta e-mail rozpoczęła się jako metoda komunikacji tylko tekstowa, 1:1 w 1971 roku, kiedy została wymyślona przez Raya Tomlinsona. Przez dziesięciolecia poczta e-mail ewoluowała, odchodząc od tekstowych wersji wczesnych wiadomości e-mail do HTML. Popychanie poczty w przyszłość to twórcy poczty e-mail, używający kreatywnych technik w ściśle określonych granicach.

W tym czasie programiści e-maili stworzyli wszelkiego rodzaju „najlepsze praktyki”, aby pomóc innym rozpocząć kodowanie e-maili lub działać jako przypomnienie dla tych, którzy są w okopach o tym, co programiści e-maili mogą, a czego nie mogą zrobić.

Jesteśmy tu dzisiaj, aby przypomnieć programistom poczty e-mail, że najlepsze praktyki nie powinny być postrzegane jako statyczne. Zmieniają się. To, co było najlepsze dla programistów poczty e-mail pod koniec lat 90., przestaje być prawdą w połowie 2010 roku.

Oto siedem mitów dotyczących rozwoju poczty e-mail, które istnieją od wieków, i dlaczego nadszedł czas, aby w końcu je położyć:

• Mit nr 1: E-maile muszą mieć szerokość 600 pikseli.
• Mit 2: Musisz używać tylko standardowych czcionek systemowych.
• Mit 3: Używaj tylko przejściowego DOCTYPE.
• Mit 4: Należy używać selektorów atrybutów.
• Mit 5: Wszystkie style w e-mailach muszą być wbudowane.
• Mit 6: Nie używaj obrazów tła w wiadomościach e-mail.
• Mit 7: Wiadomości e-mail muszą wyglądać identycznie we wszystkich klientach pocztowych.

Mit nr 1: E-maile muszą mieć szerokość 600 pikseli.

Zanim telefony komórkowe i tablety stały się powszechne, a poczta e-mail była wyłącznie aplikacją komputerową, zgodnie z najlepszymi praktykami wszystkie wiadomości e-mail nie powinny być szersze ani węższe niż 600 pikseli. Dlaczego dokładnie 600 pikseli? Rozmiar widocznego obszaru najczęściej używanych klientów poczty e-mail w tamtych czasach (HoTMaiL, Yahoo i Outlook) wynosił około 500-550 pikseli. Ustawienie szerokości wiadomości e-mail na nie większą niż 600 pikseli pozwoliłoby na jak najmniejsze przewijanie w poziomie w wiadomości e-mail.

Ta zasada 600 pikseli utknęła. Mimo że obecnie dostępnych jest więcej urządzeń, wszystkie z różnymi rozmiarami ekranu, dlaczego trzymamy się zasady 600 pikseli?

Jest to prosta zasada, której można się trzymać, zwłaszcza jeśli Twój obieg pracy poczty e-mail obejmuje tworzenie projektu w programie Adobe Photoshop lub Sketch — aby rozpocząć projektowanie wiadomości e-mail, potrzebujesz fizycznej szerokości. Prawdą jest, że wiadomość e-mail o szerokości 600 pikseli nadal będzie się bardzo ładnie wyświetlać wśród bardziej popularnych klientów poczty e-mail na komputerach stacjonarnych. Korzystając z zapytań o media, programiści e-maili mogą łatwo zmieniać szerokość wiadomości e-mail w zależności od urządzenia używanego przez subskrybentów do otwierania.

Fluid width rozwiązuje problem ogromnej liczby urządzeń, które muszą obsługiwać programiści poczty e-mail. Aby to zadziałało, użyj max-width, aby zapobiec zbyt szerokim i nieczytelnym wiadomościom e-mail w większych oknach ekranu, oraz instrukcji warunkowych MSO, aby Outlook zrozumiał (ponieważ nie renderuje właściwości CSS max-width).

E-maile Zalando mają szerokość 450 pikseli — daleko od standardu 600 pikseli, do którego przywykliśmy. W połączeniu z dużymi wezwaniami do działania wygląda na to, że przyjazne dla urządzeń mobilnych e-maile Zalando są bardziej skierowane do mobilnego tłumu.

Tymczasem e-maile Email Weekly wykorzystują technikę płynną, z maksymalną szerokością 960 pikseli. Wykorzystuje zapytania o media, aby wdzięcznie zmienić szerokość wiadomości e-mail w zależności od szerokości urządzenia.

W zależności od klientów i urządzeń używanych przez subskrybentów do otwierania wiadomości e-mail, sensowne może być ustawienie szerokości wiadomości e-mail na maksymalnie inne niż 600 pikseli.

Gdzie Twoi subskrybenci otwierają Twoje e-maile? Dzięki Analityce poczty e-mail możesz dowiedzieć się, na jakich urządzeniach i klientach poczty e-mail otwierają one Twoje e-maile. Dowiedz się więcej →

Mit 2: Musisz używać tylko standardowych czcionek systemowych.

Czcionki systemowe od dawna są bezpieczną opcją do użytku w wiadomościach e-mail. Cóż, były jedyną opcją.

Z drugiej strony projektanci stron internetowych eksperymentują z używaniem niestandardowych czcionek w sieci od początku XXI wieku. W 2008 roku reguła CSS @font-face w końcu uzyskała wsparcie przeglądarek internetowych dla projektantów stron internetowych, aby używać niestandardowych czcionek na swoich stronach internetowych. W 2010 roku firma Google uruchomiła własną bibliotekę czcionek internetowych, z której mogą bezpłatnie korzystać projektanci stron internetowych.

Projektanci e-maili nie mają takiego szczęścia ze względu na brak solidnej metody importowania czcionek internetowych do wiadomości e-mail w formacie HTML. Nie wspominając o braku licencji: kiedy po raz pierwszy tworzono czcionki internetowe, nikt nigdy nie przypuszczał, że będą używane w wiadomościach e-mail, więc licencjonowanie czcionek internetowych nie obejmowało korzystania z poczty e-mail.

Chociaż zalecamy standardowe czcionki systemowe w wiadomościach e-mail, nie oznacza to, że nie możesz używać czcionek internetowych jako techniki progresywnego ulepszania. Repozytoria czcionek online zaczynają uwzględniać korzystanie z poczty e-mail w swoich licencjach. A Google Fonts, z 800 darmowymi czcionkami internetowymi, staje się teraz biblioteką dla projektantów e-maili, którzy chcą używać niestandardowych czcionek internetowych w swoich e-mailach.

Obsługa czcionek internetowych istnieje w Google Android 4.4, Apple Mail na iPhone'a, iPada i Maca oraz Outlook 2011 i 2016 w systemie OS X. To może nie wydawać się dużo, ale według stanu na wrzesień tego roku czterech z pięciu największych klientów poczty e-mail , w udziale w rynku, obsługują czcionki internetowe — iPhone, iPad, Google Android i Apple Mail. To ponad 50% wszystkich e-maili otwieranych we wrześniu! Oczywiście musisz spojrzeć na własną bazę subskrybentów, ale jest to dobry wskaźnik potencjalnej liczby osób, które będą mogły zobaczyć czcionki internetowe w Twoich e-mailach.

Czy widzisz subtelne różnice między tymi dwoma e-mailami? Ten po lewej używa czcionek internetowych, podczas gdy prawy ma wyłączone czcionki internetowe. Outnet wybrał świetną czcionkę zastępczą, która pod względem wyglądu i stylu jest bardzo zbliżona do ich czcionki internetowej, pokazując, w jaki sposób można dziś konsekwentnie używać czcionek internetowych w e-mailach.

Mit 3: Używaj tylko przejściowego DOCTYPE.

DOCTYPE dokumentu HTML informuje przeglądarkę, jak renderować stronę i jest używany do sprawdzania poprawności kodu HTML dokumentu.

Najczęściej używanym DOCTYPE w wiadomościach e-mail jest:

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

Twórcy poczty e-mail nabrali dobrego nawyku posiadania DOCTYPE, mimo że niektórzy klienci poczty e-mail całkowicie usuwają DOCTYPE lub zastępują go innym. Gmail, Outlook.com i Yahoo! Mail należą do klientów poczty e-mail, które usuwają wszystkie DOCTYPE obecne w wiadomości e-mail i zastępują je HTML5 DOCTYPE.

W Internecie różne DOCTYPE zmieniają sposób renderowania niektórych właściwości CSS i elementów HTML. Powyższy DOCTYPE pozwala na najszerszy zakres elementów HTML, w tym przestarzałe elementy, takie jak <font>, które były używane w wiadomościach e-mail. W poprzednich testach ten DOCTYPE okazał się najbardziej niezawodny w przypadku poczty e-mail. BYŁ sprawdzony — czas przeszły.

To było zanim HTML5 stał się standardem, jakim jest teraz:

 <!DOCTYPE html>

DOCTYPE HTML5 pozwala na użycie nowszych elementów HTML5, na przykład <video>, które można wykorzystać w wiadomości e-mail. Chociaż nie wszyscy klienci mogą być w stanie renderować nowe elementy lub właściwości, nie ma powodu, aby nie przesuwać poczty e-mail w przyszłość, aktualizując DOCTYPE. Nadal możesz używać przestarzałego kodu z kodem DOCTYPE HTML5, ale kod nie będzie już prawidłowy po sprawdzeniu za pomocą usługi walidacji. Chociaż prawidłowy kod nie ma wpływu na dostarczanie ani wydajność wiadomości e-mail, dobrym pomysłem może być sprawdzenie znaczników HTML pod kątem otwartych tagów HTML, które mogą mieć wpływ na renderowanie wiadomości e-mail.

Mit 4: Należy używać selektorów atrybutów.

Wieśniak! Mail był nieco lepszym klientem poczty e-mail do opracowania niż, powiedzmy, Outlook. Odkąd pamiętamy, wspierał styl w głowie. Jedno dziwactwo Yahoo! Mail oferował to, że renderował dowolne oświadczenie CSS w zapytaniu o media wraz z dowolnym CSS poza zapytaniami o media. Prostym rozwiązaniem tego problemu było napisanie instrukcji CSS jako selektora atrybutów:

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

Pisanie CSS w nagłówku takiego e-maila stało się standardem, ponieważ inne klienty pocztowe, które również czytają styl w nagłówku, nie miały problemu z odczytaniem prostych selektorów atrybutów, jak w powyższym przykładzie.

Na początku 2015 r. Yahoo! Mail wprowadził aktualizację, która umożliwiła mu czytanie stylu tak, jak każdy „normalny” klient poczty:

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

Jednakże, ponieważ selektory atrybutów były tak mocno zakorzenione w tworzeniu wiadomości e-mail, nie było zaskoczeniem, że wciąż kopią w kodzie wiadomości e-mail. Twórcy e-maili byli po prostu przyzwyczajeni do ich używania i często szablony e-maili nie były aktualizowane.

Wcześniej nieszkodliwe selektory atrybutów mogą teraz trochę zaszkodzić Twojemu e-mailowi, jeśli masz je w swoim kodzie. Jeśli styl e-maila nie działa w Gmailu, sprawdź, czy nadal używasz selektorów atrybutów w swoim stylu. Gmail nie obsługuje selektorów atrybutów, ale teraz (wreszcie!) obsługuje styl w <head>.

Dzięki selektorom atrybutów, które nie są już wymagane w Yahoo! Brak obsługi poczty i Gmaila, nie ma potrzeby używania selektorów atrybutów w CSS w swoich e-mailach.

Mit 5: Wszystkie style w e-mailach muszą być wbudowane.

Tabele układu i stylów inline są podstawą tworzenia wiadomości e-mail od… od zawsze. Określają różnicę między tworzeniem poczty e-mail a tworzeniem stron internetowych. Style inline są teraz tak powszechne wśród programistów poczty e-mail, że nieco niejasne stało się, dlaczego style muszą być inline w pierwszej kolejności.

Szokująco, niektóre witryny twierdzą, że powodem, dla którego potrzebne są style wbudowane, jest Outlook i Gmail. Co jest po prostu błędne. [Tweetuj to]

Outlook nigdy nie miał problemu ze stylem w nagłówku wiadomości e-mail. Z drugiej strony Gmail tak. Gmail był dosłownie największym powodem (z udziałem w rynku wynoszącym 16% od września 2016 r.), dlaczego programiści poczty e-mail mają wbudowany kod CSS.

Pod koniec września Gmail zaczął wspierać styl w głowie. Czy więc musimy już uwzględniać wszystkie style?

Jeśli Twoi subskrybenci najczęściej korzystają z Gmaila, iOS, a nawet Outlooka, możemy śmiało powiedzieć, że nadszedł czas, aby przenieść swoje style do głowy. Jeśli jednak większość Twoich subskrybentów korzysta z niejasnych klientów poczty e-mail lub międzynarodowych klientów poczty e-mail (Yandex, Libero, Terra), które opierają się na stylach inline, być może będziesz musiał nadal ich używać. Jak zawsze zalecamy testowanie wiadomości e-mail za każdym razem, gdy wprowadzasz w niej jakiekolwiek istotne zmiany.

Mit 6: Nie używaj obrazów tła w wiadomościach e-mail.

Obrazy tła były bardzo trudne do uzyskania w wiadomości e-mail. Programiści poczty e-mail używają skomplikowanego kodu VML do renderowania w wielu wersjach Outlooka, a także w innych klientach poczty e-mail brakowało obsługi obrazów tła.

Oto rzecz: obrazy tła mogą działać i działają w wiadomościach e-mail, ale w ten sposób są włączane do projektu wiadomości e-mail. Przy ograniczonym wsparciu nie powinieneś używać obrazów tła jako kluczowego elementu w projekcie e-maila, ponieważ to powoduje lub psuje wrażenia dla subskrybenta. Można ich jednak używać w wiadomościach e-mail podobnie jak w przypadku czcionek internetowych — jako stopniowego ulepszenia.

Jednym z największych powodów, dla których nie używano obrazów tła w e-mailach, był brak obsługi przez Gmaila właściwości CSS background-size i background-position. Te właściwości CSS są ważne w przypadku ekranów o dużej gęstości pikseli i hybrydowych/płynnych/responsywnych wiadomości e-mail, w których należy zapewnić pewną kontrolę nad rozmiarem i rozmieszczeniem obrazów tła. Oba są teraz obsługiwane w Gmailu i Inbox by Gmail, więc jest jeszcze mniej powodów, aby nie próbować używać obrazów tła w e-mailach.

Kristian Robinson, główny programista poczty e-mail w TWO Digital marketing i prelegent na konferencji The Email Design Conference 2016, zagłębia się w obrazy tła w wiadomościach e-mail, jeśli czujesz się zainspirowany do ich rozwiązania.

Mit 7: Wiadomości e-mail muszą wyglądać identycznie we wszystkich klientach pocztowych.

Wszystkie klienty poczty e-mail mają nieco inne sposoby renderowania wiadomości e-mail w formacie HTML. Zamiast to zaakceptować, twórcy poczty próbowali włamać się do identycznych wiadomości e-mail w wielu klientach poczty e-mail. To bardzo honorowe zadanie, ale może skutkować nadętym i hackowym kodem HTML, który może być koszmarem do zarządzania i aktualizowania.

Może to nie być programista poczty e-mail poszukujący doskonałości poczty e-mail, ale klient lub inni interesariusze. Jednak obowiązkiem programisty poczty e-mail jest edukowanie osób wokół nich, aby zrozumieli pułapki związane z tworzeniem poczty e-mail — dlaczego klienci poczty e-mail renderują się inaczej i dlaczego nie ma znaczenia, czy coś jest o 1 piksel wyższe w jednym kliencie poczty e-mail w porównaniu z innym.

„Czas, w którym e-maile musiały być idealne do piksela, są już za nami”. @ericlepetitsf #LitmusLive

— Chad S. White (@chadswhite) 16 sierpnia 2016

Mit ten jest szczególnie szkodliwy, gdy próbujemy zastosować nowe techniki w poczcie e-mail, które mogą nie być renderowane w 100% klientów poczty e-mail, na przykład czcionki internetowe i obrazy tła. Oba są fantastycznymi sposobami na ulepszenie poczty e-mail. A gdzie bylibyśmy jako branża, gdybyśmy nie próbowali adoptować i eksperymentować z nowymi technikami w naszych e-mailach?

To, że od lat coś robiono w określony sposób, nie oznacza, że ​​nie ma lepszego sposobu na zrobienie tego. Nadszedł czas, aby zakwestionować zasady i najlepsze praktyki, z którymi branża e-mail marketingu współpracuje od dziesięcioleci.

Koduj e-maile szybciej i łatwiej dzięki Builder

Przyspiesz przepływ pracy nad tworzeniem wiadomości e-mail dzięki Builder, jedynemu edytorowi kodu stworzonemu specjalnie do obsługi poczty e-mail. I to nic nie kosztuje!

Zacznij korzystać z Buildera →