web-dev-qa-db-ja.com

たくさんのボタンがあるグリッド/テーブル

ユーザーが実行できるアクション用のボタンがいくつかあるグリッドがあると考えてください。こんな感じです。

Button grid

システムに同様のグリッドがいくつかあります。どうすればよいのか、人々の意見を聞いているところです。

  1. そのままにする
  2. さまざまなオプションのドロップダウンリストが付いたボタンが1つあります。これは、行の高さが低いことを意味します。
  3. 他の何か。

これは、ユーザーが定期的に使用しない画面で、平均して1日に1回だけです。速度(1 vs 2クリック)はおそらく大きな問題ではありません。

23
Craig

Youtube Studio Video Editorにも同様の状況があり、アイデアの取得、アイコンの組み合わせ、ドロップダウンオプションメニュー、および対話性を支援します。

  • 各行には2つのアイコンがあります。左側のselectアイコンとviewオプション付きの緑色のアイコン
  • Watch in Youtubeアイコンと3つのドットのオプションメニューをホバーすると表示されます行
  • 3つのドットのオプションメニューをクリックすると、5つのオプションが表示されます。
    • 編集する
    • リンクを取得
    • 宣伝する
    • ダウンロード
    • 削除する

enter image description here

30
Danielillo

アクセシビリティの観点から、表のセルごとにインタラクティブ要素を1つだけにすることを強くお勧めします。スクリーンリーダーでのテーブルの操作が大幅に改善されます。私の職場でも同様のテーブルがありました。一部のセルは、セルとそのテーブルヘッダーのすべてのさまざまなコンテンツにより、スクリーンリーダーによって10〜20秒間読み上げられます。

現状のまま:醜いが機能的。各行に同じボタンの配列があり、無用なボタンがグレー表示されていると、読みやすくなります。すべての行の形式がまったく同じ場合は、表形式のデータを処理する方が簡単です。 Bootstrapの場合、これを行うのは少し面倒ですが、なぜbtn-xsを削除したのですか?)

ドロップダウン:選択のアクションがアクションをトリガーする場合、ドロップダウンの操作は物理的にエラーが発生しやすいため、このインターフェイスはミスの発生率が高くなります。アクションを選択してからボタンをクリックして実行するのであれば、問題ありません。

4
nigel222

これ以上のコンテキストがなければ、質問に答えることは困難です。ユーザーはどのようにテーブルを使用しますか?彼らはそれとどのくらいの頻度で相互作用しますか。さまざまな状態で可能なアクションはユーザーに明らかですか?

ここでは、コンテキストを知らずにいくつかの考えを示します。現状では、見栄えがよくないかもしれませんが、ドロップダウンに比べていくつかの利点があります。すべてのアクションがすべての州で利用できるわけではないことは明らかです。可能なすべてのアクションが一目でわかります。ユーザーは、最初にドロップダウンをクリックすることなく、目的のアクションを直接クリックできます。これを変更する場合は、これらの利点を考慮する必要があります。しかし、いくつかの欠点もあります。 UIは非常に雑然としている。ユーザーのために処理する多くがあります。

問題は、このテーブルの目的は何ですか。ユーザーがタスクを実行する際に非常に効率的になるのに役立つかどうか。ユーザーに状態の概要をすばやく説明するのに役立ち、アイテムとの対話は二次的なものであり、常に必要なわけではありません。

ソリューション1と2を組み合わせて使用​​できると思います。最もよく使用されるアクションを使用可能にし、あまり使用されないアクションをドロップダウンに追加します。難しさは、アイテムの状態によってはメインアクションが常に同じではないことです。

しかし、最終的には、ユーザーが最もよく知っています。だから私がやろうとしていることは、簡単なプロトタイプでこれをテストし、実際のユーザーでテストすることです。状況に応じて最適なソリューションがどれかを確認するために、多くのユーザーでテストする必要はありません。

3
BrunoH

すべてのオプションをコンテキストメニューに配置し、アイテムのステータスが原因でその時点で使用できないオプションを無効にすることができます。これにより、ユーザーは常に同じオプションのリストを使用できます(オプションが無効になっている理由を説明できる場合があります)。

また、ビューオプションをボタンではなく、行自体をクリックするだけにすることもできませんか。

3
Annemiek

注文に対する3つのタイプのアクションを識別できます。それらを分割し、タイプ内でアクションをグループ化します。

見る

まず最初に、注文に共通する唯一のオプションのボタンをviewに指定します(ここでは、新しい注文を表示することに異議はありません)、独自のより予測可能な場所。今では、利用可能な他のオプションに応じて、あちこちを飛び越えています。

編集

注文を編集するとき、ユーザーは最初に何が入っているかを確認する必要があります。そこで、ここで編集ボタンを削除し、ビュー画面から編集オプションにアクセスできるようにします。

処理

これで、送信、再送信、受信、キャンセル、キャンセルの取り消しができました。ドロップダウンを使用することもできますが、これらは通常のボタンより少し厄介なので、おそらく5つのボタンのグリッドが最適です。使用できないオプションは非表示にしないでください。オプションを無効にすると、各ボタンは常に同じ場所に配置されます。


最初に表示、後でアクション

または、 Annemiekの優れた提案 に従って、行をクリックしてviewingを使用可能にします。すべてのボタンを削除して、それらをビュー画面に再配置します、注文ごとの余分なクリックが問題にならない場合。それはユーザーによって多少異なります。これはdoesユーザーが注文を処理する前に最初に注文を表示する必要があるため、一種の追加のチェックを作成します。

3
SQB

システムに同様のグリッドが多数あります

共有したスクリーンショットでは、行ごとにアクションが異なります。これらすべてのボタン/アクションを各行で前もって利用できるようにすることは、視覚的な混乱、ユーザーの認知的負荷、および Tobias のようなアクセシビリティの観点からは、良い選択ではありません。各行に1つのアクションがあり、ユーザーがそのアクションを頻繁に実行する場合、そのボタンを行に置いたままにして、残りの2次アクションをケバブメニュー(3つの縦のドットアイコン)内にグループ化できます。

2
Sooraj MV

行ごとにホバーアクションを続けることができます。したがって、ユーザーが行にカーソルを合わせると、アクションのリストを提供するドロップダウンオプションが表示されます。

このビューの項目ごとに異なるオプションがあると混乱するようです。通常、グリッドまたはリストでは、ユーザーは各要素に対してまったく同じインターフェースを期待します。

そのアクションはすべてのアイテムで使用でき、ユーザーがアイテムを「表示」したときに表示されるUX要素に他のオプションを移動するため、「表示」ボタンを保持することもできます(アイコンに変換することもありますが、それは重要ではありません)。 。

さらに、表示は破壊的なステップではありませんが、他のアクションは何らかの作業を行いますが、元に戻すことはできません。ユーザーがORD-123545とORD-213455の間に挟まれたリストでORD-123455をキャンセルしようとしていると想像してください。アイテムの表示と操作の間に追加のアクションを追加することにより、摩擦が少し追加されますが、正しいアイテムが選択されていることをユーザーに確信させることができます。

0
Harrison Paine