[new layout idea] have less keys and place some characters as a swipe

[lrvideckis]

hi! so i've been using the following 2 layouts for the past year now:

hindi:

and my biggest issue with the english layout is mistyping. one thing other keyboards do is predict the next letter (as you type) and make the hit-box for that letter slightly bigger. now this feature is quite hard to do well. another feature is autocorrect https://github.com/Julow/Unexpected-Keyboard/issues/68 which is also quite hard to do well

so instead i'm thinking of another idea: so after typing in my hindi layout for a while, i rarely mis-type because the keys are bigger (it's quite nice actually). so what if we made an english layout like my hindi layout: where we have maybe 6-10 (bigger) keys total, put frequent letters as a tap, less frequent letters as a swipe.

the biggest downside is this would be a completely new layout which i would have to learn.

we would have to create+optimize this layout using maybe simulated annealing (like this https://xsznix.wordpress.com/2016/05/16/introducing-the-rsthd-layout/ ). also how to handle symbols/numbers?

i'm open to any of your ideas

[lrvideckis]

some things ive noticed for optimizing the layout:

1. tap is better than swipe
2. its good for consecutive letters to be typed with opposite/alternating thumbs (in particular since ctrl is in the left corner, then for common shortcuts like ctrl-c,ctrl-z, c,z should be on the right)
3. its easier for a thumb to swipe towards the edge and or downwards, and harder to swipe towards the middle and or upwards (especially with sticky thumbs)
4. when the same thumb has to type 2 letters in a row, the closer these keys are, the better
5. when the same thumb has to first swipe, then tap, it's good if the swipe is in the direction of the tap

probably the layout should be optimized for 2-thumb typing. for the case of 1-thumb typing, typing speed should be similar no matter which layout

[lrvideckis]

Basically I'm thinking about something like this

https://www.reddit.com/r/KeyboardLayouts/comments/raed9m/im_developing_an_alternate_input_method_for/

https://www.reddit.com/r/KeyboardLayouts/comments/no9sbc/i_designed_a_keyboard_layout_for_smartphones/

https://play.google.com/store/apps/details?id=com.exideas.mekb

https://github.com/dessalines/thumb-key

[Spike-from-NH]

You can get close to this with custom layouts (instructions here), except ➊ you can't have 60° swipes, only 45° (the "compass points") and I tend to only use 90° to minimize ambiguity in my gestures; ➋ you can't have key-on-top-of-key, as our XML doesn't have analogs of ROWSPAN and COLSPAN in HTML; ➌ you aren't as free regarding appearance as you might like; the result has keys that are basically squarish. Within this framework, however, you should be able to pursue the goal of increased typing speed.

[agy3]

Someone posted a "HoneyKey" layout for Unexpected Keyboard on Reddit, see the comments for the XML definition: https://www.reddit.com/r/KeyboardLayouts/comments/1c69olx/honeykey_my_custom_smartphone_keyboard_layout_for/

Edit: Also, check out the MessagEase layouts in the user layouts: https://github.com/Julow/Unexpected-Keyboard-layouts

[lrvideckis]

Hi, Thanks for sharing!

HoneyKey layout does look interesting, but there's this critique.

IMO the MessagEase layout looks a tad better than HoneyKey.

I'm personally working on a simulated annealing program to find some optimized layout based on the factors I mentioned above. Here are some example layouts it has produced:

   +   |   7   |   8   |   9   | {   } |
 | d & | * n . | ? i ! | v r % | ( w ) |
   `   |   p   |   y   |   ,   | [   ] |
------- ------- ------- ------- -------
   ^   |   4   |   5   |   6   |   ~   |
 = u @ | z o ' | m e f | c t / | < l > |
   \   |   k   |   b   |   g   |   #   |
------- ------- ------- ------- -------
   0   |   1   |   2   |   3   |
 shift | : h - | " a j | ; s _ | backspace
       |   q   |   x   |   $   |
------- ------- ------- ------- -------

   $   |   7   |   8   |   9   | {   } |
 % l \ | | h " | ' n - | j s * | ( u ) |
   _   |   p   |   y   |   ,   | [   ] |
------- ------- ------- ------- -------
   ^   |   4   |   5   |   6   |   =   |
 & w + | q o ; | m e g | ? a x | < d > |
   @   |   k   |   f   |   b   |   /   |
------- ------- ------- ------- -------
   0   |   1   |   2   |   3   |
 shift | z r . | ! t v | c i ~ | backspace
       |   `   |   :   |   #   |
------- ------- ------- ------- -------

I'm currently still playing around with it, and trying to find something I like. Maybe I'll write a blog post/reddit post about it when I'm finished, we'll see.

[lrvideckis]

oh dang, MessageEase did a lot of research on their layout https://github.com/dessalines/thumb-key?tab=readme-ov-file#messagease

ya, the more I work on this, the more I realize it's a hard problem (finding optimal keyboard layout), and I keep second guessing some of the factors

[lrvideckis]

Hi, update on this, I finally found a layout I like

https://www.reddit.com/r/KeyboardLayouts/comments/1fdc5la/optimized_layout_for_mobile_android/

https://github.com/lrvideckis/keygen/blob/nine_by_nine_only/README.md

LMK if you're interested in including this layout in your app. I don't mind creating a PR

[lrvideckis]

i can totally understand if you don't want this layout in the main app, it is for hardcore power users anyways

here's the xml https://github.com/lrvideckis/Unexpected-Keyboard/blob/my_changes/srcs/layouts/messagease_inspired.xml

[Julow]

I would love to include a messagease inspired layout in the app. Though this one seems to be too different from other layouts. Here are some remarks:

• The spacebar slider is gone and no compose key. I'd prefer to include a layout that uses the standard bottom row, unless it's for a precise reason.
• Editing keys are not present in any other layouts.
• Uneven empty spaces on the sides.
• The middle row might be hard to reach for some people on some devices and this layout put the most important row there. Isn't the dual layout more popular ?
• You can use the anti-clockwise gesture to put digits on the main layout.

[lrvideckis]

Hi! Ok it seems you're serious about this. So I optimized the layout for my needs specifically, but my needs are slightly unusual. If we're going to do this, I can keep searching for a (different) layout more suitable for the average person.

• The bottom row in my screenshot is custom. For my PR, I will keep your current bottom row. Sorry for the confusion. My work is mainly just for optimizing the 3x3 grid of letters/symbols. Beyond this 3x3 grid, I'm open to anything you suggest.
• I optimized my layout specifically for one-thumb typing, whereas for the average person, two-thumb typing is more popular. (in particular it means consecutive taps should be on opposite/alternating thumbs, which my above layout basically ignores). Here, I can add in a penalty for alternating thumbs.
• I personally was going to use this layout mainly for texting, and chose to put a limited number of symbols (.,'!?-). My code considers the frequencies of these 6 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). But the average person might want a different set of symbols. I am open to changing it to any set of symbols which you suggest.

Also what do you mean by the "dual layout"?

Finally, this reddit post came out earlier today. And if we're serious about this, then probably we should optimize for 2 thumbs, meaning not have a 3x3 grid. Instead have something more like in that post.

[Julow]

I'm very happy to see people trying out the messagease-inspired gestures and making layouts :)

By the "dual layout" I mean the one where the 3x3 grid is repeated on the right and on the left, for each thumb separated by a column of more rarely used keys in the middle. I think I saw former messagease users requesting this, though I can't find where.

[lrvideckis]

got it. here's what i'll do: I'll stick to 3x3 grid. I'll add a penalty for alternating thumbs. I'll make a PR with 2 new layouts: one with a single 3x3 grid and one dual layout; Both new layouts with the same 3x3 grid

it's a good middle ground for me. I'll stop learning my above layout, and will learn the new one instead.

the difference between this new layout, and my above current layout is pretty much the difference between MessagEase and ThumbKey:

Alternate thumbs for vowels and consonants (Vowels on right side of keyboard, consonants on left). This naturally results in fast digram speeds.

https://github.com/dessalines/thumb-key?tab=readme-ov-file#thumb-key-letter-positions

[lrvideckis]

oh btw see my critique of the MessagEase (and also ThumbKey) layout which is my main motivation for creating my layout

[lrvideckis]

Hi, update on this, I tweaked my metrics, inspired by the list here https://github.com/dessalines/thumb-key?tab=readme-ov-file#thumb-key-letter-positions and found this layout:

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

random notes about the layout:

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). 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 (instead having penalty for swipe). 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 space, enter, backspace): The way I did this was the following: I modeled it where the "space key" is on the right column:

       |       |       |
   r   |   s z |   i   |
     c |   k   |       |
