非常に長いドキュメントの縮小するスクロールバースライダー
Word 2007で非常に長い文書に取り組んでいますが、文書内を移動するのが難しくなっています。ええと、見出しなどでナビゲートできますが、スクロールバーのスライダーに焦点を当てましょう。
問題は、ドキュメントが長くなると、スクロールバーのスライダーが小さくなることです。それには明らかにいくつかの欠点があります：
- マウスポインターでキャッチするのは困難です。
- キャッチすると、小さな動きでも、探していたものを確実に追い越してしまいます。
一方、唯一の利点は、ドキュメントの長さの手がかりになることです。これは、スクロールバーの目的がナビゲーション用であることを考えると、あまり役に立ちません。
私はUIデザイナーではないので、あまり知りません。 Apple、Adobe、およびその他のグラフィックスソフトウェアのメーカーは、ユーザーが大きな紙をナビゲートするのと同じくらい自然にコンテンツ領域をパンできるようにすることで、これに関して良い仕事をしたことを私は観察します。
まあ、私はスクロールバーがしばらくの間ここに留まると思います。これに対する私の考えは、スライダーをキャッチするのに十分な大きさに保ち、ドキュメントの長さに応じてスライドの応答を調整して、オーバーシュートを最小限に抑えることです。この問題に対処するために、UIデザインコミュニティでは他に何が行われましたか？
スクロールバーデザインの妥協
MS Windowsでは、スクロールバースライダーの最小サイズは約10ピクセルです。マウスは、熟練したユーザーが約1ピクセルの精度までドラッグできるように調整されています。したがって、スクロールバートラックのピクセル数が、スクロール先のコンテンツのペイン数に等しい場合、スクロールバーはドラッグスクロールに使用できなくなります。たとえば、高さ1000ピクセルのスクロールペインがあり、990ピクセルのスクロールバートラックがあり、コンテンツの行ごとに20ピクセルあるとします。次に、ユーザーがドラッグしてスクロールできる最大のドキュメントは（1000/20）* 990 = 49,500行です。この時点以降、ユーザーはスライダーを任意のコンテンツにドラッグできなくなります–オーバーシュートは避けられません。彼らができる最善のことは、一般的な近所にドラッグしてから、比較的細かい調整のために他の手段を使用することです。実際には、ドキュメントがこの制限の約半分になると、スクロールが困難になります。
従来のスクロールバーでは、スクロールバースライダーのサイズをいくらか小さくする必要があります。これは、マウスをそこに移動しやすくすること（フィッツの法則）とできるだけ多くのトラックを残しておくことの間のトレードオフであり、これにより、ドラッグする精度を決定できます。場所なので、トレードオフがあります。これは、スクロールバーを使用してドキュメントのサイズとユーザーの相対位置をコーディングしていない場合でも問題です。極端に言えば、最小スライダーサイズをペインの半分（例では500ピクセル）に増やすと、トラックに残っているピクセルは500ピクセルになり、最大ドキュメントサイズはドラッグスクロールで25,000行になります。
スクロールバーの動作を変更しますか？
スクロールバーのゲインを下げることをお勧めします。トラックの長さ全体をドラッグしても、ドキュメント全体がドラッグされるとは限りません。代わりに、スライダーの動きの各ピクセルは常に1ペインのコンテンツより少ないため、ユーザーは常に1ペインの精度までドラッグできます。ただし、これにより、ナビゲーションに重要なサイズと位置のフィードバックが削除されます。ドキュメントのサイズとユーザーの位置を表示することは、ナビゲーションと関係があります。どこに行くか、ユーザーがどこにいるか、どこまで行けるかを知る必要があるため、スクロールバーのコードにこの無関係な情報は考慮しません。位置コーディングは、長いドキュメントでは特に重要です。小さいドキュメントのスライダーサイズを大きくしても、ドキュメントのサイズを示すだけでは不十分です。また、可能な場合はスクロールを高速化できます。スライダーを使用するほうが簡単で、ドキュメントの一方の端からもう一方の端に移動するまでのドラッグが短くなります。ゲインを下げると、スクロールバーの「ビューポート」のメタファーが壊れ、ユーザーを混乱させます。スライダーを下または上にスクロールするとどうなりますか？途中で「ポップバック」しますか？それは奇妙で、繰り返しドラッグするためにユーザーが常にスライダーに戻る必要がある場合に制御するのは困難です。
一方、私はこのようなものを分離したコントロールがに追加された（= /// =）追加の可能性があるペインのスクロールバーにとして見ることができましたたくさんのコンテンツを表示します。私はそれをサムホイールのように見せて振る舞い、役に立つ比喩を作り、スライダーにホーミングするという問題をまったく排除します。ユーザーはペインに沿った任意のポイントからドラッグできます。 「運動量」で速度に敏感にして、遅いドラッグよりも速いドラッグが遠くまでスクロールできるようにすることもできます。私にとっては、HCIの修士論文のようです。
最小サイズを増やしますか？
TPTBが現在の最小スライダーサイズをどのように決定したかはわかりませんが、画面が小さくなったとき、それは確かに何年も前に行われました。今日の画面では、マウスのスルー距離が大きくなり、トラックサイズが大きくなっています。これにより、マウスのホーミングとドラッグの精度の間の最適なポイントを変更することが期待されます。最小サイズを大きくした方がいいと思います。上記の例では、最小サイズを4倍の40ピクセルにすると、マウスの原点復帰時間が最大29％削減されますが、最大ドキュメントサイズはわずか3％しか削減されません。
その一方で、小さなスクロールペインがいくつかあり、おそらく常に表示されます。たとえば、私のコンピューターでは、Windowsフォルダーオプションの[ファイルの種類]ペインの高さは115ピクセルで、各行は17ピクセルです。スライダーの最小サイズを10ピクセルから40ピクセルに増やすと、使用可能な最大行数が710から507に減少します。これは、許容できない30％の削減です。スライダーの最小サイズを大きくする場合、多くのダイアログボックスを再設計（大きくする）する必要があります。ペインのサイズに応じて最小スライダーサイズを変えることもできますが、どれだけうまくいくかわかりません。ユーザーが最小スライダーサイズを認識し、それを使用して「ペグ」されているかどうかを判断しますか？研究を必要とする多くの問題。それがもう一つの修士論文だと思います。
その他のソリューション？
個人的には、この問題が従来のスクロールバーの上に構築されたエキスパートショートカットで対処されることを望んでいます。これにより、混乱や不動産の消費がほとんど増加せずに、使いやすさが向上します。たとえば、私が目にするドラッグスクロールの多くは、単に最初と最後に移動することです。 Ctrlキーを押しながらスクロールバーの矢印ボタンをクリックすると、これに影響するはずです。 Ctrlキーを押しながらスクロールバートラックをクリックすると、すぐにドキュメント内のそのポイントにジャンプします。スライダートラック内のツールチップやグラフィックコード*は、ユーザーがクリックする場所を知るのに役立ちます。精度は依然としてトラック内のピクセル数によって制限されますが、ドラッグするよりもCtrlキーを押しながらクリックして正しい領域に移動し、スライダーを上下に通常クリックして微調整する方が簡単だと思います。修士論文も自由に作成してください。
* McCrickardを参照DS＆Catrambone R（1999）Beyond the scrollbar：Evolution and Evaluation of Alternative Navigation Techniques Georgia Institute of Technology Technical Report GIT-GVU-97-19。