As you may remember from our series on common usability terms, I have a lot of interest in graphical user interface concepts. In addition, I applaud anyone trying to improve existing concepts, people that try to think beyond set conventions to come up with an improved version of that concept, or a new concept altogether. Thorsten Wilms took on the well-established concept of the scrollbar, and came up with a few interesting tweaks.His idea is one of those things that are hard to explain by textual means – hence the video he made, which he put on YouTube for us all to see.
While I applaud the efforts made by Wilms (I already noted his email to gnome-usability), I have difficulties seeing the exact problems this new type of scrollbar tries to resolve. When observing my friends, who are almost all decidedly not computer savvy, I see that they use the scroll wheel for minor scrolling, and the ‘scroll blob’, as I like to call it, for heavier scrolling (like jumping to specific sections of a page). Of course, this is completely unscientific, but I think it’s rather representative for most people out there. I’ve never seen anyone frantically turning the scroll wheel, only to be amazed by being pointed to the scroll blob – or vice versa. In other words, what problem does this new type of scrollbar address?
The only thing I can see is that when the scroll blob becomes too small, the act of being able to click and drag in the entire scroll bar to scroll can be quite handy. However, I would argue that scroll blobs becoming too small is not an inherent problem of the current scroll bar concept itself, but of the underlying toolkit instead: scroll blobs should always remain big enough to remain an easy target: you know, usability’s favourite dead horse, Fitts’ Law. In other words: this is a low-level problem, that you really shouldn’t try to fix with a high-level solution.
This leaves us with the ever important question of whether or not to embrace a new UI concept: is the problem that the new concept tries to address big enough to justify learning that new concept? Seeing the relative complexity of Wilms’ scroll bar, I tend to answer that question with ‘no’.
Feel free to disagree in the comments.
Quite interesting concept.
Almost all applications that require much scrolling would benefit from this.
#
About the flash… I don’t think there’s too much difference in link a flash video and making it embed as you’ll probably watch it, as the article suggests, anyway (if possible)…
I think that scrollbars in their current form are pretty well designed, do not vary a whole lot across the major platforms, and are not hard to learn to use. That video looked cool, but the interaction was more complex, and relearning those basic skills for the tiny bit of benefit wouldn’t be worth it.
I tend to dislike things that react to “mouseover”. Lightup widgets aren’t so bad. Tool tips are ok as long as they are not overused, and as long as the timeout is sufficient that they are relatively unobtrusive. (Anyone who has ever used Limewire will recognize what I am complaining about. Mouseover events make that app unnecessarily aggravating to use.) This scrollbar seems a little over the edge for my taste. It feels like overused Javascript done by a web designer who was just a little too anxious get into Web 2.0.
Sometimes it is best to leave well enough alone.
Beautiful
Honestly, I haven’t used a scrollbar since i bought a mouse with a scroll wheel.
I forget they exist really.
The concept isn’t horrible, and I’m not sure you would be “relearning” anything — the functionality he’s replacing is almost never used as it is. I think the idea is kind of “blah” but I’m glad he’s thinking of UI anyway.
I really don’t want to sound like a Mac snob (I’m really not that big of a fan! I swear!), but I have to say I love the Mac Book Pro’s multi-touch. I almost never use a scroll bar because of the combination of the up/down arrows on a keyboard and being able to scroll horizontally and vertically by simply using two fingers instead of one.
When I eventually have to replace my MBP and get something cheap that runs Linux, I will really miss this functionality (and I guess I kind of like the keyboard as well).
In Linux, you get to enable circular scrolling on your touch pad too. It’s triggered slightly differently (start your finter in hotspot of your choice) though, as right and middle clicks are done with multiple finger taps, but the basic interaction style is still there.
I have a macbook and I can do that as well. Two finger scrolling is great
I never got why double finger scrolling is so much better than regular using the edge of a touchpad. I have to move my entire palm to perform this gesture which makes it slower and I can’t see myself using it for a prolonged time like when reading an e-book. Edge scrolling is also more intuitive, window has a scrollbar on the right (and/or down) and so does touchpad.
More on topic. I think the popup scrollbar concept is not so good mainly because I can’t see a simple way to jump to a certain point in the document anymore.
the whole idea behind the two finger gesture as opposed to the scroll pad to the right of your track pad is that you’re not limited to a small area, which is generally what makes scroll bars somewhat unhandy, since you’ll have to move the cursor to a specific area of the screen.
This is eliminated by the addition of the scroll wheel and in Apple’s case the two finger gesture.
I don’t think you understand how scrolling works on most touchpads. You move your finger along the right physical border up and down and it’s exactly like a scroll wheel, just flat and without tactile feedback.
[edit]
To make it clearer, here’s a demo of stand-alone, probably Synaptics based (like in most notebooks, including Apple ones) touchpad and some common possible gestures.
http://www.youtube.com/watch?v=rF9sXAMLBW0
Edited 2008-05-11 11:23 UTC
Or on any PC since Windows 2.0 that has a mouse with THREE buttons (even my old Mouse Systems optical on one of the metallic pads with the blue and red lines going each way and the 25 pin Serial connector had three buttons!) – or ***SHOCK*** pushing down on the scroll wheel. You get this nice little arrow cursor that lets you scroll in any direction – without even having to move sideways to the scrollbar.
That’s what I don’t get – this isn’t innovative, it’s a step behind two decades ago. (though it would be nice if middle button scrolling was persistant to the window element that had the focus if scrollable and not just the window itself)
Hehe, since I’m using UNIX operating systems, I’m familiar with handling a three button mouse. Honestly, it’s more comfortable than a two button mouse with a wheel – the wheel acts “bumpy” when scrolling (hop, hop, hop), while pressing the middle mouse button and moving the mouse in Y direction generates a more shmooth scrolling. Well, this is a standard behaviour in UNIX / X11 based applications for years, nothing new, really. Ah yes, and it’s more healthy than the wheel which causes carpal tunnel diseases because it makes you move your fingers in an unhealthy manner. 🙂
Of course you could extend this concept not only to vertical scrolling, but to scrolling in general (pressing middle mouse button and moving mouse in X direction – do horizontal scrolling, or pressing middle mouse button within a media player window and moving mouse in X or Y directioon – do skipping in video or in playlist).
As you surely will notice, this concept does not force you to aim precisely with the mouse to a certain control object (a scrollbar slider or a scrollbar button), you simply move the mouse into the context you want to control (e. g. the web page, the video player, the directory list, the file list) and you do the actoin desired. Another advantage is the obsolescense of the need to put the scrollbars onto the screen – this gives you more real estate for the content you’re working with.
It’s also a one way ticket to RSI. Dragging and dropping is also worse enough in this context, but a continual mouse button press in order to scroll?
Ugh. To each his own.
Nah, I think he means when you press the middle mouse button, you go into scroll mode, and you scroll where you move the mouse. Then, when you want to stop scrolling, you press the MMB again.
See i have one of the logitech mx laser mice that has the clutch scroll wheel. Click and it’s smooth, click again and it’s jumpy…i like it smooth
I haven’t touched a scrollbar since I got my MX revolution
.
I have to agree with the other poster.
I use a Thinkpad which happens to have a 3rd button which activates scrolling. Secondly, when I dock it, my mouse has a scroll wheel.
If this guy released this concept 15 years ago, yeah, it would have been beautiful.
If the visible area is >90% of the whole document there wont be room for his extra buttons and he’ll have to allocate space for them.. which is gonna look ugly and somehow probably end up with the same kind of button placement we already have.
Nope. The arrow buttons appear on a layer above the trough/indicator. So the minimum scrollbar length is just the space needed for both buttons and the gap between them, independent of what percentage the indicator takes. Below that size, I would propose switching to just having up/down buttons.
I guess I’ll break the mold and find this incredibly useful. Maybe not on the desktop, but certainly for stylus-driven mobile applications.
No matter how calibrated my stylus is, I have trouble grabbing the scroll bar to quickly get past a lot of junk during internet browsing (the leftmost part of the screen during desktop browsing usually comes first, followed by the content). Being able to tap anywhere on the scroll blob and direct where I am in the document as if I had control of the bar thingy would be handy.
Edit: cleaned up the first paragraph a bit.
Edited 2008-05-11 00:54 UTC
I hate trying to grasp the scrollbar on my treo. I always just use the up/down buttons for scrolling.
This isn’t an improvement, but rather a duplication of the existent solution. That, in itself is not a problem; however, re-solving a solved problem is the mark of bad interface design, as it tends to clutter interfaces with bad choices rather than build on the current strengths.
Love it or hate it, users are used to scrollbars, know how to use them and use them intuitively due to familiarity. Recreating the wheel is forcing the user to learn to use a familiar widget and causes an interface that implement it to become counter-intuitive. One thing you don’t want to do is have an interface that is different than everything else on the user’s system. If design-wise, you don’t think scrollbars are good, eliminate scrolling (i.e. fit everything in a frame) altogether. Replacing them with your own widget is reinforcing the problem you were trying to avoid, and is creating a new one.
This is an interesting concept, but I wonder which problem it solves?
– The size of the ‘scroll blob’? That’s a solved issue: just put a limit on its size.
One criticism against this is that it would make the ‘scroll blob’ imprecise to indicate where we are in the document.
This can be solved if ‘scroll blob’ is drawn with two colors, one for the ‘scroll blob’ the other indicating where we are in the document.
– the need to grab the ‘scroll blob’?
Apparently from the video you can scroll from anypoint in the scrollbar, no need to grab the ‘scroll blob’, this is very interesting (especially for old people) but it comes at a price:
apparently, you cannot anymore point at one location in the scrollbar and has the document jump to this point, maybe this could be added with the ‘middle mouse button’ doing this, but very few people would know about it (when was the last time that you read an help file about how a widget is behaving?)..
In the end, I think that this ‘popup scrollbar’ is VERY interesting but it has one big drawback: it looks like the old scrollbar but it behave differently, this could annoy users..
..a solution looking for a problem.
Exactly!
Holy crap. Find something useful to improve. Scrollbars aren’t one of them.
Thom, you should really look at the Haiku RFCs more often.
I already wrote about a similar idea:
http://www.haiku-os.org/glass_elevator/rfc/rethinking_scrolling
So the article text has a screenshot in it, rather than a flash movie, with some explanation text…. And what do I see to the right of that screenshot?
An animated flash advert.
I’m not a big flash fan, but it’s use for video has always made good sense to me, as has more generally the use of embedded video, so I say go ahead and embed video clips into OSNews articles.
Having a fall-back image for when flash is not present would make sense. Putting a title below that links to the YouTube page would also make sense. These two things would make it work perfectly on my iPhone.
Thom: thanks for the article!
About what the concept tries to address:
– If you use means outside the widget to scroll (keys, gestures, touchpad), it’s purpose is to show you where you are in the document and how large the visible part is.
In this case arrow buttons just take space away.
The slider doubling as indicator leads to the sizing problem you mentioned. In contrast, my concept has the largets possible target area for drag-scrolling.
– If you want to use arrow buttons, they are tiny targets in remote places. Usually far apart from each other. In my concept, the arrow buttons have large target areas and are close to each other.
The lack of pag up/down is a very valid concern. I assumed it would be rarely used. I always found it bothersome that clicking the trough only works until the slider appears below the pointer and never used this feature because of that.
From some comments I can see that some people think of clicking the trough as way to move the slider to the place where the pointer is. But there’s middle or shift-click for the real jump
I will think about this some more.
I think it’s all ok to be able to just grab the scroll bar anywhere and move away instead of trying to hit the current page piece so to speak. I find the arrows rather useless thought, yes, it’s an advancement to have them even closer to the pointer, but who use them? It’s true as the osnews post say that everyone (?) use scrollwheels or similair for small motion work.
I thought about that issue with a very short scrollbar (on say a 900 pages document) and how hard it is to get to the right place for a few seconds and my first idea is this (which won’t work good in a maximized window environment but anyway:)
What if a click on the scrollbar (or something else) brought up a right half of a circle gadget/window from beneath the window, with an arrow/line pointing to the right and say small indications along the edge. Think a half compass which points to the east. The user can then click on the compass (arrow eventually, if big enough, but whole compass would be ok aswell.) which would grab the arrow so to speak. Moving the mouse upward would make it point more to “north”, and downward more to “south”. For a small movement in either direction the pointer would remain quite much to the “east” or right, and the scroll speed would be slow, for a bigger movement it would eventually peak up or down/north or south and the scroll speed would be very fast.
The problem that would solve is that when you are in a huge document on say 900 pages and you want to go to page 437 with a regular scroll bar the movementspeed will be the same thru the whole document so you will very fast and easy get to page 300-600 or so but there it will be quite hard to actually hit the right spot and drop on the correct page because a small mouse movement will scroll away many pages. This way you could just pull that “arrow” downwards quite a lot to scroll fast down to page 400 or so and then move it up a little to “south-east-east” so to speak and have the scroll speed slow down and take you in at a slower speed to your page.
Uhm. But now when I’ve written it a more compatible way to do this with the current design would be to just have the scroll “box” sping back to the vertical center. And then if you pulled it up or down a little it would scroll slow, and if you pulled it all the way up or down the scroll bar it would scroll fast. (But then you would lose its function as an indicator for telling you where you are in the document, and also being to go to say the top or the bottom immediatly, so maybe we would need both things at once somehow. In any case I would like to have some sort of thing in my user interface which would let me scroll a document at varying speeds.)
When I saw “pop-up scrolling” I thought this might lead to a pop-up window, say something like a context menu, only one where you could scroll around the document. I would find that a lot more convenient than having to roll the trackball (or slide the mouse) to the side of the screen to access the scrollbar. It’s especially annoying in text documents when I’m typing: reach for the mouse, find the scrollbar, scroll, etc. If we can move the context menu to a popup, it seems intuitive to move the scrollbar to a popup. I personally use the scrollbar a lot more than most menu items.
Unfortunately, this doesn’t change that. Seeing the demo, I agree with most people that this implementation isn’t really a problem. I also don’t see how it’s a “popup” scrollbar.
It’s definitely a poor title.
Doing dev all day, I use scroll bars – a lot. Yes, you can use your scroll wheel, but it really is no match for the scroll bar when you’ve got to get somewhere in a hurry.
This would be a welcome improvement. Good idea!
Right clicking on the scroll bar scroll bar should pop-up a selection window.
The selection windows should have:
1) Page
Word Processors should also have a “Section” (This should give me a listing of sub-headers).
Code Editors should have a “Procedure” (This should give a list of procedures in the source).
Selecting a page number, Section, or Procedure should move to that location.
I knew that concept seemed familiar:
http://en.wikipedia.org/wiki/Image:OpenWindows-filemgr.png
Not really, I think I used this scrollbar and sure visually it looks the same, it lacks the ‘major feature’ of this ‘new scrollbar’ which is you click anywhere on the scrollbar (not just on the scrollblob) and then you can move the scrollblob.
Advantage: no need to point the scrollblob (faster, nice for old people who cannot use the mouse precisely)
Inconvenient: when you’re used to current scrollblob IMHO this would be a little annoying because say your mouse pointer is a the bottom of the mousepad and you want to scroll your document from top to bottom, you move to the left vertical scrollbar and click but when you try to go down, you can’t because you reach the end of your mousepad..
So it’s a bit weird.
Have you listened to the narration on the video? The second point mentioned (at 00:08) is:
“The arrow buttons appear above and below the pointer.”
That would serve as a pretty good description of how the OpenLook/openwin scrollbars worked – the only difference is that the OpenLook scrollblob didn’t automatically jump to the mouse pointer’s position.
The page up/down keys already fill that role quite nicely.