UXチームMailChimp：開発[本の第6部]

[ TL; DR ]



[本の最初の部分 ]

[本の第2部 ]

[本の第3部 ]

[本の第4部 ]

[本の第5部 ]

[本の第7部 ]

[本の第8部 ]

アダプティブディストリビューションシステムの作成

ファビオ・カルネイロ



電子メール設計者がトレーニングや作業に使用できるモジュール構造のアダプティブメーリングのモデルを作成することは、私たちにとってユニークなタスクでした。 MailChimpのメーリングリストデザインテンプレートライブラリには膨大な数の記事とコード例がありますが、そのようなすぐに使用できる実用的なコードを作成することで、このすべての情報を実用的な参照モデルの形で組み合わせることができます。



このようなアダプティブテンプレートはMailChimp専用に作成されたものではないため、メールデザイナーが使用できるさまざまな状況を考慮して作業する必要がありました。 その結果、2つの論文を作成しました。1）さまざまなタスクや目標に合わせて文字を作成し、2）できるだけ多くのメールクライアントでテンプレートを使用できるようにします。



異なるシステムで使用できるようにすることはそれほど難しくありませんでした。 多くの電子メールクライアントはひどいですが、それぞれの長所と短所を理解し始めるとすぐにタスクが単純化されます。 与えられた制限内で作業するだけです。



テンプレートをさまざまなタスクに適応できるようにするための要件は、より困難なテストでした。 特定のタスク用のメーリングテンプレートの設計と開発は非常に簡単です。計画を実現するために、問題を設計したり、特殊なHTMLコードとCSSを使用したりすることはできません。 これはすべて、コンテキストを知っているためです。レターの作成目的、コンテンツの種類、および理想的にはこのレターが開くメールクライアントを知っています。 しかし、テンプレートを作成して幅広い人々のグループが作業できるようにテンプレートを作成する必要がある場合、その目標は常に前もって説明できません。そのようなコンテキストは単に存在しません。



このコンテキストの欠如を克服するために、MailChimpで電子メールテンプレートを作成するために使用したプロセスと同様のプロセスに従うことにしました。

1. ニュースレターの最も一般的な使用事例の概要を説明します。
2. これらのユースケースのデザインテンプレートを作成します。
3. HTMLで独立したオブジェクトのシステムを設計します。
4. さまざまな電子メールクライアントをサポートする機能を備えたコードを完成させます。
5. 理解を深めるためにコードにコメントを記載し、明確なマークアップを使用します。

そして、ここに私がそれをした方法があります：



ユースケースの一般的な範囲を概説する



このプロセスにより、何を開発する必要があるのか​​、そしてそれをどのように行うかの大まかなアイデアを策定できます。



ほとんどすべての電子メールは、4つの広範なカテゴリのいずれかに起因します。

• 「Read me」-これらは、たとえばニュースレターであり、その意味は、テキストまたは画像に基づいて宛先に情報を提供することです。
• 「Buy me」-これらは、読者が一定の金額を使うことを確実にすることを目的とした電子商取引分野からの手紙です。
• 「Join me」-一部のアクティビティをカバーし、それに参加するための行動を促すフレーズを含むイベントまたは招待に関する情報。
• 「Understand me」とは、小切手や注文情報などの特定の取引を反映し、重要な詳細とデータを含む文字であり、原則としてそれ以上のものはありません。

アダプティブレターテンプレートを作成する場合、これら4つのシナリオすべてを検討する必要がありました。



デザインテンプレートを作成する



これらのユースケースにはすべて、重複する要素セットが含まれています。 たとえば、「Buy me」、「Join me」、「Understand me」などの文字にはすべてボタンの形でCTAを含めることができますが、「Buy me」や「Read me」などの文字は、通常、特定の数の画像。



さまざまな文字グループの共通要素を研究し、その外観のテンプレートがどのように見えるべきかを理解し始め、その結果、作成する必要のあるブロックのリストを作成しました。 その結果、ボタン、画像のグループ、キャプション、ブロックで囲まれたコンテンツ、カレンダー、キャプション付きの画像など、17種類のテンプレートが完成モデルに含まれました。



HTMLでオブジェクトシステムを設計する



開発に必要なものを正確に理解するとすぐに、コードを書き始めました。



