通知：2カラム — ルールと例

2カラム通知は、1つの共通テーマのもとに2つの短いラベル付き通知を配置します。通知はアクションを対比させたり、2つの条件を説明したり、関連する状態を区別したりできますが、それぞれが単独で読まれても正確で有用である必要があります。

このレンダリングされた要素が機能する理由は、「下書きページ」と「公開済みページ」が見せかけの見出しではなく、実際の条件だからです。共通のタイトルが判断基準を定義し、各通知は完全な指示を提供し、どちらも色や水平位置から意味を推測することを読者に求めません。

この要素が重要な理由

読者は、自分に該当する条件を探しながらガイダンスを読むことがよくあります。「下書きにはラベル付きのサンプルが含まれる場合があるが、公開済みページには検証済みの値が必要」という長い段落は、読者に一方の句を記憶させながらもう一方を確認させることになります。2つの境界のある通知はその作業を軽減します。ラベルが先に分岐を示すため、読者は該当する条件を特定してからその指示を読むことができます。

心理的な利点は選択的注意です。人々は両方のメッセージを常に等しく必要とするわけではなく、正しい方に気づいたという確信が必要です。共通のタイトルが質問を設定し、明確なラベルが利用可能な状態を可視化します。また、左右に並べることで、勝者と敗者として過大評価することなく、意味のある対比を明確にします。

この利点は、作成者が偽の対称性を強制すると失われます。偽の対称性とは、レイアウトによって2つのアイデアが同等の範囲、重要性、または有効性を持つように見えることを指しますが、コンテンツはそうではありません。1文のリマインダーが6ステップの安全手順の隣にある場合、それはペアではありません。必須の法的制限が任意の生産性向上のヒントの隣にある場合も同様です。等幅のカラムは、等しくないメッセージを交換可能に見せかける可能性があり、それはまさに誤ったシグナルです。

機械抽出容易性とは、ソフトウェアがコンテンツを正確にする関係を保持しながらコンテンツを分離できる能力です。型付きの2カラム通知は、1つの親テーマと2つのラベル付き子通知を公開します。検索システムやAIエージェントは、「公開済みページには、出典と確認日付のある検証済みの値を使用してください」を、どの見出しがどの文を統括しているかを推測することなく取得できます。明示的なラベル、ソース順、および自己完結型の本文は、レスポンシブスタッキングやテキストのみの抽出でも機能します。

このコンポーネントを選択する前に、要素の書き方ルール に従ってください。目的が外観に優先します。深刻なリスクは警告ボックス のままであり、行動ごとの修正はDo’s and Don’ts ブロック のままであり、2つの事実がデザインでカラムにできるというだけの理由で通知になるわけではありません。

使用するタイミング

この要素は、1つの共通テーマに正確に2つの短い通知があり、両方を同時に見ることで読者が分類、比較、または混乱を避けるのに役立つ場合に使用します。適切な関係の例は次のとおりです：

• 2つの条件： サインイン済みとサインアウト済み、下書きと公開済み、移行前と移行後。
• 2つの対象者： アカウント所有者と招待ユーザー。両方が同じイベントに関するガイダンスを受ける限り有効です。
• 推奨行動と推奨しない行動： 各側が一致する行動のリストではなく短い通知である場合のみ。
• 利用可能状態と利用不可状態： ラベルが各状態を生み出す条件を示している場合。
• 現行の動作と今後の動作： 日付またはバージョンの境界が明示されている場合。

以下のすべてのテストに合格する必要があります：

1. 1つの見出しが両方の通知を正確に導入できること。
2. 条件またはメッセージが正確に2つ存在し、ソースが3つ目のケースを隠していないこと。
3. 各通知に固有のラベルと、完全な結果またはアクションがあること。
4. 狭い画面でソース順にペアを理解できること。
5. どちらの通知も、ネストされた手順、表、フォーム、または長い限定条件を必要としないこと。

