Notes! 1. It also seems unlikely that early practitioners of this new and probably not very accessible technology were constantly relearning revamped layouts well enough to reach speeds that necessitated a revision. In modern times, of course it's hard to account for biases due the differing number of practitioners for each layout. It could also be that typing is not a difficult enough task, or that people collectively are not at the level of skill where layout makes a difference, or a combination of these factors. Switching to a different layout could still make you faster, as has been anecdotally observed, but that is generally attributed to relearning better typing habits (which one could just do on QWERTY) rather than anything specific to the key arrangement. 2. Another behaviour that fast typing results in, unconsciously or not, is "interlaced" keyup and keydown sequences. For example, interlaced "th" would look like t down, h down, t up, h up. This is required for speed, as waiting for the first key to be fully raised (t down, t up, h down, h up) before tapping another key adds unnecessary time. (Part 2) Also, when it comes to rolling, inner rolls (toward the center of the keyboard) are generally preferred, but for this configuration both inner and outer rolls are treated equally. 3. One category I didn't mention is chording-based layouts. These are generally even smaller than half-sized keyboards and work by typing different letters depending on which combination of keys are hit at the same time. In my experience, their clunkiness is a much bigger inhibitor of speed than any other solution so they weren't a consideration for me. 4. More advanced firmware features also exist -- some that I intentionally don't use and some that my tool doesn't yet account for. You can expect those details in the video about my full app, including some discussion of "Callum-style" layouts and Miryoku. 5. The plan is to eventually have multiple text datasets that you can toggle on and off. So for example, if you journal a lot, you could select samples of introspective text with more first-person writing, or if you code a lot, you could toggle coding/stack overflow data. 6. Specifically, it makes use of "one-shot" behaviour. This means is that while held, uparrow2 overlays layer 2 so that its letters are active; but also, when tapped, uparrow2 causes the keyboard to "remember" that layer 2 is active, but only for the next keypress. One-shot behaviour can also be applied to shift and in fact is something I use. 7. I'm borrowing *some* inspiration from the BEAKL family of layouts for my grid -- all in all, it seems to be the simplest and most flexible method for quantifying position accessibility. 8. There are some interesting optimizations that can be done if you account for irregular home positions and hand moving. For example, on a larger keyboard, one action could be "move hand over x columns" -- then, the effort grid and finger mapping grid could also be moved over x columns and that could become a temporary base position.
Absolutely fascinating. Funny little story - I broke my hand and have been looking for alternate solutions because i type a lot for work. Your video popped up and while it isnt super practcal for me right now, but i got hooked into the process. awesome stuff and best of luck with your channel! Subbed!
Thanks and hope your hand heals soon! I have a lot of related ideas, one of which is around making the learning process as easy as possible (whether by making some concessions to the layout or the actual approach to learning) since I personally do plan to test more things and I want to minimize that initial learning time. But we'll see what happens there
Holy... This project in its entirety is a remarkable feat. Thank you for your extensive research, logical approach, and just general high levels of intelligence haha. Makes me happy to be alive in 2023, to watch this and learn.
Really cool additions to the genetic algorithm! I'd be interested to see how you could use this for something like a stenography layout. If your algorithm already has a notion of different regions for different fingers, it could smartly distribute those keys across the layout, and you could have one key for common letter combos instead of having two 'e's to accomplish something similar.
what a great project! this is fascinating. the results are so different from historical one-handed layouts. i appreciate that you are thinking so much about context (rolls, same-finger sequences, etc.). i would love to hear your thoughts on heavy layering vs. putting more things in L0.
Thanks! So something I've wanted to try is expanding the size of the board to fit more things in the base layer. One issue is that if I only expand a little (5x7, 5x8), I think there will be a tendency to reach the extra columns with index/pinkie which I personally don't like, and if I expand by a lot, then there might end up being a lot of back and forth hand movement, which I also don't like. Something I thought of though is adding a valid action during optimization to be "move hand x columns, y rows" and subsequently shift the effort and finger mapping grids with it. This idea here would be to maximize the time spent after a hand move in the same region of the board -- maybe like one section of the board ends up better at typing words that end with "ion", or words that start with "re", or something -- before having to move back/elsewhere. This would definitely end up with more repeated letters, but then also more new letters that benefit from those repeated ones. But yeah, I personally prefer layering a bit more over hand movements. Slight tangent, but something I didn't mention in the video is that there are a few layer-specific optimizations to make it feel better. In particular, I tried to limit how many times *consecutive* layer switches happen -- e.g., layer2 -> layer1 -> layer2 -> layer1 -> layer2 is bad since it's kind of a weird rhythm to work with mentally, feels awkward to me, and adds a lot of keypresses even if they are low effort. Staying in a layer is fine, and sprinkles of different layers are fine as well, it's just the immediate switch back and forth that is weird imo. (I first encountered this issue when I tried mirrored Dvorak actually. Since the left half of Dvorak has the vowels and the right half has the common consonants, it was annoying to type on even with a low effort thumb key performing the mirroring, which is why that kind of layer switching is specifically penalized.)
Suggestions (since you asked ...). Use word caps instead of caps lock. Use word-backspace in addition to, and easier to press than, backspace. Based on the GUI key appearing on two layers, my guess is you're a Mac user but not a fervent chord user; or you just don't plan to use chords much when typing one-handed. Leveraging chords, even in a one-handed layout means you can leave your pointer where it is and invoke lots of functions from the board. And placing the ⌘ key under the pinky might then become a burden. That might be mitigated some by implementing sticky keys for ⌘ and perhaps other modifiers as well.
I bet you could get a much better "punishment grid" by doing a lot of reaction time / time difference tests - you could probably gather a lot of good data while using Monkeytype
This is something I totally wanted to see done, and I have to say, I love how in depth you've made everything. Great job! We can finally free our hands to do, other, things. On a side note, have you considered a long press technique, or even something like an analogue switch pressure to control the layer switching? I'm not sure whether current software supports it as I don't own any keyboards (wooting, razer, etc.) with any of those features, but might be an interesting prospect. One last thing, do you think it would be possible to build something of a predictive text input for something like this, kinda like typing romanized in some languages. Perhaps hitting the first 3 or 4 letters may be enough to just predict the whole word.
Thanks! So long pressing is something that is on my radar; I personally don't like layer/mod-tapping so I didn't implement a way to account for it initially but I know other people do like the functionality. It would probably be something like allowing a key to have multiple functions and assigning an optional penalty if the held behaviour is used. I am interested in analog switches as well but yeah I don't own any of those keyboards. It doesn't look like they are supported yet but could be interesting to play around with on their own. Predictive text is definitely a cool idea but probably not feasible to run on board with typical controllers due to size. I think general text prediction is on Windows and Mac now though so that's probably the best route. A user (Pascal Getreuer) did implement a basic on-board autocorrector though, "Autocorrection with QMK". Haven't tried it but definitely cool.
Great video! I've been looking to adopt an optimized one-hand layout, however, I'll be one of those waiting for your algorithm to be in a useable state, I would like to run more passes but on my 4x10 ortholinear layout instead If you ever make an update, I hope to hear things possibly regarding tap-dance and repeat-key too in terms of optimization! Oh I'd also love to hear your thoughts on the konomu-frogpad layout if you've ever stumbled upon it
Loved this video!! I know you said because we can pre move our fingers developing good tying habits is better than just getting a better layout but let’s say out of curiosity someone wanted to optimize a layout for a voyager layout how would they use the code in the link?
Basically, you would want to add dummy columns/rows to fill out any of the non-ortholinear keys on the voyager and then develop your own effort layer -- for example, due to the stagger on the Voyager, you may consider some positions to require lower effort than their ortholinear counterparts. The differences in physical layouts manifest in the effort layer and currently require self-tuning. I have thought of providing some default effort values based on key spacing and such but haven't gotten around to that yet. Then you can run the algorithm with ngram frequencies that make sense for you. Ideally usage would be better documented with examples and templates and such, but between travel and vacation I haven't had much time to work on this. Currently the only file with any semblance of usage info is the one I used to generate my layout: github.com/sandsq/AdvancedLayoutCalculator.jl/blob/dev/test/Calculator/generatelayout.jl but it's not going to be easy to decipher :(
You need to make a business out of this. Take your devices on the road, set up a reasonable test for people to fine tune your model to their preferences, and sell them. With full instructions as to how to further customise it if they wanted to. This could be massive.
This work is excellent. Sorely needed. What about a 2 handed layout? Have you done anything there? I am trying to do the same with a modified maltron layout on a standard corne but I feel it's not quite right.
I haven't done much experimentation on a 2 handed layout but I'm almost finished rewriting the app with a GUI and I'll be doing more testing once that is done (github.com/sandsq/alc-gui )
I am super interested in this. My daughter suffered a stroke and can only use her right hand. There are really no solutions out there. Unfortunately, the one handed keyboard market is geared toward gamers with two hands and not for the disabled. The two I see out there are Malton and Beeraider. I cannot find good reviews on either. I would pay serious money for a one handed keyboard with optimal layout if one existed. Please keep up the good work. I 'll check out Keebio.
If you have the time, one solution could be to design your own keyboard from scratch to specifically suit your daughter’s hand. It’s a lot less intimidating than it sounds, but does require some research of course. I think Ben Vallack here on RUclips would be a good starting point for a lot of surface level information, and reference to more in-depth resources. I hope you can figure something out that works for your daughter, good luck!
Why is it that I feel you will soon drown in the deep waters of Steve Mann's septambic keyer? Lol, loved the video, pretty simple. Have you read the "Keyboard layouts doc"? I don't know where I got it from, but it is basically a bible of alternate layouts, how people created them, what criteria are good and bad etc etc.
It looks like the shift key is one-shot. Is the layer two key also oneshot? I'm going to have to look into how to duplicate this setup for a corne keyboard. It's just-about 1:1 for the letters, except for q, x, z, l. Your choice to put the layer 3 key on a reach for the pinky seems a little weird to me vs one of the thumb spots.
Yep, shift and layers are oneshot. When it comes to layer 3, I mostly ran out of thumb space since I used to use alt+tab a lot and wanted alt on thumb.
Have you considered a stenography inspired approach? Pressing multiple keys at the same time that comprise a syllable, word or grammar related syllables/ words.
So there's some open source steno software called Plover and I think steno is actually pretty well suited for one-handed typing (in fact, there is a plugin for doing so), assuming one is willing to put in the time. I'm not sure if a one-handed-optimized steno layout would be different, or if just using the two-handed ordering with more strokes is already the best, but definitely an interesting idea
Based on the GUI placement, my guess is Mac user which then makes all but the pinky keys GUI modifiable. And the pinky keys are GUI modifiable if sticky keys are used. However for Linux and Windows without sticky keys, your assessment would be true. On the other hand (no pun intended), one handed typing also implies mouse use with the [in this case] right hand so right clicking is an option. Not my first choice, but viable.
Everything about this rules A reminder that there is an endless ocean of innovation still yet to be made in life Once we see how much better it can be, the old ways would seem barbaric Right now with with regular keyboards, you gotta let go of mouse and move your hand to type Terribly inneficient This is the solution You are on to it
Thats pretty amazing. I too have optimized my own layouts with genkey and oxeylyzer (although for two handed use). I'm also into columnar staggered keyboards. I could see myself using a one handed layout for several reasons: 1. I have RSI in right hand. 2. At work I write ALOT. however we have speech recognition software too. I could write and edit with left hand only and hold the microphone in my right to avoid shifting between mouse, keyboard and microphone. I would still have to make my own variant. Your corpus is english, and I a layout for another language Would you mind open sourcing your AI?
Glad you found it interesting! Unfortunately I got distracted by other things so the code is not in a very user friendly state...I wanted to develop a GUI app so that people could use it easier but alas
this keyboard misses something extremely important: programmers. you really need to be able to get all those pesky symbols and numbers in there somehow. or did you with layer 3? it would be great if this could be somehow included in the optimisation. i do believe that it makes sense to keep programmer in a separate layer so that the same layout can be used by both ordinary users and programmers
It's an interesting approach with big potential. Unfortunately it's being heavily hindered by the chosen keyboard & non-staggered ortholinear layout. For any type of optimised layout There shouldn't be any keys that is 30 times harder to press. Also The thumb is the most underutilized finger of all. You should at least use it for three buttons. Which means you need a keyboard \ keypad with a thumb cluster like zsa moonlander \ ergodox. Or even some dactyl variation to optimise finger movement in 3D. The bad choice of keyboard is the likely reason you didn't found mirrored layout to be any good, which is not true, as it's an easiest one to learn for one hand typing.
The thumb is heavily utilized in practice since it covers space, backspace, and a utility layer with navigation and the common copy/paste/etc. shortcuts, which I admittedly didn't really talk about in the video. You are right that a better thumb cluster and physical layout overall would improve the typing experience though. Luckily it isn't too difficult to tweak the setup and rerun the algorithm. For mirroring, as I mentioned the biggest benefit is that is has the easiest learning curve. However, it doesn't have any of the explicit optimizations that make for a better typing experience, hence why I said I don't think it's optimal in terms of speed and comfort. And since I'm willing to put in the practice, I decided to redesign the layout from the ground up. There is also a particular annoyance that I found with mirroring personally. The thumb is generally the finger that activates the mirror, so what happens at the end of words is that you often need to mirror and then press space afterwards (also given to the thumb), requiring an immediate back and forth thumb movement. Thumb movements aren't inherently problematic, but this particular kind I found disruptive to typing flow ("good" thumb movements in my eyes is one where you can spend the next couple of keys moving your thumb back or ones that are mentally distinct from the typing-thought process. So for example, putting a modifier on the thumb works out well since you're usually switching off of that typing context when using a keyboard shortcut). If you decide not to use a dedicated thumb key and instead add some sort of layer tap functionality to space, that introduces the the tapping term issue -- I know many people are fine with layer taps, but I am in that group that doesn't like them. (Another side note, I have admittedly spent more time with mirrored Dvorak than mirrored QWERTY, and mirrored Dvorak is significantly worse. Dvorak has a heavy emphasis on alternating hands while typing, which means in a mirrored form a lot of effort is spent hitting the designated mirror key -- regardless of how low effort that is, I didn't find it to flow well in typing.)
Very cool I have a friend who is working on a one handed stenography theory. Personally, I use a layout I call "cnaey" the layout is like this ,LSFPBWHU. CNAEYGTIOM ;XRVKDJZ/ It has a decent number of rolls, prioritizes common letters, and minimizes some same finger moves, by making the bottom row under the less dominant fingers have less common letters.
Notes!
1. It also seems unlikely that early practitioners of this new and probably not very accessible technology were constantly relearning revamped layouts well enough to reach speeds that necessitated a revision. In modern times, of course it's hard to account for biases due the differing number of practitioners for each layout. It could also be that typing is not a difficult enough task, or that people collectively are not at the level of skill where layout makes a difference, or a combination of these factors. Switching to a different layout could still make you faster, as has been anecdotally observed, but that is generally attributed to relearning better typing habits (which one could just do on QWERTY) rather than anything specific to the key arrangement.
2. Another behaviour that fast typing results in, unconsciously or not, is "interlaced" keyup and keydown sequences. For example, interlaced "th" would look like t down, h down, t up, h up. This is required for speed, as waiting for the first key to be fully raised (t down, t up, h down, h up) before tapping another key adds unnecessary time. (Part 2) Also, when it comes to rolling, inner rolls (toward the center of the keyboard) are generally preferred, but for this configuration both inner and outer rolls are treated equally.
3. One category I didn't mention is chording-based layouts. These are generally even smaller than half-sized keyboards and work by typing different letters depending on which combination of keys are hit at the same time. In my experience, their clunkiness is a much bigger inhibitor of speed than any other solution so they weren't a consideration for me.
4. More advanced firmware features also exist -- some that I intentionally don't use and some that my tool doesn't yet account for. You can expect those details in the video about my full app, including some discussion of "Callum-style" layouts and Miryoku.
5. The plan is to eventually have multiple text datasets that you can toggle on and off. So for example, if you journal a lot, you could select samples of introspective text with more first-person writing, or if you code a lot, you could toggle coding/stack overflow data.
6. Specifically, it makes use of "one-shot" behaviour. This means is that while held, uparrow2 overlays layer 2 so that its letters are active; but also, when tapped, uparrow2 causes the keyboard to "remember" that layer 2 is active, but only for the next keypress. One-shot behaviour can also be applied to shift and in fact is something I use.
7. I'm borrowing *some* inspiration from the BEAKL family of layouts for my grid -- all in all, it seems to be the simplest and most flexible method for quantifying position accessibility.
8. There are some interesting optimizations that can be done if you account for irregular home positions and hand moving. For example, on a larger keyboard, one action could be "move hand over x columns" -- then, the effort grid and finger mapping grid could also be moved over x columns and that could become a temporary base position.
Absolutely fascinating. Funny little story - I broke my hand and have been looking for alternate solutions because i type a lot for work. Your video popped up and while it isnt super practcal for me right now, but i got hooked into the process. awesome stuff and best of luck with your channel! Subbed!
Thanks and hope your hand heals soon! I have a lot of related ideas, one of which is around making the learning process as easy as possible (whether by making some concessions to the layout or the actual approach to learning) since I personally do plan to test more things and I want to minimize that initial learning time. But we'll see what happens there
Holy... This project in its entirety is a remarkable feat. Thank you for your extensive research, logical approach, and just general high levels of intelligence haha. Makes me happy to be alive in 2023, to watch this and learn.
Subscribed. Best wishes from the UK.
Fascinating execution, thank you for sharing ;)
keep doing what you're doing
ive always wanted to try this, nice work using actual science. i think the glove80 is up to the task
Have same thoughts! You did a good job!
Really cool additions to the genetic algorithm! I'd be interested to see how you could use this for something like a stenography layout. If your algorithm already has a notion of different regions for different fingers, it could smartly distribute those keys across the layout, and you could have one key for common letter combos instead of having two 'e's to accomplish something similar.
Very interesting :) Cool vid.
Excellent video.
Nice one, very interesting.
This is awesome.
what a great project! this is fascinating. the results are so different from historical one-handed layouts. i appreciate that you are thinking so much about context (rolls, same-finger sequences, etc.). i would love to hear your thoughts on heavy layering vs. putting more things in L0.
Thanks! So something I've wanted to try is expanding the size of the board to fit more things in the base layer. One issue is that if I only expand a little (5x7, 5x8), I think there will be a tendency to reach the extra columns with index/pinkie which I personally don't like, and if I expand by a lot, then there might end up being a lot of back and forth hand movement, which I also don't like. Something I thought of though is adding a valid action during optimization to be "move hand x columns, y rows" and subsequently shift the effort and finger mapping grids with it. This idea here would be to maximize the time spent after a hand move in the same region of the board -- maybe like one section of the board ends up better at typing words that end with "ion", or words that start with "re", or something -- before having to move back/elsewhere. This would definitely end up with more repeated letters, but then also more new letters that benefit from those repeated ones.
But yeah, I personally prefer layering a bit more over hand movements. Slight tangent, but something I didn't mention in the video is that there are a few layer-specific optimizations to make it feel better. In particular, I tried to limit how many times *consecutive* layer switches happen -- e.g., layer2 -> layer1 -> layer2 -> layer1 -> layer2 is bad since it's kind of a weird rhythm to work with mentally, feels awkward to me, and adds a lot of keypresses even if they are low effort. Staying in a layer is fine, and sprinkles of different layers are fine as well, it's just the immediate switch back and forth that is weird imo. (I first encountered this issue when I tried mirrored Dvorak actually. Since the left half of Dvorak has the vowels and the right half has the common consonants, it was annoying to type on even with a low effort thumb key performing the mirroring, which is why that kind of layer switching is specifically penalized.)
Suggestions (since you asked ...). Use word caps instead of caps lock. Use word-backspace in addition to, and easier to press than, backspace. Based on the GUI key appearing on two layers, my guess is you're a Mac user but not a fervent chord user; or you just don't plan to use chords much when typing one-handed. Leveraging chords, even in a one-handed layout means you can leave your pointer where it is and invoke lots of functions from the board. And placing the ⌘ key under the pinky might then become a burden. That might be mitigated some by implementing sticky keys for ⌘ and perhaps other modifiers as well.
I'm speechless, literally.
I bet you could get a much better "punishment grid" by doing a lot of reaction time / time difference tests - you could probably gather a lot of good data while using Monkeytype
This is something I totally wanted to see done, and I have to say, I love how in depth you've made everything. Great job! We can finally free our hands to do, other, things.
On a side note, have you considered a long press technique, or even something like an analogue switch pressure to control the layer switching? I'm not sure whether current software supports it as I don't own any keyboards (wooting, razer, etc.) with any of those features, but might be an interesting prospect.
One last thing, do you think it would be possible to build something of a predictive text input for something like this, kinda like typing romanized in some languages. Perhaps hitting the first 3 or 4 letters may be enough to just predict the whole word.
Thanks! So long pressing is something that is on my radar; I personally don't like layer/mod-tapping so I didn't implement a way to account for it initially but I know other people do like the functionality. It would probably be something like allowing a key to have multiple functions and assigning an optional penalty if the held behaviour is used. I am interested in analog switches as well but yeah I don't own any of those keyboards. It doesn't look like they are supported yet but could be interesting to play around with on their own.
Predictive text is definitely a cool idea but probably not feasible to run on board with typical controllers due to size. I think general text prediction is on Windows and Mac now though so that's probably the best route. A user (Pascal Getreuer) did implement a basic on-board autocorrector though, "Autocorrection with QMK". Haven't tried it but definitely cool.
Great video!
I've been looking to adopt an optimized one-hand layout, however, I'll be one of those waiting for your algorithm to be in a useable state, I would like to run more passes but on my 4x10 ortholinear layout instead
If you ever make an update, I hope to hear things possibly regarding tap-dance and repeat-key too in terms of optimization!
Oh I'd also love to hear your thoughts on the konomu-frogpad layout if you've ever stumbled upon it
soon with GUI (github.com/sandsq/alc-gui ) :)
I haven't seen the konomu-frogpad before but I'll definitely check it out
Loved this video!! I know you said because we can pre move our fingers developing good tying habits is better than just getting a better layout but let’s say out of curiosity someone wanted to optimize a layout for a voyager layout how would they use the code in the link?
Basically, you would want to add dummy columns/rows to fill out any of the non-ortholinear keys on the voyager and then develop your own effort layer -- for example, due to the stagger on the Voyager, you may consider some positions to require lower effort than their ortholinear counterparts. The differences in physical layouts manifest in the effort layer and currently require self-tuning. I have thought of providing some default effort values based on key spacing and such but haven't gotten around to that yet. Then you can run the algorithm with ngram frequencies that make sense for you.
Ideally usage would be better documented with examples and templates and such, but between travel and vacation I haven't had much time to work on this. Currently the only file with any semblance of usage info is the one I used to generate my layout: github.com/sandsq/AdvancedLayoutCalculator.jl/blob/dev/test/Calculator/generatelayout.jl but it's not going to be easy to decipher :(
have you thought about assigning some functions to additional mouse buttons? and use them in combination with the keyboard
He is typing faster with one hand on a weird ass layout than I can with a layout Iave been using for 2 years.
And has better accuracy.
Never too late to start practicing!
i must admit that i type about twice as fast as he so far does including correcting for my inaccuracies using the normal extended qwerty layout
You need to make a business out of this. Take your devices on the road, set up a reasonable test for people to fine tune your model to their preferences, and sell them. With full instructions as to how to further customise it if they wanted to. This could be massive.
BASED
I’m an amputee and writer, this is incredible.
Bit of a stretch to call a genetic algorithm AI. GAs are more of a random search and pretty brute force just trying out variants
This work is excellent. Sorely needed. What about a 2 handed layout? Have you done anything there? I am trying to do the same with a modified maltron layout on a standard corne but I feel it's not quite right.
I haven't done much experimentation on a 2 handed layout but I'm almost finished rewriting the app with a GUI and I'll be doing more testing once that is done (github.com/sandsq/alc-gui )
Nice
I am super interested in this. My daughter suffered a stroke and can only use her right hand. There are really no solutions out there. Unfortunately, the one handed keyboard market is geared toward gamers with two hands and not for the disabled. The two I see out there are Malton and Beeraider. I cannot find good reviews on either. I would pay serious money for a one handed keyboard with optimal layout if one existed. Please keep up the good work. I 'll check out Keebio.
If you have the time, one solution could be to design your own keyboard from scratch to specifically suit your daughter’s hand. It’s a lot less intimidating than it sounds, but does require some research of course. I think Ben Vallack here on RUclips would be a good starting point for a lot of surface level information, and reference to more in-depth resources.
I hope you can figure something out that works for your daughter, good luck!
@@Psoewish Thank you.
I'm sorry to hear that, I definitely would be interested in working with people who do require these more specialized tools for typing in the future!
Why is it that I feel you will soon drown in the deep waters of Steve Mann's septambic keyer?
Lol, loved the video, pretty simple. Have you read the "Keyboard layouts doc"? I don't know where I got it from, but it is basically a bible of alternate layouts, how people created them, what criteria are good and bad etc etc.
Very interesting device! I've read scatter webpages about various layouts and their design philosophies but not anything all compiled into one doc
It looks like the shift key is one-shot. Is the layer two key also oneshot?
I'm going to have to look into how to duplicate this setup for a corne keyboard. It's just-about 1:1 for the letters, except for q, x, z, l.
Your choice to put the layer 3 key on a reach for the pinky seems a little weird to me vs one of the thumb spots.
Yep, shift and layers are oneshot. When it comes to layer 3, I mostly ran out of thumb space since I used to use alt+tab a lot and wanted alt on thumb.
Have you considered a stenography inspired approach? Pressing multiple keys at the same time that comprise a syllable, word or grammar related syllables/ words.
So there's some open source steno software called Plover and I think steno is actually pretty well suited for one-handed typing (in fact, there is a plugin for doing so), assuming one is willing to put in the time. I'm not sure if a one-handed-optimized steno layout would be different, or if just using the two-handed ordering with more strokes is already the best, but definitely an interesting idea
A keyboard you can copy but can't paste
Based on the GUI placement, my guess is Mac user which then makes all but the pinky keys GUI modifiable. And the pinky keys are GUI modifiable if sticky keys are used. However for Linux and Windows without sticky keys, your assessment would be true. On the other hand (no pun intended), one handed typing also implies mouse use with the [in this case] right hand so right clicking is an option. Not my first choice, but viable.
how does hitting layer 2 keys on the middle finger column (ie. enter, x, j) work? do you use another finger?
I'm using oneshot layers so the layer stays active for the next keypress!
the maltron is paid by the inssurance that is why the price is that high.
Everything about this rules
A reminder that there is an endless ocean of innovation still yet to be made in life
Once we see how much better it can be, the old ways would seem barbaric
Right now with with regular keyboards, you gotta let go of mouse and move your hand to type
Terribly inneficient
This is the solution
You are on to it
Thats pretty amazing. I too have optimized my own layouts with genkey and oxeylyzer (although for two handed use). I'm also into columnar staggered keyboards.
I could see myself using a one handed layout for several reasons:
1. I have RSI in right hand.
2. At work I write ALOT. however we have speech recognition software too. I could write and edit with left hand only and hold the microphone in my right to avoid shifting between mouse, keyboard and microphone.
I would still have to make my own variant. Your corpus is english, and I a layout for another language
Would you mind open sourcing your AI?
Oh wait...It is open sourced :D
Let me see if I (a non-programmer) can use it
Glad you found it interesting! Unfortunately I got distracted by other things so the code is not in a very user friendly state...I wanted to develop a GUI app so that people could use it easier but alas
this keyboard misses something extremely important: programmers. you really need to be able to get all those pesky symbols and numbers in there somehow. or did you with layer 3? it would be great if this could be somehow included in the optimisation. i do believe that it makes sense to keep programmer in a separate layer so that the same layout can be used by both ordinary users and programmers
Rise up gamers
It's an interesting approach with big potential. Unfortunately it's being heavily hindered by the chosen keyboard & non-staggered ortholinear layout. For any type of optimised layout There shouldn't be any keys that is 30 times harder to press. Also The thumb is the most underutilized finger of all. You should at least use it for three buttons. Which means you need a keyboard \ keypad with a thumb cluster like zsa moonlander \ ergodox. Or even some dactyl variation to optimise finger movement in 3D.
The bad choice of keyboard is the likely reason you didn't found mirrored layout to be any good, which is not true, as it's an easiest one to learn for one hand typing.
The thumb is heavily utilized in practice since it covers space, backspace, and a utility layer with navigation and the common copy/paste/etc. shortcuts, which I admittedly didn't really talk about in the video. You are right that a better thumb cluster and physical layout overall would improve the typing experience though. Luckily it isn't too difficult to tweak the setup and rerun the algorithm.
For mirroring, as I mentioned the biggest benefit is that is has the easiest learning curve. However, it doesn't have any of the explicit optimizations that make for a better typing experience, hence why I said I don't think it's optimal in terms of speed and comfort. And since I'm willing to put in the practice, I decided to redesign the layout from the ground up.
There is also a particular annoyance that I found with mirroring personally. The thumb is generally the finger that activates the mirror, so what happens at the end of words is that you often need to mirror and then press space afterwards (also given to the thumb), requiring an immediate back and forth thumb movement. Thumb movements aren't inherently problematic, but this particular kind I found disruptive to typing flow ("good" thumb movements in my eyes is one where you can spend the next couple of keys moving your thumb back or ones that are mentally distinct from the typing-thought process. So for example, putting a modifier on the thumb works out well since you're usually switching off of that typing context when using a keyboard shortcut). If you decide not to use a dedicated thumb key and instead add some sort of layer tap functionality to space, that introduces the the tapping term issue -- I know many people are fine with layer taps, but I am in that group that doesn't like them.
(Another side note, I have admittedly spent more time with mirrored Dvorak than mirrored QWERTY, and mirrored Dvorak is significantly worse. Dvorak has a heavy emphasis on alternating hands while typing, which means in a mirrored form a lot of effort is spent hitting the designated mirror key -- regardless of how low effort that is, I didn't find it to flow well in typing.)
Mirror the layout on a second keyboard and you have reached 120 wpm 😅
virgo
Any updates?
soon(tm) (github.com/sandsq/alc-gui )
Ooooo
Very cool
I have a friend who is working on a one handed stenography theory.
Personally, I use a layout I call "cnaey"
the layout is like this
,LSFPBWHU.
CNAEYGTIOM
;XRVKDJZ/
It has a decent number of rolls, prioritizes common letters, and minimizes some same finger moves, by making the bottom row under the less dominant fingers have less common letters.