情報アーキテクチャ

ページがどんな形を取るか。色や余白を決めるより前に決めることです。

このセクションの他のページは部品についての問いに答えます。本ページが答えるのは、その前に来る問いです。画面が抱える情報がこれだけある中で、読み手は何をしに来たのか、どんな配置ならそれができるのか。

こんなとき：複数のオブジェクト、複数の状態、そしてその関係を同時に載せる画面を作り始めるとき。コンソール、ダッシュボード、管理画面、ワークベンチ、監視ページなど。ランディングページや単一コンバージョンのフォームは対象外です。あれらの成否は説得力で決まり、密度の高い情報の中で読み手が正しく判断できるかどうかでは決まりません。

データが揃っていることと、ページが設計されていることは別です。API が返すフィールドがすべて載り、フィルタもステータスタグも一括操作も揃っていて、それでも読み手は何から見ればよいのか分からない。欠けているのは情報ではなく、順序です。

コンポーネントに触れる前の三つの問い

1. 読み手が開いた瞬間に見るべき一つのことは何か。 それがページの主情報です。
2. それを理解するために、ほかに何が見えている必要があるか。 関連リソース、関連モデル、文脈。
3. 見たあとに何をするのか。 判断するのか、操作するのか、考え続けるのか。

三つともコンポーネント一覧を開く前に答えます。答えが明確なページが形を外すことはめったにありません。飛ばしたページは、結局 API のレスポンスに沿った作りになります。

一ページに主モデルは一つ。 補助モデルは主モデルの理解や操作を助けることはできますが、ファーストビューを奪ってはいけません。

形はタスクで決まり、ペイロードでは決まらない

形を外したページの大半は、この二つの近道から生まれます。

• エンドポイントが配列を返したので、テーブルにした。
• ルートに ID があるので、詳細ページにした。

どちらも理由になりません。同じオブジェクトでも、タスクが違えば形は変わります。検索している間 issue はコレクション、処理している間はステータスフロー、協働している間はディスカッションスレッド、監査している間はイベント列です。レコードに日付フィールドがあるのは、データに日付があるというだけのこと。そのページがカレンダーだという意味ではありません。

表現スケルトンの選び方

主要な問いに、頭の中の変換がいちばん少なくて済む配置を選びます。

取り違えやすい組み合わせ

• タイムラインかステップか。 タイムラインは起きたことを順に語り、ステップはいまどこにいて次に何が来るかを語ります。見た目は似ていて、時間の向きは逆です。
• カンバンかフィルタか。 カードを動かすこと自体が操作であるときだけカンバンが成立します。列が保存済みの絞り込み条件でしかないなら、ドラッグが必要なフィルタを作っただけです。
• カレンダーかタイムラインか。 カレンダーは占有と衝突に答え、タイムラインは順序に答えます。レコードの日付が選んでくれるのではなく、問いが選びます。
• カードグリッドかテーブルか。 画像が認識のアンカーであるか、ないかのどちらかです。数値を比べて選ぶなら、先頭列のサムネイルは判断材料のフィールドを押しのけます。
• グラフか隣接リストか。 経路や伝播そのものが判断材料であるときだけ図を描きます。そうでなければ、上流と下流をまとめたリストのほうが速く読めます。
• ドキュメントかフィールド表か。 順に読む文章は文章のままにします。段落ごとにカードやキーバリュー行へ刻むと、読みやすさそのものが壊れます。

作れるからといって三つのビューを全部作らないこと。ビューが一つ増えるたびに、フィルタ一式、ステータスの対応付け、同期し続けるアクション一式が増えます。二つ目の使い方が実際に高頻度になってから追加します。念のためではなく。

各種情報の置き場所

事実ごとに権威ある置き場所は一つだけ。 他の場所には要約か入口を置き、そこへリンクします。

読む順序

ページの識別
→ 現在の状態または異常
→ 主タスクと主アクション
→ 判断に必要な情報
→ 関連・変更・根拠
→ 二次情報と低頻度のアクション

