レスポンシブなテーブルをデザインする方法

レスポンシブなテーブルの設計とは、利用できる幅が変わっても、表が持つ有用な関係を保つことです。すべての列を収めるのは、方法の一つにすぎません。比べたい値を離してしまう整ったカードの縦積みより、読みやすいスクロール式の表のほうが、比較を助けることがあります。

タスクから始めましょう。複数のレコードを比べたいのか、一つを探したいのか、詳細を読みたいのか、まとめて操作したいのか。この答えで、一緒に残す情報と、操作の後ろに移せる情報が決まります。これがないと、小さな文字、隠す列、窮屈なボタンを増やすだけになりがちです。

具体例には、プロジェクト名、担当者、ステータス、期限、未解決コメント数を持つ、架空のレビュー待ち一覧を使います。

残す必要のある関係を見つける

表では位置が意味を持ちます。一列を縦に追って値を比較でき、一行を横に読んでレコードと属性を結びつけられます。レスポンシブの変更で、一方の関係を保ちながら、もう一方を弱めてしまうことがあります。

レビューの例では、マネージャーは未解決のコメントがある中で、最も期限の早いプロジェクトを探すかもしれません。プロジェクトの識別情報とともに、期限とコメント数が一緒に見える必要があります。たまたま最後の列だからとコメント数を隠すと、すっきり見えても、そのタスクができなくなります。

自分の担当プロジェクトを開くレビュー担当には、別のニーズがあります。名前、ステータス、明確な操作が重要で、ほかの詳細は後から見られればよいかもしれません。短い要約と展開表示でも機能するでしょう。データが同じでも、必要な最初の表示は違います。

各タスクに必要な情報を記します。すべてのタスクで使う列は、基本の表示に残します。項目を選んだ後だけに使う情報は、展開して見せる候補です。これは作業についての情報設計上の判断で、重要度の低いデータを削除する指示ではありません。

テーブルの幅とページの幅を分ける

広いテーブルのために、ページ全体を横スクロールさせる必要はありません。CSSではoverflow-x: autoのラッパーで、表だけをスクロール領域にできます。見出し、説明、フィルター、周辺の文章は画面幅に収めます。ラッパー自身もページ内で縮められる必要があります。固定的なグリッド列の中では、幅いっぱいの子要素がページ全体を押し広げることもあります。二次元の領域を、必要な内容の中に限定するためです。

W3Cのリフロー達成基準の解説では、データテーブルを含め、意味や利用に二次元が必要な内容には例外を認めています。また、表と、セル内で適切に折り返す必要がある内容を区別しています。この例外は、すべてのラベルや周囲の段落まではみ出させてよい理由ではありません。W3Cのリフローの解説。

実際には、長いプロジェクト名を妥当なセル幅で折り返します。デスクトップで使っていたというだけで、巨大な空白の幅を残す必要はありません。列の関係のために横移動が必要でも、セルの寸法を考える価値はあります。

コンテナには認識できる境界が必要です。見える最後の列が画面端ぴったりで終わり、先の内容が分からなければ、これで全部だと思われるかもしれません。次の列を一部見せる、環境が対応するならスクロールバーを見せる、短い案内を付ける、といった方法で続きが分かります。装飾的なフェードだけに頼らないでください。

可能なら、表のタイトルとタスクの文脈はスクロール領域の外に置きます。「レビュー待ちのプロジェクト」なら、レコードの共通点が分かります。最初の並び順や必要なタイムゾーンも、短い注記で説明できます。これは場所を理解する助けで、場所を奪い合う追加列ではありません。

USWDSで見る、本質的に異なる二つのパターン

U.S. Web Design Systemのテーブルには、スクロール型と縦積み型があります。前者は表の行列を保ち、後者は狭い幅で一件ごとの値にラベルを付けます。動く公式の例で違いを見られます。

部品の名前より、この違いのほうが重要です。行列では、位置から二つの列の関係を読み取れます。縦積みのレコードでは、ラベルを繰り返し、一件を独立して読めます。同じデータでも、比較のための作業は大きく変わります。

レビュー一覧で、コメントが5件を超えるプロジェクトのうち、最も遅い期限を探してみます。表なら、件数と日付を一緒に追えます。カードでは、一件ずつ読み、前の候補を覚える必要があるかもしれません。今度は「Cedar Lodgeの担当者と期限を読む」に変えます。比較が中心でなくなれば、縦積みのほうが快適かもしれません。

読む人の負担から、変換方法を選ぶ

実装への引き継ぎでは、不変の条件をいくつか示します。行の識別子が分かること、値に単位が付くこと、並べ替えの対象が理解できること、サイズ変更後も選択の範囲が同じことです。デスクトップの全列をスマートフォンに収める、という指定より長く役立ちます。実装者は、タスクを黙って変えずに表示を工夫できます。

パターンが苦手とする端も試します。長い行ラベルで右端までスクロールします。長さの異なる隣のレコードを展開します。一件選んで画面幅を変え、同じ操作を続けます。整った初期画面では、古い選択件数、値を覆う固定列、別のレコードに付いた詳細パネルは見つかりません。