------- ------- -------
   x   | p   f |       |
   n l |   o   | u a   |
   v   | g   d |   y   |
------- ------- -------
   j   | b   w | '   q |
   h m |   t   |   e   |
       |     , |   .   |
------- ------- -------
       |       |       |
       |       | 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) gravitated towards the bottom/right spots. Furthermore, there's a slight preference to having rightward swipes over leftward swipes (also bottom row is slightly preferred over top row). 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

---

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 any suggestions, and can keep tweaking my model in search of something better. I'm also happy to go into more technical details of the metrics and/or the how the optimization process works which I used!

In particular does anything about the layout seem off/weird (like intuitively)? LMK! cuz then either my code has a bug or one of my metrics needs to be rethought through.

[lrvideckis]

Now I did implement it, trying to address some of your comments above, a̶n̶d̶ I̶ r̶a̶n̶ i̶n̶t̶o̶ a̶n̶ i̶s̶s̶u̶e̶:̶

Some questions I have:

• i̶s̶ t̶h̶e̶r̶e̶ a̶n̶y̶ w̶a̶y̶ y̶o̶u̶ c̶a̶n̶ h̶a̶v̶e̶ t̶h̶e̶ a̶n̶t̶i̶-̶c̶l̶o̶c̶k̶w̶i̶s̶e̶ l̶a̶b̶e̶l̶ n̶o̶t̶ o̶v̶e̶r̶l̶a̶p̶ w̶i̶t̶h̶ t̶h̶e̶ d̶o̶w̶n̶w̶a̶r̶d̶s̶-̶s̶w̶i̶p̶e̶ l̶a̶b̶e̶l̶?̶
• I will mention this layout isn't finished: I do want to add other symbols like !?+-"() (maybe all the symbols actually). Of course I can choose myself where to put these, or I'm open to any suggestions.
• There's a lot of empty space - Should we leave it that way, or else what to put there? But I do plan to also add the dual layout, so probably we should put any extra symbols (!?+-"()) in the 3x3 grid so they also exist in the dual layout, and it's consistent

