私たちは Web アプリケーション (「単なる」Web サイトではなく、機能的には実際のアプリケーション) をプログラミングしており、次のリリースについて次のような議論があります。
したがって、この問題の長所と短所について、ベスト プラクティスのガイドライン、信頼できる情報源からの声明、コーディングの議論など、「より堅実な」議論を探しています。 ...
アプリケーションをイントラネットで実行する場合、おそらく UI デザイナーの引数は有効です。アプリケーションのすべてのユーザーがよく知られており、Windows アプリケーションをエミュレートしたい場合は、右クリックを制限しても問題ないと思います。またはその他の入力。これは、他のアプリと同様に、このアプリケーションの要件にすぎないためです。
しかし、アプリケーションをインターネットで実行する場合、右クリックを無効にしたり置き換えたりするのは非常に悪い考えです。
まず第一に、ユーザー インターフェイスの動作を変更することは攻撃的で煩わしいものです。サイトにアクセスするためだけに「新しいコントロール」に慣れることは誰も望んでいません。つまり、右クリックが何をするかを知っていて、常に同じことをしたいのです。
Windows アプリと Web アプリの違いは理解できるので、「Windows アプリの動作をエミュレートする」必要はありません。
誰もが Windows を使用しているわけではありません :-)
また、Firefox の設定や、このような特定の JavaScript 命令を無効にするプラグインなど、この動作を上書きする方法がいくつかあるため、これは無効です。
視聴者によっては、ユーザーが右クリック メニューがあることさえ知らない可能性が非常に高くなります。したがって、これを唯一の選択肢にしないでください
私が使用する引数（劇的な効果のために引用符で囲みます）：
他の妨げのない Web インターフェイスと比較して、一貫性の欠如と機能の低下は、ユーザーの信頼の喪失につながります。これは控えめに言っても望ましくありません。
もちろん、多くまたはほとんどの Web アプリケーション ユーザーが既に Windows アプリに精通しているか、常連のユーザーである場合、UI デザイナーは正しい方向に進んでおり、Windows アプリとの一貫性が勝者になる可能性があります。
とはいえ、私の意見では、Web ページ内でカスタム コンテキスト メニューを直感的にするのは難しいです。一部のユーザーはそれに好意的かもしれませんが、ほとんどの人はおそらくそれを使用しないと思います。
Web アプリを (既存の) Windows アプリに近づけたいからです。
Windows アプリで右クリックするのはよくないと思います。
Web ブラウザーでは、誰もそれを予期していないため、UI の惨事です。
コンテキストメニューをブラウザのクロムの一部として認識するかどうかによると思います。もしそうなら (そして私はこの見方に帰する)、それは目標から外れているはずですが、それ以外の場合は、アプリケーションに使いやすさを追加するのに適した場所です。
GUI の特定の領域のブラウザの右クリック コンテキスト メニューを Web アプリケーションから置き換えると、非常に便利です。コンテキスト メニューを無効にするためだけにこれを行うと、ユーザーはそれを回避する方法を見つけようとする可能性があります。また、アプリケーションの全領域からブラウザの右クリック コンテキスト メニューを削除または置換すると、通常は煩わしく、デバッグがより困難になる可能性があります。
残念ながら、私はこれ以上確固たる議論を提供することはできず、どちらの意見も正確に受け入れるわけではありませんが、Web アプリケーションの開発者として、また Web ユーザーとしての私の経験を共有したいと思います。