凡例をデータテーブルに導入するためのガイドライン
グリッドがあり、それに凡例を追加することを考えています。チャートの凡例があるように。
凡例は次のとおりです。
列の70％は編集可能です。既知のパターンは、各列に鉛筆アイコンを配置することです。しかし、私は鉛筆の軍隊になってしまいます... :)
一部のラインアイテムにはデータがありません。ユーザーにわかるように、ラベルを付ける必要があります。
コンテンツを追加できる列が1つあります。編集されていません。
この3つを色分けして考えました。しかし、考えてみると、ADAの目的で、この情報を通信するための色に依存しない方法が必要です。とにかく、結局アイコンになってしまいます...
正しい？何か案は？
ユーザーがデータを変更する必要がある方法と頻度を確認します。凡例の代わりに、データが不足している場所を明記してください。
一括編集
ユーザーが適切な量のフィールドを変更している場合は、「編集」するための主ボタンを配置できます。編集可能なコンテンツは、フォーム入力（テキストフィールド、ドロップダウンなど）によって表示されます。
Pro
- ボタンを1回押すだけで、編集可能なコンテンツが表示されます
- 表示モードでは、テーブルは鉛筆やツールチップなどに邪魔されません
Con
- ユーザーがモードに入ります。1つの小さなフィールドを編集したいだけの場合、重く感じるかもしれません。
1つずつ編集
別のアプローチは、編集可能なフィールドにホバー時に記号を表示することです（つまり、鉛筆を編集）：
Pro
- アイコンとインジケーターで邪魔にならない表示
Con
- ユーザーは、何が編集可能かを正確に確認するために、大量のコンテンツをマウスで移動する必要があります（同じ列の特定のフィールドが制約によって編集できない場合、混乱する可能性があります）。
テーブルに関しては、凡例に関する特定のデザインガイドラインを見たことがありませんが、チャートやグラフの凡例のスタイルを設定する方法に似ていると思います。
凡例の必要性をなくす相互作用のいくつかを処理するための既知の設計パターンは次のとおりです。
- 編集可能なセルのみが状態を変更するビューモードと編集モードを切り替えるためのトグル/ボタンを作成します（または、実際にセルのスタイルを変更して、編集可能なセルを入力フィールドのようにすることができます）
- アイコンが表示されるホバーオーバー効果（つまり、ツールチップ）を作成する（とにかくこれを行っていると思いますか？）
- さまざまなステータスに固有の列を作成する（オーバーライドが適用されるなど）ため、行全体にスタイルを適用する必要がありません。
上記の戦略（独自のソリューションを含む）の組み合わせを試して、表示されるデータで何が最適に機能するかを確認し、エンドユーザーでテストする必要があるかもしれませんが、前述の設計パターンは、テーブルの凡例。
「鉛筆の軍隊」で終わらせたくない理由について述べた根拠は、データが欠落している行が多くて「感嘆符の軍隊」になったのと同じである可能性があることを指摘したいと思います。
バリエーションやコンテンツの種類をテーブルに導入しすぎない限り、必要なのは、設計上の決定が一貫していて簡単であることを確認することだけです。そうすれば、少なくともユーザーはすばやくそれを学び、設計に慣れることができます。