クライアントが実際にユーザーのために話していると仮定します。「一目で」より多くの情報を表示することは本当に有利です。</p>
通常、各ユーザーは自分に割り当てられた作業にのみ関心があるように思われるため、最初に行うことは、ユーザーごとに個別のページを生成することです。各ページに一意のURLを指定して、ユーザーがページをブックマーク/ショートカットして直接移動できるようにします。さらに良いことに、ユーザーが最初にアクセスした後にCookieをドロップして、ページがデフォルトで自分のものになるようにします。無関係な混乱を取り除くことに加えて、これは名前列を排除し、他の情報のためのより多くのスペースを提供します。
スクロール、クリック、ホバーなど、すべてを「一目で」確認するには、情報をできるだけコンパクトで整理された状態にする必要があります。
ページテンプレートを最小限に抑えます。テーブルでは水平方向のスペースが最も重要であるため、サイドバーメニューやナビゲーションコントロールはありません。ブランディングとメニューを上部の1つのバー、できれば50ピクセル以下の高さにします。少なくともあまり使用されないコマンドを保持するために、必要に応じてプルダウンメニューを使用します。
フィールドをできるだけ近くに圧縮し、10ピクセルだけ離します。テーブル内のタスクアイテムの数も（フィールドの数に加えて）問題になる場合は、デフォルトのフォントサイズで、フィールドを上から上に20ピクセル以内で一緒に絞ります。 。フィールドの境界線を削除またはミュートして、視覚的な混乱を減らします。特に、3D（斜角など）またはマルチカラーの境界線は避けてください。コード化され、圧縮された、対照的なコントロールでのいくつかの特定のガイドラインとアイデア。
グラフィックデザインをトーンダウンし、色、3D外観、テクスチャ、およびライトオンダークヘッダーまたはテキストのバリエーションを削減または排除します。必要なときに情報を視覚的にグループ化するのに十分なグラフィックを使用します。「退屈に見える」ことを心配する必要はありません。ユーザーはグラフィックデザインではなく、情報を勉強することになります。
デスクトップスタイルのオブジェクト選択アクションモデルを使用します。このモデルでは、ユーザーは最初にアクションするタスクアイテムを選択し、次にメニューから実行するアクションを選択します。これにより、テーブル内のアイテムごとに各コマンドコントロールを繰り返す必要がなくなり、テーブルにデータのみを表示できるようになります。
同じアイテムのフィールドを互いに積み重ねるのではなく、リスト内の各タスクアイテムをテーブル内の1つの行に保持します。単一の行を使用すると、フィールドラベルを繰り返す必要がなく、混乱を避けることができます。また、テーブル内の水平方向および/または垂直方向のルールを排除し、テーブルを介して目をガイドするためにフィールド自体に依存することもできます（ただし、目が密接に押されたときに行を追跡するのに役立つため、微妙なゼブラストライプを含めることができます一緒）。アイテムごとに1行になると、アイテムのスキャン、並べ替え、比較も簡単になります。テーブルがある理由は、ユーザーがタスク項目に優先順位を付けることができるようにするためだと思います。
フィールド幅に対して長すぎる文字列の完全な値を表示するには、マウスオーバーを使用することを検討してください。これにより、99パーセンタイルの長さで値全体を表示するためにサイズを変更する必要がないため、かなり短いフィールドを使用できる場合があります。ドラッグアンドドロップで列のサイズを大きくして、ユーザーがそれぞれのデータに必要な最小幅を設定できるようにすることもできます。
よりコンパクトな形式、集計、略語、コード（色合い/色など）、またはアイコンを使用してフィールドと列自体を圧縮し、値または列ヘッダーを示します。これにはユーザーのトレーニングが必要な場合がありますが、マウスオーバーを使用して、コード/アイコン/略語の意味に関するツールチップを提供することもできます。略語はおそらく認識、学習、および覚えやすいですが、グラフィックコードとアイコンはスキャンしやすく、「一目でわかる」評価に役立ちます。GをGUIに配置する際のコーディングに関する推奨事項。ただし、この記事では、コードとテキストを組み合わせることもアドバイスしています。これにより、スペースを節約できません。
列ヘッダーを複数行にして、フィールド自体が必要とするよりも列の幅を強制しないようにします（たとえば、Y | Nフィールドの場合）。必要に応じて、列ヘッダーを斜めに配置します。垂直ヘッダーよりもスペースは必要ありませんが、読みやすくなっています。
少なくとも大きなモニターを使用しているユーザーがすべてを一目で確認できるように、テーブルのサイズはウィンドウのサイズ変更に合わせて変更してください。
上記のすべてを実行した後、すべてが一目で見えるようにするためにできる限りのことを実行しました。それでもすべてのデータが収まらない場合は、優先度の低い情報を表示するには、対話が必要です。オプションは次のとおりです。
水平スクロールを備えた幅の広いテーブルで、優先度の低いフィールドを右側に配置します。これは、ユーザーがすべてのタスクアイテムを比較できるため、多くの場合、最も単純で最も使いやすいソリューションです。通常、各アイテムにテーブル内の複数の行を取得させるよりも優れています。水平スクロールは、特に行ヘッダーを固定し、他のフィールドのみをスクロールする場合、散文用のテーブルの使いやすさの問題にはなりません。
テーブルの下に優先度の低い「オーバーフロー」フィールドのペインのようなフォームがあるマスター/詳細部門。テーブルで現在選択されているアイテムの値が表示されます。このオーバーフローペインをタブ付きにすると、非常に多くのフィールドを保持できます（ただし、「一目で」は保持できません）。オーバーフローペインをエキスパンダーに配置して、ユーザーがエキスパンダーを閉じると、テーブルがウィンドウの高さ全体に拡張されるようにします。これにより、優先度の低いフィールドを表示する必要がないユーザーは、より多くのテーブルアイテムを表示できます。オーバーフローペインのフィールドは複数のアイテム間で簡単に比較できないため、このソリューションは、タスクの優先順位付けに使用されるフィールド（テーブル内にある）とタスクの完了方法を決定するために使用されるフィールド（移動する）の間でフィールドを分割できる場合に最適に機能します。オーバーフローで）。
ツリーまたは望遠鏡。各テーブルの行を展開して、優先度の低いフィールドを表示できます（+ボタンのアイデア）。これがマスターディテールよりも優れている主な利点は、理論的には2つのアイテムの優先度の低いフィールドを比較しやすいことです。ただし、2つのアイテムがテーブル内でたまたま隣接している場合に限ります。それ以外の場合は、マスター詳細よりも多くの問題があります。優先度の高いフィールドはスクロールアウトして表示されない可能性が高く、特定のアイテムに到達するためのスクロール量が変化し、特定の低いアイテムを見つけるためにより多くのクリックが必要になります。優先度の詳細。
ユーザーがテーブルから「ドリルダウン」する優先度の低いフィールド用の別のページまたはウィンドウ。これは通常、これらのフィールドのページが必要な場合（たとえば、直接移動する場合）、またはクライアントが必要だと主張する非常に優先度の低いフィールドを詰め込む場合にのみ有効です。
TakeingPanesでのこれらのオプションの詳細とイラスト。
マウスオーバーで情報を表示することは、短い補足情報のみのために予約する必要があります。そうしないと、邪魔になりやすく、アクセシビリティの問題が発生する可能性があり、ユーザーは他の何かを操作しているときにコピーしたり表示したりできません。
列の非表示/表示は、さまざまなユーザーがさまざまなフィールドを使用している場合にのみ意味があります（たとえば、水平スクロール）。これは、セッション間で保持する必要があるユーザー設定にすることができます。