[Spike-from-NH]

I've gotten used to the recent clockwise swipe to type capitals—but you can't apply this to a letter that is already a swipe.

I don't think anticlockwise swipes get a legend at all. On custom layouts, the documentation does warn that any indication for a key will clash with any s swipe the key has.

[lrvideckis]

I don't think anticlockwise swipes get a legend at all.

ah I just got it: you have to do both anticircle="3" indication=""

[lrvideckis]

<?xml version="1.0" encoding="utf-8"?>
<keyboard name="RSINOA" script="latin">
  <row>
    <key shift="1.5" key0="r" key4="c" anticircle="7" indication=""/>
    <key key0="s" key6="z" key8="k" anticircle="8" indication=""/>
    <key key0="i" anticircle="9" indication=""/>
  </row>
  <row>
    <key shift="1.5" key0="n" key6="l" key7="x" key8="v" anticircle="4" indication=""/>
    <key key0="o" key1="p" key2="f" key3="g" key4="d" anticircle="5" indication=""/>
    <key key0="a" key5="u" key8="y" anticircle="6" indication=""/>
  </row>
  <row>
    <key width="1.5" key0="shift" key2="loc capslock" anticircle="0" indication=""/>
    <key key0="h" key6="m" key7="j" anticircle="1" indication=""/>
    <key key0="t" key1="b" key2="w" key4="," anticircle="2" indication=""/>
    <key key0="e" key1="'" key2="q" key8="." anticircle="3" indication=""/>
    <key width="1.5" key0="backspace" key2="delete"/>
  </row>
