カスタムHTMLのメールブロックは、標準コンポーネントでは解決できない具体的な問題を補うために使います。商品名が長くなったとき、画像が表示されないとき、スマートフォンで開いたときにも使える状態を保つ必要があります。必要最小限の部品を定義し、エディターの外でもテストして、条件が変わっても機能するものを再利用しましょう。
必要な変更を最小限に定める
ブロックで何を伝えるのか、既存のレイアウトではなぜうまく伝わらないのかを書き出します。マークアップはその目的に絞りましょう。メールアプリが対応しない可能性のあるスクリプトや複雑な仕組み、スタイルを含むウェブページ全体を持ち込むのは避けます。
SendvioはHTMLメールブロックに対応しています。翌月にテンプレートを引き継ぐ人にも理解できるコードにしましょう。装飾的なマークアップの中にメッセージを隠すのではなく、明快な構造、意味のあるテキスト、適切な画像の代替テキストを使います。
小さなコンポーネントの仕様を決める
ブロックの目的、必須の内容、任意の内容、現実的な最大文字数、リンク、画像の扱い、モバイルでの表示順を定めます。たとえば2つの商品を比べるブロックなら、商品名、異なる特徴、価格の情報、それぞれの行動ボタンが必要かもしれません。画面幅が狭くなっても、どの要素を一緒に表示するかを仕様に含めます。
もっと簡単な標準ブロックの組み合わせで実現できないか先に確認します。カスタムHTMLを使うのは、複雑な見た目を作れるからではなく、明確な伝達上の問題を解決できる場合です。構造上のルールが増えるたび、次の編集者が理解してテストすべきことも増えます。
カスタムブロックは独立させます。周辺のコンポーネントを意図せず変えてしまう広い範囲のスタイルや、主な内容を伝えるためのスクリプト、ウェブサイトのような操作に依存しないでください。複雑な選択や計算が必要なら、メールで内容を説明し、対応できるページへ案内します。
エディター外でも動作を確認する
メールの表示は通常のウェブサイトとは異なります。実際に配信したメールを、関連する複数のアプリ、画面幅の狭い端末、画像を表示しない状態でテストしましょう。リンク、読み上げ順、文字サイズの変更、標準テンプレートの部品と並んだときの表示も確認します。
内容に合わせて変化する箇所を固定の高さで囲んだり、改行できない長い文字列を入れたりしないようにします。短いサンプルでは問題がなくても、顧客名や翻訳した見出しで不具合が見つかることがあります。安定して動かない場合に使える、より簡単な代替デザインも用意しましょう。
元のサンプル以外の内容でもテストする
短い商品名を現実的に長い商品名に置き換えます。任意の画像を外し、翻訳した見出しを入れ、価格やボタンのラベルも長くしてみましょう。レイアウトが自然に広がるか、文字が切れたり固定の高さに余白が残ったりしないか確認します。こうしたテストで、ブロックが再利用できるのか、ひとつの例だけに合わせて作られているのかがわかります。
関連するメールアプリで実際に送信した結果を確認します。意味の通る読み順が保たれるか、画像の代替テキストが文脈に合うか、すべてのリンク先が正しいかを調べます。レイアウトテーブルを使う場合は、支援技術に内容の意味を誤って伝えないよう、実装者が適切な構造を確認してください。
テスト済みのバージョンだけを再利用する
承認したブロックを、目的と制限を記した短いメモと一緒に保存します。テキストだけの変更と、表示テストのやり直しが必要な構造変更を区別しましょう。
メールをウェブサイトのように動かすため、トラッキングスクリプトや実行可能なコードを追加しないでください。メールで確実にできない操作は、適切なリンク先ページに置きます。作成者のプレビューだけで動く複雑な部品より、安定した小さな部品のほうが顧客に役立ちます。
承認済みブロックの用途、担当者、既知の制限、変更履歴をテンプレートのメモに記録します。文字の変更はリスクが低くても、列の構成を変えたり条件分岐を増やしたりする場合は、表示確認が必要です。この違いを共有すれば、不必要に毎回すべてを再テストせずに済み、デザイン変更を単なる文章修正として扱うことも防げます。
ブロックが安定して動かない場合に備え、より簡単な代替案を用意します。複雑なレイアウトが一般的な環境で崩れるより、1列の比較をきちんと読めるほうが有用です。受け入れ条件は実用的に考えます。内容が正しく、関連する要素がまとまり、文字が読みやすく、操作にアクセスでき、次の担当者が安全に再利用できる構造であることです。