For as long as I can remember, I’ve been having issues with scrolling in Windows and its applications. When scrolling via dragging the scroll blob, it seemed as if Windows had the annoying habit of randomly resetting your scroll blob to its starting position, which irritated me to no end. It took me a while to figure out, but I finally know when this behaviour occurs – now I just need to know: why?!
In case you’re unfamiliar with my personal graphical user interface lingo, the scroll blob is that little thing inside your scrollbar which indicates where in a document you are. It can also be used to scroll through documents, by clicking and dragging it up and down (or left and right for horizontal scrollbars).
Before we dive into the problem I mentioned, there’s actually quite a few interesting things to say about scrollbars and the scroll blob. As most of you will know, the scroll blob is proportional; the smaller it is, the larger the document you’re viewing, and vice versa. For me personally, the blob’s most memorable role is that it serves as a sort of taunting reminder of just how much more illegible scientific drab I have to wade through during studying.
Then there’s the issue of scrollbar behaviour. Clicking inside the scrollbar, but outside of the blob, can have two different outcomes, depending on system settings and operating system used: the right one, and the wrong one. Because the scroll blob is proportional, you would expect the scrollbar to be proportional too; as such, the only correct behaviour when clicking inside the scrollbar is “jump to here”. The incorrect, inconsistent, annoying and obnoxious outcome is “move one set arbitrary distance down/up”. The former outcome indicates that the computer thinks I’m smart, while the latter indicates that the computer gives me a reassuring pat on the back, thinking “I know what’s best for you, now shut up”.
Yes, any system that uses the latter setting is wrong. Non-negotiable. I’m quite strict on this. Oh, and I base it on absolutely no evidence whatsoever.
Finally, the issue of the scrollbar arrows. There is only one correct way of displaying the scrollbar arrows: grouped. BeOS already knew this, and who are we to argue with what is probably the best operating system of all time? In all seriousness, the reason grouping them is better is that it reduces the amount of mouse movements you need to make when scrolling. Sure, mouse wheels and the like have reduced the significance of the arrows considerably, but I still sometimes find myself using them. On top of that, I dislike touchpad scrolling, so on laptops I’m pretty much confined to the arrow keys and the actual scrollbar itself.
Now, moving on to the actual problem at hand. The problem I see is that during scroll blob drag operations, Windows creates an invisible “hotspot” around the scrollbar; if you move your mouse cursor outside of this hotspot while still dragging the blob, it will reset itself to its initial position. If you’re still holding down the mouse button, the reset is visual only; moving your mouse pointer back into the hotspot will “undo” the reset. If you release, however, the reset will become permanent.
The actual problem here is that this hotspot is too small. The below screenshot indicates the size of the hotspot.
The width of the hotspot is sort-of adequate; you’ll rarely find yourself veering off that far east or west (but it does happen). The real issue here is north and south: as you can see in the shot, there is barely any space to move your mouse before the blob will reset itself. I use the blob drag behaviour all the time (especially on sites with lots of comments, like OSAlert), so I run into this annoying problem continuously.
The million dollar question here is why on earth does this hotspot exist in the first place? Can anyone think of any scenario in which this behaviour is even remotely useful? I did a little digging around, and found that even in 1999, people were complaining that KDE had adopted this annoying scrolling behaviour. Karl Fogel already concluded back then that Microsoft actually had to write additional code to get this behaviour.
The solution to this bug is drop-dead obvious: ditch the hotspot. It serves no purpose, other than to annoy and aggravate people. I should be able to move my pointer to hell and back while dragging the blob without it resetting the scrolling position.
Can anyone tell me if other systems have been affected by this bug as well? Does KDE still have it? GNOME? Mac OS X?
Thom, this article raises one valid and well defended point, that yanking a scroll “blob” up or down and moving the mouse beyond the length of the scrollbar should not reset position.
Before getting there, it throws in a couple of unsubstantiated opinions defended not by logic but rhetoric (location of up/down boxes, behavior when clicking in scrollbar) that don’t add to your argument. Probably you’re losing readers before they get to the end. This is not good journalism.
(Written from OSX with up/down arrows configured to be at opposite ends of the scrollbar.)
It’s clearly tongue-in-cheek. We take stuff like this way too seriously.
There’s a bug in XP where you can actually make the scroll area hotspot colours invert:
IIRC its done by left clicking one arrow then right click which still pressing the left mouse button down.
Then repeat the process on the reverse arrow.
Now, when you drag the scroll bar, the hotspot inverts
I agree with malxau. As I wrote somewhere before, personally I prefer articles that stay factual, but I can tolerate those that don’t.
Tongue-in-cheek is fine, but you shouldn’t overdo it. And almost the whole first half of this entry being in Maddox mode clearly is overdone, for my taste. Starting with “Dear diary” would fit this article perfectly.
Please, less of that.
Edited 2009-12-10 23:38 UTC
It was clearly tongue-in-cheek, but I still thought you were an idiot for having that opinion.
and here on win 7 it doesn’t do it
and i’ve never seen experienced it
but the reset when movieng away to the side is realy annoying
Windows 7 does do it here… But not on all applications: Internet Explorer 8 doesn’t do it, Outlook 2007 doesn’t do it, Chrome does do it as does Notepad++.
I’m using KDE 4.3 here and it doesn’t behave like that.
But I can see where they came with that. Microsoft does everything so the user can undo if regretted. Even a simple scrolling. So, if the insecure and shivering user regrets his daring scrolling operation, he can back off safely to where it was.
FYI: Clicking on the scroll bar but above/below the scroll block, usually has the same effect as pressing PageUp or PageDown on the keyboard.
You can undo pretty much any drag-n-drop operation in Windows (before you release the mouse button), including dragging the scroll bar, by pressing the ESC key.
The ESC while dragging the scrollbar doesn’t work in XP.
While I can understand that it’s annoying when the behaviour is not understood, I regularly find myself using this ‘annoyance’ as a feature.
It helps to cancel and go back to exactly where I was before I scrolled in case I’m in a long document and don’t want to have to look for the spot again.
Although I never noticed the problem with the north/south aspect, I see that as the worst part of it, but then only in theory since I never actually had a problem with it.
As for the buttons grouped…I think the scrollbar looks nicer when they are on opposite ends, but that is subjective. I hardly ever use them, what with scrollwheels.
I agree about cancelling. I actually use this frequently when reading a long document. I come across something that reminds me of something I saw before, and I want to look back real quick. I grab the scroll bar up to find what I wanted to look at (perhaps some other text, or a referenced figure, diagram, or table), hold it for a second, and then move off to the side and release in order to get back where I was before.
I actually do that too without thinking, though I can understand why the “vertical” hotspot is a problem.
Left/right hotspot would be enough for me at least.
The correct scrollbar placement IMO is grouped, but on *both ends*. That way whichever place you like to place your mouse you can get both directions. The loss of vertical space is rarely important… and you could put in simple rules saying “if smaller than foo, hide one set of arrows.”
Thus solving the problem in a way everyone will love, except UI wonks.
I’ve always done that by moving the cursor to the side. And I only knew about that because cursor moving too far to the side is the only time I ever see my scrollbar snapback. I had no idea it did it when moving too far up or down, which is funny since that’s the direction that bothered Thom
I’m using Xubuntu. SO how does XFCE stack up to Thom’s complaints?
Reset to initial value if outside “hotspot”: Nope! You can drag the knob from anywhere on the screen and it behaves as it should.
Grouped scroll buttons: Nope. They’re on either end of the scroll bar.
Go to where you click in the scroll bar. Nope. It does the same as EVERY OS IN EXISTENCE – it scrolls up/down one set amount. Personally, I feel Thom is wrong on this point. Scrolling to where you click is a crazy idea. How good are you at estimating where to click? What if you click too far? Several times because you suck at guesstimating where to click? The only valid response to clicking in the scroll bar is to scroll that direction a set amount.
And if you look at the scrollbar as an extension of the cursor keys, it makes sense: click above the blob is like hitting Page Up; click below the blob is like hitting Page Down.
Or should hitting the Page Up key take you to some random spot in the document?
In Windows all you have to do is SHIFT-Click to go to where you click in the scrollbar.
Interesting. Apparently KDE 4.3 behaves the same way.
Why shift-click when you could use the MMB?
Thank you guys. I’ve been annoyed by this behaviour forever. I usually scroll up down in documents with the keyboard. However I often find myself wanting to go somewhere in a long document. Scrolling down with page-up/down takes forever, but clicking into the scrollbar just did the same thing. I never knew you could use the MMB or shift-click. Never thought of trying either.
Cheers
Jochen
Likewise. I’ve used windows since 3.x but never knew about this feature.
Then again it took me 8 years to learn that I could paste with shift+insert instead of ctrl+v.
Is there a setting for this? It doesn’t for me…. It does in Firefox, but not Konqueror, Dolphin, Kword or Arora… not Shif + Click, Nor CTRL or ALT + Click… I haven’t tried anything else, and it’s time for work.
You are correct.
In Firefox on KDE 4.3, shift-left-click, ctrl-left-click or middle click in the scroll bar margin = “jump” to that place proportionally.
In Dolphin or gwenview or other native KDE applications, shift and ctrl have no effect on clicks in the scroll bar margin. Middle-click alone works to “jump” to a place proportionally, while all left clicks (either with or without shift or ctrl) implement page up or page down.
For consistent behaviour, then, between GTK+ applications and native (Qt) applications under KDE4, use middle-click in the scroll-bar margin in order to jump.
Edited 2009-12-11 11:59 UTC
In Mac OS X it’s option-click.
Did you try the middle mouse button? Works for me^a"c
Like someone else said shift+click also jumps to where you point it to (tested with firefox).
With many programs I have scroll up/down grouped (firefox does have it like that) on the bottom and also a scroll button at the top but this seems to depend on the program, some do not have the scroll up/down grouping (skype 2.0.0.72 for example). Maybe this depends on the theme in use.
Not true. OSX for example does scroll to where you clicked, has no hotspot and has grouped scroll buttons. Ofcourse, Thom rather complain that use something from Apple.
All of which are customizable, just for the sake of accuracy.
If the goal is to get content from document into your brain (or vice versa), there’s a couple of obvious steps you can take to make life easier:
1. Optimize vertical real estate by turning your widescreen (aka shortscreen) monitor sideways. Obviously, this isn’t an option on laptops. Personally, I refuse to buy a new one until they stop making them in aspect ratios that put movie watching before doing actual work.
2. Stop squandering your precious vertical real estate with toolbars, giant win7 taskbars, and other UI frills.
3. Use a tiling window manager. The only way to really get all the screen you’ve paid for.
4. Use document viewers and editors that don’t require the mouse. Instead of context switching to find your cursor and carefully position it on the UI widget that translates into the scrolling command you want, just use something that lets you hit a key, like the space bar. This is even better when editing, since your fingers are already on the keyboard.
Ditto! While the Thinkpads (especially the X series) have been mocked for sticking with 4:3 displays after most others had gone widescreen, I actually prefer it and was disappointed when Lenovo changed that with the x200/300 models.
Or if you must have a giant taskbar, move it to the left (or right) of your monitor. I’ve been using this configuration since Windows 98 – it’s the only sensible layout for working on a widescreen monitor. It also allows for much more applications in the taskbar without all that silly grouping (pre-Windows 7 anyway).
Unfortunately, I’ve yet to find a Linux desktop environment that supports it without making a mess of the layout. KDE4 almost manages it but still looks ugly. It’s been completely broken in GNOME since time immemorial. XFCE nearly got it in 4.0, but broke it terribly in later versions with no sign of it ever being fixed.
The only correct behaviour when clicking inside the scrollbar is “jump to here”. The incorrect, inconsistent, annoying and obnoxious outcome is “move one set arbitrary distance down/up”.
Both solutions are wrong. “Jump to here”? What part of the window should go to the point clicked? The top? The bottom? An arbitrary point inside? Not only that, but accurately predicting the actual meaning of a relative point in a document inside the scrollbar is pretty hard, meaning that you’ll likely miss your attempt by some ammount, and once you clicked, there is no way to retry the gesture since the displaced thumb is now blocking access to the bar behind. If you want to scroll to an arbitrary point, it is better to drag the scrollbar, and you’ll have the benefit of previewing and adjusting the position as you do it.
The correct solution is to give the gesture an useful meaning: just scroll a full page of text. This is the solution used by Windows and there is absolutely zero problems with it. It is a bit invisible, though, and most people don’t know that you can click and hold to scroll continuously until the point clicked, in a way similar to your proposal.
Anyway, you’re 100% correct about the thumb reset bug and I’d love to hear an explanation from someone in the known.
I’m not going to argue this one, as it was clearly tongue-in-cheek and I know I’m pretty much alone on it anyway – but the problem I have with the scroll-one-page solution is that you end up with a proportional UI element (the blob) inside a non-proportional element (the bar). With jump-to-here, both are proportional, which makes more sense to me (and only me, probably).
By extension, you could also make the blob non-proportional, and have it have a fixed size, but this takes valuable information away.
Edited 2009-12-10 20:24 UTC
I always questioned myself as why the default behaviour was a single “page up/down” instead of the “jump here” I think would be more intuitive. I guess I’m not alone anymore!
On another note, why don’t you have your window maximized (at least vertically)? You probably wouldn’t have the problem of the top/bottom buffers to small if the window was maximized. Was it only to show the behaviour?
I’ve never understood why people don’t use 100% of their screen estate… you paid for that big screen, use it! Or even worse, on smaller screen (eg. netbook) the space is rare so I want my windows to be not only maximized, but fullscreen. But then even on my 22 inches monitor, everything’s maximized, even fullscreen’ed.
This is the reason I don’t feel at home on Mac: You loose so much screen estate…
Not having everything max by default greatly reduces the amount of window re-size operations when you do decide you want two or more windows visible.
I think _playing_ with window resizing won’t reduce the number of operations you do… We should let the window manager resize windows correctly to compare them. For example, in windows 7 the window manager can put two windows side by side easily. I had to play with wmctl to get that feature in kwin two years ago. I would love to see that incorporated directly in kwin…
If need is to compare two windows, the just unmaximize them? We migth be arguing over a window manager issue rather then screen estate maximization…
I love the Windows7 behavior when you drag windows to the right of the screen.
I should have been less specific, and included more than just comparing windows. Having a small window for some other purpose is something I do frequently, also. A calculator is a good example.
Having my windows always be maximized was my old behavior, but using a 1600×1200 screen changed all that. I am also in agreement with an above poster that screen aspect ratios for movies suck when you have work to do.
Also, I personally despise window managers that try to guess what I want to do. It really, really pisses me off.
I really wish two things for Windows window management: an always-on-top/always-on-bottom button, and multiple workspaces. Windows 95 had it, but all later versions didn’t, and third party solutions were always broken. Even the really cool Windows XP powertoy was slightly broken, but it was really nice. Being able to preview smaller versions of all four desks at once is something Aero should really shine at.
RE: Multiple Workspaces
Have you tried Virtual Desktop Manager?
http://vdm.codeplex.com/
I agree. The thing that annoys me most is windows that don’t remember your size setting and stupidly open very small with list columns stupidly narrow. So, you open the program, maximize/resize, then manually adjust the list column widths so you can read the damn stuff (because it’s too stupid to adjust automatically to the new size). If you close the program and re-open it, you have to do all that again. Microsoft programs are famous for that.
One Amiga (MUI) feature that other operating systems lack is the ability to “snapshot” all window sizes, positions and column sizes. After you snapshot (click the window gadget), the program ALWAYS opens to your preferred size and position. This works for every single Amiga MUI program. (automatic – doesn’t depend on program author) You can even back up your preferred settings and use them on another computer.
I NEVER maximise a window. It’s so utterly pointless for 99% of the applications out there – all you gain is extra white space.
I bought my large LCD to be able to see multiple windows at once – not to see the same content but with added useless whitespace.
For huge screens, I agree. I was commenting more on optimum window size – good width & position, maximum vertical space for windows I have to scroll. I’d rather not scroll unnecessarily if I can make the window big enough so that I don’t have to.
This is one of the reasons I *know* you’re crazy. I maximize all of my windows, with few exceptions. Need two windows? Alt+Tab. At once? Two screens. Works really well, futzing with sizing windows is something I haven’t done for the better part of a decade.
What you gain is having your entire workspace displaying things you care about plus a very non-distracting ether.
I maximize pretty much any window I’m working in.
Edited 2009-12-11 00:18 UTC
True… for most of the applications except… the beb browser! It depends on the particular webpage, but if the page layout is designed well you won’t get those ‘white’ spaces, and using maximization makes sense then.
Actually not true. I know of at least two windowmanagers which let you remember size,position,virtual desktop and a number of other things, enlightenment e16 and e17. I’m also quite sure that a number of other windowmanagers do have this feature.
One feature I miss in e17 that was available in e16 was the ability to group windows fixing their relative position to each other
Fluxbox can do this as well.
I’m with Thom on the scroll bar issue – that has always annoyed me!
I believe this is why Windows acts this way. In Windows 3.x and earlier, scrollbars were non-proportional, and it made sense. With proportional scrollbars, previous behavior was carried forward. I don’t know if this will be revisted someday, but it probably should be.
[q]I’m not going to argue this one, as it was clearly tongue-in-cheek and I know I’m pretty much alone on it anyway – but the problem I have with the scroll-one-page solution is that you end up with a proportional UI element (the blob) inside a non-proportional element (the bar). With jump-to-here, both are proportional, which makes more sense to me (and only me, probably)./q]
No, this makes a lot of sense to me as well… I can’t remember where i first encountered this behaviour but it always seemed more logical to me… If you want to move up or down by fixed increments you have the up/down buttons, the cursor keys and the pageup/pagedown keys.
Ofcourse, best way would be to have this option configurable, so those of us who like it can turn it on.
The bar is proportional: when you click in it, the “blob” moves a distance in proportion to the size of the document.
click and don’t release. It will page up/down until it gets where your cursor is and will then stop
Personally, I prefer to have the choice that OSX offers. If you click on the scroll bar outside the thumb, you will get one page scrolled. But if you hold the alt key while doing that, you will go directly to that location in the window.
You can also make jump to click the default for scrollbars in OSX. That is what I do. I have keys for page up and page down.
The same capability exists on Windows (7?), by shift-clicking to a scroll bar location.
I actually never knew about it, until I read your comment, and tried different alternatives. So I learned something new today, thanks.
I like in GTK where middle-click does the jump-to-here behavior
I’m a Mac guy and I don’t have so much experience with Windows… I’ve always found Windows’ scroll bars very annoying but I never realized why… now I know the “why”!!!
Thanks Tom!! I’m with you on this one!!
I’ve been complaining about this from the first time I ever used Windows. (wow, that’s 15 years of non-stop complaining…)
I wonder why more people haven’t complained about this stupid scrolling “jump off point” problem (that’s what I call it). It serves absolutely no purpose. If you still have the mouse button down, obviously you still want to be scrolling! You shouldn’t have to constantly check to see if you’ve got the arrow close to the scrollbar. The Amiga does the right thing and doesn’t care where the hell the pointer is. If you’ve got the mouse button down, you’re still scrolling.
Unfortunately, the Firefox port for BeOS has that same stupid “jump off point” behaviour. Why, why, WHY???
That and applications that use the older Windows libraries that do not have proportional scrollbars give me The Rage.
compared to the inability to scroll with your mouse wheel without having focused the windows first. The last time I checked in Windows 7 it doesn’t happen by default. Rather nasty behaviour.
Easy fix is to turn on the x-mouse features of Windows.
Personally, I think that’s the only way to roll.
This has bothered me most since switching back to Windows. Often times, the only way to get focus is to activate something in the panel you are going into, or to start scrolling by clicking on the scrollbar, which begins an unwanted scroll.
In Windows, applications call a function that sets the range of the scroll bar and that range consists of a line length, page length and a document length.
The scroll bar itself consists of 5 distinctive areas: up button, up track, thumb, down track and down button (for a vertical scroll bar).
The up and down buttons moves the scroll bar position by the line length.
Clicking on the track moves the position by the page length. If you hold down the mouse button, it starts to continuously scroll the position by the page length.
Dragging the thumb allows you to move to an exact position.
To allow you to abort your movement operation you can move the mouse cursor outside a certain area. This behavior is consistent with other controls, such as a push button where you can press down a button and then regret your click by moving the cursor away from the button and release your mouse button.
The thumb itself is supposed to present a page in the document. A page in this regard is not a physical page, but rather how much is visible on the screen. Therefore, your ‘arbitrary jump up/down’ when you click the scroll track actually equals to pressing Page Up and Page Down on your keyboard. In the same manner, the buttons equal to pressing Arrow Up and Arrow Down in a scrolling scenario.
About the position of the buttons, that is mostly taste in my opinion. It is true that having them grouped together is technically better, but visually I find the Windows position of the buttons prettier. In any case, if the application requires you to actually click these buttons, the UI is already in big trouble with regard to usability. I’ve never had to click such scroll buttons in all the time I’ve used Windows. YMMV.
But a button activates an action, so there must be a way to cancel the action from being triggered once you already pushed the button. The scrollbar acts really different. Consistency just for the sake of it is dumb. It’s normal that when you drag the scroller your hand move away from the vertical bar, as the hand is optimized for horizontal movement through an arc, not vertical movement. And when you are focused on reading some text, your mind is telling your hand to follow the eyes, so it deviates from the scroller position. The way KDE (just as an example) does it is more correct, as I can drag the scroll bar and move the pointer around the screen and it doesn’t reset the scroller position. I believe the way Windows implements it is more a limitation of Win32 controls than pursuing consistency.
Edited 2009-12-10 21:30 UTC
I sometimes like this behavior, and sometimes hate it.
I noticed this behavior a long time ago, but I never knew there was a vertical border too (I usually have windows maximized). The horizontal problem actually did affect me fairly often.
The one reason I like it is that it makes it possible to get to exactly where you were before in case of a mistake with a long document.
However, I have an idea that I think would be a better way to solve this problem: “scroll bookmarks”. Basically, right clicking on the scroll blob would create a little marker at that spot on the scroll bar. Clicking on it would go to that location. Moving your mouse over the marker would show a snapshot of what you see at that locations, like when you mouse-over a window on the taskbar in Windows 7 or GNOME with the right Compiz settings. This would allow you to have as many “bookmarks” as you wanted, and would not cause any annoying, non-obvious behavior (although right clicking the blob may not be very obvious).
Wasn’t that idea already implemented somewhere? Office could be? Looks familiar.
There’s a Windows text/code editor called EditPlus, it has a similar feature. You can mark a line with the F9 key and jump from one mark to another using F4.
I used to use that feature heavily when I did a lot of research and writing. It was very handy to dump a bunch of research material into a single text file, then skim through an use the marks to highlight individual points.
Finally someone who understands the why and also offers a solution!
I never got annoyed by this feature because I also understand the why, but your suggestion might be a much better alternative. Let’s hope it gets heard
That’s what the middle mouse button is for. As far as i know it works on allmost any graphical toolkit on Linux and Windows. Don’t know about mac though.
There are 2 really big annoyances I have with Windows in terms of using it.
1. Whatever I have my mouse hovered over I should be able to scroll with mouse wheel.
TRYME: In Windows explorer highlight something in the right pane, then in the left pane where there are more directories and files in the window than one can see, try, without clicking, to scroll and see what cannot be seen. This affects all applications which use panes.
TRYMEAGAIN: Open two programs, one must have scrolling capabilities. Hover over the unfocused scrollable window and scroll mouse wheel.
No dice? Unless they fixed this in windows 7 it is the most retarded *cough* mentally challenged behavior in Windows. Being a 10year Linux user I may be biased.
2.The address bar click behavior.
TRYME: Single click the address bar in FF or IE in Windows.
What happened? Yes that is right THE WHOLE F*IN THING SELECTED!!! Strange because the behavior in every other piece of software on windows single click places the cursor. So if I typed psnews.com and realized I made a mistake and single click between the P and the S to remove the P and then pressed backspace, the whole thing disappears. Every instance of text entry usually uses single click as cursor placement, double click to highlight one word, triple click to highlight the line/all. As for a web browsers address bar double click should highlight all, single click place cursor, end of story.
1. X-Mouse is the way to go. Focus-follows-mouse is awesome.
2. That’s not windows behavior, that’s application behavior, and you can change it in firefox. in about:config, change browser.urlbar.clickSelectsAll to false.
Good to know, however I believe the default setting is the Microsoft way and Mozilla is just adhering to UI guidelines.
True. Too bad the Microsoft way isn’t the Windows way.
Thanks for the x-mouse tip. The lack of focus follow in Windows have been driving me crazy.
Strange how I find Linux easier to work with nowadays than Windows.
For x-mouse, there are a couple of ways to enable it through windows. Stay away from third-party solutions.
In accessibility settings, there is an option for focus follows mouse. However, that autoraises, which I find incredibly annoying.
The other way is to edit the registry by hand.
Find HKEY_CURRENT_USER\Control Panel\Desktop\userpreferencemask
Add 1 to the first hex value for focus follows mouse, add 40 (remember, this is a hex value) if you want autoraise.
then, change the value of HKEY_CURRENT_USER\Control Panel\Desktop\ActiveWndTrkTimeout to set the delay for the focus change. This value is in milliseconds.
It helps immensely to set it to at least 200. Otherwise, there is very nasty behavior when you’re working stuff in the notification area on the taskbar. Namely, when you want to change volume, or change which wireless network you want to connect to, or any time you move from a tray icon to the associated window, the window will disappear because with an instant focus change, the taskbar gets the focus when you move it from the icon to the window. This doesn’t always happens, but once it start, it doesn’t stop unless you change the value.
haha that address bar single click to select behaviour is usually the first thing I change in FF on Linux when trying out a new distro.
me and my brother both think one click feels natural in the address bar, 2 clicks to select is awkward and annoying
I wasn’t conscious of this in Windows until I started using Gnome a lot, and came to find the ability to scroll background windows pretty useful.
Windows has one nice feature though, which is the ability to drag from a background window without focusing it, meaning I can drag from a maximized background window into a smaller foreground window which would otherwise be obscured.
In Gnome I can set the smaller window to always be on top, but I personally find it a tad easier just to be able to drag at random.
Agreed, that is annoying behaviour. The best workaround I’ve found is Logitech’s “MouseWare” app. With it installed, using the scroll wheel while the mouse is over an un-focused Window will bring that Window to the front.
Although I stopped using it a while back because it doesn’t work very well with KVM switches (switch to another computer and switch back, and the scroll wheel no longer works at all).
I’ve gotten used to it, and tend to miss it when using an OS that it isn’t present on. I do all my easy, slow scrolling via mouse wheel, and use the scroll bar when I want to move quickly. Usually, when I want to move quickly, I want to move quickly back to where I was initially, so that hot spot is a great help.
I agree with the other posters about clicking in the bar should move a page instead of to that point. It’s not at all easy to know where the content you want is located on the scroll bar. Also, the current behavior pre-dates proportional scroll bars. Using the jump-to behavior instead of page-scroll behavior is even more difficult when the indicators were little boxes.
BeOS did get the location of scroll-bar arrows correct, though.
GTK/Gnome does not have a hotspot zone. As long as you stay clicked, you can go anywhere with your mouse.
Arrows have same pb as Windows (one at top, one at bottom). And the click in the scroll bar is set at standard jump instead of proportional.
However, one thing, I want to insist is that blob size proportional to document size is a terrible idea. On large document, you can end up with extremely small blob, hard to click on. I am glad Gnome does not have it.
I’ve always liked the way BeOS did it: there’s a (configurable) minimum size for scrollbars.
How about this; when mouse is hovered near the tiny blob, it would expand so it would be easier to grab it with click, then after clicking, it would reset back to it’s tiny form and could be moved around and positioned with accuracy.
Finally, the issue of the scrollbar arrows. There is only one correct way of displaying the scrollbar arrows: grouped
Correct in one opinion, incorrect in another. I like them separated and I dislike them grouped together.
I don’t know if this has been mentioned, but in Windows, if you go out of this hot-spot, the blob resets, but if you don’t release the mouse button and move the cursor again into the hot-spot, you can keep scrolling. Try it out.
Where your left click scroll down, and right click scroll up, middle key jump here. and depends on where is your mouse position at the scroll bar, you could control how much it scrolls for each click. I wish all apps’ scrollbar use this behavior.
I don’t tend to use the scrollbar. I typically either scroll with the mouse wheel, use the up/down arrow keys, or middle click on the window to get the dot with the four arrows and move the mouse in the direction I want to scroll. The last scenario isn’t supported by all applications, but it works in my web browser (Opera) and Microsoft Word.
Edit: Right after I posted this, I noticed that I used the vertical scrollbar to quickly take me to the top of the page. I guess I probably use it more than I realize. It just must be so automatic that I don’t realize I do it.
Edited 2009-12-11 00:00 UTC
While I agree with Thom, he did completely miss the more annoying aspect of Windows scrolling: the active window receives all scroll wheel events.
I hate this. I love being able to just put my mouse over a window and scroll. Helpful when you need to read from one window, and write into another.
“Focus follows mouse” and “focus does not imply foreground” – two concepts I’m ejoying for many years happily.
I’m a KDE user and a friend of mine who uses both Linux and Windows once told me about one curious thing that I had never noticed. In Windows (at least XP which is the last I’ve used) you can only use the scroll wheel in the active window. In KDE and I think that in Gnome too, you can scroll where you pointer is, independently of the focus of the window.
It’s a completely different problem but I found it a curious behave.
Yep – All X-based UI systems (like KDE or Gnome) treat the mouse wheel event the same way they treat other mouse events – they go to the window underneath the cursor. Mac OS X behaves the same.
Windows treats it as a key press event, so it goes to the active window. Not only that, but it goes to the active control. If you have a window with multiple scrollable controls (Windows Explorer, for example, or a web page with an iframe in it) you have to click first to select the control, then scroll.
Yah, like clicking “in” the webpage to scroll it, not just the navigator.
I really enjoy this behaviour under OS X. Is there a 3rd party addon or a registry key in Windows (XP) to enable the same behaviour?
After using Ubuntu exclusively for 4 years I got a new notebook and I decided to keep Win 7 on it as I wanted a different OS experience (I have enough Ubuntu machines). And I hate the fact that I can only use the scroll wheel to scroll when the window has focus!
Why the hell would clicking above or below the blob take you to that location? If you want to do that, just drag the blob there and enjoy the benefit of being able to see where you are, live, in the document.
So you’d basically take away ability to move up and down exactly one page with the mouse, to replicate functionality that is already in the scroll bar? Makes no sense at all. You are just wrong here Thom.
KDE 3.5 – No scrolling issues as described in the article.
Also.. LXDE, FluxBox, OpenBox, BlackBox, and XFCE do not exhibit any of these issues either.
I’m unable to confirm for Gnome.. I stopped using Gnome because of its inclusion of the Mono code. So, there you have it.
Enjoy!
Thom, you wrote: “Clicking inside the scrollbar, but outside of the blob, can have two different outcomes, depending on system settings and operating system used: the right one, and the wrong one.”
In fact, there are those two ways: the right one, the wrong one, and a differnt one. Three! Three ways!
You missed the third one, but maybe you’re not familiar with it, so let me explain:
One of the oldest X toolkits, the X Athena Widgets (Xaw), default to a third way, which is very comparable to what you (in opinion possibly correctly) call the right way. Imagine a vertical scroll bar with a blob (I’ll use this terminology) in a size representing canvas size vs. document size. If you click the left button inside the scroll bar – no matter where, the concent moves up (meaning your focus goes down) nearly page-wise. If you click the right mouse button, the opposite happens. But when you click the middle mouse button (and we all can remember that PCs and especially “Windows” didn’t utilize the concept of a three button mouse very much), the blob gets to the position you exactly clicked at. You can hold down the middle mouse button and scroll as slow or as fast as you like – the blob stays “connected”. This is the behaviour that you expected for clicking inside the scroll bar, but outside of the blob in terms of the right way.
I know that “nearly page-wise” is an arbitrary amount of space (lines, pixels, whatever) again, and that’s a downside as you mentioned it when describing what happens when you click inside the scroll bar, but outside of the blob in terms of the wrong way.
According to your question “Can anyone tell me if other systems have been affected by this bug as well?” referencing the “leave the window to reset” problem:
When I click the blob in one window and move the mouse cursor off it (and off the scroll bar, as well as off the whole window), I can control the movement of the scroll blob from anywhere on the desktop. If I release the mouse button, the blob will stay where I left it.
My testing setting was WindowMaker running Opera and some tk 1 and 2 applications. All of them behave the same way.
For scrolling in general, I prefer the three button mouse (from Sun) I’m still using because I can’t stand scroll wheels: They have the same “problem of arbitrary chosen scroll step”, they are unprecise, make the window concent move in an unconfortable way and are unhealthy to the hand. So I press the middle mouse button and move the mouse in Y direction. I can scroll as slow or as fast as I want to. Needless to say that this doesn’t require the window to be scrolled to have be in the foreground. Because of “focus follows mouse”, I can, for example, leave my Opera window, scroll the text in the editor that is “beneath” the Opera window, and return the focus to the Opera window afterwards. That’s quite handy in situations where you want to write in one window which you intend to be in the foreground, and scroll in another window that you don’t want to cover the window you’re writing in.
You’re almost right. The scroll amount depends on the distance from the top of the scrollbar. For example, left-clicking on the scrollbar at the height of the first line (from the top) will scroll down by 1 line, while right-click scrolls up by 1 line. And so on until the bottom of the scroll bar, where you scroll a screenful at a time.
The scroll-cancelling behaviour is one of the many things that irritate me whenever I have to use a Windows box (which, happily, is very rarely). GTK can do this with the Esc key.
BTW, GTK does have secondary scroll buttons. My .gtkrc-2.0 has:
style “scrollbar” {
# GtkScrollbar::has_secondary_forward_stepper = 1
GtkScrollbar::has_secondary_backward_stepper = 1
}
class “GtkScrollbar” style “scrollbar”
This gives a single up button at the top and both up/down buttons at the bottom of the scrollbar. Uncomment the first line for an additional down button at the top.
What annoys me to no end is that on Ubuntu (probably everything with GNOME), Fitt’s law isn’t applied to the scroll bar. When i maximise a window, my mouse cursor has to be ONE PIXEL from the side of the screen to scroll! Please, please remove that pixel of window border, or make the scrollbar 1 pixel wider.
Edited 2009-12-11 09:50 UTC
My Kubuntu KDE4.3 has no stupid one pixel border.
About Thoms Windows nitpicks:
– no hotspot CHECK
– middle mouse button will just to where you want to go CHECK
– grouped scroll buttons CHECK
Honestly Thom, a picky geek like you that wants to have things work exactly the way he likes it is KDE target audience. Always has been. And you can even influence the direction they are going a lot more than with Windows (MS will never change these things, people exspect this broken behaviour from Windows and MS is all about backwards younameit)
Did KDE ever have it?
KDE 4.3:
– No hot spot area behaviour at all.
– Click on “scroll blob” lets you drag it. It stops “dragging” and stays at the final position when you release the mouse, no matter where your release it.
– Left click in the scroll margin below the scroll blob = page down, above the scroll blob = page up.
– Middle click or shift-left-click or ctrl-left-click anywhere in the scroll margin (even on the scroll blob itself) = jump to that place (proportionally) in the document.
– Right click anywhere in the scroll margin = nothing happens.
– No one-pixel borders
Edited 2009-12-11 11:50 UTC
You can just middle-click wherever you want to go there immediately, at least with Qt base interfaces…
I think because loads of people use Windows and have never seen another OS, they think that the reset of the scrolling position when dragging too wide during a vertical drag/scroll is “normal” and “doesn’t every PC do this?”.
It’s one of the worst “features” of all time on Windows and I always bitterly curse that reset when it happens. As Thom says, it’s totally pointless and, even worse, you can’t even seem to turn off its abhorrent behaviour (if someone knows of a way, please tell us sufferers!).
When I drag a mouse vertically up or down to scroll, it’s virtually impossible to do it in a perfectly vertical straight line and, to compound things, I don’t watch the mouse pointer at all during such a drag, since I’m looking at the window contents scrolling and not the scrollbar. Hence, it’s simply too easy to “drift” the mouse during drag without noticing and then get mad when it does a reset.
No wonder I use GNOME on Linux 95% of the time to keep my sanity intact
Edited 2009-12-11 14:58 UTC
I always liked the way scrollbars worked in RISC OS. Especially as I also had to use Apple’s far less advanced Mac UI, which didn’t even offer proportional scrollbars and live scrolling back then.
Click the RISC OS scroll blob and the mouse pointer becomes stuck to it, only able to move up and down, and not able to leave the scroll blob area. There’s no problem of overshooting the end of the scrollbar because the mouse pointer stops when it hits it.
It had single scroll arrows at each end of the bar, but right-clicking on a scroll arrow reversed its direction, allowing you to scroll a window either way without moving the mouse pointer.
Uniquely, it has something similar with the scroll blobs, allowing for 2D scrolling. If you right-click a vertical scrollbar and drag to the left or right, it’ll move the horizontal scrollbar (or vice versa with the horizontal scrollbar clicked), allowing you to scroll the document in any direction. Quite useful for panning around a large image on a low res screen, back in the days before scrollwheels.
RISC OS usually maintained a great balance between protecting the user from accidental annoyances, while offering a lot of UI power, flexibility and elegance.
Clicking on the RISC OS scollbar scrolled one windowfull of content, just like with Windows and Mac, but I don’t see the usability problem with that. It just makes the scrollbar act like the Page Up/Down buttons; it’s not exactly an arbitrary and unpredictable behavior.
That sounds neat. IIRC, scrolling in OpenLook worked in roughly the same way – except that the up & down arrows were attached to the top and bottom of the scroll blob (respectively).
http://xwinman.org/screenshots/olwm.gif
I like that I can easily reset the position after a quick scroll through the document without having to search for my original position. I miss it in Gnome.
Microsoft should create an option to enabling/disabling it this “feature” as not everybody like it.
And I agree, that’s a “feature” I HATE with a passion. I totally forgot about it when I switched to linux.
In Linux (or at least GTK), you middle-click on the scroll bar to do the jump here behavior. I love using that.
Cool, didn’t know that, thanks.
My personal preference on scrollbars are:
1 – the scroll blob. I drag it, so I don’t care what happens when I click on the empty bar. But if I have to choose, I am more on the wrong side: it should scroll down (or up of course) to what immediately follows what I’m seeing. I blame the lazy programmers here.
2 – the arrows. I don’t care about them, but I prefer them to the top and bottom.
3 – the touchpad. Can’t go back from my MacBook’s multi-touch pad, scrolling with two fingers on the glass pane feels so damn good…
4 – the mouse wheel. Mice makers should put more attention on this, it should be soft and silent, and you must feel the steps. Unfortunately, on most mice it’s either hard, noisy, or the steps aren’t precise.
I am very glad to have found someone bringing up this topic because even after more than 15 years using Windows, I still cannot get used to it. Thom is totally right about the ‘hotspot’ and reset while dragging being wrong, and here is why:
1. Once you start a drag on the blob, there is only one direction that has any relevance: up and down (in a vertical scrollbar — side to side in a horizontal one. I’ll just deal with vertical here). Any side to side movement of the mouse must be accidental and should therefore be ignored. The user can drag diagonally if they want to — the blob should simply go up and down with the vertical component of the mouse’s movement.
2. The OS should not permit movement of the mouse pointer outside the interior of the scrollbar. This effectively makes the movement infinite. If I want to scroll to the bottom (or top) of a document, I simply grab the blob and throw it at the bottom (or top) of the screen. It shouldn’t matter that the window may not be maximised or that there is a border — any vertical movement should have the right effect and if the mouse is restrained, I don’t have to be careful about how far I move it. That is what I mean by ‘inifinite’. In practice, however, if you move the mouse too far the thing bounces back to where it was. Very irritating. And slower, because you have to pay attention to the movement rather than just slamming the mouse up or down. Great for someone like me, whose co-ordination is not schooled by a wasted youth playing computer games. (They hadn’t been invented. I’m that old.)
Remember when Windows 95’s Start button was one pixel away from the edge of the screen? It meant you couldn’t slam the mouse into the corner and click — it wasn’t infinite. This is why the Mac’s menu at the top of the screen — to get there, just slam the mouse upwards: it’s infinite.
RiscOS on the old Acorn used to be like that: starting a drag would restrain the mouse rectangle to the scrollbar. It was great. Window’s behaviour is for me the most annoying area where it really sucks and feels amateurish.
I also agree that having the arrows together makes more sense than having them at opposite ends of the bar, because it reduces mouse movement when scrolling up and down. RiscOS had the best of both worlds: the up and down arrows were in the same places as in Windows, but right-clicking would have the opposite effect. Not terribly intuitive, perhaps, but it chimed with that OS’s use of the right button as the ‘alternative’ button (the middle one being menu).
I am going to disagree with having the movement proportional to where you click in the scrollbar. I often use clicking above or below the blob as an alternative to Page Up/Down — I think it would be hard to judge how much movement a click would bring, and by moving one screenful at a time, you don’t miss any of the document while scrolling up and down.
I certainly didn’t know about Shift-click. How terribly unintuitive!