Mouse Pointer as a Mere Mortal

DonHopkins on Nov 3, 2019 | parent | context | favorite | on: Evolution of the Scrollbar

Open Look scrollbars would be impossible to implement properly in the web browser without using the Pointer Lock API that let you "warp" the mouse cursor position, because when you click on the elevator or cable, the elevator cab actually pushes the cursor up and down with it.

https://developer.mozilla.org/en-US/docs/Web/API/Pointer_Loc...

Here's a demo of Open Look scrollbars from Brad Myers' "All The Widgets" video, which he produced for the ACM CHI 1990 conference. It also has demos of many other kinds of scrollbars and other widgets. (Sun Microsystems, Inc. OPEN LOOK, 1988):

https://www.youtube.com/watch?v=9qtd8Hc90Hw&t=12m57s

>All the Widgets (Fixed v2) - 1990: This was made in 1990, sponsored by the ACM CHI 1990 conference, to tell the history of widgets up until then. Previously published as: Brad A. Myers. All the Widgets. 2 hour, 15 min videotape. Technical Video Program of the SIGCHI'90 conference, Seattle, WA. April 1-4, 1990. SIGGRAPH Video Review, Issue 57. ISBN 0-89791-930-0.

When I was working on The NeWS Toolkit at Sun (an Open Look toolkit implemented in PostScript), Jonathan Payne implemented the Open Look scrollbars, and I thought they had such a cool interesting 3D shape with their elevator, cable, anchors, ridges and arrows, that I carved an 3D Open Look scrollbar for him out of soap as a birthday gift. (He also implemented JOVE: Jonathan's Own Version of Emacs for Unix, and JED: Jot EDitor for TNT.)

https://commons.wikimedia.org/wiki/File:The_NeWS_Toolkit_scr...

Google Wave also had elevator-like scrollbars with arrows on the elevator, but since they were implemented in the web browser without the Pointer Lock API, they could not push the cursor like Open Look scrollbars, so they implemented a weird shadow and didn't move the elevator until you moved the mouse away, with was very confusing to users:

http://ignorethecode.net/blog/2009/11/15/google_waves_scroll...

>Using Google’s scrollbars, it’s also possible to scroll by clicking, but since the arrows are attached to the thumb, that creates a bit of a problem. Typically, the thumb indicates the scroll position. But since you can’t move the thumb while the user is clicking on it, Google has introduced a second element, a «shadow» that is displayed below the thumb. This shadow indicates the current scroll position:

http://ignorethecode.net/upload/217/click_scroll_google.mp4

>If the user moves the mouse away, the thumb will eventually move to the shadow.

>I did not notice this until a commenter on Hacker News pointed it out. He also notes that the scrollbars seem to perform poorly with longer waves.

http://news.ycombinator.com/item?id=944012

https://web.archive.org/web/20100308003557/http://www.comple...

>The Non-Standard Wave Scrollbar

>Figure 6-1. Unlike the scrollbar in your web browser, Wave's scrollbar is the same height no matter how long the list it's scrolling, which keeps the up and down arrows always the same short distance away.

>The scrollbar on the right side of Wave's panels works a bit differently than the scrollbar in your web browser. Like most scrollbars, you can drag it up and down to scroll, or click its up and down arrows to move it. Unlike most scrollbars, the Wave scrollbar's height doesn't change. It's always the same, small size, which puts its up and down arrows in close proximity to one another, as shown in Figure 6-1. Google's intention is to benefit people accessing Wave on mobile devices or netbooks with a limited mousing area, but it has thrown off some preview users.[2] Google explains "the deal" with the scrollbar in Wave's Help section:[3]

>You might find that the scrollbar in Google Wave behaves a little differently from scrollbars in other Google products. To use it, you can drag the bar or you can use the arrows on either end of it—clicking the arrows without moving your mouse allows you to very quickly scroll up and down the page.

>Even at this early stage, at least one developer has created a Google Chrome extension that reverts Wave's custom scrollbars to Chrome's native scrollbars.

Google Wave: Scrolling. How to use the scrollbars in Google Wave.

https://www.youtube.com/watch?v=Lxt2LXCSw5Q

A Pissed Off Tutorial For Google Wave

https://www.youtube.com/watch?v=4Z4RKRLaSug

If there's really a case where you need to see the exact position of the cursor while it's off-screen, you could display it wrapped around only while it's actually off-screen. But this would potentially confuse new users, so it should be optional and disabled by default.

Seeing is an inferior means of knowing where the cursor is compared to intuition. When I move the cursor, I know where it is with no conscious effort because I treat it as part of my hand. I disable mouse acceleration to make this easier. I don't need to look at my hand to know where my hand it. My subjective experience of mouse clicking is the same: I look at the target and the mouse cursor automatically appears there. If you allow software to move the mouse cursor you weaken this intuition.

>I don’t understand what this means. If it’s not off-screen then it’s automatically also not wrapped around.

When the cursor moves off-screen, it could be displayed with position modulus the screen width/height. Additionally, the cursor shape could be changed to make it obvious it's not the true position. This might make sense if you really need to know the exact off-screen position and the GUI control you're manipulating doesn't provide sufficiently precise feedback.

>This presumes that “cursor is suddenly allowed to be off-screen and not visible” is less confusing.

It is less confusing because other than extending the range of the mouse off-screen, the mouse behavior doesn't change. As soon as the off-screen action finishes, the mouse cursor snaps back to the position it would have otherwise been in.

An alternative option would be to snap back to the position it was where the special off-screen mode was initiated. This might actually be better, because it makes the off-screen mousing mode an extension of moving the mouse while it's lifted off the mouse pad, which users already have intuition for.

Realize it consciously or not, visual feedback is a critical part of this loop.

> As soon as the off-screen action finishes, the mouse cursor snaps back to the position it would have otherwise been in.

The cursor jumping to the edge of the screen, which is not somewhere the user ever saw it and may be outside of the application, seems worse than any current issue while still being insufficient for most legitimate use-cases.

I don't really see any fake cursor approach that isn't going to behave awkwardly in practice - e.g: is it your real (invisible?) cursor or fake cursor that can click to focus another application, and what happens to your cursors when you do so?

Just letting the user deny mouse control for an app (like on Wayland) seems sufficient to solve your annoyance. Maybe adding a separate permission for control while unfocused, since that's rarer. No need to break all windowed applications with reason to capture/move the mouse.