@syd scrolling on the touchpad sucks and the scroll wheel doesn’t function the same as clicking and dragging the scroll bar down. if you want to get to get to the bottom of a very long document the scroll wheel becomes very ineffecient.

@Amir: To get to the bottom of a document, simply press “end,” or CTRL+end if it’s an open word document. Press home or Ctrl+home to get to the beginning. Combining these with Page-up, Page-down, and with the up and down arrows, I don’t need a scrollbar.

Syd: I make much use of the wheel /or space key in browsers. But the scrollbar is always good to have because it shows you where you are and how large the part you see is. My concept is better at showing that.
Now if you do use the widget, it should do the best possible job.

Let me preface with the fact that I have been studying all day, so perhaps I am missing the obvious in my study induced delirium.

But isn’t adding additional layers of functionality (that is arguably not needed) almost necessarily make things more complicated and less elegant?

Don’t scroll wheels negate the need for arrows? You have to move the mouse to access the arrows and scroll bar in this implementation anyway, why not go another couple inches to the current arrow or scroll bar location?

Jesse: GTK works on Windows. If PyGTK and this script works there, I don’t know.

Ben: The existence of arrow buttons doesn’t mean you shouldn’t use the wheel.
Arrow buttons are good for precise single steps, or for holding them to scroll continuously.
If you don’t want/need arrow buttons, you have none in this concept as long as the pointer stays outside. With conventional scrollbars the buttons always eat space.
If you want to use the arrow keys, the are faster to hit here, because their ‘virtual’ target size extends from the drawn button all the way up/down. So just moving the pointer over there and blindly moving up or down will result in hovering over the respective button.

Ben, not all of us have a scroll wheel, and the touchpad sidescrolling option blows, Home, End, Page Up and Page Down often move too large of a chunk of page, this is a small innovation but a great one nonetheless. I would certainly appreciate using it on my laptop and the PC with an older optical mouse sans scrollwheel.

This is terrible. It makes things more complex effectively taking away from the user experience rather than adding it. User experience is often about finding the simplest solution rather than try to add multiple functions to an existing one – you effectively partly destroy what made the original solution work. The scroll bar is simple and already has the scroll up / down buttons in most cases either at the bottom or at top and bottom – why move them? Also there’s a minimum height for most windows for a reason – beyond a certain height they become unusuable and pointless – especially at 1 pixel.

In general looks like a engineering solution not a user experience solution.

Stew: The buttons of conventional scrollbars are rather tiny and you often have to cross quite some distance to get to them. Especially if you just used the bottom one and now want to step up again.
I didn’t talk about a minimum height of windows. If you have a very long document, the relative size of the visible part can be tiny. My concept can show the true relative size until only 1 pixel height is left. The indicator becomes a line. The slider of normal scrollbars can’t do that, it has to stay large enough to be clickable.

I don’t mean to be mean, but that seems like just messing around with well established widget behavior without solving any problem. That sort of “improvement” should be strictly optional that those who think it would be better can choose. Having a Firefox extension that chances scrolling to work like that would be a nice real world test of actual usefulness of that. If the extension becomes popular you might be on to something.

Btw. I think that more pressing problem with scrollbar is its basic behavior: You drag the scroll handle down to move screen content up and vice versa. There is a sound reasoning for it to work like that but movement directions are still wrong. I doubt there is a way to solve that without inventing completely new widget to replace scroll bars.

To the person that said you can just use CTRL + END, or CTRL + HOME to go to each end of a document, you obviously don’t understand how slow this is to a power user. Switching around from mouse to keyboard is very slow. I can just imagine how quick it would be being able to zip over to the scrollbar and move around the document without having to locate the “gray box”.

Occasionally I do find it useful to be able to click below the “gray box” to “page down”, but not often enough to miss it. Plus, it’s an easy fix. Just make it so that a right-click on the arrow goes down a page.

Overall, I love it. I hope it will be easy enough to install system-wide.

This is a very good design. The traditional style is simple and easy and so is this new style and also adds more functionality. This should’ve been the original design for a scroll bar.

Pointless:
The reason you go down on the page is because you scroll down, how on earth are the directions wrong for the scroll bar? What you wanna go left when you scroll down? Please explain how the movement directions are wrong.

