データテーブルUIシステム
目的
データテーブルUIシステムスキルは、構造化された多属性データを整理・提示するための方法論を提供します。大きなデータセットをスキャン、比較、操作しやすくするために、テーブル形式内の配置、間隔、階層、およびインタラクティブ要素に関する明確なルールを確立します。
使用例
- SaaSダッシュボードでの在庫管理、ユーザー管理、請求の設計
- ECサイトやマーケティングサイト向けの商品比較表の作成
- 技術アプリケーション向けのログビューアや監査証跡の実装
- 構造化ビューでの財務データやパフォーマンス指標の整理
- 「データテーブル」または「データグリッド」のコンポーネントライブラリ標準の確立
使用すべきでないケース
- シンプルなキー/バリューペア: 2列しかない場合（ラベル：値など）は、説明リスト（
<dl>）またはシンプルなリストを使用してください。 - ナラティブコンテンツ: 長文テキストやストーリーは、標準のタイポグラフィやセクション構造を使用し、テーブルは使用しないでください。
- レイアウトグリッド: ページレイアウトには
responsive-grid-systemを使用し、テーブルは厳密にデータ用です。 - 低データカード: データが視覚的で属性が少ない場合は、
card-ui-systemを使用してエンゲージメントを高めてください。
入力
- データスキーマ: 表示するデータの種類（文字列、数値、日付、ブール値、アクション）
- 列の優先順位: 識別に必須の属性と、二次的な詳細の属性
- ユーザータスク: ユーザーは特定の行を見つける必要があるのか、行間で値を比較するのか、一括操作を行うのか
- ボリュームの見込み: 典型的なビューで想定される行数と列数
出力
- テーブル構造仕様: 定義された領域（ヘッダー、行、セル、フッター）とその内部スペーシング
- 配置マトリックス: データ型に基づく水平配置のルール
- 密度バリアント: コンパクト、標準、ゆったりとした行の高さの定義
- インタラクションマップ: ソート、フィルタリング、行選択、インラインアクションの動作
ワークフロー
1. 列タイプと配置の定義
「配置の経験則」を適用してスキャン容易性を確保します:
- テキスト/デフォルト: 左揃え（単語の先頭を目で追いやすくするため）
- 数値/指標: 右揃え（小数点を揃え、大きさの比較を素早く行えるようにするため）
- 日付/ステータスラベル: 中央揃えまたは左揃え（列幅に応じて）
- アクション: 右揃え（通常は最後の列）
2. 視覚的階層の確立（ヘッダー）
テーブルヘッダーはデータと明確に区別できる必要があります:
- スタイル:
<th>要素に異なる背景色、太字、または大文字表記を使用します。 - 固定化: 長いテーブルでは、スクロール中にユーザーがコンテキストを失わないように、スティッキーヘッダーを使用します。
3. 行密度とリズムの設定
ユースケースに基づいて密度レベルを選択します:
- コンパクト: 高いデータ密度（例：32px 高さ）。パワーユーザーやダッシュボードに最適です。
- 標準: バランス型（例：48px 高さ）。一般的なユーティリティに最適です。
- ゆったり: 低密度（例：64px 高さ）。マーケティングやシンプルなリストに最適です。 行を区切り、「行の読み飛ばし」を減らすために、ゼブラストライピングまたは微妙なボーダーを使用します。
4. インタラクティブデータの設計
ユーザーがデータをどのように操作するかを定義します:
- ソート: ソートをサポートするヘッダーにインジケーター（シェブロン）を追加します。
- 行の状態: 行のホバー状態、選択状態、フォーカス状態を定義します。
- 一括操作: 必要に応じて、左端にチェックボックス列を追加します。
5. コンテンツのばらつきへの対応
データ長のエッジケースを処理します:
- 切り詰め: 識別に重要でない長いテキストには省略記号（...）を使用します。
- 折り返し: 重要な説明テキストには折り返しを許可します。
- 固定幅: 安定した列（ステータス、日付など）には固定幅を、主要な識別子（名前など）には流動幅を割り当てます。
決定ルール
- スキャン容易性ルール: 最初の列は常に最も重要な識別子（名前、IDなど）とし、行のアンカーとして機能させます。
- 数値の配置: 値の比較が主要なタスクである場合、数値に等幅フォントを使用して桁を完全に揃えます。
- ゼブラストライピング vs ボーダー: 非常に広いテーブルでは、横方向の目の追跡を助けるためにゼブラストライピングを使用します。短くシンプルなテーブルではボーダーを使用します。
- アクションの配置: アクションは最後の列にまとめるか、表示可能な「その他」メニューを使用してインターフェースをクリーンに保ちます。
- 空のセル: セルを空白のままにしないでください。ダッシュ（—）または「N/A」を使用して、データが単なる読み込みエラーではなく欠落していることを確認します。
制約
- アクセシビリティ: セマンティックな
<table>タグを使用する必要があります。ヘッダーにはscope="col"が必要です。コンテキストのためにキャプションを使用する必要があります。スティッキーヘッダーは、下にスクロールされたセルや行アクションのフォーカスインジケーターを隠してはいけません（WCAG 2.2 SC 2.4.11）。インラインのアクションボタン/リンクは、24x24px の最小ターゲットサイズを満たす必要があります（SC 2.5.8）。 - レスポンシブ対応: ビューポートが縮小した場合、
responsive-data-tablesのパターン（スクロール、スタック、トグル）に従う必要があります。 - コントラスト: ヘッダーテキストとステータスインジケーターは、WCAG AA（4.5:1）を満たす必要があります。
一般的な失敗パターン
- 数値の配置ミス: 数値を左揃えにすると、一瞥して大きさを比較することが不可能になります。
- 「テキストの壁」: ゼブラストライピングや明確なヘッダー区別なしに高密度行を使用し、「目の疲れ」を引き起こします。
- 見えないヘッダー: ヘッダーがデータとあまりにも似ているため、列が何を表しているかを把握するのが難しくなります。
- アクションのアフォーダンス欠如: セル内のボタンやリンクが小さすぎてタップできない、またはインタラクティブに見えません。
- 空の状態の欠如: 「結果が見つかりません」というメッセージなしに空白のテーブルを表示します。
検証基準
- 列の配置がデータ型ルールに従っていること（テキスト=左揃え、数値=右揃え）
- テーブルヘッダーが行データと視覚的に区別されていること
- 主要な識別子が最初の列にアンカーされていること
- 構造にセマンティックHTML（
<table>、<th>、scope）が使用されていること - 空のセルが空白ではなくプレースホルダー（例：—）を使用していること
- インタラクティブ状態（ホバー/選択）が明確に定義されていること
- 長いコンテンツを適切に処理する設計であること（切り詰めまたは折り返し）
- スティッキーヘッダーが行やセルアクションのフォーカスインジケーターを隠さないこと（WCAG 2.2 SC 2.4.11）
- 行アクションが24x24pxの最小ターゲットサイズを満たしていること（WCAG 2.2 SC 2.5.8）