モデルを作成して、受信したHTMLコードに誰でもアクセスし、その構造を理解し、必要なデザインテンプレートを使用して目標を達成し、フレームワークの状態を気にせずに執筆スタイルを変更し、すぐに開始できるようにしたかった結果をメールキャンペーンで使用します。



これらのすべての要件を満たすために、すべてのコンテンツブロックが均等に構造化されるようにHTMLコードを記述したため、コードの学習と理解が容易になりました。 さまざまなタイプのコンテンツのデザインテンプレートはそれぞれテーブルの別の行に配置されました。これにより、最終モデルのモジュール構造が実現しました。 対応する行をコピーまたは移動するだけで、個々の要素を複製または移動することが可能になりました。



さらに、プロジェクト全体が最小限のCSSで構築されました。標準CSSには4つのルールセットのみ、メディアクエリには4つだけです。 さらに、コンテンツ自体の基本的なスタイル設定が使用されましたが、これはテキストのデザインと背景色のみに影響しました。 したがって、デザイナーは、ニュースレターの機能コンポーネントへの影響について困惑することなく、独自のCSSを作成できました。



受信したコードを完成させる



開発が完了したら、ブラウザとモバイルデバイス用の電子メールクライアントを使用して、標準的な一連のテストを使用して、結果のモデルをテストしました。 最初の実行中、受信したメッセージはすべての一般的な電子メールクライアントで問題なく表示されました。 しかし、私の仕事はそこで終わりではありませんでした。2つのメールクライアントがあり、問題がありました。



Outlook 2007/2010とAndroid向けGmailモバイルアプリは悪夢です。 OutlookにはMicrosoft Wordベースのグラフィックエンジンが原因で多くの問題があり、Gmailアプリケーションはモバイルであるにもかかわらずメディアクエリをサポートしていません。 Outlook用のレターのバージョンを書くには、非常に柔軟性がなく、慎重に検証されたコードを作成する必要があり、Gmailメールクライアントには、非常に「ゆるい」コードが必要でした。



通常、安全にプレイし、メーリングリストの信頼性を高め、Outlookサポートの可能性を考慮に入れることをお勧めします。結局のところ、Microsoftは鉄のグリップを備えたPC用の電子メールアプリケーションの市場を保持しています。 しかし、私たちの適応モデルは、技術に精通しているメールデザイナー向けに考案されたため、私は反対側を選び、モバイルサポートを最大限に活用することにしました。 これは、 テーブルの配置を使用して複数のコンテンツブロックを作成することを意味しました。 AndroidのGmailアプリですべてが整いました。



「GmailのみがAndroid向けなのはなぜですか？ 結局のところ、iOS用のアプリケーションもあります！”もちろんありますが、それはさらに悪く動作します-そして、何もまったくサポートしていません。 文字は通常表示されますが、今日ではモバイルアプリケーションのサポートを忘れることがあります。



それでも、Gmailにテーブルの配置を使用することは柔軟性を高めるための優れたソリューションですが、Outlook 2007/2010で（推測しやすい）要素の配置がクラッシュする原因となります。 問題は、22インチ（または1700px）より長いドキュメントに改ページを自動的に挿入するOutlookの非常に潜んでいるバグにありました。 これが発生すると、floatプロパティを持つ整列されたテーブルがクリープし始めます。 幸いなことに、この問題はOutlook 2013で解決されたようです。



1つの解決策は、条件付きCSSを使用し、別のスタイルを作成してOutlookの問題を克服することです。 この場合、私はそれを複雑にしないことに決め、モバイルクライアントのメディアクエリを使用して以前に行われたすべてを単純に繰り返しました。 条件付きCSSはオプションですが、問題の良い解決策です。



Outlook 2007/2010とGmail for Androidのサポートを考え出した後、このモデルはほとんどのメールクライアントで確実に動作し始め、同時に十分なレベルの柔軟性を備えました。



コメントトレーニング



これらの手法の一部は、電子メールデザイナーとして働き始めたばかりの人には必ずしも明確ではないかもしれません。 この問題を解決するために、このコードブロックまたはそのコードブロックが使用される理由と、このブロック内で正確に何が起こるかを示す説明をコードに含めようとしました。



また、セクションの始まりと終わりにマークを付けて、コンテンツの存在を暗示し、それらを埋めるために特別なアクションが必要かどうかを示しました。



基本的なユースケースに作成されるモデルの焦点を維持し、レター全体に繰り返しデザインテンプレートを適用し、信頼性があり同時に柔軟なコードを作成することで、誰もがアダプティブHTMLレターテンプレートを理解し、簡単に作業を開始できるようにしました。