not all that impressed, and the mac solution works fine, and i feel like i was looking at a scrollbar from the 80’s sorry – but kinda lame and, well – there are seems to more important things to get excited about…. like, lets see… Web 3.0 (just re-packaged USEFUL technology) or video on demand… or video conferencing…. all i gottah say is that i feel like this post should have been done during the days of floppy-drives, and 300 baud cradle modems.

To the naysayers: can’t you tell that the same scrollbar functionality is preserved? You lose nothing, and gain much. Or do you prefer moving your mouse a mile to hit the arrow instead? Because if that’s the case, you can STILL do that with this new scrollbar.

Believe it our not but there are poeple who do not like moving from the touchpad to the keyboard, press a awkward 1,2 or 3 key sequence to do something. and then go back. and forth…etc. It aint hard but it sure is stupid sometimes.

watching my mother trying to use scrollbars is painful. Yes the scroll bar is 30 years old. and you know what, THAT IS NOT A LONG TIME. How can you say it is easier to focus on 2 little boxes, one 18 inches from the other on my screen..or preciesely placing the cursor somewhere between the top of the screen and the bottom to control a bar that can be just a tiny little box on a big document that out of control speeds through a document with the slightest move?

>This new interface doesn’t really enhance the scrollbar.
>In general looks like a engineering solution not a user experience solution.

So tell me how his feature specifically is NOT making the basic sucky scroll better.

Come on, tell me point by point by what he shows in the video is actually worse. You havent even tried it, so make it good.

And dont give me “its makes things so compicated for me” grandpa. This isnt so tough. This interface is not ancient. it has not been used by thousands of generations, it hasn’t proven squat.

Sometimes people 20 years old already sound staid with the stuff they learned in the early 00’s on their 800×600 screens. Just look at it like this: If a 5 year old had to chose to work with your old way or with this , which would it choose? And once again, explain why your old scroll is the best solution.

I can see where you’re coming from with this concept, but I don’t really see this as an improvement over current scrollbars.

You cannot, at least from what I can tell, easily change the direction you are ‘stepping’ in. Clicking, then moving to the other direction would, intuitively, initiate a drag. This is, pretty much, an unsolveable issue. If the behaviour is changed so that dragging the other way makes it start stepping in the other direction, it becomes unintuitive & awkward (because it would be difficult to know how far down to move the mouse — moving too little would keep it scrolling up, moving too far would initiate the drag)
This issue exsists with the most common scrollbars too, as they have one button on each end. This is, however, not an issue in OS X scrollbars and, depending on configuration, linux ones)

There is also no easy way to jump to a specific part of a document; nor is there mouse only page flipping. Clicking in the scroll area currently tends to have one of two functions; page up/page down (depending on the relative position of the indicatior) or jump to the point that was clicked. Neither of these functionalities, to my knowledge, are preserved in this concept. One of these (jump to a point) is not available anywhere else in the GUI, or in the mouse. It is also a very useful behaviour. If the scrollbar is of the ‘jump to point’ variety, The entire scrollbar is an active area. Clicking and dragging will have the same functionality it has in your concept. Only your scrollbar moves to where you click first. This is, in my opinion, both more useful & more intuitive.

And, in your concept you do not move the scroll indicator. It is just that, an indicator, moving seperately from the mouse. In your concept, you move the page. This makes the direction of movement wrong (as ‘pointless’ said). Moving the mouse upward should move the page upward. When you move the page upward, the LOWER portions become visible, and thus the scroll indicator would go down.

@Jimbo. Put your finger on your monitor. Pull it upward through a content area. Think about what should happen . . . The page should move upward; and by moving upward, lower portions will become visible. The page should scroll down. The page should move with you, not against you, as it does in this concept, and in current scrollbars. The difference between this behaviour in current scroll bars & in this concept is that in current scrollbars, you do not actually move the page. You move the indicator. IT moves with you. In this concept, there are two possiblilities. Either you are moving the page itself (which leads to the issue explained above); or you are moving the indicator from afar, (which is just plain bad GUI design. (Try to name one other place in the GUI where there is no feedback for your actions in the place you are doing them))

@Paul Walker: Yes, I’ve noticed too that there is the loss of the ‘jump anywhere’ in the document functionnality, this could be re-added with say a ‘middle mouse click’, but the issue is that nearly nobody would think about doing this..

[ Who know that in Windows Explorer shift+right click brings back the ‘open with’ entry (which is a very stupid idea, it should be always present..)? That Win+D iconify all the window in Windows?
Not so many people.. ]

