メール開発の7つの神話

公開: 2016-10-25

電子メールは、レイ・トムリンソンによって考案された1971年に、テキストのみの1：1の通信方法として始まりました。何十年にもわたって電子メールは進化し、初期の電子メールのテキストのみのバージョンからHTMLに移行しました。電子メールを未来に押し上げるのは、厳密な範囲内で創造的な技術を使用する電子メール開発者です。

当時、電子メール開発者は、他の人が電子メールコーディングを開始できるようにするため、または電子メール開発者ができることとできないことの塹壕にいる人々へのリマインダーとして機能するために、あらゆる種類の「ベストプラクティス」を作成しました。

今日は、ベストプラクティスを静的なものと見なしてはならないことをメール開発者に思い出させるためにここにいます。それらは変化します。 1990年代後半に電子メール開発者にとって最善であったことは、2010年代半ばにはもはや当てはまりません。

これは、何年も前から存在している7つの電子メール開発の神話と、最終的にそれらを休ませる時が来た理由です。

神話＃1：メールは600ピクセル幅でなければなりません。
神話＃2：標準のシステムフォントのみを使用する必要があります。
神話＃3：移行DOCTYPEのみを使用します。
神話＃4：属性セレクターを使用する必要があります。
神話＃5：メールのすべてのスタイルをインライン化する必要があります。
神話＃6：メールで背景画像を使用しないでください。
神話＃7：電子メールはすべての電子メールクライアントで同一に見える必要があります。

神話＃1：メールは600ピクセル幅でなければなりません。

携帯電話やタブレットが一般的になり、電子メールが単なるデスクトップアプリケーションになる前は、ベストプラクティスでは、すべての電子メールの幅を600ピクセル以下にする必要がありました。なぜ正確に600ピクセルなのですか？当時最も一般的に使用されていた電子メールクライアント（HoTMaiL、Yahoo、およびOutlook）のビューポートサイズは、約500〜550ピクセルでした。電子メールの幅を600ピクセル以下に設定すると、電子メールの水平方向のスクロールをできるだけ少なくすることができます。

その600ピクセルのルールは固執しました。今日、対応するデバイスは増えていますが、すべて画面サイズが異なりますが、なぜこの600ピクセルのルールに固執するのでしょうか。

特にメールワークフローにAdobePhotoshopまたはSketchでのデザインの作成が含まれている場合は、これを守るのは簡単なルールです。メールデザインを開始するには物理的な幅が必要です。確かに、幅600ピクセルの電子メールは、デスクトップ上で、より人気のある電子メールクライアントの間で非常にうまく表示されます。また、メディアクエリを使用することで、電子メール開発者は、サブスクライバーが開くために使用するデバイスに応じて、電子メールの幅を簡単に変更できます。

流体の幅は、電子メール開発者がサポートする必要のある膨大な数のデバイスの問題を解決します。これを機能させるには、max-widthを使用して、大きなビューポートで電子メールが広すぎて判読できなくなるのを防ぎ、MSO条件ステートメントを使用してOutlookに理解させます（max-width CSSプロパティをレンダリングしないため）。

Zalandoのメールの幅は450ピクセルです。これは、私たちが見慣れている600ピクセルの標準からはほど遠いものです。大規模なCTAと組み合わせると、Zalandoのモバイルフレンドリーな電子メールはモバイルの群衆により多く対応しているように見えます。

毎週メール — ウィークリーのレスポンシブメールをさまざまな幅でメールで送信します。メール全体を見る

一方、Email Weeklyの電子メールは、最大幅960ピクセルの流動的な手法を採用しています。メディアクエリを使用して、デバイスの幅に応じて電子メールの幅を適切に変更します。

サブスクライバーが電子メールを開くために使用するクライアントとデバイスによっては、電子メールの幅を600ピクセル以外の最大値に設定するのが理にかなっています。

あなたの購読者はどこであなたのEメールを開いていますか？

Email Analyticsを使用すると、メールを開いているデバイスとメールクライアントを見つけることができます。

詳細→

神話＃2：標準のシステムフォントのみを使用する必要があります。

システムフォントは、長い間、電子メールで使用するための安全なオプションでした。まあ、彼らは唯一の選択肢でした。

一方、Webデザイナーは、2000年代初頭から、Web上で非標準フォントを使用する実験を行ってきました。 2008年、CSSルール@ font-faceは、WebデザイナーがWebサイトで非標準フォントを使用できるようにWebブラウザーからサポートされました。 2010年、Googleは独自のウェブフォントライブラリを立ち上げました。ウェブデザイナーは無料で使用できます。

WebフォントをHTML電子メールにインポートするための確実な方法がないため、電子メール設計者にとってそのような運はありません。ライセンスの欠如は言うまでもありません。Webフォントが最初に作成されたとき、誰もそれらが電子メールで使用されるとは思っていなかったため、Webフォントのライセンスは電子メールの使用をカバーしていませんでした。

