web-dev-qa-db-ja.com

ネストされたスクロールバーとのマウスホイールの相互作用

ネストされたスクロールバー(別のスクロール可能領域内のスクロール可能領域)は、主にマウスホイールでスクロールすると、不幸な問題を引き起こします。

このようなスクロールバーが良いアイデアなのか、それとも避けるべきなのかについては、以前に説明しました。

この質問について、私はそのような星座で立ち往生している場合に何ができるかを尋ねたいと思います:

mockup

download bmml sourceBalsamiq Mockups で作成されたワイヤーフレーム

上記のウィンドウレイアウトは、ほとんどが固定されているとしましょう。アプリには、1つの画面には高すぎる外側の領域と、いくつかの高い内側の領域があります。ユーザーがマウスのスクロールホイールを操作しやすくするために何ができますか?

デフォルトのウィンドウのパラダイムは次のようです:

  • マウスカーソルが現在置かれている領域をスクロールする
  • その方向にそれ以上スクロールできない場合を除いて、その場合は次に高いレベルをスクロールします。

これは妥当なデフォルトですか?私の経験では、これは、ユーザーが大きな領域をスクロールしようとしたときにいくつかの不快な相互作用につながる可能性があり、そのプロセス中に小さな領域がカーソルの下に移動するため、スクロールターゲットが切り替わります。

ここでユーザーエクスペリエンスを向上させるために何ができますか?

10
HugoRune

私は何度もこの状況に陥っています。私がいつもやっていることは、アプリがカーソルを合わせた子要素をスクロールするようにプログラムし、その要素をonlyにすることです。

明確にするために、その要素をonlyと言うとき、ある要素を一方向にスクロールしていて、そのスクロールバーの最後に到達した場合、親要素をその方向にスクロールすることによってしないようにプログラムします。

親要素をその方向にスクロールすることで処理を進めた場合、子要素を「エスケープ」するためにカーソルを移動する手間が省けると主張する人もいます。これは本当ですが、スクロールされるさまざまな要素間の望ましくない上下の相互作用を引き起こすので、それはまさに私が避けようとしている状況です。

要約すると、私はアプリをプログラムして、要素を一方向にスクロールしていて、そのスクロールバーの最後に到達したときに、次のいずれかを実行するまで何も起こりません:1)反対方向にスクロールするか、2)スクロールしたい別の要素にカーソルを移動します。

ここに視覚的な表現があります:

mockup

download bmml sourceBalsamiq Mockups で作成されたワイヤーフレーム

8
Code Maverick

悪い状況ですが、古いアプリケーションを保守しているときに時々起こります。

少しわかりやすくするためにできることがいくつかあります。

  • デフォルトでメインウィンドウのスクロールバーをスクロールし、ユーザーが明示的にクリックした場合にのみ内部コントロールをスクロールします。これには、現在選択されているコントロールに関する視覚的なフィードバックも必要になるため、オプションではない場合があります。君は。
  • デフォルトの動作を維持しますが、スクロールハンドオーバーの間にギャップを導入します。これにより、ユーザーは、内側のスクロールバーが外側のスクロールの前に終了した後、マウスのホイールを少し回さなければなりません。バーが動き始めます。一時停止は、ユーザーが内側のスクロールが停止したことを認識し、外側のスクロールアクションがアクティブになる前にマウスホイールの回転を停止する機会をユーザーに与えるのに十分だと思います。
7
Franchesca

絶対にnotこれに関してデフォルトの動作を変更します。どうして?これは、OSの動作が厳格かつ一貫して定義されすぎてそれを壊すことができないというまれなことの1つだからです。今のところ、私はこの動作を壊す単一のアプリケーションを見たことはありません(ウィンドウズで実行することを意図していないか、正式にクロスプラットフォームではありませんが、現実的にはそうではありません)、非常に正当な理由が必要です。そうする。次の質問になります:あなたには非常に正当な理由がありますか?まだ、他の回答を読んでまだ聞いていません。特に、サブエリアとサイドスクロールバーの間に少しスペースを残した場合は、すぐに下にスクロールするのはニースからは遠いので、可能であれば、水平方向のスペースを作成することをお勧めします(Webで簡単、デスクトップアプリでは難しい) )、しかしそれは一貫した標準的な振る舞いを破る理由としてはほとんど十分ではありません。その点でのフランケスカの答えは、それを完全に変更するのではなく標準の動作を拡張しようとする試行ので、かなり賢明ですが、ソリューションがどれほど実用的であるかわかりません。

ここに問題があることを指摘するのが間違っていると言っているのではありません。ただし、ここでの本当の問題は、マウスホイールを相互作用させる方法ではなく、ほとんどの部分で石に設定する必要がある部分です。しかし、なぜ悪いUIが石に設定されるのでしょうか。タブを上下に並べるのではなく、タブを使用するというUser50881の提案は、たとえば有効であり、ほとんどの場合優れています。または、コンテンツによっては、他にも考えられるより優れたインターフェイスが無数にあります。ポイントは、カスタムスクロール動作(簡単ではない何か)をコード化する時間が得られた場合、UI自体を適切な提案で変更できないとは信じられません。

3
David Mulder

これは妥当なデフォルトですか?はい、小さな領域をスクロール可能にしたい場合。

ここでユーザーエクスペリエンスを向上させるために何ができますか?入れ子を取り除き、3つのタブを使用します。たとえば、コンテンツ領域1、コンテンツ領域2、残りのページ。または、ポップアップウィンドウを開くために領域をボタンで置き換えます。

箱の中に何が入っているかを詳しく知ることで、人々はより専門的なヒントを与えることができます。

1
user50881