私はウェブベースの医療記録システムに取り組んでいます。以前のバージョンでは、メインの水平メニューはExtJSを採用していました。標準のクリックを使用して、ExtJSにあるサブメニューを表示しました。これをホバー表示に変更するか検討中です。確かにホバーはWebサイトでより一般的ですが、一部のWebアプリはデスクトップアプリのクリックによる表示モデルに従っています。
私は hoverに関するユーザビリティの懸念の一部 について読みましたが、うまくいっているようです(つまり、トンネルの問題を回避するためにhoverIntentまたは他のプラグインを使用しています)。より速く。
ドロップダウンにホバーを使用しない理由Webベースのアプリケーションの場合?ある方法が他の方法よりも優れていることを示す定量的研究はありますか?
モバイルデバイスを考慮していなくても、タッチスクリーン付きの新しいデスクトップの販売が増加しているため、マウスは保証されたユーザー入力デバイスとしての完全な優位性を失っています。開発途上国の田舎の診療所でさえ、マウスだけのインターフェースを備えているとは思えません。インドは、特にこれらの分野で大きな売り手になる可能性のある安価なタッチテクノロジーをリードしているからです。
http://www.bbc.co.uk/news/world-south-asia-10740817
したがって、最も簡単な回答と将来の証明のために、ホバーメニューはナビゲーションが少し速くても、ホバーメニューに依存しません。エンドユーザーが利用できるものを信じるには、あまりにも多くの時間がかかります。
単純な理由でホバーメニューに反対しています。誤ってアクティブ化される可能性があります。たとえば、SEの場合、マウスポインターを1つの場所に置いて、下方向キーを使用して下にスクロールすると、ホバーがアクティブになることがあります。したがって、予想されるテキストや画像を表示する代わりに、ホバーされたものを何でも表示しています。
「私の唯一の」例外(私の頭に浮かぶ)は、インプレースのホバーです。たとえば、ポインターがその上にあるときに色が変わるコマンドボタンです。より多くのスペースを占めるものは、私にとってはノーノーです。
ただの意見。
考慮すべき他のことは、ホバーメニューには、ユーザーが優れた細かいモーター調整と優れたマウスを必要とすることです。これらがないと、ユーザーはメニューの使用に苦労します。
スクリーンリーダーを使用しているユーザーは、フーバー操作を行わないため、メニューが使用できなくなります。
クリックしてサブメニューを開くと、アクセシビリティに関心がある場合に移動できます。
私はインドのウェブサイトで作業していて、最近、サイトの多くの場所にカーソルを合わせたときに表示される情報を実装しました-質的調査の結果、ほとんどのユーザーが機能を完全に見落としがちであることに気付き、戻ってきましたホバーせずに情報を表示します。
したがって、開発途上国の農村地域で使用するアプリケーションを開発している場合は、ホバー機能を使用しないことを強くお勧めします。コンピューターの識字率は非常に低いレベルです。インドのような国では、ティア1またはティア2の都市のユーザーでさえ、ほとんどがサイバーカフェからWebにアクセスしているため、非常に低速な接続で古いデスクトップを使用していることがわかります。ホバーは、ユーザーが見つけるのに十分な速さでロードされない場合もあります。