Idea: Spotaneously adapted circle

[ManDay]

This is just a silly idea which may not even be feasible, but it popped to mind when I mistyped something by crossing into the circle prematurely:

Perhaps it would have a positive effect on writing "blind" if the circle re-centered itsself onto the point where the user started dragging? So if the user happens to start a little bit off to the l/r/t/b that would compensate and the user could twirl around the circle as if they had started in the exact middle every time!

On top of that, perhaps the "initial" circle could be made larger, and when the user starts dragging inside of the circle, it becomes a smaller circle during the drag - that would solve my personal dilemma that sometimes the circle is too big for my gestures and otherwise too small to hit it correctly in the beginning.

[flide]

seems interesting... and complicated...

[martin-braun]

I have to say I like where he comes from. I tried swiping blind with 8vim and faced the same issues. While the former suggestion seems very complicated and would introduce a breaking change, the latter one is probably easy to implement and would work best.

Please let me elaborate:

The current system allows to map swipes that aren't starting from the center circle, so centering the circle to the initial touch position to always start in the middle would break a lot of layouts. Please let's not consider this.

However, shrinking the circle when starting to move into a direction within the inner circle would make movement easier in general. It would be essential to not shrink it immediately on touch to prevent you from entering a side-cell you don't want to take. But, if you start to shrink it (animation) during touch movement within the circle, it should help you to quickly reach your side-cell without further ado.

[ManDay]

seems interesting... and complicated...

I know, users always think everything were trivial, but...

The way I see it, the logic is almost there: 8vim's settings allow to change the circle horizontal position and the circle size. If we add to that the ability to change the vertical position, then dynamic centering & resizing amounts to adjusting these settings "on the fly".

There you have it: The user told you that it's trivial! 😁

@martin-braun, of course, you are right: The method only makes sense for gestures which start at the center. For me, that's 99.9% of all cases.

[martin-braun]

@ManDay That's not the point I make. Even if it's fine for 99.9% in your case, you would effectively disable all other functions that start from the neighbour's cells. Did you know that you can insert your clipboard with L-C (left -> center)?

You can't forcefully center the center circle, because you lock yourself out from other start cells. My point is that you would rather make the center circle bigger to hit it easier and 8vim could shrink the center circle when you move around, so that you get the benefit of a small center circle while drawing your sequence, until you lift your finger.

[ManDay]

@martin-braun I don't understand your comment. The initial keyboard would not look any different from how it looks now. You can start your gesture in any sector or the center, as usual. Only if you start your gesture in the center, the circle will shrink and center itself on the initial point for the duration of the gesture.

Also, consider that this solves your conundrum of "shrinking the circle away under the touch" - the two things have to go hand in hand.

[martin-braun]

@ManDay Thank you for clearing this up. I wasn't understanding your comment either, but now I understand, and I think it's a much better solution to the problem, because we don't need an animation. You could shrink the circle immediately, if you center it.

The part I was missing was that you want it to center ONLY when hitting the center. This way, it would not lock you out of other starting cells, beautiful. +1

[mtt-ableton]

Same issue, not sure if same idea:

I remember playing games in early Android age, where joysticks would always be centered wherever the finger starting touch, which means one did not have to aim very precisely at the center of the joystick to play, and could just rely on relative finger movements.

Given that the concept of 8vim is based on relative finger movements, I guess we should have something similar where the initial circle would have a grace area, where the finger can start touching, that would temporarily move the area a bit to make it inside the circle.

[chrysn]

