Scrolling

Contents

Designers

Don't show mouse-based affordances when using only touch since content itself should be manipulated.
Focus the design on indication rather than manipulation for touch.
Reduce visual noise and complexity for both touch and pointer-driven UI.
Do not require reserving much space for scrollbars.
Support intra-window scrolling as well as window edge scrolling (in left panes for example).
On pointer-based devices allow manipulating bar to scroll.
On pointer-based devices allow paging up/down.

Scrolling long content using the scrollbar handle has always been very difficult. What other examples do:

Gmail combines paging with scrolling.
OS X - drag handles aren't that effective, but they have very effective touchpad/magic mouse scrolling to compensate.
Ubuntu - overlaid paging buttons.

GNOME 3.10 - a fine scrolling mode was introduced, activated with the shift key. In GNOME 3.14 the shift modifier was replaced with long press to activate. The delay for activation was increased for 3.16, due to issues with fine scrolling mode being accidentally triggered.

Alternative solutions could include:

Rely on scrollwheel/touchpad scrolling for long lists, without the aid of a fine scrolling mode (this would be helped by improvements to scrollwheel/touchpad scrolling, such as smoother and/or kinetic scrolling).
Variable scroll speed, depending on drag speed (could be linear or two-step).
Limit the range of the scrollbar for very long lists.

Show a simple handle for view position and for direct manipulation.
Should focus on indication when not being manipulated.
Should take advantage of screen edge scrolling in maximized windows (Fitt's Law).
When pointer hovers over bar:
- Show a channel to use used for paging.
- Add affordance for direct manipulation.
When dragged by pointer:
- Scroll the content view as smoothly as possible.
- Use a linear scaled scroll factor.

Scrollbars used to show the current position within a document. On touch when they can be hidden, they need to show up:
- when the document first shows up
- any time it's being interacted with (window gaining focus for example)
- even if you have a "don't show scrollbars if i don't need them" setting for non-touch
Jon thinks that could also be always visible on touch, if they are minimal enough (though they then hamper the display of the document) (@SIG)
CarlosGarnacho: I'm looking into implementing this in GTK+ with an eye on mixed input environments, where I think we want dynamic switch between mouse and touch driven approaches. The problem I mainly see is the "should/shouldn't overlap view content" dichotomy. For dynamic mode switching, and if we want to avoid relayouting the view content, overlapping scrollbars anytime makes most sense.
A users experience with our arrow-less scrollbars: http://bugzilla.redhat.com//show_bug.cgi?id=812982