March 3rd, 2011 byOne of our goals in the Unity design effort is maximising immersion in content, and reducing the amount of chrome and clutter needed around that content.
Unity’s new Overlay Scrollbars are a small but important detail in this bigger picture.
Problem
Today’s scrollbars are optimized for cursor driven UI but they became easily unnecessary and bulky on touchable and small screen devices. In those cases, optimization of the screen’s real-estate becomes essential. Other platforms optimized for touch input like Android and iOS are already using a light-weight solution visible only while dragging the content.
Our interest is in bringing a more lightweight approach to window chrome, like scrollbars, to the desktop experience. Touch and scrollwheels are making that chrome, if not obsolete, then certainly less important. We want to embrace new thinking from the mobile world, while still retaining some of the key semantics and experiences of the desktop world in recognition of the differences between the environments.
Process
Research
There have been few attempts in the past to bring innovation in this very mature GUI widget. Unfortunately the most radical approaches didn’t really survive long. We had a look at these attempts and analyzed why they failed. Some of them were just trying too hard, a good approach could have been to do a step at the time, in this case more an evolution than a revolution.
Prerequisites
After having a better idea on the problem, and the various attempts, it was time to take some decisions starting from the scope for the solution.
The prerequisites we defined were:
- Has to reduce at the minimum the usage of screen real-estate: to provide more immersive experiences.
- Has to allow the user the ability to interact with 100% of the content surface: to be able to work over any content already created.
- Has to work well both on cursor driven UI and on touch ones: this is a prerequisite of any Unity solution.
- Shouldn’t conflict with the window resizing functionalities (ie. dragging windows borders)
One of the contexts we used to validate our solution was scrollable panes rich applications like Eclipse:
Prioritization
To have a solution which would embrace touch input devices, some of the functionalities available on cursor driven solutions might have to go. For this reason we prioritized the scrolling functionalities (from the more important to the least):
- Scrolling via mouse wheel (or dragging content on touch devices)
- Scrolling via thumb
- Page up/down
- Jump to position via bar
- Line up/down
Exploration
Going for an evolution approach of the current cursor driven scrollbars towards the overlay ones we have seen on more recent touch UI platform, we quickly narrowed down the options and the variations we considered were fairly similar.
Solution
Without further ado, here the video which shows both the prototype and the work in progress implementation (the visual might not be 100% accurate).
Overlay Scrollbars in Unity from Canonical Design on Vimeo.
User testing
As we usually do, especially for the more controversial design solutions, we tested the prototype in our office with external users. The results were so positive that they almost surprised us. People were involved in completing tasks where the scrollbars were just a marginal mean, of course they weren’t aware of what was really tested. Bottom line, despite they were using a not 100% stable prototype, they used the scrollbars so intuitively, going straight to the thumb and using it without any problem.
The current implementation is already available for everyone to test it starting from here. Please give it ago and report some bugs if you can!
Disclaimer
- We are fully aware that our solution can be an easy target for critics (as they were who tried to innovate in the field before us). As mentioned earlier, we believe priorities are changed recently in the industry and that this is the right time to make our own attempt.
- We just noticed MacOSX Lion is likely to give it a try on merging the traditional scrollbars with the overlaid ones. From the few screenshots we saw, it looks like a quite different solution. What else can we say, good luck to them and may the best win!
The toolkit
107 Responseshide comments
this is awesome, yet not everybody likes it that much. It should be included in a theme pakage so that users can enable/disable it, plus it has to be available in all apps
Looks nice, but is very nasty. These buttons for up and down are just a fail. What’s funny is that you really move the little horizontal bar like a big one but you need to carefully click on these little pixels.
Please work on it so that it is better usable for cursor driven UI. Please remove the up and down buttons. Show a little scrollbar on the side like you do it with your “overlay-scrollbar” currently, but make the scrollbar __fat__ when you come to her at __any__ point of the side, so that you can scroll nicely with your mouse, if you want.
Nice ! I can wait to try it.
Two problems remain, I’d say:
* the user have to move e.g. to the right for scrolling UP/DOWN, and move UP/DOWN to scroll LEFT/RIGHT.
It would be more intuitive to move in the direction you want the content to move.
* the new scroller still carries over the behaviour from the old. I.e. you have to know that there suppose to be an legacy scroller there, and therefore move over. A coloured line is not intuitive.
I’d say the solution to both problems would be what IMDB does on pictures.
http://www.imdb.com/media/rm3902375168/nm1817256
Try hover to the left and right over the picture.
But instead of just showing the arrows when hovering, I’d always show then for the edges the user can move the content in.
Hi Sandra, a solution like that might be useful when there is not a defined limit for the scrolling, I think I saw similar approaches on maps.
The limits could be illustrated by an old fashioned scroll =)
http://www.google.com/search?q=scroll&um=1&ie=UTF-8&tbm=isch&source=og&sa=N&hl=en&tab=wi&biw=1280&bih=916
Upgraded desktop (1280×1024) yesterday to Ubuntu 11.04
1) Now I seem to be constantly playing hunt the scroll thumb.
For previously opened documents the scroll thumb might be somewhere in the middle of the document. That didn’t matter with ye olde scrollbars, because clicking in the top or bottom of the scrollbar would cause the page to scroll – but now it seems I have to find where the scroll thumb is before I can scroll with it.
2) Why didn’t this go away when I changed to Ubuntu Classic!
One of the first things I did after upgrading to Natty was look for a way to disable this feature. Where is the easy option in the settings to turn off the overlay scrollbar? It certainly isn’t in an obvious or well documented place. Between disabling this feature and getting rid of Unity, my Natty feels very much better now.
Christian,
Thanks for the blog post, you really explained a lot of this well. But…
You correctly identified and prioritised all the functionality:
Scrolling via mouse wheel
Scrolling via thumb
Page up/down
Jump to position via bar
Line up/down
But then it seems you discarded numbers 4 and 5? I don’t understand how you can consider any solution that doesn’t cover a good 15-20% of the use cases.
I’d really love to hear your thoughts behind that, because this seems like well known and intuitive functionality that’s being tossed out the door.
I appreciate we can disable them, but the average user cannot, and will not, so something this basic has to be spot on.
Hi Oli, can I ask you how did you calculate that 4 and 5 together cover 15-20% of the use cases?
As explained, the scrollbars performed very well in the user testing and made us believe that 4 and 5 cover a much smaller percentage of cases.
There is definitely room for improvements, so thanks for sharing your experience, it would be useful for the new iteration!
Christian,
Thanks for your response.
I get 15-20% from gut feeling, which I know from experience is absolutely no substitute for user testing, but is still hard to escape.
So instead, I’ll ask – did you test with new users/regular users/power users/developers? Small files/big files? Low screen res/high screen res? High CPU load/low CPU load (think about lack of feedback/responsiveness – this could cause them to travel along the list of use cases)? Low stress/high stress? Time limited tasks vs open ended?
I notice Natty excluded it from Firefox and some other apps – what was the user feedback on it in those apps? On certain site designs scrolling could come second only to clicking links in terms of activities!
Remember the basics – it’s easier to hit a bigger target, and I can think of any number of reasons that someone needs to scroll somewhere fast/in large increments – and if you’re on the mouse (think GOMS) then it’s faster to click anywhere on the scrollbar than to target the thumb, or context switch to Page Up/Page Down keys.
There’s also the hybrid use case of large increment scroll (using empty scrollbar space say), and then micro adjustment using the thumb or the top/bottom arrows.
Thoughts?
Oh, and of course, the way to get good numbers would be to instrument the regular scroll bars and deploy that to whatever user population you have access to, eg Canonical.
Hi Oli, as far as I know, we tested properly the prototype (so not so responsive) with no Ubuntu or power users (as we usually do).
The overlay scrollbars don’t appear everywhere because they have not been implemented on every toolkit (Firefox uses XUL, Chrome doesn’t use GTK too).
Cheers, chr
Probably a billion people that already wrote this, but:
I had to remove the package and disable these overlay scrollbars.
Reason: I want to be able to middle mouse click somewhere in the middle to quickly go to a certain section on a page.
(In case this is possible with overlay scrollbars: it’s totally unclear how.)
I have mixed feelings about the scroll bar change.
At first glance I had to hunt for it, then I realized where it was and with moderate content to scroll through it works very well. The only issues I am having is when you have a lot of content to scroll through and it feels little to hard to find the scroll bar “hot spot” to bring it up.
Over all, I feel a little tweaking and this could be one of the best features with the new Unity UI that many OS’s will try to copy.
I love the idea, but in use over a remote connection it’s simply unusable. I have no desire to use the mouse wheel to go through a huge list like in the software centre, and there are no affordances for grabbing the thumb,
Nice work. But it still the old way of moving inside a window.
What i dont like is, that if you want to go down, you first have to go to right to the scrollbar and then you can move down. If you want to go to the right, you have to move down to go to the scrollbar to move to right. Really great would be to switch the scrollbars (dont know exactly what would be an usable Control) in a way that if you want to go down inside the window, you go down with the mouse and find something like “scrollbar” to move down; and if you want to move inside the document to the right, you go right with the mouse to find a control to move to the right. Wouldnt be traditinal, but more intuitive.
greetings
Hi,
An interesting idea and it’s great to see Ubuntu innovating.
However while it works well when you’re approaching the scrollbar from the inside, I think some more work needs to be done when you approach a pane form the outside.
Currently one has to move the mouse inside the pane and then out again. This has the following issues:
- It’s counter-intuitive (at least for me)
- You need to move the mouse a lot further, and in many more directions, to do a simple operation.
- If you move the mouse in, and then accidentally too far out again, you have to start from scratch. This can amplify the distance travelled by the mouse further.
I hope that you can find a way to improve this, I’d just make the scrollbar appear on the opposite side from the mouse approach, but I’m sure you’ll think of something much smarter!
Patrick
In acrobat reader pop-up windows (e.g. printing dialog) the overlay scrollbars disappear when you click on them. Then again, the normal menus in reader have also become unreadable.
Here is another idea.
Instead of having scroll bars, this [0] icon shows up behind the pointer, when the pointer is inside a scrollable area.
[0] http://postimage.org/image/2dyts6ip0/
The pointer can be moved freely inside the navigation icon, and clicking on the arrows scrolls in the direction the arrows points in.
When the pointer reaches the boundary of the navigation icon, the icon will follow the pointer.
Can you follow my idea?
While this scroll bar idea is fun, I’m pretty sure that most interaction designers would point out that Fitts Law predicts it won’t perform as well as a standard scroll bar. This is because it shows a much smaller hit area at first, thereby slowing the time to acquisition.
http://en.wikipedia.org/wiki/Fitts%27s_law
So in designing this, you’ve probably blown your chances of ever working for Bruce Tognazzi
Hi jonathan, unfortunately the whole point of this cosmetic change was to have a visually interactive area much smaller at first.
On the other hand, because the thumb stays on the side, when the window is maximised, it is easier to stop in a valid position reaching the end of the screen.
There is one major problem with the new scrollbars. Previously I can click above or below the scroll button to page the view. Now I must drag the scroll button, or scroll the mouse wheel. This is worsening my RSI… Now I switch back to my keyboard PgUp/Dn keys to scroll.
I like it.
As an evolutionary approach I suggest constraining the development team to mechanisms that are user controllable through a GUI. With a feedback mechanism in place the team can see how people truly use these new concepts on a statistical basis.
Further, this would limit the already over proliferation of arcane environment variables and hidden control items that one needs to learn about to recover from impact of a designer’s experiment. I’m speaking here of the overall Linux experience as well as the haptic.
But, again, nice new concept.
Usability of these scrollbars on my netbook touchpad is really poor. Being able to click above or below the position indicator to page up and down is really important to me. This fails. It takes me out of my immersive environment wen I have to delicately scroll or take the effort to accurately place my cursor in just the right portion of the bar to finally click it to page down.
I understand this is part of a larger pursuit to unify interface design for mobile devices, tablets, netbooks and desktops. Which I think is a terrible idea. After all, shoes, bicycles, automobiles, and airplanes all allow you to get from one place to another. But people use them in very different ways.
This ‘feature’ is maddening to me, and my #1 problem with the new Natty interface.
Maybe it is just because I use a trackball, but this annoys the bejesus out of me. I often spend five or ten seconds fiddling around trying to get the thing to appear and to reliably drag it. It seems the distance to make it appear is much greater in the actual application than in this video.
And I hate not being able to tell where I am in a document at a glance. And even in the best scenario, it makes it more time consuming to scroll. Before, I could look at the slider, move my mouse there, and slide it. Now, I have to move my mouse in the general vicinity, wait for the slider to show up, then move my mouse there and slide it. It’s aggravating.
I understand where you’re coming from, it’s fine, but for the love of God…ALLOW US TO DISABLE IT.
PLEASE, PLEASE, PLEASE.
They save space and waste time. A classic tradeoff. I have plenty of desktop real estate. I use two monitors to increase my productivity. These overlay scroll bars reduce my productivity. I think this new feature was only appropriate for small-screen devices. It should not be the default in a desktop install.
Dear Sirs:
quote:
(Your requirements.)
Has to reduce at the minimum the usage of screen real-estate: to provide more immersive experiences.
Has to allow the user the ability to interact with 100% of the content surface: to be able to work over any content already created.
Has to work well both on cursor driven UI and on touch ones: this is a prerequisite of any Unity solution.
Shouldn’t conflict with the window resizing functionalities (ie. dragging windows borders)
end quote.
I notice that none of the requirements listed are USABILITY and FUNCTIONALITY. While the bar looks cool (if you are into cool), it is totally useless. Imagine you are a driving 18 wheel truck. Imagine that a child is running across the street. Imagine that your break would be this scrollbar. So, to stop the truck you take two steps (1) hunt for the scrollbar, (2) push on the break. Ooops you ran over the child.
The MORAL of the story. Cool is cool. But usability and functionality comes first.
Getting to the saving space. Typical window is 100mm x 100mm. Typical normal scrollbar is 3mmx 100mm on the bottom and 3mm x 100mm on the right. So total area of normal useful scrollbars is 3×100 + 3×100= 600mm^2. Total window area is 100mm x 100mm = 10,000mm^2. In other words by making the scrollbar invisible (and useless) you saved 600/10,000 or 6 lousy percent.
-respectfully
-Jim
Nice idea but I don’t find the damn things! Using a laptop with no touchscreen or mouse wheel, I need the scroll bar to do longer scrolling. My display has 150 ppi (which I hope is at least as much the future as touch interaction is) so your 1-pixel-or-what wide indicator is a nice try but no help whatsoever. I want the scroll bar to show up when I mouse-over the right edge of the window, not only the scroll bar itself. Because if I have no fricking clue where the damn thing is, how am I supposed to make it show up?
You might want to try the future version of the overlay scrollbars, which does exactly what you want (“show up when I mouse-over the right edge of the window, not only the scroll bar itself”), as shown here: http://vimeo.com/30096481
You can install this development/preview version here: https://launchpad.net/~ayatana-scrollbar-team/+archive/release
Sorry, are we talking “Ubuntu Mobile” here? If so, using ideas from mainstream mobile operating systems such as Android and Symbian makes sense. But no, I’ve just downloaded Ubuntu, to use with my 1680×1050 mouse operated display, and you’re saying it’s better that it now uses scrollbars optimised for phones? Even on a netbook, I’d prefer the standard UI.
For a large display and/or using a mouse, you’ve violated Fitt’s Law. Firstly the smaller scrollbar that’s harder to hit. But another problem is that to drag, I first have to move to the scrollbar, I can no longer just click elsewhere on the scrollbar, meaning a longer mouse movement distance.
Even if this *was* for a mobile, I don’t see how a thin hard to hit scrollbar is a good thing, when people are using their fingers – typically larger UI elements are needed, not smaller!
“Has to reduce at the minimum the usage of screen real-estate” – it’s odd that you worry about a few scrollbar pixels, when tonnes of space is wasted on things like the Unity “task bar”, the sidebars in every file window, not to mention the gargantuan window that opens when you click the “Unity” start button.
“Has to work well both on cursor driven UI and on touch ones” – unfortunately, it fails on both.
@Mark, for 12.04 the pointer interaction will be dramatically improved: http://vimeo.com/30096481
Thanks for your feedback!
ohh, i so dont like it!! its useless! i mean with widescreens allover the place…
even on smallscreens like 10″ there is no point in doing this, you are just ruining indicator of page. vertical space is needed more, so 2 panels in gnome2 were bad thing for small screens. i dont like this solution at all…
i mean really? scrollbars? is that whats been using up my screen??
my first attempt as a gui program was a ‘mind-machine’ begun in 1996 with plain Xlib; i gave up on it circa 2002. Xaw toolkit. in december, 2011 i decided that since i was the first multiply disabled electrical engineer and computer geek — and, as far as i know, the only one — that i would finally do what i had been promising to do for years: write a gui program for people who could type but whose speech was impaired. or people who were entirely mute.
as usual, i dived in head first with gtk. some of my help windows had those loathesome thin-red-lined and that tiny slider that i had trouble grabbing before it melted away. but i figured i would deal with that later. it wasn’t until i got into the Options drop-down where the user selects several things that i stumbled into trouble again.
i have horizontal bar that espeak uses for pitch, volume, speed, &c. the hscale widgets render flawlessly; but the scrollbars were, again, these thin lines with the bloody thumbs. i tried adjusting my v 11.10 settings. nope. no way i could grab hold of the stubby and vanishing slider. at least not consistantly. the thumb fades after two seconds; that isn’t enough for those with any kind of movement disorder. {how about this: that the moment the cursor hits the red line, the cursor is placed atop the thumb?}
i understand the need for such radical changes given the tint cell displays, but this was simply thrust upon us. –if there Was any annoucement, i never saw it.
i asked all over; zip. finally tracked down the concept of “overlay-scrollbars” and got rid of it. it has been a royal PITA–whatever the rationale.
Next Time there is any kind of change that affects the UI, i think the community should learn of it months in advance, one, and have the option of using or not using it, two.