電子メールには標準のシステムフォントを使用することをお勧めしますが、それはプログレッシブエンハンスメント手法としてWebフォントを使用できないという意味ではありません。オンラインフォントリポジトリは、ライセンスでの電子メールの使用をカバーし始めています。また、800個の無料で使用できるWebフォントを備えたGoogle Fontsは、非標準のWebフォントを電子メールで使用したい電子メール設計者にとって頼りになるライブラリになりつつあります。

Webフォントのサポートは、Google Android 4.4、iPhone、iPad、Mac用のApple Mail、OSX上のOutlook2011と2016にあります。これはそれほど多くないように思われるかもしれませんが、今年の9月の時点で上位5つのメールクライアントのうち4つです。、市場シェアでは、iPhone、iPad、Google Android、AppleMailなどのWebフォントをサポートしています。これは、9月に開かれるすべての電子メールの50％以上です。もちろん、あなたはあなた自身の加入者ベースを見る必要があります、しかしこれは潜在的に何人の人々があなたの電子メールでウェブフォントを見ることができるかについての良い指標です。

これら2つのメールの微妙な違いがわかりますか？左側はWebフォントを使用しており、右側はWebフォントが無効になっています。 Outnetは、ルックアンドフィールがWebフォントに非常に近い優れたフォールバックフォントを選択しました。これは、今日の電子メールでWebフォントを一貫して使用する方法を示しています。

神話＃3：移行DOCTYPEのみを使用します。

HTMLドキュメントのDOCTYPEは、ページのレンダリング方法をブラウザに指示し、ドキュメントのHTMLを検証するために使用されます。

電子メールで最も一般的に使用されるDOCTYPEは次のとおりです。

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

一部の電子メールクライアントがDOCTYPEを完全に削除したり、別のDOCTYPEに置き換えたりする場合でも、電子メール開発者はDOCTYPEを使用するという良い習慣を身に付けています。 Gmail、Outlook.com、Yahoo！メールは、メールに存在するDOCTYPEをすべて取り除き、HTML5DOCTYPEに置き換えるメールクライアントの1つです。

Webでは、DOCTYPEが異なると、一部のCSSプロパティとHTML要素のレンダリング方法が変わります。上記のDOCTYPEは、電子メールで使用されている<font>などの非推奨の要素を含む、最も幅広いHTML要素を許可します。過去のテストでは、このDOCTYPEが電子メールに対して最も信頼できることが証明されました。証明された—過去形。

これは、HTML5が標準になる前のことでしたが、現在は次のようになっています。

 <!DOCTYPE html>

HTML5 DOCTYPEを使用すると、電子メールで使用できる<video>などの新しいHTML5要素を使用できます。すべてのクライアントが新しい要素またはプロパティをレンダリングできるわけではありませんが、DOCTYPEを更新して、将来的に電子メールを微調整しない理由はありません。 HTML5 DOCTYPEで非推奨のコードを引き続き使用できますが、検証サービスでチェックすると、コードは無効になります。コードが有効かどうかにかかわらず、配信可能性やパフォーマンスの点でメールに影響はありませんが、開いているHTMLタグのHTMLマークアップを確認することをお勧めします。これは、メールのレンダリング方法に影響を与える可能性があります。

神話＃4：属性セレクターを使用する必要があります。

Yahoo! メールは、たとえばOutlookよりも開発するのに少し親切な電子メールクライアントです。それは私たちが覚えている限り、頭の中でスタイルをサポートしていました。 1つの癖Yahoo! メールは、メディアクエリ内のCSSステートメントをメディアクエリ外のCSSと一緒にレンダリングすることを提案しました。これに対する簡単な修正は、CSSステートメントを属性セレクターとして記述することでした。

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

このような電子メールの先頭にCSSを書き込むことは、先頭でスタイルを読み取る他の電子メールクライアントが上記の例のように単純な属性セレクターを問題なく読み取るため、標準になりました。

2015年の初めに、Yahoo！メールは、「通常の」電子メールクライアントと同じようにスタイルを読み取ることができる更新を公開しました。

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

ただし、属性セレクターは電子メール開発に深く根付いていたため、属性セレクターがまだ電子メールコードで動き回っているのを見るのは当然のことでした。電子メール開発者は単にそれらを使用することに慣れていて、多くの場合、電子メールテンプレートは更新されていませんでした。

以前は無害でしたが、属性セレクターがコードに含まれている場合、属性セレクターが電子メールに少し害を及ぼす可能性があります。メールのスタイルがGmailで機能していないように見える場合は、スタイルで属性セレクターをまだ使用しているかどうかを確認してください。 Gmailは属性セレクターをサポートしていませんが、<head>のスタイルを（ついに！）サポートするようになりました。

