Julow
[new layout idea] have less keys and place some characters as a swipe
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
some things ive noticed for optimizing the layout:
- tap is better than swipe
- 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)
- 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)
- when the same thumb has to type 2 letters in a row, the closer these keys are, the better
- 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
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
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.
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
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.
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
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
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
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.
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.
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.
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
oh btw see my critique of the MessagEase (and also ThumbKey) layout which is my main motivation for creating my layout
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.
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
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.
I don't think anticlockwise swipes get a legend at all.
ah I just got it: you have to do both anticircle="3" indication=""
<?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
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?
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/
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.
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)
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.
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!
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.
favoring southwest and northeast swipes
I'm curious what's the reason for this? I did notice the main qwerty layout follows this principle
favoring southwest and northeast swipes
I'm curious what's the reason for this?
Slightly easier mechanics with my right thumb.
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)
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.