Rethinking scrolling
The way scrollbars work is pretty inefficient - especially for novice computer users. They offer three (!) methods for scrolling relative to the current position and none of them offers comfortable scrolling speed for all document sizes.
The arrows in the corners are very small compared to the scrollbar's overall size and they are too slow in most cases. Still, a lot of people use the arrows to scroll rather large distances in a document.
The scroll thumb (slider) is too small in big documents and requires too much aiming although it is the fastest and - for moderately-sized documents - a sufficiently accurate way to change your relative position. For very big documents this way of scrolling becomes nearly useless because it moves areas bigger than the visible region.
Scrollbar basic lookA third alternative is to scroll page-wise by clicking on the non-highlighted area. This is often too coarse-grained and sometimes collides with the thumb which may suddenly appear under the mouse cursor, so you have to adjust your mouse position to continue scrolling that way. Inexperienced users sometimes click on the non-highlighted area to quickly get to a specific location.
The following proposal should be more effective, but it requires an initial training phase because it's different from the current way of scrolling.
The arrows at the top and bottom are not buttons, anymore. Also, they are bigger to make it more obvious that they are part of the scrollbar background. The scroll thumb lights up when the mouse is moved anywhere on the scrollbar (not just the knob). The general appearance of the scrollbars is very similar to that of the current mainstream operating systems.
Left-click scrollingPress and hold the left mouse button on any place on the scrollbar and you get into relative scroll mode. To clarify, you can click on the thumb, or on the arrows, or anywhere else on the scrollbar and it will have the same effect. By moving the mouse you can scroll a proportional amount of screen area in the same direction. The mouse movement causes the thumb to be moved at comfortable speed which is independent of the document size. Mouse movement has no effect on the cursor's position (i.e.: it works as if you could move beyond the screen borders).
Right-click scrollingRight-click (tablet users will prefer ALT+left-click) on any place on the scrollbar and you immediately jump to that location in the document. By keeping the mouse button pressed and moving the mouse the thumb will move directly with the mouse pointer as if you had right-clicked there.
When moving the mouse over a scrollbar the cursor becomes a double-arrow (up/down or left/right), so it becomes more obvious that by left-clicking you can move the scroll knob.
Pressing ESC with the mouse button held will bring you back to the last position before scrolling.
This proposal has the disadvantage that the right-click scrolling function is non-obvious and users would have to learn it, so it's not perfect and it could need more work.
Comments
Re: Rethinking scrolling
I really like your right-mouse-button idea. After reading your description, I played around with different mouse buttons on the scrollbar in my window manager, KDE. Apparently, the MMB works the way your proposed RMB function would work. It's a neat function, and I wish it were the primary one.
In fact, I think that should be the primary function in your setup too, rather than the secondary one. The reason for this is that "absolute scrolling" can be used anywhere, and only becomes difficult in very large documents, in which case its usefulness is limited by the user's own dexterity. For these cases, we need a special function: your proposed "relative scrolling."
As a primary function, relative scrolling is likely to feel limiting (it would be as if the scrollbar had only up and down buttons). We don't want the user to have that impression.
I think we can make the transition to the new scrollbar style even easier for the user if we keep the scroll buttons. That way, anyone who knows how to use scrollbars in other operating systems can use them here. With this setup, nothing is lost if you haven't ascended the learning curve. It just feels like a normal scrollbar. Learning to use the RMB function (relative scrolling) will help the user, but they won't feel like they're missing something without it.
I've said a lot here, and I'm trying to be as clear as possible, but I'm sure it looks better in my head than it will in yours. Push back, ask for clarification, correct me, disagree, whatever. Give me some feedback.
Re: Rethinking scrolling
Our developers liked the right mouse button idea, too, so it is already implemented in Haiku. You can test it. Never noticed? :)
Making absolute scrolling the primary function can be very frustrating because you just don't get enough precision and for relative scrolling you'd have to aim very well. Absolute scrolling is only useful when you know where to look (e.g.: somewhere in the middle of the document), and how often is this the case? Most of the time you adjust your position relatively (reading an article, quickly scanning through a document, etc.).
Also, what if you're a newbie and don't get that the right mouse button is for relative scrolling, esp. when viewing a large document?
BTW, this article describes a slightly older concept. I'd like to have "panning" (try middle-click in IE, Firefox, and Opera under Windows to get a similar function). IOW, the farther you move the mouse from the start position the faster you scroll.
You could scroll very fast by moving the mouse pointer out of the visible screen area (well, the mouse pointer shouldn't be visible while scrolling).
Also, under Windows panning is often too sensitive. By decoupling the mouse from the screen while panning you should get comfortable sensitivity and fast scrolling all-in-one. At least, that's the theory. ;)
Update: You also forgot that the goal of this article is to make scrolling more efficient. Absolute scrolling always requires good aiming which is very time consuming. With relative scrolling you can click on any place of the scroll bar (almost no aiming required, esp. if the window borders disappear when docked on the screen borders).
Re: Rethinking scrolling
Heh, no, I never noticed. Still, that gives us two absolute scrolling functions, and no special relative scrolling function. The panning idea is a good one; I think current implementations could be greatly improved upon by adding a decent sized deadzone. Without that, it's difficult to stop or avoid scrolling left and right. Sensitivity could stand to be decreased as well, as you mentioned.
As for being more efficient, well, I was arguing that the absolute method was more efficient. I've been forcing myself to use the scrollbars (I usually use the scrollwheel), and now I think you're right.
With relative scrolling you can click on any place of the scroll bar (almost no aiming required, esp. if the window borders disappear when docked on the screen borders). [bold added for emphasis]
That is extremely useful, especially with maximized windows. Example: In windows, if you maximize a window, your scrollbar is squashed right up to the edge of the screen. Jam your mouse over to the side, and you can't miss it. Haiku definately needs to do that. The window manager I use (KDE) doesn't, and it's annoying as hell.
I would argue that Fitts' law should be applied in other places as well, but that's not really relevant here.
Re: Rethinking scrolling
Heh, no, I never noticed. Still, that gives us two absolute scrolling functions, and no special relative scrolling function.
Two absolute scrolling functions? Note, the scroll thumb would be no clickable control. I.e., you can't move it up or down, clicking it results in the same behavior as when clicked anywhere else on the scroll bar. Right-click would be the only absolute scrolling function.
Re: Rethinking scrolling
I was talking about what we currently have.
Re: Rethinking scrolling
Maybe one could use the page metaphore as in a wordprocessor: if the document is larger than the window size, you get as much pages as a multiple of the window size.
The scroll bar is about the page*, and the arrows are like page-down/up. At top/bottom of a page, one displays a bit of the next/previous page.
Beside that, one could use a navigation window to pan the document. Usually that requires some dexterity but, the navigation window could show as well the page breaking, hence one could just click on a page to get it.
By this way, I think that we'll need no more horizontal scrolling and the best place to display the navigation window is at top-left (more generally at the starting point of the reading). Otherwise, if one has to pan horizontally, the snap could hide what one really wanted to read. This is a little bit disturbing but not a big annoyance.
*it's a contradiction, which comes from my habit to use the scrollwheel. Anyway, one needs to scroll a given page: when one reads a text, sometimes one rather likes to bring up the lower lines or the next paragraph to the eyes rather than moving our eyes and neck; or if one arranges horizontally two windows, that's better to scroll a page than passing through several pages. So, the window size isn't the sole referential.
All that becomes easy with a scrollwheel which solves some of the problems mentionned in this topic, at least for the vertical scrolling.
To stay simple, I'd keep the conventional scrollbar and let the page metaphore in the navigation window.
Re: Rethinking scrolling
Waldemar, I think the behavior you propose is simply perfect, but I'm not sure all of the visual cues are really necessary. Try implementing the click-anywhere-for-relative-scrolling part, and see how that works out. Since the right-click is already implemented, it won't be too big a change from what we already have. The arrow buttons are a legacy thing that should be obsolete now that everybody is used to mouse wheels.
Re: Rethinking scrolling
This could probably be implemented as an alternative to the existing scrollbars, just change a preference and get the new behavior. If it's liked it may even be changed to a default.
Re: Rethinking scrolling
Сheckout this scrollbar idea, the text is russian, but pictures makes it pretty obvious.
http://www.visualpharm.ru/articles/scrollbar.html
Re: Rethinking scrolling
One thing I'd like to add: I wish scrollbars didn't have a "jump off point". Currently, if you move a little too far off the scrollbar while scrolling with mousebutton down, it stops scrolling and the page jerks back to the point where you started scrolling. This is very annoying.
I suggest that there is no "jump off point". Obviously, if you've still got the mousebutton down, you still want to scroll. There is absolutely no reason to stop and jerk the page back.
Re: Rethinking scrolling
I beg to differ on two accounts:
1. I just tried StyledEdit and Tracker and there's no "jump off point".
2. I wish there were a "jump off point". Say, you're reading a large document and want to quickly scroll down to the end to quickly look something up and then continue reading where you left off.
With a "jump off point", you just keep the mouse button pressed, scroll down, find the thing you were looking for and move the mouse outside the "jump off point" and release the button. Bang, back where you left off. Now, once you've started scrolling, there's no going back.
Re: Rethinking scrolling
1. Hey, you're right! There is a "jump off point" in Firefox and I (foolishly) assumed that was the standard. (...thankfully, it's not)
2. Is that how you're supposed to use that "feature"? I never want to scroll to the end and jump back to where I left off. Say, you're reading a large document and you actually want to read all of it. I don't know about you, but when I'm scrolling I look at the page, not the scrollbar. If there is a "jump off point", you have to be extra careful and keep looking back to the scrollbar to make sure you're not too far off it. If you do "jump off", you have to move back to the scrollbar and then try to find out where you were when you were rudely jerked back to where you started. In a large document, this can be very annoying.
Re: Rethinking scrolling
I never had a problem with the behaviour. When I'm scrolling I also keep my eyes on the document. When the "jump off point" is reached, I see that by the document jerking back to the starting point. I know that I left the scrolling area (which of course mustn't be too small). Without thinking about it, I move the mouse horizontally to the right (experience taught me I always move out the scrolling area on the left side, probably normal for every right hander), and I'm back scrolling where I left off.
I find that quite handy when reading e.g. a user manual which at one point makes a reference like "A bit further down we learn XYZ...". I can quickly sneak a peek.
As long as the scrolling area up to the "jump off point" is large enough, it shouldn't bother your usage.
All this just in case anyone considers to implement this bug/feature. :)
Re: Rethinking scrolling
Hmmm. Maybe I misunderstood you a bit. To clearify: when reaching the "jump off point" the document jumps back to the position you started scrolling. But as long as you keep the mouse button pressed, you'll jump back to the position you "jumped off" when you re-enter the invisible scroll area around the scrollbar.
At least that's the behaviour that I'd consider useful.
Re: Rethinking scrolling
Hmmm. Maybe I misunderstood you a bit. To clearify: when reaching the "jump off point" the document jumps back to the position you started scrolling. But as long as you keep the mouse button pressed, you'll jump back to the position you "jumped off" when you re-enter the invisible scroll area around the scrollbar.
Yes, but only if you re-enter at the same vertical position you left. If you re-enter above or below that point, you're at a different part of the page. That's what makes it really annoying. First, you get the shock of the page jerking back, then you have to carefully move the pointer exactly horizontal so you don't miss the spot you left. If you're a little too high or low when you re-enter, you've got to scroll around to find your spot again.
I don't consider that useful. (...in fact, I consider it "user hostile")
Re: Rethinking scrolling
I was just wondering if anything speaks against locking the vertical position of the mouse pointer while dragging the scrollbar. That way you'd re-enter at the left off point.
Oh, oh, oh... Now, thinking about the other thread dealing with aborting drag&drop operations, maybe it'd be best if we leave all as it is (yeah, thought you'd like that... :) ) and have ESC cancel the scrolling and jumping back to the starting point.
I'd like that.