A little experiment with scrollbars

Beautiful!

My guessed aesthetic preference is for the larger handle to move from the top to the bottom in linear relation to the smaller indicator. This means that when the handle is at the very top, so is the indicator, and when the handle is at the very bottom, so is the indicator, and they transition smoothly between, with the indicator moving down the handle. Curious what you think of that.

Yes someone else suggested that as well on Mastodon. I think of it as "yo dawg, I put a scrollbar in your scrollbar so you can scroll while you scroll." After some thought I think it might be less distracting if: • The small handle starts out at the top when the scrollbar is on top. • It quickly moves to the middle once there's room. • As you scroll further down it remains stably in the middle for most of the file as long as there's room below. • As you get close to the bottom it quickly moves to the bottom. What do y'all think?

I like mine more. 🙂

But, but.. just gaze upon this!

FWIW, aside: what I see in this is something that Jef Raskin discussed in “The Humane Interface”. Measuring and increasing the size of the target area of buttons and selectable doo-dads. Now that I’m retired, I am discovering a lot of horrible UI problems in everything I use. I’ve had to disable cmd-Q in MacOS and ^X^C in emacs (due to increased finger-slop, I hit ^X and ^C together when I mean to hit only ^X). I regularly type cmd-C when I mean cmd-V only due to the physical closeness of those keys. I regularly click on the Claude icon in the dock when I mean to click on draw.io, due to the similarity in background colour (orange) and the relative density of the foreground image (white splat for Claude vs. white node-and-wire for draw.io, both filling about 75% of the icon, vs. the Pages icon which has an orange background but with only 30%-ish white foreground image). Disappearing and reappearing scroll bars and dock-bars are plain annoying. Auto-rearrangement of menu items (e.g. by recently used) is annoying and confusing - I first noticed this problem in SBCL’s restart menu (ultra-horrible UI, due to inconsistency).

I always thought it might work better for the size of the thumb to be logarithmically related to the size of the text.

Logarithmically related?

Typically, if the viewport is showing 1/10th of the document, the thumb takes up 1/10th of the scroll bar; if 1/100th, 1/100th. At that point, the thumb is so small, it’s a bad UI experience — hard to see, hard to click on. Rather, the reduction should be logarithmic, so that even at 1/1000th, the thumb is smaller, but still usable.

And by thumb you mean the handle itself that you can drag? I don't know the names of things. I've been calling it the scrollbar that lives in the scrollbar gutter. Is it a thumb that lives in the scrollbar?

Yes.

After this experiment and talking to @Ivan Reese I realized a much simpler solution is to grow the hit area of the thumb. https://mastodon.social/@spiralganglion/115469389148175886 https://git.sr.ht/~akkartik/carousel2.love/commit/c84cda3eec839c25fafddb2eb98b02bcb3244360

Yes, this is an even better solution.

There might still be some role for logarithmic calculation. One remaining problem is that it's hard to get to the right line in a large file. I'll still thinking about that one.

The other thing I struggle with in large files is not just the hit area of the scroll bar but the lack of destination precision. Tiny motions move pages of text.

Yeah, I think breaking away from linear / 1-to-1 motion of the mouse -> scroll position is a good goal. These days I think most people expect "click in scrollbar gutter" to jump the scroll thumb to that spot, but the other option was "scroll in that direction", which could make a comeback here.

(necro's thread) oh I've built one of these! The colorful track on the right is a 30-day chunk of the track on the left. Since the user can directly manipulate the 'small handle', I preserved its relative offset whenever possible (i.e. unless you scroll off an edge). I believe we got there on destination precision, from the scientists' perspective. If we had to do (say) 3000 days, like a genome browser, I'd try adding a third track. Also, switching over to written queries and the find-all metaphor.

These days I think most people expect "click in scrollbar gutter" to jump the scroll thumb to that spot, but the other option was "scroll in that direction", which could make a comeback here.

There's also been a 3rd option that the vertical position of the click affects how far you jump with each click. Emacs did this ~20 years ago:

The left and right buttons in the scroll bar scroll by controlled increments. kbd{Mouse-1} (normally, the left button) moves the line at

the level where you click up to the top of the window. kbd{Mouse-3} (normally, the right button) moves the line at the top of the window

down to the level where you click. By clicking repeatedly in the same place, you can scroll by the same distance over and over.

... before it courted standard toolkits and switched to fixed size jumps. xterm can do this, depends on one's xrdb bindings. SmallTalk did this with single mouse button: hover on the XEROX text for scroll bar to appear, then note how hovering over left/right halfs of the bar shows down/up arrow. Try clicking both ways near the top (scrolls a little) vs. bottom (scrolls a lot). (1) Theoretically, this gives user more control. In practice, not sure—grabbing and dragging engages your normal eye-hand instincts for controlled positioning. (2) It was also always hard to discover. (3) The difference between the click position outside the handle vs. dragging the handle was always jarring. I think I've also seen models where distance from handle affects size of jump? That's much more intuitive 👍 But by that point it's close enough to "jump to where you clicked" that people didn't bother...