When dragging the scrollbar using the mouse, the contents of the scrollpane move up and down as the bar moves with the mouse. But if you keep the mouse button held down, and move the pointer sideways for about 100 pixels (tested on Windows machines), the scrollbar goes back to its location before being dragged, and the scrollpane with it. Moving the mouse closer again will make the scrollbar follow the mouse again. Is there any benefit or explanation for this behaviour from a UX point of view?
9
-
2Probably to escape the action, but it should really just let you hit Esc.– KeavonCommented Apr 13, 2014 at 3:50
-
4nice question! i wonder if this happens on other OSs too. imho it's just a terrible ui decision. if it was made to resolve an issue, they introduced one that is worse– user39775Commented Apr 13, 2014 at 7:56
-
1@Keavon: yes, to escape the action, but hitting Esc is not an alternative. Hitting Esc to cancel a drag movement seems illogical and counter-intuitive.– Marjan VenemaCommented Apr 13, 2014 at 10:04
-
1I intuitively hit Esc all the time when dragging files, objects in Photoshop, etc. It's possible it's not intuitive for new users, but it certainly is for me.– KeavonCommented Apr 13, 2014 at 15:06
-
1There's preciously little information on the net about this, and I consider the possibility that windows can "automatically drop" what I'm dragging a serious breech of trust. What I want to know, and what's unsaid here, is whether there's a tweak/setting somewhere that defines the distance for this behavior? I'd like to be able to extend it (e.g., to a very large number) or to disable it entirely.– user52632Commented Aug 4, 2014 at 18:33
|
Show 4 more comments
5 Answers
I believe it’s a means of providing the ability to cancel a half-executed command. Imagine a user is 45% down a long page. The user attempts to perform a drag operation on the contents of the window (maybe to move an icon or select some text), but accidentally “catches” the scrollbar slider instead, resulting in scrolling page to X% down, and leaving the user to have to try to find his/her original place. To mitigate this scenario, the scrollbar is designed so that users can “slew off” of the slider and thereby cancel the command. Since scrolling happens as the slider moves, the users can see they’re scrolling instead of selecting text or whateveer, so they have a chance to realize the mistake and recover before releasing the mouse button.
This is behavior is not unique to scrollbars. Command buttons, menu items, check boxes, and radio buttons also cancel if the user slews off the control without releasing the mouse button. These other controls do it with about 0 pixels of slew-off. I think the scrollbar slider has a ~100 pixel “buffer zone” because dragging is hard to do, so they allow the user a range of error when deliberately scrolling to avoid accidentally canceling a scroll.
I don’t know if it actually works. That is, I don’t know if users that accidentally activate these controls react by slewing off the control without releasing the mouse button. My guess is that the vast majority of users (and not a few UI designers) are unaware of this feature of the controls. On the other hand, maybe the natural reaction to mis-clicking something is to “jump away” from it, a generalization of the proximity heuristic. Maybe users make these cancellations without really realizing it.
answered Apr 14, 2014 at 11:54
-
1Well said. Although I disagree that my intuition tells me to drag my mouse away to cancel scrolling, you seem to have the most logical explanation.– SimonTCommented Apr 15, 2014 at 0:56
-
1@SimonT: It is consistent with the behavior of other controls which cancel operations if the user leaves while the button is held and does not return before releasing it. Controls which do not expect the mouse to move while it is held generally require that the release be within their active region, while click-drag controls offer more leeway.– supercatCommented Jul 17, 2014 at 18:34
-
@supercat That actually does make sense, although it's more clear after having that explained. So the original or "default" case would be that the scrollbar stops having an effect if the cursor leaves, but that would be too difficult in practice for the user. So that 100px is a buffer for unsteady human hands.– SimonTCommented Jul 18, 2014 at 0:16
-
@SimonT: That's the idea. I think it would be better to say that a click-drag control would only be "let go" if the user does some affirmative action like clicking the second mouse button before releasing the first, so as to create an "infinite" target zone for the ends of the scroll bar, but that's probably a judgment call which Apple made one way and Microsoft the other.– supercatCommented Jul 18, 2014 at 15:09
As far as I can tell, there is no good reason for it. The behavior was started by Microsoft (Windows) and sadly taken over in other user interfaces such as KDE.
Here is some more e-mail conversation going on about the subject.
Many people (including mysef) find it annoying for the simple reason that you look at the windows contents while dragging and thus not seeing that you are moving the mouse horizontally too much.
Also see this article and read through some of the comments. Notice the frequent use of the word "annoying".
answered Apr 14, 2014 at 12:18
An opinion from the other side:
Oh my word I love this behaviour. I have moved to a Mac for work and I miss it dearly.
When you're working on or reading a document or webpage, you can grab the bar scroll up or down to check something, and then drop it again to continue from where you were. As has been said here already, it's about cancelling an operation on a UI element that you've moved away from, and it's consistent with other elements, and it's valuable. Imagine clicking on the wrong button on a dialog, realising it when you see it light up, and being unable to stop that click from happening by dragging away from there.
I've come to this page while searching to find some way of getting this behaviour on a Mac. When I grab the scrollbar and move the mouse at all, I've lost my place and I have to hunt it down again. It's infuriating in a work context where I'm reading documents and research papers and I can't easily cross-check things within the same document.
-
1Agreed, from a developer perspective (grab scrollbar, move up, quick glance, "flick" to make it go back, resume coding)– AlexCommented Jul 21, 2015 at 15:18
-
@Alex I usually just use ctrl+click to go somewhere, then alt+left back. This only applies to coding in an IDE however.– NjolCommented Oct 7, 2015 at 9:23
-
1Have you found a way to recreate this behavior for the Mac or a way to cancel a scroll action and return to the original position? Commented Jan 28, 2022 at 2:11
A UI should always function in a way which is plausible to the mind of the user, based on their experience of manipulating objects in the real world. The scroll bar is locked to either vertical or horizontal movement. If you drag your mouse pointer too far in a direction where the scroll can't follow, then at some point it is illogical for the scroll to keep moving with the mouse. The mouse pointer is like a hand that pushes or picks up objects. Actions at a distance would violate this expectation.
answered Apr 13, 2014 at 0:29
-
1i don't agree, if user is still dragging the scroll-thumb, why would he expect the scrolling get reset?– user39775Commented Apr 13, 2014 at 7:54
-
@Wes, because the scrolling must have some way to be "undone" and hitting Esc is illogical and counter-intuitive for a drag movement. Commented Apr 13, 2014 at 10:03
-
1@Wes I would say that an action where the user drags the scroll perpendicular to the scroll direction is most likely an accidental action. In this scenario a reset is the safest course of action. Commented Apr 14, 2014 at 6:25
-
1not just perpendicular: i.imgur.com/KkNN2WF.gif and you have just 40px of margin– user39775Commented Apr 14, 2014 at 8:25
-
1i disagree, if i grab an object in the real world stuck to a straight track, if my hand strays too far from the track i don't lose hold, it just becomes more difficult or impossible to pull it Commented Apr 14, 2014 at 20:35
It also happens if you drag a vertical bar too far up, all the way to the top of the screen for example, (probably 100 pixels, I haven't tested). EDIT: The range is much smaller for vertical over-shooting, compared to horizontal.
I'd like to scroll to the top of the page, so I half-blindly grab the scroll bar and just drag it all the way up there. Going too far it pops back to wherever I was at before. It's very annoying.
It's in contrast to such elements at the X in the top-right for closing windows, wherein you don't have to precisely click the X but just anywhere in the top-right corner of the window (when maximised). I never look up there when I want to close something, just slam the mouse up-right and click.
A nice system-wide on/off toggle would be greatly appreciated, since there are apparently people who like it.
