テーブル行が選択されるまで一括編集機能を非表示にする必要がありますか、それともより良い解決策がありますか？
例として、MailChimpはサブスクライバーリストをテーブル/データグリッドに表示します。ユーザーは各行の左側にあるチェックボックスを使用して1つ以上の行を選択できますが、行が選択されるとどのようなアクションが利用可能になるかはわかりません。何も表示されません。
次に、彼は行を選択します。 [削除]ボタンが表示されていることに注意してください。
このパターンが使用された理由を理解しています。行を削除することはそれほど一般的ではないタスクであり、常に表示されている必要はないとデザイナーは感じています。行が選択されていないときに[削除]ボタンが表示されている場合、クリックしても機能的な結果が得られないことも事実です。 （デザイナーはボタンを明らかに無効な方法で提示するか、エラーメッセージなどを提供する必要があります。）
理解していますが、これは完全に満足しているという意味ではありません。
異論
- 発見性の欠如。インタラクションのカテゴリ全体が画面上と画面外を飛んでいるのは不快です。ユーザーは、行を選択するまで、行に対して実行できるアクションを確認できません。共通のインターフェイスパターンに精通しているかどうかに応じて、非表示の関数がそれ自体を明らかにすることを予期することすらできず、行を選択するインセンティブをほとんど感じることができませんでした。
- 不適切な近接の使用アクションボタンがチェックボックスから遠く離れている可能性があるため、ユーザーはページの一番下までスクロールして何かを選択し、次に一番上までスクロールします。ページの上部でアクションを実行します。
- 悪いフィードバック。おそらく、ユーザーがページの一番下までスクロールして選択を行い、[削除]ボタンが隠れている可能性があります。その場合、ユーザーの知識によっては、明らかなフィードバックがないために何が起こったのか理解できない場合があります。
最後の2つは、「スティッキー」なアクションバーで軽減できる可能性があります。近接性はそれほど問題ではありませんが、依然として問題です。
結論
MailChimpが進歩的な開示を彼らが持っている方法で使用した理由を理解し、私も同じパターンを使用しています。それでもいくつかの小さな点で間違っていると感じているので、もっと良い解決策を期待しています。
特定のコントロールを非表示にできるかどうかを尋ねています。
この質問に対する有用な答えの1つに出会ったのは、Ellen IsaacsとAlen Walendowskiによる本 画面の両側からデザインする です。
この本では、機能を作成する必要があるかどうかを評価する方法としての頻度と共通性、およびユーザーインターフェイスで機能をどの程度目立たせるかについて説明しています。前提は、プログラムには多くの機能があり、それらすべてをメインUIに含めることはできないためです。なぜなら、UXデザイナーとしては、UIを過密にしたり、ユーザーを圧倒したりしたくないからです。
このグリッドは、ユーザーインターフェイスで機能のコントロールを表示する場所についてのアイデアを大幅に簡略化したものです。
グリッドを使用して、頻度と共通性の特定の組み合わせに対する可能な治療を調べます。新機能の場合は、金額を見積もります。既存の機能については、ユーザーの行動を測定します。このグリッドでは、「頻繁」とは、ソフトウェアを使用するほぼすべてのことを意味します。他のガイドラインと同様に、他のガイドラインがこのガイドラインよりも優先される場合があるため、これに従わないことを選択できます。
免責事項。繰り返したいのですが、上のグリッドは完全に単純化しすぎています。上記のグリッドで省略されているオプションやニュアンスは他にもたくさんあります。また、基本的な概念はIsaacs＆Walendowskiからのものですが、これらは彼らの言葉ではないため、解釈の誤りは私のものです。 :)
このアイデアを仕事で大規模に見る
周波数の共通性に関心がある場合は、ビデオ（またはスライドとオーディオのみ）で Jensen HarrisがThe Story of the Ribbonに通知する をご覧になることをお勧めします。 Office 2007リボン上のコントロールのグループ化。リボンが気に入らなくても、ビデオはメソッドへの興味深い洞察を提供します。
一括編集は強力なツールです。
ここでは発見可能性の方が関連性の高い用語である可能性がありますが、アフォーダンスは大きな問題ではありません。これは、アイテムを削除または編集する唯一の方法ではないためです。特定のアイテムにいつでもドリルダウンして管理できます。ですから、初めてそれを「学ぶ」必要があります。あなたが持っていると、それは大したことではありません。
また、一括編集を許可するインターフェイスは、十分な使用量を受け取り、データセットにある程度の複雑さが含まれているシステムを扱っていることを前提としています。そうでなければ、なぜ一括編集機能が必要になるのでしょうか？インターフェースは現在、ほとんどの状況下で定期的に使用されるツールです。発見可能性は効率よりも重要ではありません。
次のポイントは、近接ルールの違反です。
システムがページの最上部または最下部にスクロールして一括アクションを実行し、ページに大量のデータがある場合、前述のとおり、これは使い勝手が悪い。長いスクロールテーブルに関しては、Gmailの一括編集のような「スティッキー」なアクションバーが慣れています。
はい、バルクアクションは選択した行のすぐ横にない場合があります。ただし、アクションは常に一貫した予期される場所に表示されます。率直に言って、一括編集は十分に特化したアクションであり、ユーザーが意図的にアクションを実行してマウスをアクションバーに移動させることは悪い考えではありません。一括編集は、多数のレコードに影響を与える可能性があります。ユーザーは、アクションを実行する前に確認する必要があります。
行が選択されるまで一括編集アクションを非表示にするかどうかに関しては、利用可能なアクションの数に要約されます。たくさんある場合は、状況に応じてそれらを表示して、インターフェースが煩雑にならないようにすることをお勧めします。そうでない場合は、そうしません。