</keyboard>

I can open a PR if that's better

[Onikoroshi]

Such cool ideas; we've been chatting on Reddit too! I'm very interested in taking a look at your annealer program, but unfortunately that link results in github's famous 404 error. Any chance we can get an opportunity to play around with that?

[lrvideckis]

https://github.com/lrvideckis/keygen/tree/nine_by_nine_only

I use a different code formatter, so here's the relevant diff: https://github.com/lrvideckis/keygen/compare/format...lrvideckis:keygen:nine_by_nine_only

I was inspired by this https://xsznix.wordpress.com/2016/05/16/introducing-the-rsthd-layout/

[Julow]

I modeled it where the "space key" is on the right column:

I'm not a user of a messagease layout but in my QWERTY experience, I often have to reach the backspace key and it takes a lot of effort. The enter key on the bottom-right is the most uncomfortable to reach but is hopefully less often used. I think the bottom right and bottom left are the hardest places to reach, as hard as reaching the top-middle. My lazy thumbs are most comfortable in the diagonal that goes from the bottom-middle to the top-right and to the top-left. Do you have a different experience ?

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

That's the good thing to do. In my experience, swipes are not precise, perhaps due to the thumbs being more comfortable on the arc bottom-middle to top-right and not on a vertical line. The best swipe angle is different for every keys.

I do want to add other symbols like !?+-"() (maybe all the symbols actually).

It would be best to have all the symbols to type passwords but that's not required. A messagease user should learn to switch to a more complete layout when writing passwords or programming. The empty space on the left and right could be good places to put these rarer symbols.

I have some feedback on the shift and backspace keys: They are hard to reach and are too large, making them ugly. I'd suggest making them smaller by adding empty space between them and the 3x3 grid using the "shift" attribute.

[lrvideckis]

My lazy thumbs are most comfortable in the diagonal that goes from the bottom-middle to the top-right and to the top-left. Do you have a different experience ?

so my daily driver layout has the relatively tiny spacebar (see my initial screenshot) and I've found that I do have to reach a bit with either thumb to hit space

maybe my screen is wider than yours (I use a pixel 6)

[lrvideckis]

Hi, after some thought; I think everyone has their own opinion about what an "optimized" layout is. For example this came out recently, also it seems some people like this.

I'm not really convinced anymore that my layout is endgame.

[Onikoroshi]

But, it's an excellent addition to the options! I'm really liking Typewise hexagonal keys, but I'm frustrated that I cannot make my own layout (even when I pay). I wish I could either put hexagonal keys on Keyboard Designer or change the layout on typewise. Nothing is perfect; but progress is being made!

[Spike-from-NH]

I've been playing around with your minimalist layout. The ultimate goal is maximum typing speed. In the meantime, I've been using the conflicting notions of putting related characters (f/v) nearby; putting characters where I can remember them (pseudo-alphabetical); favoring southwest and northeast swipes; and making common sequences a single swipe. Happily, if I settle on something, it will port to all of my Android devices. But I'm unlikely to abandon QWERTY because I do a lot of typing on the PC too.

[lrvideckis]

favoring southwest and northeast swipes

I'm curious what's the reason for this? I did notice the main qwerty layout follows this principle

[Spike-from-NH]

favoring southwest and northeast swipes

I'm curious what's the reason for this?

Slightly easier mechanics with my right thumb.

[lrvideckis]

got it. so my most recent layout doesn't take this (certain swipe directions are easier for certain thumbs) into account

it brings up another question: do we optimise for right/left/both thumbs?

for example optimizing for both thumbs would look like:

• southwest and northeast swipes better for middle,right columns
• northwest and southeast swipes better for middle,left columns

it does seem to compete with the finger travel metric meaning you'd have to choose which metric you care about more (i.e. can't have both)

[Spike-from-NH]

I see a lot of people using both thumbs. In which case, yes, sw-ne on the right side, nw-se on the left side, drop the 9-key assumption and perhaps go with two blocks of six.

