Rsinoa layout

[lrvideckis]

       |       |       |
   r   |   s z |   i   |
     v |   k   |       |
------- ------- -------
   j   |   p   |       |
   n l |   o f | u a   |
   x   |   g   |   y   |
------- ------- -------
   c   | b   w |   q   |
   h m |   t   | ' e   |
       | .   d |   ,   |
------- ------- -------

Optimized for a few metrics, inspired by the list here https://github.com/dessalines/thumb-key?tab=readme-ov-file#thumb-key-letter-positions

• 9 most common letters are a tap
• minimized finger travel
• optimized for alternating thumbs
• most used keys towards bottom-right (including preferring swipes towards bottom, and right)

BTW I wasn't actually able to get the app running. I was running into android studio/java version issues :( So I'm hoping you can check that my ENRsinoa.kt file is correct (and matches the above ascii-art representation of the layout)

Here's the code for anyone who is crazy enough to go read it haha

Let me know any feedback! Currently I'm pretty happy with this layout, and I do plan to start learning it. But I'm also open to feedback, and can keep tweaking my model in search of something better.

[lrvideckis]

see my previous issue #1053 (I got some feedback on this previous layout, and rethought some things to create this current layout)

Also see my critique of the MessagEase/ThumbKey layout which is my motivation for creating this current layout

[lrvideckis]

random notes about the layout:

The shift,cancel shift swipes for the ThumbKey layout are on the middle row/right column key. But my optimized layout ended up putting the letter y there :( . So I moved the shift,cancel shift swipes to the top row/right column.

---

Regarding the 9 most common letters rsinoahte as a tap: I did hard-code this into the model (the model only considers layouts with these 9 letters as a tap, and all other letters/symbols as a swipe). And this property did not arise naturally from some metric. I figured here that there's a pretty good consensus that having these 9 letters as a tap is good/optimal.

At one point, I did try not hard coding this. And occasionally the model would try putting (the next frequent) d or l as a tap. But it always had a worse score.

the benefit of hardcoding is the model won't waste any time on suboptimal solutions

---

regarding prioritizing the bottom right side of the keyboard (because it's close to both space, enter, and modifier keys): The way I did this was the following: I modeled it where the "space key" is on the right column:

       |       |       |
   r   |   s z |   i   |
     v |   k   |       |
------- ------- -------
   j   |   p   |       |
   n l |   o f | u a   |
   x   |   g   |   y   |
------- ------- -------
   c   | b   w |   q   |
   h m |   t   | ' e   |
       | .   d |   ,   |
------- ------- -------
       |       |       |
       |       | SPACE |
       |       |       |
------- ------- -------

Then, when I minimized finger travel, I took spaces into account (spaces were included in the corpus). And then naturally the most used keys (ETA) were in the bottom/right spots. Furthermore, there are very few upwards and left swipes. Most swipes are downwards/rightwards. Again this all emerged naturally from minimizing finger travel

---

Regarding optimizing for alternating thumbs, my model considered sequences of 3 and 4 letters only (from the corpus). And then having vowels on the right, consonants on the left naturally emerged from the model

---

Regarding the symbols .,': My code considers the frequencies of these 3 symbols in the corpus, and optimizes their placement along with the 26 letters simultaneously; making no distinction between letter and symbol. (they are all just different characters in the eyes of the optimization algorithm).

I specifically didn't include other (somewhat common) symbols like !?-*"+= mainly because the frequencies of those symbols in (my chosen) corpus are a bit off/skewed from what you'd might use them for in daily phone usage. So instead I opted to only include .,' and there's much space for users to add any symbols they wish

---

No 2 swipe-letters are adjacent (formally, having a 45 degree angle). I did add a penalty for adjacent swipes in my model exactly as described in my comment

[lrvideckis]

so I just stumbled upon this #169 where some layouts are mentioned, and it gets pretty technical. LMK if you want me to go more in depth about any of my metrics and or the how the optimization algorithm works which I used. I'm happy to get more technical

[dessalines]

Looks good, thx for doing all this work! I'll run ./gradlew formatKotlin to pass lint.

I'd be happy to add more keyboards in the future if you like.