scroll

[godbout]

gathering ideas and discussions about what would be the best UX for scrolling.

1. extra hotkey? and then?
2. special search term with Wooshy? and then??
3. reach Scroll Areas with Wooshy, navigate through kindaVim?
4. profit???

[jannis-baum]

I almost feel like it would be nicest to have a third app in the ecosystem now. kV for typing, Ws for clicking & a third for gestures; most importantly of course scrolling, but also zooming, maybe even rotating and whatever else people like to do with their touchpads.

This new app could be activated with another hotkey, which would have a popup similar to kV's overlay that displays the last move and/or darken the other windows like kV can as well.

Once activated, we could use keys similar to Vi-bindings to move around, like hjkl for scrolling in smaller steps and ud for paging (ctrl wouldn't be needed because this app only handles gestures), etc., and make up new ones for other gestures that don't make sense in Vim. Making up keys would come with a greater need for customizability of bindings, but this of course would also work through Distributed Notifications, Hammerspoon and Karabiner.

Like I said in the other thread, I really like the feel of Vimari's animated scrolling. I tend to get lost with instant scrolling.

[godbout]

i like the idea of having a third app. i like to keep things separated. easier to see the boundaries, and to implement for me.

Once activated, we could use keys similar to Vi-bindings to move around, like hjkl for scrolling in smaller steps and ud for paging (ctrl wouldn't be needed because this app only handles gestures), etc., and make up new ones for other gestures that don't make sense in Vim. Making up keys would come with a greater need for customizability of bindings, but this of course would also work through Distributed Notifications, Hammerspoon and Karabiner.

ok, so here we're coming to the multiple questions i have, and it's a mess for now. i'm just gonna spit it out:

let's say you're on Slack. you wanna scroll down somewhere. what is the UX?

1. do the hotkey shows you all the scroll areas available on Slack? or does it show you the one under the cursor?
2. if it shows you all the scroll areas available: how do you choose between them? same as we choose Targets in Wooshy? tab/shift tab left/right command up/down to choose? then jk ud etc to move the scroll? i'd find this confusing, because personally i use kV and jk ud Ggg to select my Targets.
3. if it shows the scroll area under the mouse cursor, then how do we get there? with Wooshy? currently Wooshy filters out scroll areas because you can't click them. so if we target them with Wooshy, there's a bit of overlapping. or you could just move the cursor with shift command enter on a UI Element that is within the scroll area? is it too much work/too slow?

probably more questions coming once we have those ones clearer.

Like I said in the other thread, I really like the feel of Vimari's animated scrolling. I tend to get lost with instant scrolling.

👌🏼️ surely could have Preferences and let users choose their type and length of scrolls.

[jannis-baum]

do the hotkey shows you all the scroll areas available on Slack? or does it show you the one under the cursor? if it shows you all the scroll areas available: how do you choose between them? same as we choose Targets in Wooshy? tab/shift tab left/right command up/down to choose?

I like the idea of highlighting all scroll areas and giving some way of selecting between them! The popover/overlay I mentioned could also move around based on which one is currently selected.

Another thing we can take into consideration when talking about the UX here is that is is very rare to have a lot of scroll areas; I'd say the most common case is having only one. Two is also fairly common, but beyond two we quickly get into scenarios that almost never happen.

That said, selecting between scroll areas might not need to support the more comprehensive movements Wooshy supports, like kV's jk ud Ggg. I think it would suffice to only have tab/shift tab, maybe with a loop-around.

I agree that it would be confusing to use kV Normal mode jk for example change the selection when jk are meant to be used for scrolling. IMO it would probably be best to disable kV for when the new app's mode is active, also because the new app wouldn't have any text input (would it?).

if it shows the scroll area under the mouse cursor, then how do we get there? with Wooshy?

I think using Wooshy to select scroll areas both adds a lot of (time & brain) complexity and makes the new app useful only when the user also has Wooshy. So I wouldn't go for this.

[godbout]

I like the idea of highlighting all scroll areas and giving some way of selecting between them! The popover/overlay I mentioned could also move around based on which one is currently selected.

i'm not sure yet how sending scroll events work. like if you need to have the mouse over the scroll area.

but maybe an idea could be, you use the hotkey and if there's only one scroll area available, then you're locked on that one. else you could maybe use the hotkey again to reach the second scroll area and so forth? i need to find a good way to move between the scroll areas, and then to scroll.

so, one way could be to use the same moves to first select a scroll area, then press enter, and then use the same moves to go scroll. another way would be to use different moves to select, and to scroll. what do you think?

Another thing we can take into consideration when talking about the UX here is that is is very rare to have a lot of scroll areas; I'd say the most common case is having only one. Two is also fairly common, but beyond two we quickly get into scenarios that almost never happen.

mail apps have at least two: list of emails, content of email. Finder can have many, if you use the column view.

That said, selecting between scroll areas might not need to support the more comprehensive movements Wooshy supports, like kV's jk ud Ggg. I think it would suffice to only have tab/shift tab, maybe with a loop-around.

good point. although i'm too used to jk 😂️ (but yeah ud Ggg definitely not.) so i guess i'd need up/down. but we're back to what i said above. one way could be to have to "lock" a scroll area with enter. you could use jk to go through scroll areas, then enter, then jk again to scroll up/down. i like this in theory, but i'm wondering if it's gonna be to cumbersome in practice.

I agree that it would be confusing to use kV Normal mode jk for example change the selection when jk are meant to be used for scrolling. IMO it would probably be best to disable kV for when the new app's mode is active, also because the new app wouldn't have any text input (would it?).

no text input. although "activating" kV is up to the user. the only thing i can/have to do would be to link the moves of that new app to the Keyboard Strategy in kV (that is, if i don't add a Scroll Strategy in kV 😅️)

I think using Wooshy to select scroll areas both adds a lot of (time & brain) complexity and makes the new app useful only when the user also has Wooshy. So I wouldn't go for this.

good point. would be nice to get that new apps somehow completely usable without anything else. cool. exciting. thanks! maybe time to spawn a new Xcode project 😅️😂️

[godbout]

The popover/overlay I mentioned could also move around based on which one is currently selected.

btw i didn't get your mention of the popover/overlay like the Characters Window from kV. what would be useful for in the new app?

[jannis-baum]

but maybe an idea could be, you use the hotkey and if there's only one scroll area available, then you're locked on that one. else you could maybe use the hotkey again to reach the second scroll area and so forth? i need to find a good way to move between the scroll areas, and then to scroll.

This could be a nice alternative/second option to (shift-)tabbing through possible scroll areas!

so, one way could be to use the same moves to first select a scroll area, then press enter, and then use the same moves to go scroll. another way would be to use different moves to select, and to scroll. what do you think?

I am personally very stingy about the number of keystrokes I have to press haha so I would definitely prefer not having to press enter to lock into the scroll area when keyboards have more than enough keys to cover both switching between scroll areas as well as all the scrolling moves without having to introduce two modes.

To me having to press enter is definitely redundant, because hotkey+ntab/hotkey+scroll moves is always one less than hotkey+nwhatever moves+return+scroll moves. If I do this for the second scroll area (which will be a common scenario), it's 50% more keystrokes to get me scrolling.

I also understand wanting to use jk for selection, but I am used to selecting with tab for things like my completion popover in Vim (jk wouldn't work here because I'm in Insert mode) anyways so this would feel very natural to me. But at the end of the day you could, for example, also give the jk/modes thing as an option. Or if we do a DN API we can hack it together with Karabiner🤓

Finder can have many, if you use the column view.

Finder🙄 LOL

btw i didn't get your mention of the popover/overlay like the Characters Window from kV. what would be useful for in the new app?

This was just an idea to have a little floating square (maybe with the logo or whatever icon or something) centered above the selected scrolling area as a second visual indicator so we know what we're doing. Not at all necessary, might just be nice to have as an option.

[godbout]

This could be a nice alternative/second option to (shift-)tabbing through possible scroll areas!

yeah. tab/shift tab will be the minimum.

I am personally very stingy about the number of keystrokes I have to press haha so I would definitely prefer not having to press enter to lock into the scroll area when keyboards have more than enough keys to cover both switching between scroll areas as well as all the scrolling moves without having to introduce two modes.

To me having to press enter is definitely redundant, because hotkey+ntab/hotkey+scroll moves is always one less than hotkey+nwhatever moves+return+scroll moves. If I do this for the second scroll area (which will be a common scenario), it's 50% more keystrokes to get me scrolling.

yeah. i find it does make sense, but it's too cumbersome. had some ideas while hiking. i think i'm narrowing down the UX. still need some days, and explore the scrolling events. from my early tests today it seems that you can't ask macOS to scroll a specific scroll area, it just scrolls what's under the cursor.

I also understand wanting to use jk for selection, but I am used to selecting with tab for things like my completion popover in Vim (jk wouldn't work here because I'm in Insert mode) anyways so this would feel very natural to me. But at the end of the day you could, for example, also give the jk/modes thing as an option. Or if we do a DN API we can hack it together with Karabiner🤓

DN mandatory 😂️

This was just an idea to have a little floating square (maybe with the logo or whatever icon or something) centered above the selected scrolling area as a second visual indicator so we know what we're doing. Not at all necessary, might just be nice to have as an option.

yeah, i'm not sure yet how the UI is gonna look. i played today with getting the scroll to light up like the Wooshy Primary Target, but that makes no sense coz you can't read the area then. maybe just glowing the borders then. not sure yet. also there's actually many scroll areas (like in Xcode), but that don't actually have scroll bars because the area is not filled. would be nice to filter those out, but i have no idea yet if it's possible to grab the necessary info.

anyways, playing around and getting clearer.

[godbout]

@jannis-baum more questions!

so from my research, i see two possible tree branches for the UX. that'd be the first choice to do before going down further. the branches are:

1. scrolling what's under the mouse, whether it is the frontmost window or not. doesn't seem to make much sense at first, but windows could be side by side, and you could want somehow to scroll without the a window being the frontmost one. BUT you would need somehow to get the mouse at the current position. do people move the mouse with the keyboard?
2. only bothering with scrolling on the frontmost window. hitting the hotkey could move the mouse to the first scroll area of the frontmost window, and then you're ready to jk/ud/Ggg. pressing tab/shift tab would move you to the next or previous scroll area of the frontmost window.

i kinda like 2. way more. i personally switch apps with Alfred, and i've made an Alfred Workflow to also switch windows within the same apps. so all would work without the mouse, and i think that'd fit my workflow pretty well. but not sure it's the best for everyone.

the thing would be then to find a good UI to make it clear which scroll area we're onto. the background overlay i do with kV and Ws is done by putting a window BEHIND the frontmost one, which wouldn't work with the scroll areas. probably there's a way to create windows with holes inside, but that may be more tricky. not sure if it's the best solution. that part still needs a lot of digestion. but i'm quite happy about that first tree branches clarification.

what do you think?

[jannis-baum]

I'm 100% on approach 2. as well! This would make it consistent with Wooshy and I think it's very natural to target only whatever is focussed. Of course using the trackpad/mouse also let's you scroll windows that aren't focussed, but I'm fairly certain that 99% of Wooshy and Scrolla (is that what we're calling it?🙈) users will be used to switching window focus with their keyboard to do stuff in another window. Targeting areas outside the active window would probably confuse me ^^

do people move the mouse with the keyboard?

There are definitely people who do this but as far as I can tell it's quite rare and even most keyboard enthusiasts aren't very fond of it; it seems to be more of a last resort. My own cursor usually is and stays wherever Wooshy left it😇

the background overlay i do with kV and Ws is done by putting a window BEHIND the frontmost one, which wouldn't work with the scroll areas. probably there's a way to create windows with holes inside, but that may be more tricky

This would actually be really cool in my opinion! I know that transparent windows are possible, maybe putting 4 rectangles or 1 with a mask on one works?

DN mandatory 😂️

😊 With that it'll definitely be possible to create my version without enter presses from the one with it and the other way around hehe

[godbout]

I'm 100% on approach 2. as well! This would make it consistent with Wooshy and I think it's very natural to target only whatever is focussed. Of course using the trackpad/mouse also let's you scroll windows that aren't focussed, but I'm fairly certain that 99% of Wooshy and Scrolla (is that what we're calling it?🙈) users will be used to switching window focus with their keyboard to do stuff in another window. Targeting areas outside the active window would probably confuse me ^^

yep. i think that's gonna be the way to go 👍️

This would actually be really cool in my opinion! I know that transparent windows are possible, maybe putting 4 rectangles or 1 with a mask on one works?

https://stackoverflow.com/questions/9969924/holes-in-nsview-or-nswindow

:D

😊 With that it'll definitely be possible to create my version without enter presses from the one with it and the other way around hehe

i mean. DNs are so useful and easy to make. would be a real pity not to have them.

i think i'm clear for a first alpha. need to work on kV first, and set the licensing for Wooshy, and then i'll start with Scrolla 🎉️

[godbout]

Scrolla is out: https://twitter.com/scrollaapp site and README etc. coming later.

[roelvangils]

Nice! Gonna try it right now! For what it's worth, these are my settings in Keyboard Scroller:

Here's a thought: it might be nice to have a keyboard-friendly way to accelerate (or slow down) the scrolling by holding extra modifier keys.

[godbout]

question: how do you use Keyboard Scroller? like you need to position the cursor first right? do you use Wooshy to position the cursor? do you use Homerow?

Scrolla is gonna work differently. it works a bit like Wooshy: it'll grab the Scrollable Areas (tweaks coming later), you navigate them, and scroll.

[godbout]

Scrolla v1 out. closing.