四つのパターンとトレードオフ

1. 表を維持して横にスクロールする

整列した値の比較が主な作業で、すべての列に意味があるなら、横スクロールは有力です。別の情報構造に変えず、行列を保てます。ただし幅方向の移動は必要なので、意図して設計します。

レビュー表では、プロジェクト名を先頭近くに置き、確実に固定できる実装なら、列を見えるままにします。そうしないと、期限へスクロールしたとき、どの行を読んでいるか見失うかもしれません。固定する名前の列は、残りのデータに有用な幅を残す必要があります。

表の半分を固定してはいけません。 狭い画面で二、三列を固定すると、ほとんどの幅を使い切り、動く内容はわずかになります。文脈を保つ最小限の識別情報から始めます。名前が長いなら、巨大な領域を固定せず、折り返しや補助的な識別子を慎重に使います。

固定領域が交差する部分は、丁寧な見た目の処理が必要です。左上のセルは、固定した見出し行と先頭列の両方より上に来ることがあります。重なりの順序と不透明な背景がなければ、値が透けたり重なったりします。静止画ではよく見えて、スクロールすると失敗する細部の例です。

タッチ操作以外も確かめます。必要ならキーボードで領域に到達し、操作でき、内部の操作要素のフォーカスも見える必要があります。対象のブラウザーと支援技術で実装を確認します。モックアップに輪郭線を足すだけでは、キーボード利用を証明できません。

2. 優先する列を見せ、残りを展開する

日常の判断の大半が少数のフィールドで済むなら、その列を残し、追加データを確かめる方法を用意できます。優先順位が正しければ、主なタスクを犠牲にせず幅を減らせます。

レビュー担当には、名前、ステータス、期限が有用な短い表示かもしれません。担当者とコメント数は行の展開に入れられます。ただし、未解決コメントがある期限超過作業を探すマネージャーには、件数を隠すのは不適切です。タスクとは無関係に決まる、万能の「モバイル用の列」はありません。

展開中と分かる操作要素を使います。とくに似た行が隣り合う場合、展開した内容がどのレコードのものか見える必要があります。パネルの位置で関係が曖昧になるなら、中にも名前を繰り返します。詳細、メニュー、新しいページのどれが開くか分からないラベルは避けます。

ほぼすべてのレコードで使う操作を、展開の後ろに置かないでください。 レビュー待ち一覧なら、レビューを開く操作は常に見せる価値があるかもしれません。めったに使わないメタデータと一緒に埋めると、幅を節約する代わりに作業を繰り返させます。場所を取るフィールドだけでなく、頻繁に使う操作を評価します。

省いた列も明確にします。デスクトップで担当者を見ていた人には、狭い画面でも理解できる到達方法が必要です。アクセス可能な詳細表示、列の選択、展開した要約などが使えます。黙って削除すると、利用できる情報が変わってしまいます。

3. 各レコードを、ラベル付きのカードにする

一件ずつ読むなら、縦積みのレコードが役立ちます。値ごとに目に見えるラベルを付け、行を小さな縦の要約にします。レコード間の比較が補助的な、注文詳細や予定の一覧などに向いています。

架空のプロジェクトなら、Cedar Lodgeを見出しにし、その下にステータス、期限、担当者、未解決コメントを置けます。一件としては読みやすいでしょう。ただし十件のコメント数を比べるなら、ずっと長いページで同じラベルを繰り返し探す必要があります。

選ぶ前に、複数のレコードの一つの属性を比べてもらいます。値を覚えるために往復スクロールするなら、横移動を、もっと大きな縦方向の記憶の負担と交換しています。それでも許容できる場合はありますが、意識した選択であるべきです。

カード間でラベルと値の順序を揃えます。値がないからといって、一枚では上にあるステータスを、別では担当者の後に移してはいけません。欠けている状態を意味のある言葉で示し、構造を予測できるままにします。

アクセシビリティの結果を確認せず、ラベルを装飾的な生成コンテンツだけで入れないようにします。見える「期限」というラベルと、プログラムから分かる関係は別です。完成したマークアップは、カードの見た目を見ていない人にも、一貫したデータを伝える必要があります。

デスクトップが意味構造を持つテーブルで、狭い画面では見た目を変えるなら、関係が意図どおり利用できるかを確認します。別々の表示をページ内に持つなら、隠した内容が操作の重複や繰り返しの読み上げを生まないようにします。変換には、スタイルだけでなく実装レビューも必要です。

4. 比べる内容を選べるようにする

多くの列に正当な理由があっても、すべてを一度に必要とすることは少ない場合があります。列の選択で、役立つ表示を作れるようにできます。専用の比較モードで少数のレコードを選び、関連属性を一緒に確認する方法もあります。

こうした操作自体にも手間があります。新しい人には重要な列が分からず、初期表示がすべてだと思うかもしれません。適切な初期表示を用意し、隠れた列があることを明確にします。カスタマイズは習熟を助けるためで、基本の理解に設定作業を必須にするためではありません。

