After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 530413 - Popup Scrollbar
Popup Scrollbar
Status: RESOLVED OBSOLETE
Product: gtk+
Classification: Platform
Component: .General
unspecified
Other All
: Normal enhancement
: ---
Assigned To: gtk-bugs
gtk-bugs
scrolling
: 567125 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2008-04-28 18:15 UTC by thorwil
Modified: 2015-08-21 18:49 UTC
See Also:
GNOME target: ---
GNOME version: Unversioned Enhancement


Attachments
PyGTK demo of a vertical popup scrollbar (4.97 KB, application/x-bzip)
2008-04-28 18:17 UTC, thorwil
Details
PyGTK demo (19.65 KB, text/plain)
2008-05-09 07:54 UTC, thorwil
Details
PyGTK demo (19.65 KB, text/x-python)
2008-05-09 15:17 UTC, thorwil
Details
PyGTK Demo (33.83 KB, text/x-python)
2009-12-11 11:30 UTC, thorwil
Details

Description thorwil 2008-04-28 18:15:48 UTC
Please implement scrollbars that have no arrow buttons initially. The whole area allows dragging to scroll. Arrow buttons appear above and below the pointer as soon as it enters the widget. This way the buttons are always close to the pointer. The detailed behaviour is a bit hard to explain/imagine, so I made a demo with pygtk which I will attach.

Disadvantages over traditional scrollbar:
- this is not what people are used to

Advantages:
- as long as the pointer is outside: no button -> less distraction, more uniform. Especially nice if the mouse wheel is the preferred method of scrolling anyway.
- larger active area, more space to show the page/document ratio.
- faster to operate via dragging from any point (no aiming at the thumb).
- the indicator can show the actual page/document ratio down to when it becomes a single pixel tall.
- the arrow buttons are always close to the pointer.
Comment 1 thorwil 2008-04-28 18:17:20 UTC
Created attachment 110053 [details]
PyGTK demo of a vertical popup scrollbar
Comment 2 thorwil 2008-05-09 07:54:33 UTC
Created attachment 110623 [details]
PyGTK demo

Added triangle if indicator becomes very thin, fixed cursor change behaviour.
Comment 3 thorwil 2008-05-09 08:05:26 UTC
Demo video:
http://www.archive.org/details.php?identifier=popup_scrollbar
Embedded view is a bit small, please note download option on the right.
Comment 4 Calum Benson 2008-05-09 14:38:41 UTC
It's great that people are thinking up these ideas, and the video and demo show it off really well.

A couple of comments from playing with the pyGtk demo (in which there's a typo, btw... s/35/37 on line 541):

* I can't click in the scrollbar 'trough' to move one page up/down at at time, like I can in a regular scrollbar-- I guess this could be added without interfering with your concept, though.

* One feature of current scrollbars is that if you grab the handle, you know you're going to be able to scroll through the whole document.  While that's still true with your design, it does encourage the user to scroll from arbitrary points in the scrollbar.  And when I was playing with it, that meant I often found the pointer hitting the top or bottom of the screen before I'd reached the top or bottom of the document, which turned out to be surprisingly annoying!

* Subjectively, the arrow buttons seemed much harder to use than on a conventional scrollbar, because you can't just look to see where they are and move the pointer straight there, then click.  You have to move into the scrollbar, stop, see where the buttons appear, make quite a small, precise movement at right-angles onto the button, then click.  It's quite a fiddly operation, and I have to say I'd be surprised if usability testing found them to be more efficient than permanent, decent-sized scroll buttons.  (Which are still very useful for us laptop types without scrollwheels on our trackpads...)

Really neat idea, though... I think this is the sort of thing you'd probably have to do two or three usability study => feedback => design iteration cycles on, with subjects using the new designs for a reasonable period of time (i.e. more than the ~1 hour that a usability study usually lasts), before its potential impact could be properly assessed.
Comment 5 thorwil 2008-05-09 15:17:16 UTC
Created attachment 110648 [details]
PyGTK demo

Fixed the wrong filename, thanks to Calum!
Comment 6 thorwil 2008-05-09 15:28:36 UTC
On #4:

* I never found clicking in the trough to be useful. Of course that might be just me. Then again I bet that many people don't even know about it. How do you think it could be added to my concept?

* True. I think with a little practice, you start going for the indicator if you have to scroll far.

* You actually have to just enter the scrollbar and move up for the up arrow or down for down. The "virtual" target sizes extend from the buttons up/down over the rest of the scrollbar. So the only issue is side-way movement. Maybe a the popup could be kept from centering again if the scrollbar was just barely left and entered again (based on time?).


Sure, this could benefit from really solid testing. All I can do myself fo now is making noise about it ;)
Comment 7 Cory 2008-05-12 09:56:10 UTC
I use trough clicking A LOT, but the reason I use it so much is that it's such a pain to go all the way to the top or bottom of the window to use the arrows.  

I just tried the demo and I have to say I'm a huge fan.  I can scroll without having to go to a specific place on the scrollbar for the first time ever!  

I always found scroll bars to be a very poorly designed part of most GUIs and more often than not, just used arrows or page-up/page-down to scroll. Furthermore, the arrow buttons are the most useless part of the scrollbar anyway.  I want to go a whole page or smooth scroll a LOT more often than I want to go a single line up or down.