Other comments: ① Having done the heavy lifting of moving the entire alphabet to nine huge keys, your layout inexcusably leaves six positions with no key at all. Unexpected requires you to reserve the entire width of the screen and doing nothing with it! Putting something everywhere doesn't slow down the use you're optimizing for. ② All of these special characters ♪ I've crammed into my layout are never going to fit in a minimalist layout.

[lrvideckis]

it's really good feedback actually

[alotbsol555]

interesting thread! I just want to add a messageease-inspired layout, which is close to the original. maybe some points are useful to others.

the left column is added but could be improved, because the implementation of anticircles allows to type numbers by anticircles on the 9 letter keys. using the last button on the 2nd row switches forward to the numpad layout and back to the main layout. the dpad right to the spacebar types a space as well on key0.

main layout:

numpad layout:

edit: it's a German layout, i.e. d an o are switched and äüöß are added.

[lrvideckis]

Hi again! I re-thought through the feedback, and came up with this layout:

 ;   ] | *     | #     |     | |     / | {   % |
   l   |   c   |   m   |   p   |   u   |   o   |
 [   b |     z |     ? | @     | $     | "   } |
------- ------- ------- ------- ------- -------
 +     | \   ) | x     |     ! | <   - |     _ |
   d   |   n   |   r   |   a   |   i   |   f   |
     j | (   g |     v | '     | k   > | ~     |
------- ------- ------- ------- ------- -------
       | q     | w     | `   . |       |
 SHIFT |   s   |   t   |   e   |   h   | BACKSPACE
       |     = | &   , | y   ^ | :     |
------- ------- ------- ------- ------- -------

assumptions

• all swipes are at a diagonal (thus now I no longer have a penalty for 2 swipes at a 45° angle)
• characters <>()[]{} were not included in the optimization process (everything else was). I added <>()[]{} in at the end, manually. Here, I wanted these symbol pairs to be close to each other.
• Excluding <>()[]{}, the model does optimize the placement of all letters and symbols, making no distinction between them like before. So I updated my corpus to a modified Calgary Corpus, my full raw corpus which is roughly 7% code, the rest books,bibliographies,news,etc (so hopefully it has decent frequencies for symbols), modifications:
  • The Calgary Corpus does include some images and binary files which I removed
  • I added a space at the end of each line: here, many lines end with a period, then a newline. By adding a space after all lines, the frequency of period-space digram is now taken into account by the position of the space key in the model
• didn't include digits as I plan to put them as the counter-clockwise motion
• SHIFT and BACKSPACE keys are fixed. my model never considers placing anything there.
• 3x6 key layout. After this feedback, I wanted no column to be shared by both thumbs.
• I did model SPACE as being one row below the bottom; right in the middle (only taken into account during the finger travel metric). I dropped the assumption that "bottom-left" is better from earlier, Now it's just "bottom" is better

metrics

placement

• a penalty for not being on the "good diagonals": (higher is worse); don't worry too much about these numbers' magnitude, rather, the relative magnitude between them matters more. Also the relative magnitude is somewhat arbitrary, and I played around with this a lot. The main point is the main diagonals are "good", and the farther away, the worse.

[0.0, 0.3, 0.6, 0.6, 0.3, 0.0],
[0.3, 0.0, 0.3, 0.3, 0.0, 0.3],
[---, 0.3, 0.0, 0.0, 0.3, ---],

• a penalty for swipe, to give an idea: the penalty is 2, e.g. roughly three-times worse than the 0.6 which is the worst tap-placement.
• a further penalty for being a bad swipe for that specific thumb: (e.g. north-west is bad for the right thumb ... etc)

finger travel

• single finger travel: modeled exactly as before (inspired by MessagEase's paper). Basically, using fitts' law, how much distance is it to type out the entire corpus with one finger.
• travel when typing with both thumbs: Here, after this feedback, I had to put some thought, and came up with this:
  • If 2 consecutive keys are typed with the same thumb, then, using fitts law, I add the distance the thumb has to move between those 2 keys (a side note, it means in this case, this distance is added twice: once here, and once from the single-finger-travel metric)
  • If there are 3 consecutive keys, like (left thumb, right thumb, left thumb (or vice versa)) then I add the distance the left thumb has to travel from the 1st key to the 3rd key
  • If there are 4 consecutive keys, like (left thumb, right thumb, right thumb, left thumb (or vice versa)) then I add the distance the left thumb has to travel from the 1st key to the 4th key
  • I just stopped here, well mainly because the keygen program I forked only supported runs of 4 consecutive chars, and I didn't really feel like further modifying it

---

One note here: I realized the single-finger-travel metric and the both-thumbs-travel metric do compete a bit with each other. I̶ w̶a̶s̶ a̶ b̶i̶t̶ c̶o̶n̶f̶u̶s̶e̶d̶ w̶h̶y̶ t̶h̶e̶ ̶.̶ i̶s̶ a̶ n̶o̶r̶t̶h̶-̶e̶a̶s̶t̶ s̶w̶i̶p̶e̶, b̶e̶c̶a̶u̶s̶e̶ w̶h̶e̶n̶ t̶y̶p̶i̶n̶g̶ w̶i̶t̶h̶ o̶n̶e̶-̶f̶i̶n̶g̶e̶r̶, y̶o̶u̶'d̶ w̶a̶n̶t̶ t̶h̶e̶ ̶.̶ t̶o̶ b̶e̶ a̶ s̶o̶u̶t̶h̶-̶e̶a̶s̶t̶-̶o̶r̶-̶w̶e̶s̶t̶ s̶w̶i̶p̶e̶ t̶o̶ b̶e̶ a̶b̶l̶e̶ t̶o̶ h̶i̶t̶ s̶p̶a̶c̶e̶ m̶o̶r̶e̶ e̶a̶s̶i̶l̶y̶.

B̶u̶t̶ t̶h̶e̶ w̶a̶y̶ I̶'m̶ m̶o̶d̶e̶l̶i̶n̶g̶ b̶o̶t̶h̶-̶t̶h̶u̶m̶b̶-̶t̶r̶a̶v̶e̶l̶;̶ a̶ n̶o̶r̶t̶h̶-̶e̶a̶s̶t̶ s̶w̶i̶p̶e̶ f̶o̶r̶ ̶.̶ i̶s̶ a̶c̶t̶u̶a̶l̶l̶y̶ b̶e̶n̶e̶f̶i̶c̶i̶a̶l̶ a̶s̶ w̶i̶t̶h̶ t̶h̶a̶t̶ t̶h̶u̶m̶b̶, y̶o̶u̶ t̶y̶p̶e̶ ̶.̶, w̶i̶t̶h̶ t̶h̶e̶ o̶t̶h̶e̶r̶ t̶h̶u̶m̶b̶, y̶o̶u̶ t̶y̶p̶e̶ s̶p̶a̶c̶e̶, t̶h̶e̶n̶ t̶h̶e̶ f̶i̶r̶s̶t̶ t̶h̶u̶m̶b̶ i̶s̶ n̶e̶a̶r̶ t̶h̶e̶ m̶i̶d̶d̶l̶e̶ o̶f̶ t̶h̶e̶ 3̶x̶3̶ p̶a̶d̶ t̶o̶ t̶y̶p̶e̶ t̶h̶e̶ n̶e̶x̶t̶ l̶e̶t̶t̶e̶r̶

Alternating thumbs

• added a bonus when there are runs of 2,3,4 alternating characters just like before -̶ a̶l̶s̶o̶ I̶ r̶e̶a̶l̶i̶z̶e̶d̶ t̶h̶e̶ a̶b̶o̶v̶e̶ 2̶-̶t̶h̶u̶m̶b̶ t̶r̶a̶v̶e̶l̶ m̶e̶t̶r̶i̶c̶ a̶l̶s̶o̶ w̶o̶r̶k̶s̶ i̶n̶ f̶a̶v̶o̶r̶ w̶i̶t̶h̶ a̶l̶t̶e̶r̶n̶a̶t̶i̶n̶g̶ t̶h̶u̶m̶b̶s̶, a̶s̶ t̶h̶e̶r̶e̶ i̶s̶ a̶ p̶e̶n̶a̶l̶t̶y̶ f̶o̶r̶ t̶y̶p̶i̶n̶g̶ c̶o̶n̶s̶e̶c̶u̶t̶i̶v̶e̶ k̶e̶y̶s̶ w̶i̶t̶h̶ t̶h̶e̶ s̶a̶m̶e̶ t̶h̶u̶m̶b̶, a̶n̶d̶ t̶h̶e̶r̶e̶'s̶ n̶o̶ p̶e̶n̶a̶l̶t̶y̶ f̶o̶r̶ t̶y̶p̶i̶n̶g̶ c̶o̶n̶s̶e̶c̶u̶t̶i̶v̶e̶ k̶e̶y̶s̶ w̶i̶t̶h̶ d̶i̶f̶f̶e̶r̶e̶n̶t̶ t̶h̶u̶m̶b̶s̶ not really: when 2 consecutive keys are tapped with the same thumb, then the 2 metrics agree. But when 3 consecutive keys are tapped alternating, then they compete

---

again, notice how vowels are exclusively on one side

[lrvideckis]

updated code here

[Spike-from-NH]

That is more rigorous than I'll ever be! But the above code is to your modeling system (about which I have no opinion I believe to be better than yours). If you'd provide a link to your XML, I'll play around with it and maybe offer feedback.

[lrvideckis]

<?xml version="1.0" encoding="utf-8"?>
<keyboard name="LCMPUO" script="latin">
  <row>
    <key key0="l" key1=";" key2="]" key3="[" key4="b"/>
    <key key0="c" key1="*" key4="z"/>
    <key key0="m" key1="#" key4="?" anticircle="7" indication="⁷"/>
    <key key0="p" key2="|" key3="@" anticircle="8" indication="⁸"/>
    <key key0="u" key2="/" key3="$" anticircle="9" indication="⁹"/>
    <key key0="o" key1="{" key2="%" key3="&quot;" key4="}"/>
  </row>
  <row>
    <key key0="d" key1="+" key4="j"/>
    <key key0="n" key1="\\" key2=")" key3="(" key4="g"/>
    <key key0="r" key1="x" key4="v" anticircle="4" indication="⁴"/>
    <key key0="a" key2="!" key3="'" anticircle="5" indication="⁵"/>
    <key key0="i" key1="&lt;" key2="-" key3="k" key4="&gt;" anticircle="6" indication="⁶"/>
    <key key0="f" key2="_" key3="~"/>
  </row>
  <row>
    <key key0="shift" key2="loc capslock"/>
    <key key0="s" key1="q" key4="=" anticircle="0" indication="⁰"/>
    <key key0="t" key1="w" key3="&amp;" key4="," anticircle="1" indication="¹"/>
    <key key0="e" key1="`" key2="." key3="y" key4="^" anticircle="2" indication="²"/>
    <key key0="h" key3=":" anticircle="3" indication="³"/>
    <key key0="backspace"/>
  </row>
</keyboard>

[Onikoroshi]

j@lrvideckis : Holy cow, that's super cool! It looks kind've like my 5x3 layout except you use swipes instead of layers:

I'm not a huge fan of typing with my thumbs (I prefer to use my three strongest fingers, and sometimes my pinky), but I would love to see the xml for that layout and try it out. You might make me a convert!

[lrvideckis]

oh, on a side note, all my metrics are symmetric, so you could flip the layout (if you preferred vowels on the left) and in theory it should be the same optimal-ness

[lrvideckis]

Hi again, I was still pretty confused why the . is an up-wards swipe. So after some digging, I found my corpus is bad. I chose the Calgary corpus which includes a bunch of papers which has over 1000 occurrences of .ul, .ti-\n(x0u, .nh etc, which skewed the frequencies of .-letter digram. (not sure what these are, but anyways it doesn't even matter)

I'm switching my corpus, being more careful this time, and will post a new layout soon

[Spike-from-NH]

To your parenthetical note, those would be directives in troff, a predecessor of HTML.

Shouldn't the most common letters, E and T, be in the "rest position" of the two thumbs?

You take pains to specify superscripts as the legends for the numerals. Going with the default is equally good, to me.

[lrvideckis]

Shouldn't the most common letters, E and T, be in the "rest position" of the two thumbs?

oh good point, lemme update the placement weights

[Spike-from-NH]

PS—While your corpus should indeed not be so heavy on troff, it probably should include some HTML source files, as that is what we often type (if only to adapt your XML to local needs).

[lrvideckis]

<?xml version="1.0" encoding="utf-8"?>
<keyboard name="HLMGUO" script="latin">
  <row>
    <key key0="h" key1="&quot;" key4="v"/>
    <key key0="l" key1="&amp;" key4="z"/>
    <key key0="m" key1="%" key4="`" anticircle="7" indication=""/>
    <key key0="g" key2="^" key3="@" anticircle="8" indication=""/>
    <key key0="u" key2="+" key3="/" anticircle="9" indication=""/>
    <key key0="o" key2="?" key3="-"/>
  </row>
  <row>
    <key key0="w" key1="|" key4="*"/>
    <key key0="t" key1="p" key3="~" key4="f"/>
    <key key0="r" key1="x" key4="j" anticircle="4" indication=""/>
    <key key0="i" key2="_" key3="!" anticircle="5" indication=""/>
    <key key0="e" key2="y" key3="," key4="$" anticircle="6" indication=""/>
    <key key0="c" key2="#" key3="="/>
  </row>
  <row>
    <key key0="shift" key2="loc capslock"/>
    <key key0="s" key1="q" key2="}" key3="{" key4=":" anticircle="0" indication=""/>
    <key key0="n" key1="b" key2="&gt;" key3="&lt;" key4="k" anticircle="1" indication=""/>
    <key key0="a" key1="(" key2="'" key3="." key4=")" anticircle="2" indication=""/>
    <key key0="d" key1="[" key2="\\" key3=";" key4="]" anticircle="3" indication=""/>
    <key key0="backspace"/>
  </row>
</keyboard>

random notes:

• tweaked my metrics such that e, t naturally are in the middle now (resting thumb spot). this did arise naturally from the metrics, but there was a tradeoff:
  • In order to achieve this, I increased the placement, and alternating thumbs metrics' weight while leaving the finger travel metric the same (when compared to the previous layout)
  • as a result, this new layout scores better in both placement and alternating thumbs, but scores worse in both 1-thumb, and 2-thumb finger travel (when compared to the previous layout)

I think this is probably okay

---

• new corpus which is 3,024,595 characters worth of the book alice's adventures in wonderland haha as well as 89,244 characters worth of html
• symbols <>()[]{} added in manually at the end (like before)

[Spike-from-NH]

Cheers! When I see these, I change it to name="Irvideckis Minimal". Also, it would seem more natural to me if delete/rubout were at upper right, rather than just above Enter. I can do this for myself, and you needn't change it for everyone else—unless you agree.

I visit Github on a Samsung S4, on which my thumbs barely reach the middle. Then I install it on a Samsung J7, which is a more conventional test. Am sure it will reduce mistyping compared to my 5-row QWERTY, but I frequently revert to my QWERTY to get a special character →≠.

We heard above from a guy who types with 3 fingers rather than 2 thumbs. Also, placement of symbols for technical typing is going to depend on the language. I would not want to be the one writing a menu to query individual tastes and generate layouts so as to be "right for everyone."

[Onikoroshi]

Looks nice! I'll definitely be trying this out. Unfortunately, as nice as these sorts of layouts are, I always end up going back to something like Typewise or SwiftKey because of lack of dynamic autocorrect in Keyboard Designer and Unexpected Keyboard. ;_;

[gungsukma]

I see you are okay with seven-column layout (the hindi). Don't need to push minimize it too far, just put frequent letters as a tap, less frequent letters as a swipe.

Here is mine, it is based on workman, you may want yours based on qwerty.

I also manage to put all numbers, symbols, function keys, whole laptop keyboard keys as tap/swipe.