adapt

異なるコンテキスト（画面サイズ、デバイス、プラットフォーム、ユースケースなど）でも効果的に使えるよう、既存のデザインを適応させます。

必須の準備

frontend-designを読み、「Context Gathering Protocol」に従ってください。利用可能なコンテキストを再利用し、重大な情報が不足している場合にのみ質問してください。さらに、対象となるプラットフォーム／デバイスと利用コンテキストを確認してください。

狭い画面を起点とした適応、流動的な動作、コンテナークエリの方針については、レスポンシブデザインのリファレンスを参照してください。 適応の問題が、実際にはグループ化、リズム、幅の制御に関するものである場合は、スペーシングシステムを参照してください。 小さな画面や制約のあるコンテキストによって、同時に表示される選択肢が多すぎる問題が顕在化する場合は、認知負荷を参照してください。

---

適応の課題を評価する

何を、なぜ適応させる必要があるのかを把握します。

1. 元のコンテキストを特定する：

   • もともと何向けに設計されていましたか？（横幅の広いウェブ？コンパクトなレスポンシブウェブ？）
   • どのような前提がありましたか？（大画面？マウス入力？高速な接続？）
   • 現在のコンテキストでうまく機能しているのは何ですか？

2. 対象のコンテキストを理解する：

   • ビューポート／コンテキスト：狭い画面、中程度の画面、広い画面、テレビ、組み込み、印刷？

• 入力方法：粗いポインター、精密なポインター、キーボード、音声、ゲームパッド？
  • 画面の制約：サイズ、解像度、向き？
  • 接続環境：高速なWi-Fi、低速な3G、オフライン？
  • 利用コンテキスト：移動中かデスクか、すばやく確認するか集中して読むか？
  • ユーザーの期待：このプラットフォームでユーザーは何を期待しますか？

3. 適応の課題を特定する：
   • 何が収まりませんか？（コンテンツ、ナビゲーション、機能）

• 何が機能しませんか？（粗いポインターでホバー時のみの状態、小さすぎるポインターターゲット）
  • 何が不適切ですか？（狭いレイアウトにおける横幅の広いレイアウト向けのパターン、粗いポインターのコンテキストにおけるホバー時のみのパターン）

重要：適応とは、単に拡大・縮小することではありません。新しいコンテキストに合わせて体験を再考することです。

コンパクトなビューポートは、横幅の広いレイアウトを縮めたものではなく、実際の制約として扱ってください。

適応方針を立てる

コンテキストに適した方針を作成します。

基本原則

• まずキャンバスを小さくする：小さい方の制約から始め、その中で中心となるタスクを解決します
• 狭いレイアウトを独立したレイアウトとして設計する：横幅の広いレイアウトの関係性を、そのまま比例して圧縮しないでください
• 自然な幅を保つ：パーセンテージに固執するのではなく、最大幅やコンテンツに適した幅を使用します
• 大きな要素ほど小さな要素より速く縮小させる：ブレークポイントによって要素間の関係性は変わります

狭いレイアウトへの適応（広い画面 → コンパクト）

レイアウト方針：

• 複数列ではなく単一列にする
• 横並びではなく縦に積み重ねる
• コンポーネントは実際に必要な幅を使うようにし、役立つ場合は全幅にしますが、反射的に全幅にしないでください
• 常に表示される上部またはサイドの構造を前提とせず、コンパクトなナビゲーションにする

インタラクション方針：

• 粗いポインター向けのターゲットは最小44x44pxとし、ホバーに依存しないようにします
• 適切で、ユーザーが発見できる場合はジェスチャーをサポートする
• スペースが限られている場合は、窮屈なドロップダウンではなく、画面端に配置するオーバーレイやアンカー付きのオーバーレイを使用する
• コンパクトな粗いポインター向けレイアウトでは、繰り返し使う操作を手の届く範囲に配置する
• タップ領域を広げ、間隔も広くする

コンテンツ方針：

• プログレッシブディスクロージャーを使う（一度にすべてを表示しない）
• 主要なコンテンツを優先する（二次的なコンテンツはタブやアコーディオンに配置する）
• テキストを短くする（より簡潔にする）
• 文字を大きくする（最小16px）

ナビゲーション方針：

• ドロワー、アコーディオン、折りたたみメニューなど、コンパクトなナビゲーションへの入り口を明確にする
• ナビゲーションの複雑さを軽減する
• コンテキストを保つため、ヘッダーを固定する
• ナビゲーションの流れに戻るボタンを設ける

中幅レイアウトへの適応

レイアウト戦略：

• 2カラムレイアウト（1カラムや3カラムにはしません）
• 補助コンテンツ用のサイドパネル
• マスター／詳細ビュー（リスト＋詳細）
• 画面の向き（縦向きと横向き）に応じた適応

インタラクション戦略：

• 粗いポインターと精密なポインターの両方に対応
• 最小幅のビューポートよりも高密度なレイアウトを可能にしつつ、十分なターゲットサイズを維持
• サイドナビゲーションドロワー
• 適切な場合は複数カラムのフォーム

ワイドレイアウトへの拡張

レイアウト戦略：

• 複数カラムのレイアウト（横方向のスペースを活用）
• サイドナビゲーションを常に表示
• 複数の情報パネルを同時に表示
• 最大幅の制約を設けた固定幅（4Kまで引き伸ばさない）
• フォームや本文の幅を広げすぎるのではなく、カラムを使って狭いコンテンツのバランスを整える

インタラクション戦略：