On the note of users thinking it to be trivial (I know it's not, yet I barge in with suggestions, trusting you take them with any amount of salt necessary), I've given this some thought for quikwriting, but never implemented it there. I'd view this not so much from a single-event-alters-settings point of view, but more like SDR radios can do QPSK frequency adjustments: Averaging the positions that were detected for passing through the quadrant boundaries over the course of words, small shifts could be induced.

[ManDay]

I'm not convinced that I'd like such a sophisticated mechanism, personally. Adapting on the initial "touchdown" feels more predictable, yet sufficient for the purpose of helping with precision. I think I'd struggle with it being "too clever" and dynamically moving the circle while I write. Cognitively, I wouldn't be able to accomodate this and intuitively, I reckon it could develop some spurious dynamics such as a "drift" from a feedback-loop where the user attempts to follow the moving circle while the circle moves to anticipate the user's offset.

I think KISS would be a good approach, also for a managable implementation effort (which I talk about a lot but don't actually do 😅 )

[ManDay]

I would like to propose an additional change, which, I think, together with the adapting circle, will greatly improve typing accuracy and efficiency. I have thought about this a while, why I still make typos and why I am unable to type blind, despite having accumulated several years of experience with 8vim. My conclusion eventually was that, besides the auto-centering circle, another change is greatly needed:

Do not infer the sector from where the circle was crossed into or out of, but rather from the inclination (the angle at which) the circle was crossed into or out of!

While this wil not prevent accidental crossings into the circle (which seem semantically inevitable), it should help with correctly determining the sector (a 90° clustering is easily beyond the precision of any typical trajectory), thereby allowing for the circle to be made smaller and reducing the risk of accidentally crossing into it!

[mtivi]

I think this is an interesting idea. especially considering the angle. When I got a new phone with a different screen size it took a really long time before I found the right offset, size, etc to be able to type again,

If the position was dynamic, then new phones wouldn't be a problem

[MaethorNaur]

I think automatically shrinking the circle is doable.
We could start with a feature which automatically shrinks the circle if the movement starts there. What do do think?

[flide]

we can try beta testing the concept, provided we can gather atleast 200 users to test it

…

On Thu, Feb 22, 2024, 8:11 AM Pedro Mangabeira ***@***.***> wrote: I think automatically shrinking the circle is doable. We could start with a feature which automatically shrinks the circle if the movement starts there. What do do think? — Reply to this email directly, view it on GitHub <#304 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABX5WR5FAZLVWEYJAB2QFXLYU2V6HAVCNFSM6AAAAAAXYGIVC6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSNJYGU2TMNJUGM> . You are receiving this because you commented.Message ID: ***@***.***>

[ManDay]

I think automatically shrinking the circle is doable. We could start with a feature which automatically shrinks the circle if the movement starts there. What do do think?

I think that it has to go hand-in-hand with the recentering, because else it opens a case where you start dragging at a point within a larger circle which then suddenly becomes a sector next to the smaller sector.

@flide, how do you propose that can be achieved? Could this be an opt-in splash screen on the app? Because I can't imagine we get 200 people here in the issue.

[flide]

we are either going to use the internal test channel (would need to add testers to it) or we are going to open a beta channel on google play store for people to opt in for beta testing. don't know of any beta channels for fdroid.

@MaethorNaur is working on the google beta channel stuff.

[MaethorNaur]

@ManDay 8Vim should be available on the open testing channel.
You can test it by signing-up here.
If you are not using Google play, you can download the RC from the release page.
I've also created a category on the discussion just for the feedbacks on RCs

[ManDay]

I'll try it asap! In the meantime: It occurred to me that a better alternative to "moving" the circle would be offsetting the touchpoint by the according dinstance while keeping the circle as-is (but still shrinking). Someone had mentioned previously that this behaviour is known from on-screen joysticks. It might reduce visual confusion for those who look at the screen while writing.

Edit: I tried it and I think it's really well integrated into settings and works well as far as the shrinking is concerned 👍 . I would, however, only consider this together with "auto-centering"/"auto offset" behaviour, because otherwise you don't really gain any freedom. We still have to be precisely aligned with the center of a (now smaller) circle.

[MaethorNaur]

@ManDay
What about offsetting the circle (but still within the initial boundary), then when making movements, the circle try to follow the finger?

[ManDay]

@MaethorNaur Sorry for the late reply! Right now I can't see the utility of the circle following the finger. The goal which I had in mind when opening this issue was simply:

When you perform a (C-...-C) gesture blind it shouldn't be a problem if you didn't start in the precise center of the circle. That's why I suggested that at the beginning of the gesture (on the first "C") we re-center the circle onto the position of the touch. And it stays there until the finger is lifted.

To be honest, #445 at the current time seems to do something which is almost opposite to that (the shadow circle appears on the opposite site of the initial touch) and -- for a reason which is also unclear to me -- it moves the circle during the gesture. I'm sure you have a logic in mind for #445 which I currently just don't grasp, but I think it's not the same as the idea right here?

[MaethorNaur]

How about that? (The shadow is just there to show the other circle)

output.webm

[ManDay]

As discussed on Matrix and in the PR, I think that's exactly what we need. Concerning the Settings, I think "Auto resize circle" should only be an option if "Dynamically move the circle" is activated. Because: As by the comments on the PR, the circle should be shrunk immediately when the user touches it. So if you touch it close to the border and then it shrinks without being re-centered, you will accidentally end up in a sector (in the current Debug Build this already happens).