Compromises in Scrollbar Design
In MS Windows, the minimal scrollbar slider size is about 10 pixels. A mouse is tuned so that a skilled user can just about drag to approximately one pixel of precision. Thus, scrollbars become unusable for drag-scrolling when the number of pixels in the scrollbar track equals the number pane-fuls of content there is to scroll to. For example suppose you have a scrolling pane that is 1000 pixels high so you have a 990 pixel scroll bar track, and there are 20 pixels per line of content. Then the largest document the user can usably drag-scroll is (1000 / 20) * 990 = 49,500 lines. At and beyond this point, users can no longer drag the slider to any arbitrary content –overshoots are inevitable. The best they can do is drag to the general neighborhood and then use other means for relatively fine adjustments. In practice, it becomes difficult to scroll when the document is about half this limit.
With a conventional scrollbar, you have to have some minimum size for the scrollbar slider, and it’s a tradeoff between ease of homing the mouse to it (Fitts Law) and leaving as much track available as possible, which determines how precisely you can drag to a location, so you have a tradeoff. This is an issue even if you’re not using the scrollbar to code the document size and user’s relative position. To take the extreme, if you increase the minimal slider size to half of the pane (500 pixels, in the example), now you have only 500 pixels remaining in your track, making the maximum document size 25,000 lines for drag-scrolling.
Change the Scrollbar Behavior?
I think you’re suggesting we decrease the gain of the scrollbar, so that dragging the full track-length does not necessarily drag the entire length of the document. Instead each pixel of slider movement is always less than one paneful of content, so the user can always drag to one paneful of precision. However, this would remove the size and position feedback that’s important for navigation. Displaying document size and user position has everything to do with navigation: to know where to go, users have to know where they are and how far they can go, so I don’t consider this irrelevant information to code in the scrollbar. Position coding is especially important for long documents. Increasing slider size for smaller documents does more than indicate the size of the document. It also allows faster scrolling when it's possible. It's easier to home on the slider, and it's a shorter drag to go from one end of the document to the other. Decreasing the gain also breaks the “viewport” metaphor of the scrollbar, which would confuse users. What happens when they scroll the slider to the bottom or top? Does it “pop-back” to the middle? That would be weird, and difficult to control with the user always having to home back to the slider for repeated drags.
On the other hand I could see something like this as a separate control included in addition to the scrollbar for panes that have the potential to display a lot of content. I’d make it look and act like a thumbwheel to make a helpful metaphor and eliminate the problem of homing in on the slider at all –the user can drag from any point along the pane. Maybe you could even make it velocity sensitive with “momentum” so fast drags scroll farther than slow drags. Sounds like a good HCI master's thesis to me.
Increase the Minimum Size?
I don’t know how TPTB decided on the current minimum slider size, but it was surely done many years ago when screens were smaller. With today’s screens, mouse slew distances are greater and track sizes are bigger, which I expect to change the optimal point between mouse homing and dragging precision. I think you can make the case for increasing the minimum size. In the example above, quadrupling the minimal size to 40 pixels would reduce mouse homing time by up to 29%, but only reduce your maximum document size by an insignificant 3%.
On the other hand, there are some small scrolling panes out there, and probably always will be. For example, on my computer, the Windows Folder Options File Type pane is only 115 pixels high and each line is 17 pixels. Increasing the minimum slider size from 10 to 40 pixels would decrease the maximum usable number of lines from 710 to 507 –a 30% reduction that’s likely unacceptable. Many dialog boxes would have to be redesigned (made larger) if we were to increase minimum slider size. You could vary the minimum slider size dependent on the pane size, but I don’t know how well that would work –do users recognize the minimum slider size and use it to judge if it’s “pegged”? Lots of issues requiring research. So I guess that’s another master’s thesis.
Other Solutions?
Personally, I’d like to see this issue addressed with expert shortcuts built on top of the traditional scrollbar. This could increasing usability with little increase in clutter or real estate consumption. For example, lots of drag-scrolling I see is simply to get to the beginning and end. I think Ctrl-clicking the scrollbar arrow buttons should effect this. Ctrl-clicking the scrollbar track should immediately jump to that point in the document. Tooltips and/or graphic codes inside the slider track* would help the user know where to click. Precision is still limited by the number of pixels in the track, but I suspect it would be easier to Ctrl-click rather than drag to get to the right area, then do ordinary clicks above or below the slider for fine adjustments. Feel free to make that a master’s thesis too.
*see McCrickard DS & Catrambone R (1999) Beyond the scrollbar: An evolution and evaluation of alternative navigation techniques. Georgia Institute of Technology Technical Report GIT-GVU-97-19.