ニアミスは誤用を明らかにします。2番目の文が単に最初の文を続ける場合は、通常の散文を使用してください。読者が複数の基準を評価する必要がある場合は比較表を使用してください。3つ以上の条件が分岐する場合、または1つの答えが別の質問につながる場合は決定木を使用してください。メッセージを見逃すと害、データ損失、法的リスク、または不可逆的なアクションを引き起こす可能性がある場合はスタンドアロンの警告を使用してください。複数の誤った行動にそれぞれ対応する修正が必要な場合は、Do’s and Don’tsを使用してください。

釣り合い役を発明しないでください。正直な指示が「移行前にデータベースをバックアップしてください」である場合、「移行後：作業を続けてください」を追加しても対称性が生まれるだけで価値はありません。同様に、1つの通知を「重要」と「これも重要」に分割しないでください。ラベルは実際の条件、状態、対象者、または立場を名付ける必要があります。

配置する場所

共通の状況を定義する段落の直後に要素を配置してください。読者は、分岐に遭遇する前に、通知が該当する判断基準や状態を知っている必要があります。ペアがアクションの前にある場合は、データを変更したり読者を選択にコミットさせたりする最初のステップの前に配置してください。

正確な配置ルールは次のとおりです：

• 2条件ペアは、前提条件の後、条件固有の指示の前に配置します。
• アクション前の対比は、該当するコントロール、コマンド、ダウンロード、またはステップの前に配置します。
• 結果状態ペアは、結果が定義された後、トラブルシューティングの詳細の前に配置します。
• 証拠または出典が特定の通知のみをサポートする場合は、該当する通知内に配置します。共有の証拠は完全なペアの直後に配置します。
• 繰り返されるドキュメンテーションセクションでは、同じソース順を使用して、繰り返し状態が位置を入れ替えないようにします。

この要素は、別の2カラムコンポーネント、比較表、タブコントロール、価格グリッド、または分割コールトゥアクションの隣に配置してはいけません。隣接するグリッドは境界を曖昧にし、4方向の選択肢を暗示する可能性があります。この要素は、主張とその引用、ステップと必要な警告、またはフォームコントロールとそのラベルを分離してはいけません。番号付きステップ内に配置しないでください。ネストされた分岐により、順序と責任が不明確になる可能性があります。

一方のカラムに深刻な警告を、もう一方に日常的なアドバイスを並べて配置しないでください。等しい形状により警告の優位性が低下し、読者が2つから選択できることを示唆します。リスクを該当するアクションの前にスタンドアロンの警告に昇格させ、その後、2つの安全な条件を明確にする必要がある場合にのみこの要素を使用してください。

構造

1. 共通見出し： 両方の通知が統括する1つの状況または判断を命名します。
2. 通知コンテナ： ペアを1つの編集要素としてグループ化しますが、単一のアラートであることを示唆しません。
3. 通知ラベル： 2〜6語で条件、状態、対象者、または行動を命名します。
4. 通知本文： 該当する事実、結果、および次のアクションを、3つすべてが必要な場合にその順序で記述します。
5. オプションのアイコン： 可視のテキストラベルを補強します。単独で区別を伝えることはありません。
6. オプションの出典注記： 変更される、規制される、または外部で定義される主張を、該当する通知内でサポートします。
7. ソース順： スクリーンリーダー、コピー、およびモバイルの順序を決定します。視覚的なスタイリングでこれを逆転させてはいけません。

作成者は共通見出し、2つのラベル、2つの本文、トーン、および出典を提供します。レンダラーはレスポンシブグリッド、間隔、視覚的な強調、セマンティックコンテナ、および装飾的なアイコン処理を提供します。

デザイン例

これらはサポートされている完全なバリエーションです。バリエーションはラベルと強調を変更しますが、2通知データモデルは変更しません。

対比するアクション

推奨するアクションと推奨しないアクションがそれぞれ1メッセージずつある場合に使用します。アクションとその理由を記述し、このバリエーションを一致するリストに拡張しないでください。

条件付き状態

正しい指示が「既存アカウント」や「新規アカウント」などの相互排他的な条件に依存する場合に使用します。各ラベルに条件を名付け、最も一般的または前提条件となる状態を先に配置します。

