I agree. The first time I saw the Google wave scrollbar I thought that it was a visual glitch because it looked like the scrollbar had somehow floated outside the frame.
And the most disturbing thing in my opinion is that using my mouse's scroll wheel is very laggy, especially on longer waves. I would much rather they let the browser handle scrolling and scroll bars naturally. It would be much more efficient.
I really appreciate Google's attempt to revisit some of the basic UI interactions that we often take for granted. Scrollbar behavior has stabilized and works well for most situations, but this doesn't mean it can't be improved.
However, this new scrollbar approach seems complex and Rube Goldbergesque. For a new UI control to disrupt a firmly entrenched UI control, it's got to scream simplicity, elegance, and why-didn't-I-think-of-that obviousness. And the very best UI controls are the ones that you never notice.
Two major reasons Google added this new scrollbar:
1. Stop "jumping document width madness". With the OS scrollbar (on windows at least) the document would shrink with the scrollbar width when its length starts requiring a scrollbar.
Collapsing/Expanding a thread which makes the document shorter/longer than its view space will thus shift all centered designs right/left.
2. Does not take space. The scrollbar is drawn NO TOP of page elements. It does not occupy its own dedicated space.
Even worse were always-present scrollbars even when having nothing to scroll) as misguided attempts to solve problem 1.
The default behavior of most apps is to not show scrollbars unless there's scrollable content. So it would be inconsistent to have a web browser behave differently.
The scrollbars are ALWAS there. Even when not needed. Taking up valuable screen real estate. Just for the eventuality that they will be necessary. In the future.
Maybe not misguided, but not an ideal solution either. Google's seems better.
one possible solution is the one Mozilla Bespin went with where there's a hovering translucent scroll bar which varies in opacity depending on whether you're hovered over it.
MADNESS!!!! A context sensitive UI element that only appears when you want it to and doesn't clutter up the visual space when you don't need it? INSANITY!!!
This is a keen observation. Google's solution to this problem would be tolerable if the scrollbar managed to keep up with the simple act of scrolling. Instead it makes the entire app feel about 50% slower...like it's trying to calculate primes or fold proteins in the background or something.
I just noticed, without thinking about it, while reading through these comments, I was holding onto the scroll bar, moving the page up and down as needed to read everything. My hand and mind were in perfect sync, I was able to read and scroll seamlessly.
When using Google Wave, I feel like I'm actually BATTLING with the browser to find information. The scroll bar in Google Wave is a flaw in my opinion. A seriously poor design decision.
Random speculation: Google put this feature in Wave to get some early feedback before including it as the default scrollbar behavior in Chrome OS.
I will most likely be verifiably wrong about this soon, but it would make sense given Google's strategy of testing things out in small batches before making it default. Why the comment about "mobile devices and netbooks"? Why Wave? They could just as well put these scrollbars in Gmail or any other Google product. It doesn't make sense to me, except if they want people to try it out and work out the kinks before putting it in Chrome OS where 1) the primary target is "mobile devices and netbooks" and 2) they can much more easily make that the default scrollbar behavior.
Oh, come on. We are talking here about densly populated Switzerland in the middle of densly populated Europe. There is no such thing as remoteness there :-)
I guess that depends on your definition of the word "remote". By American standards, Switzerland would be too small to have remote areas anyway since you can pretty much cross the whole country in a few hours ☺
But there are, in fact, areas which are only sparsely populated.
The concluding sentence of this article precisely describes my complete experience with Google Wave: "without knowing exactly what problem the people at Google were trying to solve with their scrollbar, it’s impossible to say whether this change would work for them"
It's nice to see a design critique where the author actually acknowledges that it's ultimately impossible to judge the success of a design without knowing the context in which it was created.
True, even though it hasn't prevented him from suggesting his solution. But my point was that it is still unknown -- I would dare guess even to its creators -- what problem is Google Wave supposed to solve.
If they are really trying to save screen real estate by shrinking the width of scrollbars, they have wasted lots of it between the empty spaces between the windows.
That space is already there for aesthetic reasons (visual separation of content, etc.).
You'll notice that the scrollgadget is overlayed ON TOP of the that separation space/margins. Very visible when switching beteen a very short (non-scoll) wave and a long, paginated one.
I haven't had the opportunity to use the Google Wave scrollbars, but it seems that one advantage would be a consistent and reasonable sized target to click in order to scroll.
I've always found it quite difficult to scroll really large documents with the standard type of scrollbars. The click target is ridiculously small and so is hard to hit with the mouse, and then the scroll is very sensitive, so it's easy to skip over too much too quickly.
I feel its the sort of thing where there are pros and cons, and really, convincing people to change the way they collaborate online is a lofty enough goal as is, without needing to change the way people use scrollbars.
If your mouse has a proper acceleration curve (as, for instance OS X does, or Linux can be made to), then moving the mouse slowly → small movements, and tiny targets and small movements are pretty easy to manage.
The plethora of apps designed specifically to fix OS X's obviously horribly broken and unusable acceleration curve is the only counter the universe needs against your argument.
Everyone seems to be overlooking something that was actually mentioned in the article and I think seems like a pretty obvious reason: extensibility. In a wave, people are constantly updating things all over the place. The ability to show when and where on the wave updates are taking place would, IMO, clearly be a useful feature worthy of implementing a custom scroll bar.
Wow, I had never noticed that shadow thumb until this article pointed it out. I had to go back play with it. A couple other random observations: when you click on one of the arrows the real thumb doesn't snap up to the shadow thumb until you've moved the cursor a certain distance away. Also, scrolling by clicking and dragging the thumb has the lag effect mentioned in the article, but scrolling with two fingers on my trackpad doesn't.
I think the other problem that isn't mentioned in the article is that, at least for long waves, loading of content seems to make scrolling jerky and unpredictable.
They could have (maybe?) used better visual cues to make it obvious that it was a velocity control rather than a displacement. Other than that, I think the netbook argument makes a ton of sense. Even on my fullsized screen, I hate scrolling down really long pages. I also think that it's silly that if you have a really long page the scroll "sensitivity" will be much higher in a traditional scrollbar. I use the mousepad scroller more often for that reason.
The scrollbar had the up and down buttons near the scroll thumb. Clicking on them also moved the mouse cursor with the button. This requires an X11 server where the mouse cursor can be moved programmatically ('warped').
One of the reasons listed is that in the future they could add other indicators, but the native scrollbars can already do this. For example in XCode when you compile your code I believe little red lines will appear in your scrollbar at the lines that have compiler errors.
I personally really hate the scrollbar, mostly because waves can be really long and I like the feature of a normal scrollbar in that it represents the length of the scrollable material.
Well thank goodness someone agrees with me. I just hope the Googlers reading this get the idea. And as someone said, a mousewheel is the solution - hopefully temporarily.
I would really like to get some sort of iPhone-like implementation. Maybe one that fades in as you come close to the right edge of the window, and in that case with clickable buttons just for legacies sake.
I think Apple could easily do that. All the mice they sell allow for scrolling, as do all their trackpads. And they particularly like not caring about any legacies.
The scroll balls on the mice in my university's library make the screen scroll up, no matter which direction you move them. It forces me to use the scroll bars, which is so annoying that I'm tempted to carry my lovely pocket mouse with me everywhere.
I don't remember the last time I used a vertical scroll bar - for me it's always the mouse wheel (on the desktop) or the right edge of the touchpad (on the laptop).
I think the default for most mouse wheels is about 3 lines of vertical movement at a time.
When you need to jump down 3 pages to the comments, or to a deeper page in a document, most people don't wheel down 3 lines at a time, they grab the scroll bar and zip to the bottom of the page.
Not at all true. Lots of people click, hold and move the mouse as they read. Especially on laptops.
I, for one, hate that scrolling is achieved by moving my finger to the right of my touch pad and therefore tend to scroll by clicking on the window and using the up and down keys. (Overall, I love the mac method of using two fingers to scroll).
Flash scrollbars, these 'infinite ajax scrollbars', and this google scrollbar all fail miserably IMHO.