Lauri: If you assume that visibly indicating the size of the scrollable area is the main purpose, my concept has the benefit of not having a slider button that must retain a minimum height to be clickable.

I can see from screenshots that Picasa 2 has scrollbars that are different both from conventional ones and my concept. Somebody care to explain how they work?

AllanX: Yes, single clicks above/below the pointer could be used for page up/down. But it would have to happen after a delay or only after release to avoid scrolling before the user starts a drag. Waiting for release would be save and simple, but this would rule out a repeat action.

walom: there’s a Python-GTK script linked in the article. Click the link, save the file. Make sure you have PyGTK. Run the file.

I posted a comment on your ‘bug’ also, but i’ll briefly repeat here. You should implement page up/down by adding double arrow buttons above and below your current arrow buttons. I’d love it if this gets adopted by Gnome and KDE. It’d also be awesome to see MS have to ‘innovate’ it into future versions of windows.

Wally: And once again, explain why your old scroll is the best solution.

He didn’t say the old scroll bar is the best solution, at least not specifically. So if the argument is one of specifics, then you need not look any further at the multiple ( and all quite valid points ) about what you DO lose over the “old”scroll solution.

Different people WILL perceive what they want to happen, and how they want it to look as it happens, different ways. Some people will want ( or feel more comfortable with ) the “follow me” approach whereas some will want the “move it away” approach. Either way, this substitutes one for the other, and as others have pointed out, in a no-so-intuitive way.

I do applaud the effort to implement this, or to approach the subject. Pity humanity is so accustomed to “it should just work”, without answering the “which way was THAT again ?” question first.First answer the question of how action-response can be made intuitive ( what does the user do, and what does the user then see as a reaction ), and then worry about the specifics of what button goes where, etc.etc.

It’s similar to the behavior of the NeXTstep or OpenStep scroll bars with all the options being available just in a very minor variant with the pop up page buttons. Check out MacOSX or GNUstep for a comparison.

Brilliant. The target size of the scroll arrows is increased, and the visual indicator is made much more useful. I hate it when scroll areas (especially in web pages) show me a tiny bar as if there’s a lot of content, but it’s just a sham. See http://www.colani.de/werk.php?lang=en

A few responses to criticisms:

“Scrollbars are obsoleted by scrollwheels / keyboard shortcuts.” – I agree, we should be able to remove scrollbars entirely 😉 However, in the absence of that option, having one that’s actually useful would be an improvement.

“No page up/down” – It would be trivial to customize the arrows to initiate a page up/down action.

“No fast random access” – Click anywhere on scrollbar, drag pointer to location. Shortcut keys or right clicking could also initiate a jump without changing the basic design.

“Mac scrollbars are better” – I use them, and I assure you they are not 😉 Personally, I like KDE’s bars, with both arrows at the bottom and the up arrow at the top.

Devoting valuable screen real-estate to ‘always on’ buttons when something like this has been envisioned is shameful. This concept is much cleaner and more usable than anything else I’ve seen. Bravo.

I’m continually frustrated by the fact that even open source developers don’t recognize good design until Cupertino threatens to beat them over the head with it. This sort of practical innovation makes me optimistic.

Bloody brilliant!!!!! I just posted this to ubuntuforums in the Intrepid-development forum http://ubuntuforums.org/showthread.php?t=892592 & hope to have more people test/comment on this idea. Please work with someone to get this into a regular app for us to test!!!!!!

The highlighted are should reach the top/bottom of the scroll area at exactly the same moment as the mouse pointer. Also, it should scroll slower than the mouse pointer when the mouse pointer is near where the drag started and speed up later so you can easily do small scrolls as well as return to where you started – a shading could perhaps be used (or the distance of the periodic markers) to indicate depth where there will be fast movement (so the change in speed seems like the thumb has simply moved back and a perspective effect is making it go faster.

Interesting. I like that this makes the entire scrollbar a much larger target area.
– I like the dragging of the scrollbar shaft. This over-rides the traditional page-up that you get when you click in that region. Perhaps a single click could still page up and a click/drag could scroll.
– The hover arrows that show up are interesting but may cause some confusion. If a user is above the scroll thumb and and clicks it may be strange to have the scroll region move in the opposite direction. This is one of those that you have to play with to see if it works well.

In general there are a lot of innovations that can happen in scroll controls that haven’t been explored in decades.