ペアの明確化

2つの関連する事実が異なる誤解を防ぐが、正反対ではない場合に使用します。両方に中立的なスタイリングを適用して、承認、重大性、または優先度をデザインが発明しないようにします。

コンパクトなステータスペア

状態がすでに説明された後の短いステータスの結果に使用します。各本文は1文です。ラベルを削除したり、本文を説明のない値に縮小したりしないでください。

スタックされたモバイルペア

すべてのバリエーションは狭い幅でスタックします。最初の通知を2番目の直前に保ち、共通見出しを保持してください。スワイプインタラクションやタブを作成しないでください。一方の通知を隠すと要素の目的が損なわれます。

パラメータ

「ソース」は、アダプターが各値を取得する場所を識別します。本文マッピングは、2つの視覚的に配置されたカラムではなく、2つの完全な通知レコードを意図的に保存します。

親の本文の最初の見出しはtitleにマッピングされます。各ネストされたアイテムは、その最初の見出しをlabelに、それ以降のすべてをcontentにマッピングします。通知属性はtoneとiconを保持します。レンダラーは、1つ、3つ、または空の通知アイテムを黙って埋めたりカラムを削除したりせずに拒否する必要があります。

構文とコード例

すべての形式で、同じタイトル、通知順序、ラベル、本文、トーン、および出典が保持されます。「カラム1」および「カラム2」は表示上の用語であり、フィールド名ではありません。

ポータブル Markdown ディレクティブ

:::notification-two-column{variant=conditional}
## 公開状態に応じた指示を選択してください

::notice{tone=neutral icon="draft"}
### 下書きページ

サンプル値は、それが例として明確にラベル付けされている場合にのみ使用してください。公開前にすべてのサンプルを削除または置き換えてください。
::

::notice{tone=caution icon="publish"}
### 公開済みページ

出典と確認日付のある検証済みの値を使用してください。検証が不完全な場合は、主張を保留してください。
::
:::

この要素は、レコードに通知固有のトーン動作があるため、汎用のネストされたアイテム名をnoticeでオーバーライドします。最初の親見出しが共通タイトルを提供し、各通知の最初の見出しがそのラベルを提供します。

Hugo ショートコード

現在のプロダクションショートコードは、この正確なペア通知契約を実装していません。アダプターが存在するまでは、レンダリング例のようなセマンティックHTMLを使用してください。意図されたHugo表記は次のように文書化されています：

{{< notification-two-column variant="conditional" >}}
## 公開状態に応じた指示を選択してください

{{< notification tone="neutral" icon="draft" >}}
### 下書きページ
ラベル付きのサンプル値のみを使用し、公開前に削除してください。
{{< /notification >}}

{{< notification tone="caution" icon="publish" >}}
### 公開済みページ
出典と確認日付のある検証済みの値を使用してください。
{{< /notification >}}
{{< /notification-two-column >}}

スラッシュコメント形式は、この仕様例が存在しないショートコードを呼び出すのを防ぎます。将来のアダプターは、正確に2つの子通知を検証し、ソース順にレンダリングする必要があります。

WordPress ブロック

<!-- wp:amicited/notification-two-column {"variant":"conditional"} -->
<h2>公開状態に応じた指示を選択してください</h2>
<!-- wp:amicited/notification {"tone":"neutral","icon":"draft"} -->
<h3>下書きページ</h3>
<p>ラベル付きのサンプル値のみを使用し、公開前に削除してください。</p>
<!-- /wp:amicited/notification -->
<!-- wp:amicited/notification {"tone":"caution","icon":"publish"} -->
<h3>公開済みページ</h3>
<p>出典と確認日付のある検証済みの値を使用してください。</p>
<!-- /wp:amicited/notification -->
<!-- /wp:amicited/notification-two-column -->

WordPressエディターは2つの固定された通知スロットを表示し、並べ替えを許可し、ラベルまたは本文が空の場合は公開を防ぐ必要があります。グリッドブロックがより多くのカラムをサポートしているという理由だけで、作成者が3つ目の通知を追加できるようにしてはいけません。

