One 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!
Great job guys! This looks awesome!
Well, what can I say, this solution surprised me (in a good way), when I saw the the orange bar I thought “Mac OS” then, that thing appeared and I liked it instantly. I like out-of-the-box solutions :)
Good luck guys, and I think you’ll be the winners.
Is fantastic :) i love the idea, and at first i was thinking that apple will do this to Mac OS X, but i am so happy to see this in our Ubuntu that taste very good on every next bite :)) yummy :)
Finally, an uncontroversial idea :-) . This is truly great work which would be great if it could be included in Natty.
This is interesting. I have however one concern. One thing scrollbars provide for me is the indication that a document is bigger than the window displaying it. A common incident I encounter is a VNC/RDP window too small to display the entire desktop of the target system. When this happens big scrollbars pop up and I get an instant (ugly) visual cue that my window is too small.
In your prototypes you have a little orange or gray line to represent the scroll position. I’m concerned this is not obvious enough and I might tune it out. Of course it might just be that I’m conditioned to notice the gray scrollbars.
Great looking solution, nice to see genuine innovation, cannot wait to try it.
Yes, that’s a fine solution (y)
Inspiring work…. hope to see this in Natty
Why not use that thin orange line and let it thicken quite a bit when the mouse is approaching? That would have the same positive effects as this overlay scrollbar but look better confuse and will possibly (I’m now ignoring your research and am going on my gut feeling) confuse new users (coming from Windows) less.
The scrollbar thumb is an interesting UI element, the least you need it (small scrolling available) the bigger it is. Unfortunately it is quite common to have a long thumb and having a long element resizing can be quite distracting.
Thanks for your feedback!
if there is a chance, can you make other images for horizontal scroll buttons, because the “source of light” is different, horizaontal scroll should have light from top :) any way excelent work, i am proffesional designer, and for next release i will try to help your team…
You can always set the lower limit of scrollbar thumb size to reasonable value to have it big enough to act as UI element and not only as (even informative) decoration. Just make it thicker under mouse pointer (as YouTube scrolling now).
Your proposed solution offers extra (and new) UI element which is not good idea in general. IMHO.
As I mentioned briefly in the video, the visuals you have seen are not final. I will definitely pass your comment to our visual artist!
Any help is always welcome ;) Thanks a lot!
this is very very good idea Dmitry !!! go and search ( http://omgubuntu.co.uk ; http://webupd8.org ) you will see that people who test this = love this
Hi, you did a nice work with the scrollbars.
I’m just wondering if it’s just me, or someone else has this problem too: I just can’t understand how badly Gnome treats screen-estate. All window elements have HUGE GAPS in between – for example: all tabs on your picture above has at least twice the margin as it should have. I’ve used Monodevelop for some time, and it was a horror because of these oversized window-margins and useless paddings. It’s like using my grandma’s Firefox with 8 toolbars open – you can barely see the content of the window, with half of the screen lost to garbage.
With smaller resolution displays (tablets in mind) I guess it’s equally a big problem and distraction as the scrollbars-issue:)
I have a few questions. First, what about the ability to middle-click (or Shift-click) any part of a scrollbar to jump to that point on a page? Is this still possible somehow? Personally, I use that feature a lot (so much so that I would even prefer if that were the default left-click behaviour). Secondly, is this themeable? Personally, I would prefer the thin scroll indicator (what’s its official name, anyway?) to be uncoloured (at least when the content area is idle) and to have rounded ends, like elementary’s minimalistic scrollbars.
I also have a few comments about the design. I would prefer if 100% of the content area of any window were devoted to content. Thus, I would prefer a solution that didn’t even have that thin scroll indicator permanently taking up space. Have you considered, instead, overlaying it when scrolling and when the pointer is at the window edge (or the edge of the screen)? Finally, the fact that the Page Up/Down buttons don’t move while active is a little weird, since they temporarily break their visual association with the scroll indicator. Have you considered, instead, moving the buttons as the scroll indicator moves, while also moving the pointer with it? I realize that moving the pointer is a bit unprecedented and weird, but I wonder if it would be less weird than the current behaviour.
Finally, I love that this type of innovation in design is taking place in a shipping product, rather than in an academic context, where ideas take 20 years to be brought to market. I hope to see more! Thank you.
The scroll overlay is a larger target though. If I have a very long document (>1000 pages) it is still easy to grip. If I only have the orange line to grip, it would be much more difficult.
@Christian:
falling over from Marks article, and not being this “Desktop” guy, I have to say:
This is f*cking awesome.
Normally I eat what you present me, unity wise, but what you showed in the video…dude, this is….sorry to repeat me here.
Well done…and You people are on the right track.
I’m waited for years to have linux on a desktop…and now you and mark as stakeholder give it to me….
really, this is awesome…thx for sharing….can’t wait to have it on my laptop….
\sh
If you implement it like that then I’d like it to always be inside the window since that would look better. But instead of having an scrollbar overlay I’d rather you make the “position indicator” bar expand into a real scrollbar on mouse-over.
Thats indeed great.
I got a question though. Since when did the keyboard become irrelevant in favour of touch screens? You didnt mention it not once.
Are those improvements keyboard friendly?
Sure, keyboard on desktop and laptops didn’t loose any relevance in favor of touch screens. These scrollbars will be as keyboard friendly as the previous ones.
It has been so far a visual, GUI, make over, but one day we might explore if the keyboard interaction can be any better. Thanks for asking!
I wonder if the search result indication Google Chrome has (yellow marks on the scroll bar where the entered search term was found on the page) could be made to work with those new scroll bars. It’s a really handy feature I wouldn’t want to miss.
Hot shit guys. The scrollbar is an idicator for most people anyway.
Do you have statistics on the usage of mouse-wheel vs. scrollbar?
One thing I haven’t seen written about is accessibility. Did you user tests involve people with non-standard needs?
Don’t get me wrong, I think this looks great and I would certainly enjoy using it but can the user change it to something that might better suit their physical needs?
Well i love it, kudos.
Hi Jackie, we feel your concerns. The scrollbars can be easily disabled in the settings.
I wasn’t unable to see this video until I opened up the page on Vimeo. Maybe you have some bug with the embed code… :)
Excellent news, Christian. Good luck with it.
Who’s the visual artist for this GUI, and in other GUI visuals for Ubuntu?
[Desktop+Notebook User] Don’t remember when I use scrollbar the last time. So in my case you may abandon it completely. :-)
@Løvskogen
The Visual Design Lead for Unity is Otto: http://design.canonical.com/theteam/
I use my scrollbar mostly to keep track of where I am in the page content, I feel that the orange “rim” will be a lot more noticeable than the “whiteish”, which is nice because sometimes it takes a while to see where you are with the current scrollbar(using 10.10).
Gotta give mad props for the “new” font as well. :)
Great effort and good ideas. However, I would like to suggest that you look into adding some kind of cue that a view is scrollable. It might not always be obvious that there is additional content hidden away when the orange scroll indicators are so small.
intriguing… was wondering why the scroller widget doesn’t simply appear over the orange rim instead of offset inside/outside?
This is great news! The UI in Ubuntu is shaping up so quickly! It’s almost unbelievable. It’s completely unlike anything we’ve seen in other Linux distros.
I have a question: Is it possible to keep the small, “near invisible” scroll indicators, (which I loved) but not to have the overlay “thumb” with the arrows (the one that appears when you hover?) I never click the arrows or drag scroll bars… And I can see the overlay appearing all the time being a distraction for me…
I would really appreciate some setting to disable it. (But not the new scroll bars)
Thanks! :-)
Would have loved to see how Eclipse looks with overlay scrollbars :)
Yes, great.
vimeo is terminally broken for me (yes, I am running linux) and even if it worked I’m severely bandwidth limited, and so I have no idea what this is about.
Please post some pictures, and appropriate descriptive text, instead of the “here, look at this video, which half the world is unable to access”.
I recommend Tiny Menu for Firefox. It reduces the screen space the browser GUI takes away from the web page.
http://addons.mozilla.org/firefox/addon/tiny-menu/
Well thought!
I think this sums up the problem with Ubuntu and Linux-based operating systems.
They are constantly trying to fix what isn’t broken. People have huge amounts of horizontal space on modern screens, meaning two 16px scrollbars only represent 2.5% of the available horizontal space even on a typical 1280×800 resolution 13″ laptop. Vertical scrollbars are more problematic (one will take 2%), but uncommon: software that relies on them is rare and is generally badly designed (e.g. Eclipse). Ignoring whatever merits the design has (I dislike floating UI widgets), it’s not something that needs to be fixed.
Meanwhile, it’s near impossible to fix what is broken. Most notably, this is the misuse of huge amounts of vertical space by comedy-sized widgets and silly amounts of whitespace, which is a *huge* inconvenience on low-resolution devices, making GNOME software near unusable.
Even worse, by making scrollbars smaller, it makes the comedy-sized widgets and whitespace look even bigger, so the design looks imbalanced and ridiculous.
Awwwwwww, but now how will my Content Aware Scrollbars fit?
http://www.chrisnorstrom.com/2011/02/creation-introducing-the-content-aware-scrollbar-ui/
I like both scrollbars actually, my content aware scrollbars are really only useful when used for web browsers, and these new overlay scrollbars for email programs, system settings, and every thing else.
But I do agree with Oliver, this is fixing what wasn’t broken, and I feel it’s harder on the eyes to try to find the tiny little orange overlay scrollbar. The smaller it is, the more colorful it has to be to stand out easily but by making it orange and other colors it just becomes distracting again.
This is the first big UX work from Canonical that I actually like as far as I can remember.
To those suggesting that this is a fix for something that wasn’t broken, you are wrong. It may not be broken for you, but it is for many; I’d bet even most. People hate scrollbars when they get in the way.
To those suggesting that Gnome is unusable due to large UI elements, this is controlled by the theme. Try Clarity or Elegant Brit: both of these have a slimmer UI.
To those complaining that the bars are too small, I’d be extremely surprised if this wasn’t set by the theme. Furthermore, I think you’re probably wrong. I’ve been using Elegant Brit for a while; it has an orange scroll bar about 5 (or so) pixels wide, and it’s extremely visible.
I like the idea. As everybody seems to hide essential interactive tools for getting a bit more screen real estate: my kudos for this solution that seems to combine visibility, minimal GUI and efficiency very good.
Shouldn’t that scrollbar be on inner side of window ? On outer side it looks chaotic I suppose.
Why the right side only? Such a small indicator could be put symmetrically on both sides of the viewing pane at the same time. It’d be much more efficient (time / motion wise) to scroll the window for the user.
And while it sounds odd and over-decorated, I bet it’s an issue that we’re just accustomed to the 1 bar on the right of the window. Symmetrical tracks (after acclimation) would feel more analogous to the real-world. Paper between two tracks of the auto-feed on your scanner or printer, for example. The space-hogging scroll thumb would only appear on the side you move your mouse to scroll, but the thin, slivered indicators would provide more useful and comfortable feedback (after acclimation).
I agree with the person above. The indicator is so small it could be placed on both sides of the page. That would actually be a nice improvement, because most interaction is on the left side of the window.
I agree with some of the posters before: Gnome really has ridiculous padding/margin of UI elements.
I wonder why people always have to write their own .gtkrc file to make it bearable again.
Wouldn’t it be possible to fix that, once and for all?
in my opinion, it is very difficult to change the size of a window, because it is so hard to “catch” the small area, the border, where you can pull the window to enlarge it.
thats why i like the corner “right-bottom”, which is easier to catch.
hopefully this corner will not be removed.
greetings
Besides the accessibility issue (that seems to have been tackled), did you make any usability testing (or plan to do so) for this change?
Scrollbars are UI elements that are used by less technical users and despite the really elegant design, i feel that we are trading something that works well or in a familiar fashion for something new that lacks visual keys, that lacks “discoverability”.
In several usability tests that i made, i saw users struggle to understand that webpage/app was scrollable, i saw users inefficiently use the scrollbar arrows to go up and down (never using the bar or the scroll wheel), etc.
If we want effectively to “cross the chasm” we have to be careful not to break what is working.
I’m not saying that this idea won’t work, but for something that has existed so long, we have to make sure that we aren’t doing any regression to the interaction experience, hence question about usability testing.
There is a real tricky line between design innovation and usability, we must make conscious decisions about the trade-offs.
As a final note, i don’t want to undermine your work, i think the Design Team is doing a great effort to improve ubuntu.
Keep up.
Hi David, please have a look to the User Testing section. Thanks for sharing your concerns!
One feature I really like in current interfaces is the single line scroll. This seems to do away with that.
Perhaps the scroll bar/scroll tab could be scaled. Clicks at the edges of the tab would cause page scrolls, clicks towards the center would give single line scrolls.
If you wanted to be excessive it could go so far as to have widgets in metacity just like current window controls with an ability to turn on or off line scroll, page scroll, top/end jump.
The scroll tab concept is great and it’s a positive step.
Gus
@xy,
I agree, grabbing window edges takes a fair bit of precision. Using the same model as they have illustrated here, the bottom corner could easily expand to a “grab box” to make it easier to catch, especially with low precision input devices.
Gus
It looks great. I’m just afraid the current middle-button-click functionality won’t be preserved. Will it be?
i was thinking in mouse gestures instead of scrollbars,
the velocity increase according the distance percentage
check the image
http://khipu.edu.ec/scroll.png
Good idea for netbooks. It also very well for small controls with scrolling, where scrollbar hide a part of text. It will get more place now for content.
Cool!
A very intuitive and cool solution. Even on my 21.5 desktop screen, in gnome, I always feel like the interface is geting too much of my screen :D.
Canonical should follow a new strategy for the launch of Unity.
Below is a link to view the model of the idea.
Community participation and a greater period of development is important.
http://i.imgur.com/pce7m.jpg
Wow!!!
Im really like it!! :D:D
looks great!
will it be included in final natty?
Yes, quite likely only on few well tested applications. Thanks!
Idea for Unity – Mockup
I did a mock-up with new ideas for Ubuntu Unity, including social networks and a better interface with menus.
The Unity is still a little confused. Many users find it difficult to use it. It would be nice ubuntu users post their opinions about an improvement in usability of the Unity.
Mockup this video:
http://www.youtube.com/watch_popup?v=0O6v9miJKGI&vq=hd720
Forum:
http://ubuntuforums.org/showthread.php?p=10591849#post10591849
Post Webup8:
http://www.webupd8.org/2011/03/unity-video-mockup-better-menus-social.html
Blog:
http://unitymockup.blogspot.com/
Inspiration from Google Wave scrollbars?
How does the scroll bar interaction work with resizing windows? (which is a very old and well known ubuntu bug).
Does this mean that resizing will be left to a specific place(s) on windows or will there be a finer interaction with window borders?
I don’t think that would work in a touch environment, as you would have to move your finger along with the scroll bar. As it is now, all you’d need to do is simply tap the same place on the screen repeatedly to scroll down a lot.
Bravo! I clapped irl, great idea and well executed.
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.
Uncontroversial? This is one of the worst ideas ever.
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.
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!
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.
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.)
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.
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
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,
Which settings?
Which settings contain the ability to disable or change the color?
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
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 concur with the need for a consistent/predictable position – inside the outside is unnecessary. This predictability is the only shortcoming I see in metaphor – or whatever you call it.
To that end, I’d like a fixed (hidden is ok) area where I can reliably do page control. Searching for the visual telltale then getting the scroll control to appear, then moving to the arrow to page is too many steps. A quick touch at the upper or lower corner of the window would be better.
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
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
Christian –
We do understand that you tested this change. With all due respect, it’s very hard to cover all the cases, particularly for some stroke of genius you’ve had yourself. I’ve designed a number of UIs myself, so I know the user default reaction to change is usually excessively conservative, but that’s not something you should pooh-pooh. Users have good reason to be attached to the expertise they’ve developed.
Sometimes resistance to change is simply a matter of things working well in some places but not others. I really liked the unity launcher on netbooks, I’m a lot less enthusiastic about it on the desktop or laptop, particularly as it steals focus from app widgets near the edge of a maximized window.
The Overlay scrollbars are a terrific idea on tablets, because scrollbars are just vestigial there. On a desktop they’re OK, because you’ve got the scroll wheel. On a laptop with a trackpoint or trackpad, they’re poison — and there’s not clearly documented way of undoing the change other than switching desktop; you have to search in Google.
Here’s the shortcomings of this change as I see them:
(1) If you actually want to use the scrollbar instead of a wheel or keyboard to scroll the “popping” of the dragging widget actually works against content immersion.
(2) The dragging widget pops inconsistently depending on the maximization state of the window, requiring more attention diverted to it.
(3) If you want to use the scrollbar to scroll a long document on a large screen, the visual target to make the dragging widget pop is tiny.
(4) The appearance and behavior of scrollbars is inconsistent between applications and utilities is inconsistent. In some cases (Firefox) this is because the app designers draw the scrollbars with a toolkit rather than rely on the window manager. But the scrollbars in the launcher’s “Dash Home” appear and behave differently from the scrollbars created by the window manager for no apparent reason. If you make a change like this, all the major apps in the distribution should look the same and respond to the same settings.
(5) Documentation and configurations options are not provided. It wouldn’t be so hard to list all the radical changes introduced in the “About Ubuntu…” window with a link to undoing them. Documentation in general has been a sore point in recent Ubuntu releases.
On the plus side, the new scrollbars look great, even if they don’t work that well for me. I’m generally an early adopter, but I prefer the UI to fade into the background rather than draw attention to itself. Apple’s iPad UI does this; it’s initially impressive, but after a few minutes’ use it disappears from consciousness. Overlay scrollbars remind me more of the Windows tablet interface; they look great, but they never quite fade into the background like they should.
-Matt
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??
Jim,
Forget the respectfully. I just tried using UNITY… Takes twice as long gnome to do anything, why are we going back to having to know the name of the programs you want to run and having to type them into a command line!
It’s the most confusing, ugly and amateurish interface I’ve ever had the misfortune to come accross. Its the biggest mystery meat tour I’ve ever seen. Took me five minutes to work out how to log out of the system.
Respect will be deserved when this rubbish is canned.
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.
I have found in 12.04 that the scroll bars make resizing windows very difficult. Extremely small area to grab to resize. The demo vid uses a window with the horizontal scroll bar slightly above the bottom of the window. In 12.04 many status bars, buttons and other useful stuff has been done away with. When the scroll bar is on the very bottom of the window it is hard to resize, especially with overlapping windows and scroll bars.
The video makes them look good, but in practice they are very annoying… even dangerous.
It is now virtually impossible to resize windows via the right-side resize-grip, and sometimes the bottom-side resize-grip too.
In practice, many times I click on the floating scrollbar and try to drag it up and down… only to find out I “just missed” and am dragging a file or other window content. In nautilus, I’ve accidentally dragged and dropped files (into a folder somewhere) this way, and could not figure out what file was moved to reverse the action. The only solution was to reinstall and reconfigure ubuntu (or an application), which is very time consuming and annoying. I suppose backup software could mitigate this, if activated, but few people do.
Bottom line: I understand the desire, but this implementation is a FAIL. Try again, and be more careful.
An update to my 20120607 post. Finally, after a couple weeks I figure out that the popup scrollbar can be dragged to resize the window! Which means, 1 of my 2 reasons for giving the new scrollbars a FAIL was half wrong (and the implementors were half right).
Why “half”? Because the mouse cursor over the popup scrollbar gives NO indication the window can be resized by dragging the popup scrollbar! Without that visual hint, most people will never realize, and will do what I was doing — flailing around trying to get the mouse cursor to turn into a resize indicator over the right edge of the window. If you fix this, you fully solve one of the two problems I identified in my 20120607 message.
The other problem still needs attention.
It’s absolutely terrible. I’ve been using it for ages getting more and more frustrated with it.
It’s ironic that they chose eclipse as an exemplar as it fails worst with this. Not only do the handles *not* work to resize the eclipse panels, they obscure the navigation markers that eclipse puts into the scrollbar area.
Awful. Glad I’ve figured out how to turn it off.
Agreed that the main considerations are indeed Security, Cost and Access Control. Flexible deployment solutions is the way to go until the contention for cloud storage is resolved. One can choose to offer the same solution as a public cloud edition, pure on-premise/private cloud edition and even a hybrid edition to help out with the choices for organizations. What some business may be looking for is a managed Dropbox like solution on a private cloud ? Such an option may be attractive for the reluctant cloud adopter to derive the benefits of fast, easy and stable file synchronization with the security and control of a managed environment where only user accounts created by an IT admin have the ability to access shared or synced files. We are seeing the adoption of such solutions based on our experience with our product SyncBlaze