GNOME Bugzilla – Bug 530413
Popup Scrollbar
Last modified: 2015-08-21 18:49:54 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.
Created attachment 110053 [details] PyGTK demo of a vertical popup scrollbar
Created attachment 110623 [details] PyGTK demo Added triangle if indicator becomes very thin, fixed cursor change behaviour.
Demo video: http://www.archive.org/details.php?identifier=popup_scrollbar Embedded view is a bit small, please note download option on the right.
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.
Created attachment 110648 [details] PyGTK demo Fixed the wrong filename, thanks to Calum!
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 ;)
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.
*** Bug 567125 has been marked as a duplicate of this bug. ***
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!
Linked to LP: https://bugs.edge.launchpad.net/bugs/253546
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.
What needs to be done to be able to test this for GNOME 3.0?
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...)
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
Created attachment 149581 [details] PyGTK Demo You can now click in the trough to cause page-wise scrolling. Plus a couple of tweaks.
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.
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?
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)
>I'm sure that many testers would like to have a go with it Like myself!
(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.
>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.
Also, Ubuntu isn't the only Gnome distro, and they have Unity now. Gnome should be innovative too.
Is there any Minimap functionality in GTK+ or clutter similar to the "Goto Anything" panel in http://www.sublimetext.com/ ?
I think this has been obsoleted by the overlay scrollbar changes in current gtk
(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/