Back in the early 90s I wrote an Atari St paint program where the user interface was all contained in a pop-up icon menu that always appeared centered under the mouse cursor.  I found it extremely efficient to use because no matter where on the screen you happened to be working, all the controls were always exactly the same distance from where you right-clicked.  This is the same reason why you don't need to look at your TV remote to use it after you get to know it.  

The same principle applies here.  The arrows are always in the same relative place and if trough-clicking is implemented, it will be too.  I think a good way to implement page up/down would be to add additional 'double arrow' buttons above and below the current arrow buttons and leave the functionality the same otherwise.

I really hope this gets adopted by KDE and Gnome.
Comment 8 Calum Benson 2009-01-16 18:48:09 UTC
*** Bug 567125 has been marked as a duplicate of this bug. ***
Comment 9 Milan Bouchet-Valat 2009-05-15 13:13:52 UTC
Really nice, indeed! Don't you think you could hack the current GTK+ implementation of the scroll bar, so that people can test it in day-to-day use and report? AFAIK neither OS X nor Windows have dared to reconsider the scroll bar concept, so let's do it first!
Comment 10 kxra 2009-06-27 03:49:53 UTC
Linked to LP: https://bugs.edge.launchpad.net/bugs/253546
Comment 11 Joshua Simmons 2009-06-28 02:25:25 UTC
Might I suggest some changes with the button layout.

* Moving the up and down buttons closer together.
* Making the up and down buttons longer ( about double their current length? )
* Adding double arrowed buttons to the top and bottom of the current up/down buttons for skipping to the ends of the page.

I believe this would make it simpler to navigate, and remove to some extent the fiddly nature of hitting the up and down buttons.
Comment 12 kxra 2009-07-15 17:42:54 UTC
What needs to be done to be able to test this for GNOME 3.0? 
Comment 13 Matthias Clasen 2009-07-15 18:46:30 UTC
a) write a patch 

b) convince us that this is sufficiently better than our current scrollbars (and from the pygtk demo, I'm not convinced at all...)

Comment 14 kxra 2009-07-15 18:53:55 UTC
a) I can't do this currently since i don't know any programming, but hopefully someone else can while i learn =]

b) Anecdotal evidence isn't enough. We need to actually test it
Comment 15 thorwil 2009-12-11 11:30:06 UTC
Created attachment 149581 [details]
PyGTK Demo

You can now click in the trough to cause page-wise scrolling. Plus a couple of tweaks.
Comment 16 Erik Andersen 2010-03-29 00:59:11 UTC
Maybe to address the laptop touchpad concern you could have it so that there is a laptop mode. Everything except the buttons would work the same. The up button would have the top half of the scrollbar and the down button would have the bottom half. If you drug anywhere on the scrollbar (including the area of a button) with the LMB it would act just the same as when you drag between the buttons on the current version.
Comment 17 kxra 2010-04-28 01:57:58 UTC
This was posted to reddit and had lots of supportive comments: http://www.reddit.com/r/linux/comments/8w3z0/intuitive_scrollbars_for_gnome_30/

Is there a way this could be added as an *option* so that users can use it if they prefer?
Comment 18 Jean-François Fortin Tam 2011-05-10 01:46:00 UTC
Hey Thorwil, would you be willing to write a patch to GTK+ itself so we can test it? (note that I'm not a GTK developer so I can't promise it would get it, but I'm sure that many testers would like to have a go with it)
Comment 19 kxra 2011-05-10 01:47:34 UTC
>I'm sure that many testers would like to have a go with it

Like myself!
Comment 20 thorwil 2011-05-10 17:17:19 UTC
(In reply to comment #18)

I'm not familiar with the GTK+ code base, currently don't even recall how to write a simple loop in C and I'm not optimistic enough to invest the huge amount of time I would need for that patch. Meanwhile, Canonical are pulling through their overlay scrollbar.
Comment 21 kxra 2011-05-10 18:41:17 UTC
>Canonical are pulling through their overlay scrollbar.

...but Ubuntu's implementation seems to be quite different than this, no? Not intuitive at all as in the demo videos for this.
Comment 22 kxra 2012-03-28 16:20:22 UTC
Also, Ubuntu isn't the only Gnome distro, and they have Unity now. Gnome should be innovative too.
Comment 23 kxra 2014-04-09 23:37:26 UTC
Is there any Minimap functionality in GTK+ or clutter similar to the "Goto Anything" panel in http://www.sublimetext.com/ ?
Comment 24 Matthias Clasen 2015-07-31 03:04:58 UTC
I think this has been obsoleted by the overlay scrollbar changes in current gtk
Comment 25 kxra 2015-08-21 18:49:54 UTC
(In reply to Matthias Clasen from comment #24)
> I think this has been obsoleted by the overlay scrollbar changes in current
> gtk

I don't know if I agree. Please correct me if I am wrong but the overlay scrollbar in current GTK still uses the position of the mouse relative to the bar to decide which direction to scroll, where as this more intuitive design uses the bar only as an indicator of where you are, not how to interact with the page. So no matter where the bar indicator is, you can click anywhere on the whole scrollbar area to drag in the direction you would like to scroll. 

This provides more consistency because no matter where on the page you are, or how much of the page you can see, the interaction to move  up or down or left or right on a page are exactly the same. Currently, if you are close to the top of a page, you have less room to click (above the bar) to be able to scroll up. This is unintuitive and inconsistent user experience. 

https://thorwil.wordpress.com/2008/05/09/popup-scrollbar-concept-demo/