Kirill Grouchnikov's Blog

Improving the user experience with scroll bars

One of the more interesting UI rules is the Fitts' law that estimates the time that it takes to complete a movement to a specific UI target. One of the consequences of this law is that if you have a small target located far away, it will take a long time to target it. One option is to make the target bigger, and another option is to make the target closer.

One of the examples of more "problematic" UI target are the scrollbar buttons. They are usually quite small (12-16 pixels) and are situated on the opposite sides of the scrollbar. We can pretty much rule out the option to make them bigger, so we're left with making them closer. Apple's scrollbars "fix" address this issue by putting the scroll buttons together (see the screenshots at this HIG topic.

Now you can get the same and more in the latest drop of Substance 3.1. The SubstanceLookAndFeel.SCROLL_PANE_BUTTONS_POLICY client property specifies the location for scrollbar buttons. The value should be one of the SubstanceConstants.ScrollPaneButtonPolicyKind enum. Available values:

• NONE - no buttons are shown.
• OPPOSITE - the default policy. The decrease button is on one side of the scroll bar, the increase button is on another side of the scroll bar.
• ADJACENT - the decrease button is right next to the increase button of the scroll bar.
• MULTIPLE - the combination of two. There are two decrease buttons, one on each side of the scroll bar (one of them is right next to the increase button).
• MULTIPLE_BOTH - Two pairs of decrease / increase buttons on each side of the scroll bar.

The following screenshot shows horizontal scrollbar under different policies and orientations. The first scrollbar is under the default OPPOSITE policy. The second scrollbar is under the ADJACENT policy in LTR application. The third scrollbar is under the MULTIPLE policy in LTR application. The fourth scrollbar is under the ADJACENT policy in RTL application. The fifth scrollbar is under the MULTIPLE policy in RTL application. The sixth scrollbar is under the NONE policy. The seventh scrollbar is under the MULTIPLE_BOTH policy.

The following screenshot shows vertical scrollbar under different policies. The first scrollbar is under the default OPPOSITE policy. The second scrollbar is under the ADJACENT policy. The third scrollbar is under the MULTIPLE policy. The fourth scrollbar is under the NONE policy. The fifth scrollbar is under the MULTIPLE_BOTH policy.

Thanks for the comments and suggesting the NONE and MULTIPLE_BOTH policies. Thanks to Romain for his suggestion to make the default gradient painter less dark.

Comments

• RISC OS used the alternate mouse button to reverse the direction of effect of clicking on arrow buttons. Much easier to use and not as ugly as putting opposing buttons together. However, if you've got an obscure L&F, you can't really change the feel part.

  But I'm with Cedric, in that there isn't much point in clicking on these buttons any more. I think you might as well remove them and narrow the scroll bar to waste less space.
  

  Posted by: tackline on September 14, 2006 at 12:53 PM

• Interesting... Perhaps i should add one more NONE mode that will not show any buttons.

  Posted by: kirillcool on September 14, 2006 at 01:05 PM

• I think NONE would be a good addition, and also BOTH, which would place both buttons at each end (i.e. 4 buttons visible). Actually, I think this is what MULTIPLE should do, having 2 buttons at one end and 1 at the other just seems like arbitrary wierdness to me.

  Posted by: iphillips on September 14, 2006 at 01:38 PM

• Hey! How about placing these buttons right into the scrolling button? :-)

  Posted by: euxx on September 14, 2006 at 05:00 PM

• euxx,
  Do you mean placing them on the scroll thumb itself? What will it give if you're already over the thumb and can just move it?

  Posted by: kirillcool on September 14, 2006 at 05:05 PM

• tackline,
  Scrollbar width is controlled by the "ScrollBar.width" entry in UIManager - so you can set it to anything you want. The LAF implementation should respect this setting and adjust the size of scroll buttons (and the scroll arrows) accordingly.

  Posted by: kirillcool on September 14, 2006 at 05:17 PM

• I've always wanted a 2 and 2. The 2 and 1 always frustrates me, and I really like having the 2.

  Posted by: trcorbin on September 15, 2006 at 07:01 AM

• Can the Scrollbar.width thing be set on the command like, -DScrollbar.width=20 or something like that?

  So I can modify a running program w/o access to the code?

  Posted by: trcorbin on September 15, 2006 at 07:02 AM

• I'm curious about user tests. I can see how these would be logical to me. I wouldn't have to change a single habit by relying on just the "none" method & my "pgUp" / "pgDwn" keys.

  Has anyone done any tests to see how general users react.? I'd really like to develop with the "none" policy.

  ~The Scuba Skipper

  Posted by: jeditdog on September 15, 2006 at 07:48 AM

• tcorbin - that's why you have UIManager to manage all (few hundreds) of UI-related settings. The 2+2 have been added per your request.

  Posted by: kirillcool on September 15, 2006 at 11:48 PM

• WOW, thanks! I really like that flexibility.

  Posted by: trcorbin on September 17, 2006 at 07:03 AM

This work is licensed under a Creative Commons License.