• 視覚上の主見出しはページに一つ。 節の見出しは意味で進みます。フォントサイズで階層のふりをさせません。
• タスク領域ごとに主アクションは最大一つ。 主ボタンは最も起こりやすい次の一手であって、最も破壊的な一手ではありません。危険な操作には危険のセマンティクスを与え、最も重い視覚的比重は与えません。
• 警告色と危険色は、本当に注意を要する状態のためのものです。全面が緑のページは、すでに信号を使い切っています。
• バッジ、タグ、バナーは一つの注意予算を共有します。判断を変えるものだけを強調します。

情報密度

密度とは単位面積あたりのコントロール数ではなく、読み手が一目で受け取れる判断に使える情報の量です。余白を詰めても上がるのは視覚的な密度だけで、実効密度は動きません。無関係なフィールドを削り、比較を一か所にまとめてはじめて実効密度が上がります。

• 一ページで使うのは隣り合う二段階まで。標準のページにコンパクトな表が入るのは構いませんが、領域ごとに独自の尺度を作るのは駄目です。
• コンパクトは「文字とタップ領域を一緒に縮める」ことではありません。コンテナの余白と行の高さは詰められますが、本文の可読性、見えるフォーカスリング、ポインタターゲットの大きさは詰められません。
• 専門ユーザーには、一度に多く見せるより、列管理・保存ビュー・一括操作・ショートカットのほうが効きます。

タスクの文脈を保つ

スケルトンを決めたら、補助的な内容をどこに置くかを決めます。

モーダルはナビゲーションの一層ではありません。 コピーできるリンク、履歴、並列比較、リロード後も残る作業が要るものには、ルートを与えます。

この層で ranui が提供するもの

ranui はページの形について意図的に態度を持ちません。提供するのはプリミティブとトークンであって、ページのテンプレートではありません。この層で使えるのは次のものです。

• スケルトンが分かれる帯には r-section、本当に独立した繰り返し項目には r-card。カードの中にカードは入れないこと。フォームのフィールドは見出しか区切り線でグループ化します。
• r-tabs は同じオブジェクトの同格ビュー（その議論、そのチェック、その差分）のためのもので、無関係なモジュールのためではありません。それはナビゲーションの仕事です。
• 段階的開示には r-disclosure-row、一時的な文脈には r-popover と r-dropdown、r-modal は上の表が許す用途にだけ。
• ステータスは r-state-dot に必ずラベルを添えて。 色だけで伝えない。
• ファーストビューの読み込み中は r-skeleton、待たせていると感じさせる長さの処理には r-progress、結果は r-message で伝えます。

ranui にテーブル、ツリー、カレンダー、カンバン、タイムラインはありません。自作するときは、第二の視覚体系を立ち上げるのではなく、トークンと デザインガイドラインの上に作ります。余白はスケールから、文字は役割から、色はセマンティックトークンから、到達しうるすべての状態を設計して。

アンチパターン

• エンドポイントが返すフィールドがそのまま詳細の行になり、識別・ステータス・関連・根拠が同じ比重で一度に届く。
• カード、色、装飾的な余白で階層をこしらえるだけで、何から読み、そこから何を判断するのかは何も言っていない。
• 複数のアクションが主ボタンのスタイルを分け合う。あるいは低頻度のアクションがタイトル領域に居座る。
• ステータス、属性、関連、変更が一つの表に混ざり、どこでも比較が組み立てられない。
• 名前とステータスを調べたいだけの読み手に、関係グラフを見せる。
• 長いフロー、比較、あるいは誰かがリンクを送りたくなるものをモーダルに載せる。
• 同じ一文がタイトル、要約、タブ名、表に繰り返し現れ、どこでも新しいことを足していない。

ページを出す前のチェックリスト

• 主情報、関連情報、読み手の次の動作が書き出されている。
• スケルトンはレスポンスの形からではなく、問いから選ばれている。
• ページの主モデルは一つで、補助ビューはそれと競合せず、それに仕える。
• 仕様書を読まずに、対象・状態・主アクションが五秒で分かる。
• 比較は一か所で起き、タブやページをまたいで値を覚える必要がない。
• 事実ごとの権威ある置き場所は一つで、他はそこへリンクしている。
• 密度は利用頻度に見合っており、隣り合う二段階を超えていない。
• 長い文、大きな数値、狭いビューポートが情報の順序を壊さない。
• 判断の助けにならないブロック、フィールド、タグ、ボタンは削除されている。