web-dev-qa-db-ja.com

ドロップダウン付きのメニュー、クリック可能なルート要素?

ドロップダウンには2つのオプションがありますが、使いやすさの観点からどちらが最適かはわかりません。オプション(A)には、サービスに関する一般的な情報が記載されたページに移動する明示的な「当社のサービス」リンクがあります。オプション(B)では、このリンクはルート要素にあります。

オプション(B)は好きではありません。「サービス▼」にカーソルを合わせると表示されるハンドポインターが、リンクがあるか、ドロップダウンメニューであることがわかりません。

クライアントはリンクの名前を考える必要がないので(B)を好みます。(A)を選択した場合、ルート要素が「サービス▼」となり、「サービス」を配置するのは冗長/醜いでしょう。 「アイテム…

これを行うための好ましい方法はありますか?私は常にルート要素とサービスの両方でOur Servicesページへのリンクを持つA + Bの混合を行うことができます子アイテム。どちらの場合も、「約▼」ドロップダウンを「サービス▼」のソリューションと一致させる必要があります。

ありがとう!

Menu with link

20
doup

ここに背景問題があります:サブメニューはクリック時またはホバー時に開く必要がありますか?

  1. クリックで表示することを選択した場合、OptionA(ServiceA、ServiceB、...、すべてのサービス)のみを使用できることは明らかです。これは、タッチデバイスとノータッチデバイスの両方で一貫して機能します。

  2. ホバーで表示することを選択した場合、いくつかの競合が発生します。

    • ユーザーがサブメニューがホバーで開くことを知っていますか?速く開くので、ユーザーはクリックする必要がないことを理解しているが、ルート要素をクリックする可能性があると主張するかもしれません。 。

    • ユーザーが「マウスを離れる」とサブメニューが閉じることをユーザーは知っていますか?これは、一部のユーザーがルート要素をクリックしてサブメニューを閉じて、リダイレクトされます。

ルート要素をクリックするとリダイレクトされる唯一の状況は、サブメニューがない場合(ルート要素はリンクです)。

私はクリックに固執します。 2つのケース(クリックまたはホバー)のいずれの場合もOptionAを使用します(ServiceA、ServiceB、...、すべてのサービス)。

13
Alvaro

オプションBでは、偶発的なクリックのリスクが高すぎると思います。ユーザーがマウスオーバーでメニューが機能することを期待することはできません。これを行う。ラベルで1つの処理を実行し、矢印で別の処理を実行することもできますが、矢印の周りをクリックするためのスペースが非常に少なくなり、メニューにアクセスできなくなります。

もう1つの複雑な問題は、応答性とタッチデバイスに関するものです。メニューが変わりますか?次に、ユーザーがトップレベルをタップするとどうなりますか?これをハンバーガーなどに切り替える場合は、とにかく「概要」ページが必要ではないでしょうか。

個人的にはオプションAを選びます。ラベルは、使用を明確にするために支払う代金です。

2
Yisela

アドバイス:

  • クリックで開くと閉じる。
  • メインボタンの表現で、カテゴリであることを明確にしましょう
  • メニュー項目にリンク/目的を明確にさせる

背景:

重要なタスクとナビゲーションをホバー状態に完全に依存しないようにアドバイスします。

多くの場合、ホバー状態を利用できないのはモバイルに限られていることを前提としています。モバイルには、タブや引き出しなどのさまざまなナビゲーションソリューションが用意されていることがよくあります。

ただし、ほとんどの場合、タブレットとタッチ対応のデスクトップモニターにはデスクトップUIが表示されることに注意してください。これらは、ホバー状態が良好であるという前提で構築されることがよくあります。あなたの例では、タッチユーザーが3つのサービスをスキップすることを意味します。これは、ドロップダウンが開いて表示されることがないためです。

レスポンシブデザインは、モバイル/タッチを第一に考え、それには正当な理由があります。

さらなる洞察については http://uxmovement.com/navigation/why-hover-menus-do-users-more-harm-than-good/ をチェックしてください。

2
Tom.K

ここに私がそれをする方法があります:

メニューにカーソルを合わせます。メニューの開始をアニメーション化します。そのアニメーションが終了したら、メニューボタンのテキストをアニメーション化して、「すべて表示」のようなものを読みます。その時点で、ユーザーをすべての製品にリダイレクトするために、クリックイベントのリスニングを開始します。

  • これにより、メニューをクリックしてメニューを開くことに慣れているデスクトップユーザーは、期待どおりのエクスペリエンスが得られます(ただし、クリックしてもメニューは開かれませんが、この段階では害はありません)。また、メニューボタンのテキストを変更することで、すべての製品のページを取得するために何をすべきかを示します。

  • これは、メニューの上にカーソルを合わせることに慣れているデスクトップユーザーに、まったく同じもの、つまり期待するエクスペリエンスを提供します。

  • 最後に、それは彼らが期待しているものをタッチスクリーンユーザーに与えます。フォーカスを割り当てるためにクリックする必要があるかもしれませんが、メニューがまだ表示されていないため、最初のクリックではどこにもリダイレクトされません。

つまり、私の意見では、このソリューションは期待に反するものではなく、ユーザーがタッチデバイスを持っているかどうかに基づいて特別な実装/プレゼンテーションを行う必要はありません。

0
Altainia

私はあなたの質問に本当に感謝しており、私の経験に基づいていくつかの提案をしたいと思います。

視覚化

まず、メニューには下矢印アイコンがあるので、その下に何かがあることがはっきりと視覚化されます。その視覚化では、ユーザーが異なれば行動も異なります。より技術的なユーザーは、マウスをホバーしたときにそれが開かれるという考えを持っていますが、初心者の使用では、何かを機能させるためにそこをクリックする必要があるように感じ、私の観察に基づいてその矢印のみをクリックします。

一貫性

一貫性について話すとき、すべてのメニューにドロップダウンはありません。ドロップダウンでマウスホバーを使用すると、一部のメニューユーザーがクリックする必要があり、他のユーザーはマウスホバーを実行する必要がある場合と一致しません。

フォームファクター

あなたのアプリケーション/ウェブサイトはタッチデバイスで使用されますか?はいの場合、ホバーより上では機能しません。

推奨事項

クリックしてメニューを開くことで移動し、すべてのフォームファクターで機能し、ユーザーを混乱させないナビゲーション用のサブメニューを用意することをお勧めします。

例を確認したい場合は、Amazonがどのように実装したかを確認してください。

enter image description here

これは、オプションBで提案したものと同じです。タイトルをクリックすると、注文のページに移動し、マウスをホバーするとポップアップが開きます。

問題:主な問題はそれのUXです。ユーザーエクスペリエンスを考慮するページが完全に読み込まれた後にポップアップメニューが開くだけで、マウスをその上に置く多くのユーザーがポップアップに表示されないので、クリックして注文のページに直接リダイレクトするため、非常に煩わしいと感じます。 しかし結局のところそれはアマゾンです。選択はあなた次第です。

0
Zea Shah