このモデルが、電子メールテンプレートのライブラリと組み合わせて、HTMLの文字のデザインに関する謎と誤解のオーラを払拭できることを願っています。 もちろん、私たちは作業を終了していません。参照ライブラリとレターモデルの両方が、受け取ったフィードバックに基づいて開発および改善を計画しているプロジェクトです。

テキストの圧縮と相対的なフォントサイズ

マルダヴ・ヴァラ



2013年のMailChimpの再設計により、アプリケーションのタイポグラフィを慎重に選択する機会が与えられました。 モジュラーレイアウトシステム（グリッドを使用したレイアウト）を使用しても、誰も驚かないでしょうが、ネットワーク内で垂直リズムを実現する（これは「コンテンツをモジュラーグリッドに揃える」という別の方法です）、特に表示されるコンテンツのタイプが十分に強い場合は、まだそれほど簡単ではありません異なります。 しかし、主にデザインとコード間の最初の不一致の問題を解決した後、これは主に行間隔を知覚する（または知覚しない）方法と印刷メディアとWebメディアのリードの違いにより発生します。開発は同じ言語を話し始めました。



テキスト圧縮



リチャード・ラッターが述べたように、ウェブページの垂直リズムは、行間隔、オブジェクト間の境界、要素のコンテンツとその境界間の距離をきちんと操作することで達成できます。 一番下の行は、マージンとインデントのサイズを計算するための基礎を設定する適切な行間隔を見つけることです。



MailChimpアプリケーションには大量のコンテンツが含まれていますが、非常に小さな部分には多数のテキストの段落が含まれています。ほとんどすべての情報は、リスト、フォーム、表、グラフ、またはデータブロックの形式で表示されます。 したがって、大きなサイズのマージンとインデントを伴う大きな行間隔で開始する代わりに、アプリケーションの各要素に対して最小の行間隔である6pxから開始しました。 モジュラーグリッドは、この6pxの値に基づいています。



なぜ6pxなのですか？ 多くの基本的な値を試してみましたが、乗算によって6pxが非常にエレガントに12px、18px、242pxなどに変わり、さまざまなフォントサイズとインデントが得られることがわかりました。 この値は、ボタンやフォームフィールドなどの小さな要素にも完全に適用できることがわかりました。 これにより、ほぼすべてのインターフェイスを作成するために必要な柔軟性が得られました。



MailChimpでは、変更が進行中です-4週間ごとにUIの新機能と更新をリリースするため、垂直リズムの探求では、システムに十分なレベルの柔軟性を提供する必要がありました。 設計プロセスの初期段階で、垂直リズムを作成するプロセスを容易にするために、要素の下部にのみパディングを適用することにしました。 したがって、ページ上の視覚的な階層を壊すことなく、新しいモジュールを配置できます。 「一方向」のインデントを使用することで、この目標を達成できました。



簡単な数学



インターフェースは6ピクセルのモジュラーグリッドで設計されているため、垂直リズムを設定するには、すべてのサイズの行間、インデント、マージンを6の倍数にする必要がありました。 ただし、フォントサイズは任意に設定できます。この垂直リズムに違反する心配はありません。 メインフォントのサイズは15ピクセルです。このようなフォントは、すべての状況で読み取り可能であり、同時にインターフェイスをオーバーロードしません。



ベストプラクティスによると、読みやすさを向上させるための行間隔は、フォントの高さの1.5倍にする必要があります。 フォントサイズが15ピクセルの場合、この場合の行間隔は22.5ピクセルになります。 しかし、モジュラーグリッドのステップは6pxだったため、行間隔を24pxに「伸ばし」、行間隔、インデント、およびすべてのモジュールのマージンの間に直接の関係を作成しました。 計算を理解したので、これらの比率をアプリケーションの要素に適用し始めました。



すべての見出しおよびその他のフォントサイズについて、行間隔も6の倍数に設定され、フォント自体のサイズに従って計算されました。 例では、表示を簡単にするためにピクセル測定を使用しています。

