悪いUXのテーブルを右クリックしてください
ユーザーが複数の行を選択してそれらに対してアクションを実行できるグリッドがあります。行を選択すると、グリッドの上部にアクションボタンが表示されます。ユーザーがグリッドを右クリックしてこのメニューを表示できるコンテキストメニューでこれらのアクションを利用できるようにすることを検討してきました。選択された行が一番下にあり、ユーザーがそれらのアクションをクリックするまで上にスクロールする必要がない場合に便利です。
UXの観点からグリッドを右クリックすることについて何か考えはありますか？
ウェブアプリです。マテリアルの上に独自の設計システムを採用しています。
右クリックでコンテキストメニューを使用するのは良いアイデアだと思います。これはデスクトップアプリケーションでは当たり前のことであり、ウェブインターフェースでそうでない理由がないと思います。そして、GoogleとMicrosoftのすべてではないにしても多くのツールが、右クリックアクションを使用してコンテンツ関連のアクションを提供しています。また、右クリックは、タッチ対応デバイスのロングタップにうまく置き換えることができますが、これも当たり前のことです。
それらの唯一の問題は、それらを見つけるのが難しいということです。そのため、そのアクション行をテーブルの上に置いておく必要があります。
テーブルベースのUIを備えたほとんどすべてのツールがコンテンツメニューに右クリックを使用するのは良いことです：デスクトップ、ウェブ上のGmail、Googleシート、Excel。だから、あなたのためにそれが続いています、そしてホバーまたはクリックで行の視覚的な状態が変化した場合、人々は右クリックでコンテキストメニューを見ると期待することができます。
まず、ギャングスタの動きです。機能の実装に時間をかける前に、ユーザーが右クリックしているかどうかを追跡し、価値があるかどうかを検討してください。
それは一般的なUIには良いUXですが、Web上の悪いUXです。
カスタムの右クリックメニューは、通常のメニューをブロックします。これは、最小の驚きの原則に反し、ユーザーが望んでいることにも反するものです。たぶん彼はブラウザのコンテキストメニューを使いたがっています。コピーするには、スクリーンショットの作成など、現在のブラウザーのすべてまたは一部のより高度なオプションを選択します。
Webページでは、通常はブラウザーまたはOSによって処理されるイベントを傍受しないでください。とにかくそれをブロックしている（またはブロックを許可している）ブラウザーもあれば、ブロックしていないブラウザーもありますが、コンテキストメニュー、ショートカット、またはその他のキーボードやマウスのイベントを使用して操作することに慣れているユーザーを困らせます。あなたのウェブサイト。
たぶんあなたは、談話フォーラムのような独自の検索機能のためにctrl-fをインターセプトするサイトからこれを知っています。現在のページを検索したい場合、フォーラムはショートカットをインターセプトし、フォーラム全体の検索を提案します。
要約すれば：
- デスクトップアプリケーションやアプリでは、これは良い選択であり、そのように期待されています。
- Webアプリケーションでは絶対に行わないでください。 Webサイトはアプリではなく、（スクリプト化された）ドキュメントです。
実際にいくつかのセルを右クリックして、行や列を追加できるかどうかを確認しました（場合によってはまったく発生しないことがあり、別のツールを探す必要があります）。したがって、ユーザーとしての経験/意見から、もっと頻繁に見たいと思います。
UXデザイナーの観点からは、何らかの方法でテストして、コンテキストメニューにどのツールを表示するかをユーザーに尋ねるように指示します。多分あなたはカード分類ワークショップでいくつかの答えを持つことができます:)
GL！
この投稿は、Webユーザーのように回答します。
私は告白します：私は常にWebツール（Googleドライブのようなツールのように機能するWebアプリケーション）を右クリックして使用しようとしていますが、誰もこれを気にしません。まれに、誰かがそれを使用しているのを見ました。そうでなければ、あなたがウェブサイトやeコマースでそれを行うと、私は不思議に思うかもしれません、多分不幸です。
アイデアおめでとうございます。試してみて、動作するかどうか教えてください。
しかし、その前に、UX Professionalとしての考慮事項をいくつかリストします：
- あなたがそれをしたいと思う理由と結果の良い面と悪い面のリストを作ってください。
- 本当に必要な場合にだけ実行してください。そして、次に見るためにモバイル画面で画像をスワイプするようなユーザーにとって自然に見える場合。
- ユーザーが右クリックを使用する他の理由がありますか？はいの場合は、行わないでください。
- 一般的なアクションではないので、ユーザーにそれを実行できることをどのように伝えますか？
- プロトタイプを作成して、何人かのユーザー（上司やお母さんではなく実際のユーザーではなく、実際のユーザー）でテストします。
- ユーザーがこれらのアクションを必要とする頻度を分析します。それだけの価値があるユーザーを開発して教えるために必要なすべての時間？
Googleドライブはそれを非常にうまく行います。
右クリックのコンテキストメニューは発見しにくいため、機能を利用するための唯一の手段として使用しないでください。これらはショートカット用であるため、ボタンを上に置いている限り、そうです。これはまさにそのためであり、そのショートカットを提供することは良いことです。
私は「allo」がウェブ上でそれがブラウザの機能をブロックしていることについて良い点を作っていると思います、そしてそれは最小の驚きの原則に反します。 UXerの間でそれについていくつかのコンセンサスがあるのだろうか？
いいえ、それは悪いUXではありませんが、リスクがあり、追加の懸念が必要です
- ユーザーの右ボタンが機能しない場合はどうなりますか？ささいな仕事ができなくなる
- タッチスクリーンはどうなりますか？
しかし、私はあなたのアプローチに紛れもない利点があると思うので、右クリックしなくてもこのコンテキストメニューまたはそれに関連するアクションを機能させる方法を維持するだけで、それを実行できると思います。この二次的なアクションのセットは、上記のケースをカバーし、システムの機能とそのアフォーダンスの可視性を高めます 内部の制御軌跡 、これはインターフェース設計の8つのゴールデンルールの1つです
はい、Webアプリでテーブル（および他のすべての要素）を右クリックしてコンテキストメニューを表示すると、次の理由からUXデザインが悪いと見なされます。
悪い発見可能性：Webユーザーは、ブラウザーのコンテキストメニューとは異なる右クリックのコンテキストメニューを期待していません（「ユーザーの期待との確認」と「自己記述的」を破ります）
相互運用性の悪さ：すべてのデバイスが右クリックで同じように動作することをウェブ上で確認することはできません。
また、マテリアルデザインガイダンスに従う必要があります。
要素の外観と動作は、要素に対してジェスチャーを実行できるかどうかを示す必要があります。
可能な解決策
自己記述的な ドロップダウンメニュー をテーブルに追加する方法の1つの例を次に示します。
コンテキストメニューがUXの観点から良いのかどうかという質問に対する明確な答えはないと思います。他の人は彼らの答えの多くの側面を指摘しました。これらから強調したいのは、コンテキストメニューは、これらのアクションを実行する唯一の方法ではなく、追加の方法にすぎないということです。経験の浅いユーザーはオプションを見つけられないかもしれないという問題を認識していますが、彼らには代替手段があり、経験豊富なユーザーはより快適なソリューションを楽しむことができます。
しかし、コンテキストメニューの作成についても考えている理由に焦点を当てたいと思います。問題は、ユーザーがアクションボタンにアクセスするにはスクロールする必要があるということです。グリッドのコンテンツをスクロールしている間、画面の上部に留まる付箋ボタンを作成することはできませんか？デスクトップアプリケーション、Webアプリケーション、またはモバイルアプリケーションのどちらを開発しているかに応じて、これらのアクションを固定できる他のポジションがある場合があります。
私が見たもう1つのことは、各行（左または右）にボタンを提供することです。もちろん、これはアクションの数が少ない場合にのみ実行可能です。
個人的な意見/経験：ウェブ開発の背景から来て、右クリックを避けようとします（これは自動的にブラウザのコンテキストメニューと競合するためです）。前述の両方を使用しましたグリッド行でのアクションのアプローチ、たとえば各行の最後にある行をコピーおよび削除するためのボタンですが、一般的にはスクロールせずに上部にスティッキーボタンがあります。コンテキストメニューを追加する必要はありませんでしたまだグリッドですが、必要に応じて将来的にこれを実行することは想像できます。代わりにコンテキストメニューを使用したのは、主に高度なアクション用です（経験豊富なユーザーだけが実行したい、または実行できるアクションの意味で） ）または「この行が過去にどのように変更されたかを教えてください」などのメタ情報
コンテキストメニューでは、クリックが発生した要素を常にコンテキストとして使用しているとは思いません。これは、cellをクリックしているテーブルでは少しトリッキーですが、コンテキストをセルを含む行にしたい場合があります。親行だけでなく、親行のグループの場合も同様です。
ユーザーがテーブルを「リスト」として理解する場合、コンテキストはより意味があります。ここで、アイテムはたまたまそれぞれにいくつかのデータを持っています。これが「真の」表であり、行と列によって形成される関係がある場合は、あまり意味がありません。
この状況では、あなたが述べたようにグリッドの上部と下部に表示されるツールを選択します。選択が行われたときにそれらが表示されたまま（粘着性のあるヘッダー/フッター）であることを確認するために、いくらか洗練されています。