巨大なデータテーブルに最適なアプローチ（現在はスクロールを使用）
専門家、
巨大なテーブル（500行としましょう）の最善のアプローチを評価するのに助けが必要です。直感的で視覚的に魅力的で、テーブルデータにより重点を置いたものが必要です。ほとんどのページには1つのテーブルがありますが、複数のテーブルがあるシナリオもあるので、それも考慮する必要があります
現在、テーブルdivでスクロールバーを使用していますが、問題は別のスクロールバー（サイドバーナビゲーションとコンテンツ領域のスクロールバー以外）に追加されることです。現在のアプローチの大まかなスケッチは以下のとおりです。
モバイルでは、フッタブルプラグインを使用したスタックテーブルアプローチを使用しています。
Gmailの1つの機能は魅力的ですが、
- 長いメールスレッドを開いたとき
- そして、そのセクションをアクティブにするために、セクションを押して返信などを押してください
- その前のスレッド内では、「...」で切り捨てられます。クリックするとコンテンツが表示され、上下にスクロールするとメインスクロールバーが更新されます。スムーズなスクロール機能があり、コンテンツにフォーカスを維持しています。
更新：正確に列に複数の期間がある貸借対照表の財務データを保持していることを考慮してください。最初の列はスティッキー/フリーズ/固定され、残りは水平方向にスクロール可能です。私たちの主な懸念は、複数のスクロールバーですが、使いやすさが失われてテーブルのスクロールバーを避けることができるかどうかです。
エンタープライズ環境の1つのプロジェクトで、「Web UIに巨大なデータテーブルを表示する」という課題にも取り組んできました。大量の巨大なExcelシートを（内部）Webプラットフォームに移行する。
この経験から、大規模なデータセットを小さなチャンク（マスター/ディテール、サマリー、タブなど）に再編成することを目的として、データテーブルのユーザーワークフローを分析しないでくださいを強くお勧めします。おそらく私たちのスキルが不足しているか、この組織は独特ですが、これらのスプレッドシートを読んだり使用したりする支配的なプロセスはないことが判明しました。行/列、行のグループ、行と列の組み合わせなどの詳細を比較するという、スプレッドシートのさまざまな使用方法が文字通り数千ありました。これらの数千のワークフローに優先順位を付ける（簡単な）方法はなく、それぞれに異なるWebワークフローを構築する方法もありませんでした。
私たちのケースでうまくいったのはデータのテーブルの使用を避けるで、代わりにデータを提示する他の方法を使用することでした。従来のrow-column-data-tablesは、画面の領域では非常に非効率的であることがわかりました。データの総量の幅を減らすために使用したいくつかの「トリック」：
- 「行」ではなく「カード」を考えて、データの単一レコードを提示してください。 （私はテーブルをすべて一緒に取り除くことを推奨していませんが、行と列の考え方の外で考えることは役立ちます）
- 1つの「レコード」のデータを複数行に配置します。ビジネスユニット、運営会社、部門。
- すべての列ヘッダーラベルを削除します。ほとんどのテキストフィールド（部門名など）では、データによってデータが明確になります。その他のフィールド（売上、利益、マージンなど）の場合は、マウスオーバーで数値を説明します。また、並べ替えやフィルタリングを行うには、他にも優れた方法があります。
- 長いテキストを切り取り、
...マウスオーバーすると詳細が表示されます - ステータス（従業員のはい/いいえなど）をアイコンに、（再度）マウスオーバーで説明を置き換えます。
- 情報を1つの「文字列」に結合します。名、ミドルネーム、姓、ニックネームを1つの文字列に結合します。
- 四捨五入（例：$ 10,000）
- 各カードで展開/折りたたみを使用して（ただし、同じページにとどまる）、詳細を表示します。
これは私たちにとってうまくいきます：聴衆は毎日データを使用するので、アイコンxが何を意味するか、または上から3番目の量が何であるかを調べる必要性をかなり迅速に失います。他の環境（モバイル、使用頻度の低い）では、他のソリューションの方が適している場合があります。
ところで、結局のところ、いくつかのデータテーブルで終わります（古いユーザーの習慣は難しく、テーブルはなじみがあります）。水平スクロールを完全に排除することはできません。
行やデータ行をスクロールするのは面倒です。最初に尋ねる質問は次のとおりです"ユーザーはこのデータをすべて表示する必要がありますか、それともデータの背後にある情報を見つけようとしているのですか？"
すべてのユーザーとユースケースを調べ、各行と列を調べて、達成しようとしていることを理解します。このページへのアクセスが成功したと見なすのはどの時点ですか？あなたの製品はどのようにしてユーザーをより早くそこに導き、ワークロードを最小限に抑えることができますか？
テーブルが実際に必要であることがわかった場合は、次のことを検討してください。
列を表示および非表示にする機能を確認してください。
ほとんどの場合、データを表示しているときに、必要な情報を取得するために使用可能なすべての列が必要になることはほとんどありません。これにより、一部の画面領域を解放することもできます。10列でいいのですが、実際に必要なのはユーザーの1％だけです。 99％は3つの列を表示するだけでよい場合があるため、無関係なデータを非表示にする機能を提供します。
ユーザーが関連するパラメータを選択できるようになったら、次に、ユーザーが特に探しているものをもう一度確認する必要があるため、フィルターを追加する必要があります。
たとえば、この列には20種類の果物がありますが、ユーザーはリンゴのデータだけを見たいと思っています。
追加の開発作業を必要とする可能性のある最後の変更は、ユーザーがこのデータをどのように処理するかについて本当に考えることです。彼らは洞察を発見したいですか？その場合は、Excelとよく似たピボットシステムを作成して、データの概要をすばやく取得できるようにします。考慮すべきもう1つのことは、ユーザーがこの形式でデータを表示する必要があるかどうかです。データをグラフでよりよく表示できますか？
データの行に関しては、データを構造化する方法を使用すると便利な場合があります
つまり、複数のデータ項目を1つの列にロールアップします。これは、これを行うことが実際的であり、まだ価値のあることです。たとえば、顧客の住所が複数の列に分散している場合があります。
- 40ローダーロード
- 町
- 市
- 郵便番号
統計上の目的でこのデータを分解する必要がない場合は、ページ上で展開できる1つの住所列だけにデータをプルして、画面を節約できます。
概要：
- 列を非表示/表示する機能
- 各列にフィルターを提供する
- カスタマイズ可能なピボットテーブルまたはデータの概要を追加します
- データの構造を確認する
このための最も有用なアドバイスは、ユーザーが達成したいことを考え、それを簡単かつ柔軟にすることです。
簡単な解決策：テーブルを全幅にして、テーブルセクションに垂直スクロールバー（および必要に応じて水平）を設定し、複数のテーブルを異なるタブに分割します。このようなもの（悪い描画のため申し訳ありません）：
いくつかの列を削除して、水平スクロールの可能性を低くするようにします。ユーザーがデータで何をしようとしているのかを知ることが重要です。目標を達成するために、データのすべてのビットが列である必要はありません。
これは、内部アプリケーションに対して取得したリクエストの例です。
部長：「添付ドキュメントのアップロード日時を示す列を追加します。」
私：「あなたはそれで何をしますか？」
部長：「承認するアイテムを決定するために必要です。」
私：「あなたはそれをどのように使ってその決断をするのですか？」
部長：「人々は私たちが承認期限に間に合うようにアップロードを間に合わせる必要があります。」
私：「アップロードが間に合わないとどうなりますか？」
部長：「彼らは承認されません。」
私：「承認は何時にしますか？」
部長：「午前10時」
私：「どのくらい前に彼らはアップロードを行うべきですか？」
部長：「すべてが揃うまでに1時間かかる。
私：「すべてのアップロードの日時を確認する必要はありません。本当に午前9時以降に誰が何かをアップロードしたかを知る必要がありますよね？」
部長：「はい、それがそのコラムを使用するためのものです。」
私：「すべての広告申込情報についてすべての情報を確認し、それぞれの時間を確認する代わりに、今日の午前9時以降にアップロードが発生した広告申込情報にフラグを付け、真夜中にそれをクリアするとどうなるでしょうか？日時を確認せずにスキップしますか？」
部長：「それはさらに良いでしょう！」
ブーム。余分な列が回避され、タスクがユーザーにとって簡単になりました。次のコラムに進みましょう...
ユーザーはこれらのテーブルのデータも編集しますか？はいの場合、どのように処理したかを知りたいと思います：
数値のみが必要な列=文字を入力できないようにキーボード入力を制限しましたか？または、文字の入力を有効にしてからエラーを表示しましたか？
表のセルに検証エラーをどのように表示しましたか？特に、一度に複数のエラーが発生した場合（複数のセルに入力された値に基づいて検証が実行された場合）。
これを表示する最良の方法はページネーションであり、ユーザーに関連レコードをほとんど表示しない、たとえば1ページあたり50とします。これは見栄えがよく、行数が多く、クライアントがすべての行を一度に表示したくない場合にも推奨されます。
ここではテーブルのページ分割に同意しません。データターゲットは、相対データでのみ意味があるように思われ、ページ分けはまとまりのあるセクションでのみ意味があります。
したがって、私が最初に行うことは、データを機能セクションに分割し、ナビゲーションを通じてテーブルを変更できるようにすることです。
次に、私の意見では、テーブルはページを縦方向に埋め、スクロールバーのみがブラウザで処理される必要があります。これは大きなテーブルの問題を解決するはずです。 500行はそれほど多くありません。必要に応じて動的にロードします。
ページごとの複数テーブルの要件は別の獣です：関連するテーブルだけの場合は、要件を確認し、ナビゲーション（サブセクション-ページ内の各テーブル）を通じてそれを処理する必要があります。参照と比較に使用する場合（2つのテーブル）：水平に分割してナビゲーションバーを非表示にする特別なレイアウトを処理します。
スペースにまだ問題がある場合（水平方向）、凍結した年と比較して、色と符号（+と-のそれぞれ2/3レベル）を使用して履歴データを処理することができます。ユーザーはおそらく、年々データまたはパフォーマンスの異常を見つけることに関心があるため、最初に注意を引くのは、別のデータセットとの差/変動（またはその欠如）です（各列の差が必要かどうかをユーザーに尋ねます）前または常に最初の列など）。次に、行をクリックまたはタップして、ユーザーが実際のデータを表示できるようにします。