ホバー状態は必要ですか？
UIでホバー状態が必要かどうかについて、ここUX部門で議論しています。少し分かれています。次に2つの引数を示します。
反対（議論を開始）：
私は個人的にホバー状態を持たない傾向があります...私には、非常に限られた状況を除いて、実際には何の利点もない視覚的なノイズが追加されます。モバイルの世界から来ているので、ロールオーバーのようなものはなく、これを見逃したことも、ベーシックアイテムで利用できることを望んでいたこともありません。 PCソフトウェアは以前はロールオーバーを使用していませんでしたが、私はそれをテストしていただけで、現在は頻繁に使用されています。しかし、私はいくつかのMac YouTube Lionビデオを調べましたが、それらはホバー状態を使用していないようです。
For（最初の応答）：
簡単に言えば、はい、インターフェイスのすべてのボタンにホバー状態を設定する必要があります。そして、私は通常、クリック可能なもの（リストボックスアイテム、リンク（無料で提供されます）、およびホワイトボードノードやテーブルセルなどの他のカスタム要素）に拡張します。私も同様にこのアイデアに不満を感じます。通常、ホバー状態がまだ追加されていない場合は、強制的に追加します。
これはおかしなことですが、これは今では標準的なものであり、疑われることはありません。私が掘り下げることができるほとんどの研究は、ホバーを使用する必要があるかどうかをテストするのではなく、正しいホバー処理に関係しています。過去には使用されていなかったが、UIテクノロジーの欠陥が多かったのは当然だ。確かにユーザーが期待するだけの可能性があるため、この手法は事実上の要件となっています。さらに、ホバーがないことは、時代遅れであると思われる傾向があります。これらの理由から、ホバー状態がユーザビリティにマイナスの影響を与えるとは思わないという事実が相まって、常にホバーを使用する必要があると思います。
視覚的なノイズ成分がよく見えるかわかりません。私は常にデザイナーにプッシュして、ホバーを非常に微妙なものにします（選択した状態が何であれ、60〜80％です）。それらが正しく行われると、コントロールが何かを行うことをユーザーに視覚的にフィードバックします。また、インターフェイスがユーザーと通信するのにも役立ちます。これは、アプリケーションがリッスンしていることをユーザーに伝えるかのようです。
これが会話への私の追加です（私はプロのホバー状態です）：
特に従来とは異なるUI要素では、ホバー状態に固有の必要性があると思います。送信ボタン、リンク、リストアイテムには、クリック可能であるという期待と想定があると思います。 canvas/draggable要素などの他の項目は「自然な」UI要素ではないため、ユーザーはこれらのオブジェクトに関連付けられた基本的なアクションがあることを必ずしも認識していません。
カーソルの変更（通常からポインターへの変更）は、何かがクリック可能であることを知るには十分な識別子ですが、ほとんどの人はこの違いを理解していません。形が微妙に変化するため、視覚的には不十分です。矢じりに集中しない限り、ほとんど気づかないでしょう。
一方、ホバー状態では、脳が形状の変化よりも自然に色の変化にすばやく反応するため、視覚刺激が高くなります。
ホバー状態に関する皆さんの意見を聞きたいのですが。それらを使用しますか？いつ必要になると思いますか？それとも単に視覚的なノイズですか？
「はい」と投票します。確かに、タッチデバイスは非常に人気があるため、ホバーイベントに依存するべきではありません。ただし、ジョンはボタンの視覚的なホバー状態について質問しているようです。これは少し異なります。
視覚的なホバー状態は「クリック可能性」を提供します。ボタンかどうかを確認するために何かをクリックする必要はありません。ラップトップとデスクトップのユーザーは、「クリック可能な」ものがホバーに反応することを期待しており、「ライトアップ」ボタンがあると便利です。
プログレッシブエンハンスメント の形式と考えてください。使える人には便利、使えない人には無害！
設計ではホバー状態をできるだけ回避するようにしています。その主な理由は、タッチデバイスでは意味がないためです。
これはモバイル向けに設計していない場合は当てはまらないように見えるかもしれませんが、多くの人はタブレットや他のタッチデバイスを使用して、同じWebサイトを閲覧したり、従来マウスでコンピューターでのみ使用していたのと同じアプリケーションを使用したりします。
自分を制約するホバーイベントを使用しないようにすることで、使用しているデバイスに関係なくエクスペリエンスを向上させるだけでなく、後でタッチ固有のネイティブアプリケーションを作成しやすくなります。
タッチの出現がソフトウェアと対話するための主要な方法であるので、ホバーベースの対話は「拡張機能を備えているのが良い」に追いやられましたが、ソフトウェアと対話するための要件であってはなりません。
：focusの：hover状態を複製することがよくあります。これは、キーボードのみのユーザー（WCAG2を満たすために必要）にフォーカスを示すのに役立つ方法であるためです。これは、ユーザーがまだ開始することを決定していないアクションをトリガーするクリックイベントを必要とせずに、アイテムが何らかの形でインタラクティブであることを示しています。 ：hoverなしで：focusのスタイルを設定できますが、私の意見では、2つのアクションの意図は同じであり、実用的であればどこでも同じ視覚効果を持つはずです。
私はまた、ホバー状態はプログレッシブ拡張と見なすことができるというサムの見解にも同意します。少し明確にしたいと思います。
モバイルファーストの観点から、ホバー状態は実際には目的を果たしません。そのため、UIには、ホバー状態のないクリック可能なオブジェクトのクリック可能な動作（つまり、ボタンがボタンのように見える必要がある）の方が適しています。
モバイルデバイスでその概念をサポートできる場合、ホバー状態が導入される前beforeでも、同じ概念がデスクトップ/ラップトップデバイスでサポートされます。
ホバーをサポートするデバイス（ラップトップ、デスクトップなど）にホバー状態を含めると、特定のUI要素が実際にクリック可能であるというユーザーの既存の認識が確認されます。
要約すると、
- クリック可能なUI要素を作成して、あらゆるデバイスでクリック可能な動作を実現します。
- 要素がクリック可能であるという概念をさらにサポートするには、ホバーをサポートするデバイスでホバー状態を使用します。
デスクトップとモバイルの両方を対象に設計しているからといって、デザインが同じである必要はありません。モバイルユーザーが慣れている可能性のあるやり取りは、デスクトップユーザーには明らかでない場合があります。
たとえば、右側にキャレットがある白いカード。モバイルユーザーにとって、これは明らかにタップできるものです。デスクトップユーザーにはそれほどではありませんが（特にデスクトップでカードの幅が広い場合）、ホバーしてホバー状態を見ると、クリック可能であることは一目瞭然です。
特にアニメーションがますます一般的になっている今、ホバー状態はユーザーが意図したことをしているというフィードバックをユーザーに与える基本的なアニメーションです。
デスクトップにホバー状態を使用しないのは面倒で、人々を悲しくさせます。
プログレッシブエンハンスメントについて言及したサムに+1。
UIを強化する便利な機能がある場合はホバー状態を使用することをお勧めしますが、タスクを完了するためにneededしてはなりません。
たとえば、商品リストページでそれらを使用して、ユーザーがナビゲートする前に、画像にカーソルを合わせたときにアイテムに関する情報を少し提供します。その情報は、製品ページ自体にも表示されます。したがって、タッチスクリーンユーザーのエクスペリエンスを損なうことはありませんが、doを参照する人にとって、いくつかの追加の有用性が追加されます。 :-)
ボタンにアイコンがない場合はホバーすることをお勧めします。ボタンにカラフルなアイコンがあるとしたら、そのときにボタンにホバー状態を与えることは必須ではありません。例：Googleボタンを使用してサインアップします。
ホバーは、オンラインで適切な応答を求めているすべてのWebサイトにとって必須です。ラップトップで、ホバーステータスを破棄したいくつかのWebサイトを使用しましたが、非常にイライラしました。優れたデザイナーなら誰でも、オンラインの人々がRushにいて欲しいものを見つけていることを知っています。ボタンが1つであるかどうかをボタンが知らせず、新しいタブで開いて調べる必要がある場合、それは大きな問題です。失敗！
モバイルでは、ホバーは必要ありません。ただし、モバイルではいつでも無効にできます。さらに、モバイル用のボタンはオンライン用のボタンよりもはるかに大きくする必要があることを忘れないでください。そして、いずれにしても、それらは2つの異なるスタイルシートで作成されたのではないでしょうか。
信じられない:hover状態は必須です。デスクトップのUI要素はそれらなしで永遠に対処してきており、クリックを許可するように明確に設計されたオブジェクト（ここではUX.SEの[回答を投稿]ボタンなど）は、私の経験で問題なくテストされています。 役に立たないと言っているわけではありません;それは必須ではありません。
私はそうしますが、:focus そして特に :active必須の状態です。特に後者は、あまりにも多くのサイトで無視されているように見えます。明確なアクティブ状態は、ボタンクリックがすぐに登録されたことをユーザーに知らせるのに役立ちます（ これは、UIでオブジェクトを直接操作していることをユーザーが感じるのを助けるために非常に重要です ）。ボタンやメニューなどのシステムコントロールもすべてその状態を予期したものにしているため、それらを忘れることはさらに許されません。
ホバー状態は、問題の要素がインタラクティブであるというユーザーの期待に肯定的なフィードバックを提供し、それにより、疑問や曖昧さの否定的な感情の可能性を取り除くことをお勧めします。
設計は、要素がインタラクティブである多くのキューを提供します-形状、サイズ、位置、色、下線など。異なるキューは、おそらく異なる数のキューの累積効果を認識して（そして自信を持って）感じる必要があります。 that）要素はインタラクティブです。ホバーで要素を変更することは、より多くの手がかりを提供する機会です。
ほとんどの（すべてではないにしても）ブラウザーは、カーソルをポインターに変更することにより、デフォルトでホバーにキューを提供します。もちろん、これを制御でき、この効果を削除することでホバー状態を削除できます。しかし、私はほとんどの人にとって（想像するために少し時間をかけて）これが私たちのブラウジングエクスペリエンスに重大な疑いをもたらすと思います。ブラウザー（およびデザイナー）は、追加のキューの先例を設定しており、キューを配信しないと、要素がインタラクティブであるという以前に認識されたキューとは大きく矛盾します。
したがって、ブラウザのデフォルトのキューの削除は、ホバー状態の値の有用な例です。したがって、私にとっては、ホバー時の対話性の視覚的な手がかりが価値があるかどうかではなく、どれがどのくらいの数の手がかりが最適であるかが問題になります。
よく知られている便利な前例がいくつかありますが、この質問に対する答えは、アプリケーションと対象読者によって異なります。