レビュー表なら、初期表示はプロジェクト、ステータス、期限、コメントかもしれません。調整役は担当者を足し、個人の担当者は外せます。切り離された数字だけの行にならないよう、プロジェクトの識別情報は残します。

比較モードは、長い作業一覧を処理するより、少数の候補から選ぶのに向いています。商品を三つ選ぶのは妥当かもしれませんが、期限超過を知るために全プロジェクトを選ぶのは遠回りです。表が広いというだけで比較の操作を足さないようにします。

表示を保存できるなら、何を保存するかを決めます。列の表示、順序、並べ替え、フィルターは別の設定です。保存した列の配置が、意外にも古いフィルターを保持して新しいレコードを隠してはいけません。見た目のプロトタイプでは、保存ボタンを描いただけで保存機能があるように見せず、要件として記します。

ラベル、数字、空のセルの意味を保つ

レスポンシブへの変更は、内容の弱いルールを露わにします。「04/05」は広い画面でも曖昧ですが、周囲の説明の場所がなくなると、問題が目立ちます。対象者に合う形式を使い、タスクに影響するならタイムゾーンや相対日付の文脈も示します。

数値列の単位を揃えます。見出しと書式で違いを説明しない限り、コメント数と文字のステータスを同じ欄に混ぜるべきではありません。比較する数字の整列を揃え、違いを読み取りやすくします。意味が変わらないか考えず、狭い画面でだけ数値の精度を落としたり、単位を省いたりしないでください。

空のデータの表し方を決めます。「未割り当て」「コメントなし」「利用不可」は別の状態です。空欄では区別できません。レビューの例で、未割り当ての担当者が、読み込みに失敗した欄と同じに見えてはいけません。

意味を保てるなら、長いラベルは折り返します。ツールチップは補足には使えますが、繰り返し見つける必要がある必須ラベルの代わりとしては弱いものです。どこでも長すぎる列名なら、すぐ省略する前に、言葉を正確に短くできないか考えます。

W3Cのテーブルのチュートリアルは、見出しとデータのセルに構造的なマークアップと適切な関連付けが必要だと説明しています。見た目の整列以外でも、文脈を保って移動する助けになります。とくに行と列の見出しの両方が意味を持つ場合、選んだパターンの実装に使います。W3Cのアクセシブルなテーブルのチュートリアル。

操作と、その対象範囲を結びつける

並べ替えはコレクション、詳細を開くのは一件、一括操作は選択中のレコードが対象です。狭くなっても、この範囲は区別できるべきです。すべてを同じメニューへ押し込むと、何が変わるのか分からなくなります。

行の操作は、見た目でもそのレコードに関連付けます。広い表の右端にあるメニューは、横スクロールで見えなくなるかもしれません。プロジェクトを開くことが主なタスクなら、名前をリンクにして安定した経路を残し、メニューには頻度の低い操作を入れられます。すぐ使う必要がある操作で、最適な配置は変わります。

選択には、とくに注意が必要です。固定の先頭列のチェックボックスは便利でも、行の識別情報を追い出すべきではありません。複数を選んだら件数を見せ、現在のページか、絞り込み結果全体かを明確にします。狭い表示で、その意味を黙って変えてはいけません。

並べ替えの操作は、小さな矢印だけに頼らず現在の方向を説明します。列を隠す場合も、並べ替えの対象が分かるかを確かめます。見えない見出しに付けたままにするより、表の上にラベル付きの選択肢を移したほうが明確な場合もあります。

フィルターとページ送りも狭い幅で確認します。表が読めても、ツールバーが画面をはみ出したり、ページ送りが窮屈になったりすることがあります。格子の外にあっても、同じタスクの一部です。レコードを探して操作するまで、一連の道筋を試します。

扱いにくい内容と、実際のタスクで確認する

長いプロジェクト名、未割り当ての担当者、大きなコメント数、欠けた日付、折り返すステータスなど、レイアウトに厳しい内容を使います。パターンが支える方向への移動が必要になるだけの行数も用意します。均一な三件だけでは、ほとんど分かりません。

スクロール型なら、横へ移動した後、遅い期限とその名前を結びつけてもらいます。展開型なら、詳細を見つけ、次のレコードへ戻ってもらいます。カードの縦積みなら、複数のプロジェクトの一つの値を比較してもらいます。保たれた関係が、実際に必要な関係かを明らかにするタスクです。

狭い端末幅だけでなく、ブラウザーのズームも試します。拡大するデスクトップ利用者は、別の理由で同じ制約に出会います。文字が読め、操作に到達でき、固定部分が使える領域の大半を覆わないことを確かめます。

OpenDesignでは、HTMLの表を異なるビューポートのプリセットで見て、詰まった領域にコメントし、文言やスタイルを整えられます。サンプルのレコードと選んだタスクを、デザインの文脈に残します。意味構造のあるマークアップ、キーボードのスクロール、並べ替え、保存状態は、実装した表で試しましょう。