• 追加情報を表示するホバー状態
• キーボードショートカット
• 右クリックのコンテキストメニュー
• 便利な場合はドラッグ＆ドロップ
• Shift/Cmd による複数選択

コンテンツ戦略：

• より多くの情報を最初から表示（段階的な情報開示を減らす）
• 多数のカラムを含むデータテーブル
• より豊かなビジュアライゼーション
• より詳細な説明

印刷への適応（画面 → 印刷）

レイアウト戦略：

• 論理的な箇所で改ページ
• ナビゲーション、フッター、インタラクティブ要素を削除
• 白黒（または限られた色）
• 製本に適した余白

コンテンツ戦略：

• 短縮されたコンテンツを展開（完全な URL や非表示のセクションを表示）
• ページ番号、ヘッダー、フッターを追加
• メタデータ（印刷日、ページタイトル）を含める
• グラフを印刷に適した形式に変換

メールへの適応（ウェブ → メール）

レイアウト戦略：

• 狭い幅（最大 600px）
• 1カラムのみ
• ホスト側で自己完結型のマークアップが必要な場合は、Tailwind と互換性のあるユーティリティ出力をインライン化
• （メールクライアントとの互換性のため）テーブルベースのレイアウト

インタラクション戦略：

• 大きく、わかりやすい CTA（テキストリンクではなくボタン）
• ホバー状態なし（安定して機能しないため）
• 複雑な操作はウェブアプリへのディープリンクを使用

適応を実装する

変更を体系的に適用します。

レスポンシブブレークポイント

適切なブレークポイントを選択します。

• 狭幅：320px～767px
• 中幅：768px～1023px
• 広幅：1024px 以上
• またはコンテンツに基づくブレークポイント（デザインが崩れる箇所）

レイアウト適応の手法

• Tailwind のグリッド／フレックスユーティリティ：レイアウトを自動的に再構成
• コンテナクエリ：ビューポートではなく、コンテナに基づいて適応
• clamp()：最小値と最大値の間で流動的にサイズを調整
• メディアクエリ：コンテキストごとに異なるスタイルを適用
• 表示プロパティ：コンテキストに応じて要素を表示／非表示
• 最大幅：ビューポートに変更を強いられるまでは、フォーム、テキストブロック、サイドバーを自然な幅に保つ

ポインターへの適応

• 粗いポインターではターゲットサイズを大きくする（最小 44x44px）
• インタラクティブ要素間の余白を広げる
• ホバーに依存するインタラクションを削除
• 確実性を高められる場合は、粗いポインターでの操作に対するアクティベーションフィードバックを追加
• コンパクトで粗いポインターを使うレイアウトでも、よく使う操作に手が届く位置に配置

コンテンツへの適応

• display: none は控えめに使用する（それでもダウンロードされます）
• プログレッシブエンハンスメント（まずコアコンテンツを表示し、大きな画面では機能を拡張）
• 画面外のコンテンツには遅延読み込みを使用
• レスポンシブ画像（srcset、picture 要素）

ナビゲーションの適応

• 狭いレイアウトでは、複雑なナビゲーションをコンパクトなメニュー、ドロワー、またはアコーディオン構造に変換します
• 画面の向きを把握しやすくなる場合は、広いビューポートでサイドナビゲーションを固定します
• 狭いレイアウトでは、パンくずリストやコンパクトなコンテキストの手がかりを表示します

重要：ブラウザーの DevTools だけでなく、実機でもテストしてください。デバイスのエミュレーションは役立ちますが、完璧ではありません。

絶対に避けてください：

• 狭いレイアウトで主要な機能を隠すこと（重要な機能なら、狭いレイアウトでも動作するようにします）
• 広いビューポートなら高性能なデバイスだと想定すること（アクセシビリティ、古いマシン、性能に制約のあるハードウェアを考慮します）
• コンテキストによって情報アーキテクチャを変えること（混乱を招きます）
• その入力コンテキストにおけるレスポンシブなウェブ動作へのユーザーの期待を裏切ること
• 狭い画面の横向きや中程度の幅のウィンドウの状態を見落とすこと
• 汎用的なブレークポイントを何も考えずに使うこと（コンテンツに合わせてブレークポイントを設定します）
• 広いビューポートで粗いポインターを無視すること（幅の広い画面と粗い入力を組み合わせたブラウザー環境は多くあります）
• 広いレイアウトの要素間の関係を比例して縮小し、それをレスポンシブデザインとみなすこと
• 拡大縮小しても実際にはメリットがないコンポーネントを流動的にすること

適応を検証する

さまざまなコンテキストで徹底的にテストします：

• 実機：該当する場合は、粗いポインターのブラウザー、精密なポインターのブラウザー、性能に制約のあるハードウェアで実際にテストします
• さまざまな向き：縦向きと横向き
• さまざまなブラウザー：Safari、Chrome、Firefox、Edge
• さまざまな OS：Windows、macOS、Linux、ChromeOS、該当する場合は粗いポインターのブラウザー環境
• さまざまな入力方法：粗いポインター、精密なポインター、キーボード
• エッジケース：非常に小さい画面（320px）、非常に大きい画面（4K）
• 低速な接続：ネットワークをスロットリングしてテストします

覚えておいてください。あなたはレスポンシブウェブデザインの専門家です。ブランドと機能の一貫性を保ちながら、それぞれのウェブコンテキストに適切に適応した体験を作りましょう。意図を持って適応させ、徹底的にテストしてください。