例

良い例：完全なアクションを伴う2つの実際の条件

インポート前
現在のレコードをダウンロードし、エクスポート時刻を記録してください。このコピーは、フィールドマッピングが予期しない結果を生成した場合の復旧ポイントとなります。

インポート後
インポートされたレコード数をソース数と比較し、次にマッピングされたすべてのフィールドを含む少なくとも1つのレコードを検査してください。カウントは欠落を検出し、完全なレコードは値のずれを検出します。

このペアには、安全なインポート検証という1つのテーマと、実際の時間的境界があります。各通知はアクションを名付け、どのような失敗を捕捉するかを説明しています。2番目の方が長いのは2つの関連するチェックを含むためですが、両側は同等の責任を持ち、スタックされても理解可能です。

悪い例：リスクを格下げする偽の対称性

便利なヒント
後で見つけやすくするためにエクスポートの名前を変更してください。

重要
「すべて置換」でのインポートは、既存のレコードを完全に削除し、元に戻せません。続行する前に、データベースのバックアップ、ターゲットの確認、承認の取得、ダウンタイムのスケジュールを行ってください。

最初の通知は任意のハウスキーピングです。2番目は不可逆的なデータ損失といくつかの前提条件を説明しています。これらを等しいカラムに配置することは等しい重みを暗示し、重要なメッセージを2つの選択肢の1つのように見せかけます。データ損失の通知をコントロールの前にスタンドアロンの警告に移動してください。ファイル名の提案は通常の補足散文として残してください。

スキーママークアップとアクセシビリティ

2カラム通知には専用のSchema.orgタイプはありません。そのコンテンツは包含するArticle、TechArticle、またはWebPage内に残ります。2つの境界のあるレコードが存在するという理由だけで、ItemList、HowToStep、Question、またはAnswerを出力しないでください。通知に構造化データとして独立して該当するコンテンツが含まれている場合、包含する投稿タイプのスキーマルールがマッピングを決定します。この要素自体は何も追加しません。

ペアがメインの説明に属する場合はラベル付きのsectionを、両方の通知が補足的な場合はラベル付きのasideを使用してください。各子は、正しいドキュメントレベルに実際の見出しを持つasideまたはsectionにすることができます。ARIAのalertまたはalertdialogを使用しないでください。これらのロールは動的で時間依存の変更を通知するものであり、静的な編集用ガイダンスには不適切です。

アクセシブルな名前は、ネイティブの見出し構造またはaria-labelledbyを通じて可視の共通見出しから取得されます。各通知ラベルはテキストである必要があります。色、境界線スタイル、位置、およびアイコンはトーンを補強できますが、トーンを定義することはできません。アイコンが装飾的な場合は、支援技術から非表示にしてください。ラベルに存在しない情報をアイコンが伝えている場合は、代替テキストに頼ってデザインを修正するのではなく、ラベルを書き直してください。

DOMの順序が意味を制御します。スクリーンリーダーとモバイルレイアウトは、最初の通知の後に2番目の通知に遭遇する必要があります。CSSで視覚的な順序を逆転させないでください。200%のテキストズームと狭い幅では、通知はクリッピングや水平ページスクロールなしでスタックする必要があります。リンクには説明的なラベルが必要であり、複数のリンクをラベルのないアイコンの行に圧縮してはいけません。

書き方ルール

通知を書く前に関係性を記述してください：「正しいガイダンスが___によって変わるため、読者は2つのメッセージを必要としています。」空欄を具体的な条件、状態、対象者、時間、または行動の対比で埋められない場合は、散文を使用してください。

