リストとテーブルのデザイン

Question

特に画面スペースが限られている状況で、テーブルが複数の行にまたがるデータを処理できないことは、情報を表示する代わりにリストビューが使用されている理由の1つです。カード/タイルスタイルの情報表示を使用するフラット/メトロデザインの人気により、リストビューを使用してより複雑なデータを表示することもできました。

テーブルの使用はデータ構造と実装の詳細の観点から明確に定義されていますが、リストビューの仕様はそれほど詳細ではないようです。リストビューの中には、テーブルのように静的なものもあれば、追加情報を表示するようにトリガーできるものもあります。また、一般的にテーブルにはヘッダー行とデータ行がありますが、リストビューの階層レベルはかなり異なる場合があります。

StackOverflowで処理された実装の問題と特定のアクセシビリティの問題以外に、リストまたはテーブルのデザインを選択する際に他の考慮事項はありますか？

それらは論理的に同等のものと見なされますか（視覚処理または認知処理の設定の問題です）、または特定のタイプの情報表示に対応しますか（その場合、どのタイプをいつ使用するかについてより良いガイドラインを提供する必要があります）？

A 関連する質問タイルとリスト/テーブルビューの比較についても、興味深いアイデアがいくつかあります。

Babossa · Answer

1）重要な点の1つは、タイルレイアウトを使用するとアイテムを1つずつ分析しやすくなる（a）一方で、テーブルを使用するとアイテムを比較しやすい（b）ことです。

a） 1つの個別のレイアウトアイテムで1つのコンテンツアイテムのすべてのデータを取得する能力は、過小評価されるべきではありません。 2つのエンティティの類似性により、データに集中して完全に評価することが非常に簡単になります。テーブルでは、隣接する行の侵入フォームが邪魔になり、どの列を見ているのかわからない場合は毎回ヘッダーへの移動に目を向けなければならないという事実により、これはテーブルを不適切な選択にします主なタスクです。

b）
テーブルは、実装されている場合（実際にそうである必要があります）、ユーザーが選択した任意の1つの列（ascまたはdesc）の値で並べ替えることができます。これにより、さまざまな属性からアイテムをランク付けするのが非常に簡単になり、比較シナリオで非常に便利です。これは、タイルまたはリストレイアウトでも、「外部」ソート機能を追加することで、ある程度実現できます。ただし、並べ替え機能ではアイテムが正しい順序で並べられている場合でも、並べ替えた特定の値をスキャンするのは非常に困難です。それらはまだそれぞれのタイルにあり、目は単に列をスキャンするのではなく、タイル間をジャンプする必要があります。

2）タイルはメディア用の優れたコンテナです。大きな画像を含むテーブルはすぐに使用できなくなるか、少なくともランク付け/比較の利点が失われます。

）テーブルでは、ヘッダーは（ヘッダーバーに）1回だけ表示されます。タイルレイアウトでは、デザイナーは値を説明するためにヘッダーを必要とせずに、値が自分で十分に明確になるようにコンテンツをデザインするか、ヘッダーをすべてのタイルに含める必要があります。後者は非常に多くの不動産を消費し、スキャン性が悪い乱雑なデザインにレイアップします。

Rumi P. · Answer

包括的な答えを出すことはできませんが、表が優れている非常に重要なケースが1つあります。

時々、同じように構造化されたアイテムがたくさんあり（それは重要な前提条件です！）、複数のタスク（または同じタスクの複数のシナリオ）をサポートするUIでアイテムに関する多くの情報を表示する必要がありますが、与えられたタスク。そこでは、テーブルがユーザーに必要な情報だけに従うための完璧な方法を提供します。視覚的な検索クエリは、リスト表示とは異なり、非常に単純化されています。

例：マネージャーは、生産に異常がないか確認したいと考えています。彼は過去30日間のKPI番号の表をプルアップします。 30行、KPIごとに1列があります。マネージャーは、1日あたりの不気味な製品の割合に焦点を当てています（視覚的な検索クエリ）。異常に見える場合は、2つの比較を行います。最初に、彼は同じ行の他の番号を見て、それらが多数のダッド（別の視覚検索クエリ）を説明しているかどうかを確認します。第2に、直接的な説明が見つからない場合は、同じ量のdudを持つ他の行を探し（さらに別のビジュアル検索クエリ）、同じようなdudレートの行の数を比較して、他の数も一致するかどうかを確認します。一般的なパターン（視覚クエリ番号4）。

これがテーブルにある場合、これらの各検索クエリに必要な要素の位置は、xまたはyのいずれか1つの座標のみで変化するため、マネージャーは直線に沿って途中で停止できます。これは、リストでこれを行う場合よりもはるかに簡単です。リストでは、要素のx座標とy座標の両方が異なります。それらが一貫したパターンで変化する場合でも（常にそうであるとは限りません）、次のアイテムに移動するために必要な目の調整ははるかに複雑です。それは非常に複雑でさえあり、数を見つけることの認知的負荷が高く、人は目で一度に十分にそれらを処理することができません。関連する情報だけを一度にワーキングメモリに「ポップアップ」して、パターンからの逸脱をひと目で確認する方法はありません。

したがって、テーブルが常に行ごとに読み取られることが予想される場合、この引数はあまり関係がありません。リストはもっと良いかもしれませんが、よくわかりません。ただし、テーブルが列ごとに読み取られることを期待している場合、またはユーザーが単一の行を比較することを期待している場合は、表形式のデータの方が適しています。

可能なパターン検索タスクのサブセット（すべてではない）の場合、グラフ、または実際には多数のグラフ（テーブルの列ごとに1つ）の方が、テーブルとリストの両方よりも優れていることに注意してください。