Intuitive "Popup" Scrollbars

[Dylan McCall]

> Maybe scrolling itself could be sacrificed. What if we use the scroll
> wheel like this: when you scroll down, actual scrolling down will
> start, and will increase in speed if you keep turning the wheel. It
> will only slow down, and eventually stop if you scroll up again. The
> same goes for scrolling in the upward direction. Sort of like the
> middle-click scroll behaviour in Windows, only without the clicking,
> and using the scroll wheel instead.
> 
> Middle-click can then continue to be used like it is used now.
> 
> Remco

We should remember that not everybody has or uses a scroll wheel and
that scroll wheels are an RSI nightmare.
That said, I like this thought of yours. It would solve a bit of that
RSI problem, although may not fit well with every wheel out there. Keep
in mind that newer mice are removing the 'clickiness' and instead going
with an approach where the wheel glides very smoothly. Thus, we get a
similar effect happening in two places at once. Not that this is
impossible, but it would need some fiddling˙

Speaking of repetitive strain, some of the comments to that blog post
caused extended sessions of face-palming. There are two groups here I
must single out:

-Those who say touch screens are the future, thus this is irrelevant
-Those who say scroll wheels are all people need, thus scrollbars should
be abolished

As well as what I just said, scroll wheels are also really not that
commonly used amongst general users. I see many people using the scroll
bar, just as only power users really use hotkeys. (Much to our horror
when waiting for some peoples' workflow...).

Touch screens, on the other hand, are begging for a feature like this.
The fact is, our current interfaces have a lot of scrollbars. As anyone
who has encountered HP's TouchSmart PCs will realize, beneath the shiny
finger-friendly interface is the old fashioned mouse and keyboard
interface. Yes, it uses scrollbars and small buttons. Those scrollbars
are literally unusable; the targets at top and bottom are way too small
for fingers. (Looking forward to that size by units patch for GTK!).
This solves the issue by essentially raising the clickable area of the
scrollbar to be the entire thing. While it does conceal that page up /
down functionality, I think it is a worthy sacrifice for streamlining
the rest. Having too many buttons in one place causes problems, hence
the scrollbar's present sad state.

Not that I mind the thought of kinetic scrolling in addition. I think we
are in a neat spot for that, since GTK has always used a scroll area
container. In theory, it could grab unhandled mouse events to do kinetic
scrolling when the user clicks on the child window. (Which, if I recall
correctly, is what Matchbox does for moving windows; it can be done when
the user clicks anywhere within).

Suffice it to say, scrolling is a big thing and it's great that we have
such a flexible UI toolkit. It would be fun to put that flexibility to
the test.


Bye,
-Dylan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <https://lists.ubuntu.com/archives/ubuntu-devel-discuss/attachments/20080815/81e31867/attachment.sig>