Yahoo!では属性セレクターは不要になりました。メールとGmailはそれらをサポートしていないため、メールのCSSで属性セレクターを使用する必要はありません。

神話＃5：メールのすべてのスタイルをインライン化する必要があります。

レイアウトとインライン化スタイルのテーブルは、それ以来…永遠に電子メール開発の基盤となっています。それらは、電子メールとWeb開発の違いを定義します。インライン化スタイルは現在、電子メール開発者にとって非常に一般的であり、そもそもスタイルをインライン化する必要がある理由について少し曖昧になっています。

驚いたことに、一部のサイトは、インラインスタイルが必要な理由はOutlookとGmailのためであると主張しています。これはまったく間違っています。 [これをツイート]

Outlookは、電子メールの先頭のスタイルに問題があったことはありません。一方、Gmailはそうしました。メール開発者がCSSをインライン化する理由については、文字通りGmailが最大の理由です（2016年9月の時点で16％の市場シェア）。

9月末に、Gmailは頭の中でスタイルをサポートし始めました。では、もうすべてのスタイルをインライン化する必要がありますか？

サブスクライバーが主にGmail、iOS、さらにはOutlookを使用している場合は、今があなたのスタイルを頭に浮かび上がらせる時だと自信を持って言えます。ただし、サブスクライバーの大多数がインラインスタイルに依存するあいまいな電子メールクライアントまたは国際的な電子メールクライアント（Yandex、Libero、Terra）を使用している場合は、それらを引き続き使用する必要があります。いつものように、大きな変更を加えるたびにメールをテストすることをお勧めします。

神話＃6：メールで背景画像を使用しないでください。

背景画像は、電子メールで正しく取得するのが難しいことで有名です。電子メール開発者は、複雑なVMLコードを使用してOutlookの多くのバージョンでレンダリングします。また、他の電子メールクライアントでも背景画像がサポートされていません。

背景画像はメールで機能しますが、メールのデザインに組み込まれる方法です。サポートが制限されているため、電子メールのデザインの重要な要素として背景画像を使用しないでください。これは、サブスクライバーのエクスペリエンスを向上または低下させるためです。ただし、プログレッシブエンハンスメントとして、Webフォントを使用するのと同じように電子メールで使用できます。

メールで背景画像を使用しない最大の理由の1つは、GmailがCSSプロパティbackground-sizeとbackground-positionをサポートしていないことです。これらのCSSプロパティは、高ピクセル密度の画面や、背景画像のサイズと配置方法をある程度制御する必要があるハイブリッド/流体/レスポンシブメールにとって重要です。どちらもGmailとInboxby Gmailでサポートされるようになったため、メールで背景画像を使用しない理由はさらに少なくなりました。

TWODigitalマーケティングのリードEメール開発者であるKristianRobinsonと、Eメールデザインカンファレンス2016の講演者は、Eメールの背景画像に取り組みたいと思っている場合は、それらを深く掘り下げます。

神話＃7：電子メールはすべての電子メールクライアントで同一に見える必要があります。

電子メールクライアントはすべて、HTML電子メールをレンダリングする方法がわずかに異なります。これを受け入れるのではなく、電子メール開発者は、多数の電子メールクライアント間で同一の電子メールへの道をハッキングしようとしました。実行するのは非常に名誉な作業ですが、HTMLコードが肥大化し、ハッキーになる可能性があり、管理および最新の状態に保つのは悪夢になる可能性があります。

メールの完成度を求めているのはメール開発者ではなく、クライアントやその他の利害関係者かもしれません。ただし、電子メール開発の落とし穴を理解するように周囲の人々を教育するのは電子メール開発者の責任です。電子メールクライアントのレンダリングが異なる理由と、ある電子メールクライアントで別の電子メールクライアントと比較して1ピクセル高いものが問題にならない理由。

「電子メールがピクセルパーフェクトでなければならなかった時代は、私たちのはるか後ろにあります。」 @ericlepetitsf #LitmusLive
—チャド・S・ホワイト（@chadswhite）2016年8月16日

この神話は、Webフォントや背景画像など、電子メールクライアントの100％でレンダリングされない可能性のある、電子メールで新しい手法を採用しようとする場合に特に有害です。どちらもあなたの電子メールを強化するための素晴らしい方法です。そして、私たちが電子メールで新しい技術を採用して実験しようとしなかったとしたら、私たちは業界としてどこにいるでしょうか？

何かが何年もの間特定の方法で行われたからといって、それを行うためのより良い方法がないという意味ではありません。今こそ、Eメールマーケティング業界が何十年にもわたって取り組んできたルールとベストプラクティスに疑問を投げかける時です。

Builderを使用すると、メールをより速く、より簡単にコーディングできます

メール専用に構築された唯一のコードエディタであるBuilderを使用して、メール開発ワークフローをスピードアップします。そしてそれは無料です！

Builderの使用を開始→