h1 { font-size: 40px; line-height: 48px; } .small-meta { font-size: 13px; line-height: 18px; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

規則の例外



画像とグラフィックスは一般的な規則に従わず、多くの場合、モジュラーグリッドを「破壊」します。 それらのサイズはしばしば予測不可能です-それらは常にグリッドピッチに簡単に合わせることができません。 しかし、これにもかかわらず、インデントとフィールドによって定義されたオブジェクト間の境界は変わらないため、垂直リズムは侵害されません。



境界線を持つ要素は、サイズが主要な計算に追加され、システムに埋め込まれないため、モジュラーグリッドの範囲を超えることもあります。 ただし、ここでの解決策は簡単です。境界を考慮して要素の高さを計算します（このアプローチでは、要素の上下にあるフィールドを境界のサイズだけ小さくする必要があります）。



もちろん、純粋主義者は、要素の境界の高さが1pxを超える場合、そのようなアプローチは視覚的な不均衡につながると主張するかもしれません。 水平線と境界線がインデント、行間隔、マージンに適切なアプローチで垂直リズムに影響を与えることができないため、モジュラーグリッド上で水平線と境界線要素を揃える努力は必ずしも機能しません。



リストボックスフィールドを境界線の高さ1pxに縮小した例を次に示します。

 @base-unit: 6px; .dotted-list { margin-bottom: (@base-unit * 2); li { padding-top: (@base-unit * 2) padding-right: 0; // 1px less padding bottom padding-bottom: ((@base-unit * 2) - 1); padding-left: 0; border-bottom: 1px dotted #c0ffee; } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

チャートは、グリッドに比例して調整することもできます。 ブラウザウィンドウが変更されたときにグラフの縦横比が変更された場合、グリッドのステップに比例してグラフの高さと垂直インデントを設定します。 これが起こらない場合は、垂直インデントのみを設定し、グラフの高さは変更しないでください。



画像の高さは幅を変更すると拡大縮小するため、高さをモジュラーグリッドに合わせることに頼ることはできません。 これらの場合、垂直リズムを乱さないように、オブジェクトを囲むインデントが設定されていることを確認する必要があります。



このような特別なルールをコードに適用し、ルールの例外を操作すると混乱する可能性があります。 チームに関する簡単な議論とコード内の簡単なコメントにより、多くの困難を軽減できます。 テンプレートライブラリへの変更を文書化することも重要です。



モジュールレベルでの「微調整」垂直ギャップ-マークボルトンが推奨する「コンテンツ外」の設計-は、グローバルな「ページ単位」レベルでの変更よりもはるかに意味のあるプロセスであることがわかりました。 個々のモジュールがモジュラーグリッド上で互いに適合している場合、それらがどこに配置されているかは関係ありません。垂直のリズムと視覚的な階層が自動的に尊重されます。



相対フォントサイズ



emで測定された相対的なフォントサイズ（現在のフォントのサイズに等しい相対的な長さの単位）を使用して、柔軟でスケーラブルなデザインを作成することは、ピクセル単位で絶対的なフォントサイズを指定するよりも難しい場合があります。



ピクセルから相対単位（em）への値の変換は、以前はかなり退屈な作業でした。 幸いなことに、CSSプリプロセッサとユビキタスなEthan Marcotteルールを組み合わせた機能を使用することで、プロセスを簡素化できます：ターゲット÷コンテキスト=結果。



相対的なフォントサイズに関するこのような混乱の中で順序を維持するための鍵は、コンテキストに集中することです。 相対的なフォントサイズを持つネストされた要素の場合、コンテキストはピクセル単位で表される親要素のフォントサイズです。親要素の場合、コンテキストはメインテキストのデフォルトのフォントサイズです（メインテキストについてのみ説明する場合は16px）。



Treehouseのこの例に基づくサンプルHTMLコードは次のとおりです。

 <h1>Title: <span>Tagline</span></h1>
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

次のように、ヘッダーの相対的なフォントサイズを設定し、ネストされたインライン要素のフォントが混乱なく決定されるようにすることができます。

 // default body font-size @baseFontSize: 16; @h1Size: 24; @h1SpanSize: 18; h1 { #pxtoem > .font-size(@h1Size, @baseFontSize); // 24 ÷ 16 = 1.5em > span { #pxtoem > .font-size(@h1SpanSize, @h1Size); // 18 ÷ 24 = .75em } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ネストされたレベルの数が増えると（ネストされた見出し、段落、リンク、小文字要素を持つレベルになる可能性があります）、フォントサイズを監視することがより難しくなります。そのため、このような予防制御手段は、CSSの絶え間ない達成に役立ちます。