Linked by Thom Holwerda on Thu 10th Dec 2009 19:52 UTC
Graphics, User Interfaces For as long as I can remember, I've been having issues with scrolling in Windows and its applications. When scrolling via dragging the scroll blob, it seemed as if Windows had the annoying habit of randomly resetting your scroll blob to its starting position, which irritated me to no end. It took me a while to figure out, but I finally know when this behaviour occurs - now I just need to know: why?!
Thread beginning with comment 398908
To read all comments associated with this story, please click here.
Scroll bar details
by dpJudas on Thu 10th Dec 2009 21:10 UTC
dpJudas
Member since:
2009-12-10

In Windows, applications call a function that sets the range of the scroll bar and that range consists of a line length, page length and a document length.

The scroll bar itself consists of 5 distinctive areas: up button, up track, thumb, down track and down button (for a vertical scroll bar).

The up and down buttons moves the scroll bar position by the line length.

Clicking on the track moves the position by the page length. If you hold down the mouse button, it starts to continuously scroll the position by the page length.

Dragging the thumb allows you to move to an exact position.

To allow you to abort your movement operation you can move the mouse cursor outside a certain area. This behavior is consistent with other controls, such as a push button where you can press down a button and then regret your click by moving the cursor away from the button and release your mouse button.

The thumb itself is supposed to present a page in the document. A page in this regard is not a physical page, but rather how much is visible on the screen. Therefore, your 'arbitrary jump up/down' when you click the scroll track actually equals to pressing Page Up and Page Down on your keyboard. In the same manner, the buttons equal to pressing Arrow Up and Arrow Down in a scrolling scenario.

About the position of the buttons, that is mostly taste in my opinion. It is true that having them grouped together is technically better, but visually I find the Windows position of the buttons prettier. In any case, if the application requires you to actually click these buttons, the UI is already in big trouble with regard to usability. I've never had to click such scroll buttons in all the time I've used Windows. YMMV. ;)

Reply Score: 8

RE: Scroll bar details
by sbenitezb on Thu 10th Dec 2009 21:27 in reply to "Scroll bar details"
sbenitezb Member since:
2005-07-22

To allow you to abort your movement operation you can move the mouse cursor outside a certain area. This behavior is consistent with other controls, such as a push button where you can press down a button and then regret your click by moving the cursor away from the button and release your mouse button.


But a button activates an action, so there must be a way to cancel the action from being triggered once you already pushed the button. The scrollbar acts really different. Consistency just for the sake of it is dumb. It's normal that when you drag the scroller your hand move away from the vertical bar, as the hand is optimized for horizontal movement through an arc, not vertical movement. And when you are focused on reading some text, your mind is telling your hand to follow the eyes, so it deviates from the scroller position. The way KDE (just as an example) does it is more correct, as I can drag the scroll bar and move the pointer around the screen and it doesn't reset the scroller position. I believe the way Windows implements it is more a limitation of Win32 controls than pursuing consistency.

Edited 2009-12-10 21:30 UTC

Reply Parent Score: 1