• 1つの共通タイトルの下に正確に2つの通知を使用してください。
• タイトルは3〜12語、各ラベルは2〜6語に抑えてください。
• 本文は1つあたり25〜80語を目指し、120語を絶対最大値としてください。
• 通知ごとに1〜2つの短い段落と、最大1つの短いインラインリンクを使用してください。
• 事実または条件を最初に、その結果を2番目に、アクションを最後に配置してください（すべて存在する場合）。
• 並列的なラベル文法を使用してください：「起動前／起動後」であって、「起動前／管理者が後で行うべきこと」ではありません。
• 条件を直接名付けてください。「左」、「右」、「もう一方の選択肢」、または「上記のボックス」は絶対に書かないでください。
• トーンを証拠に合わせてください。中立的なペアの事実に緑と赤の処理を継承させないでください。
• 変化する主張には、該当する日付、バージョン、計画、管轄、または出典を付けてください。

同等の重みとは、両方のメッセージが読者のフローの中で同じ瞬間に値することを意味します。同一の文数や文字数を要求するものではありません。短い真実を長い方に合わせるためにパディングしないでください。一方の本文がもう一方よりもおおよそ2対1以上超えている場合は、大きい方の通知に別のセクションが必要かどうか、または小さい方の通知が偽のカウンターパートでないかをテストしてください。

複数ステップの手順、表、フォーム、料金カード、推薦の言葉、プロモーションのコールトゥアクション、長い引用、コードサンプル、動画、またはネストされたコンポーネントを通知内に決して配置しないでください。法律、医療、財務、プライバシー、セキュリティ、または破壊的なアクションのガイダンスを和らげるためにペアを使用しないでください。コンテンツ所有者が3つ目の状態が存在しないことを確認していない限り、2つの条件が網羅的であると暗示しないでください。

使用する投稿タイプ

postTypesフロントマター配列がこのテーブルのソースです。掲載されていることは、その要素が正当な2通知ケースで利用可能であることを意味し、そのタイプのすべてのページで必須であることを意味しません。

QAチェックリスト

• 共通主題： 1つの正確なタイトルが、範囲を拡大することなく両方の通知を統括しています。
• 正確に2つの通知： ソースに2つの完全なレコードが含まれ、暗黙の3つ目の状態はありません。
• 実際の関係性： ラベルが意味のある対比、条件、対象者、ステータス、または時間的境界を名付けています。
• 独立した意味： 各通知は共通タイトルとともに抽出された場合も明確です。
• 偽の対称性がない： 両方のメッセージが同等の強調に値し、どちらも埋め草や格下げされた重大な警告ではありません。
• 正しい配置： ペアはそのコンテキストの後に続き、該当するアクションまたは詳細の前に配置されています。
• 安全な隣接： 別の分割レイアウト、表、タブコントロール、または2カラムCTAに隣接していません。
• 有用なラベル： ラベルは並列的な文法を使用し、左右の位置や色に依存していません。
• 長さの制御： 本文は1〜2段落以内で、それぞれ120語を超えていません。
• コンテンツの制約： ネストされた手順、表、フォーム、メディア、プロモーション、または複雑なコンポーネントが内部にありません。
• レスポンシブな順序： モバイル、キーボード、スクリーンリーダー、コピーされたテキストの順序が作成者のシーケンスと一致しています。
• アクセシブルなセマンティクス： 可視の見出しが親をラベル付けし、子ラベルは見出しであり、静的コンテンツはアラートロールを使用していません。
• トーンの整合性： スタイリングは実際の意味を反映し、中立的な事実を良い／悪い判断に変換していません。
• 表記のパリティ： Markdown、Hugo、WordPressが同じタイトル、ラベル、本文、属性、および順序を保持しています。
• スキーマの制約： 要素はサポートされていない構造化データを作成していません。

共通主題、実際の関係性、または偽の対称性のチェックに失敗した場合は要素を拒否してください。これらはレンダラーが修正できない編集上の欠陥です。表示を調整する前に、コンテンツを散文、別のセクション、スタンドアロンの警告、または別の目的に適合した要素として書き直してください。

FAQ

フロントマターの構造化FAQは、最も誤解されやすい実装上の決定事項をカバーしています：通知は正反対である必要も同一の長さである必要もなく、モバイルの順序はソース順に従い、深刻なリスクはスタンドアロンの警告として残り、要素は独自のスキーママークアップを作成しません。