Using AI to Create the Perfect Keyboard
HTML-код
- Опубликовано: 22 сен 2022
- Try the keyboards for yourself: adumb-codes.github.io
Code for all my videos is available at: github.com/sponsors/adumb-codes/
Twitter: / adumb_codes
In this video I use a genetic algorithm to create a keyboard layout optimized for decreasing the distance the fingers have to travel when typing.
Resources used:
- arXiv.org dataset: www.kaggle.com/datasets/Corne...
- GitHub Java Corpus: groups.inf.ed.ac.uk/cup/javaG...
Stock footage provided by Videvo, downloaded from www.videvo.net
#ai #machinelearning #geneticalgorithm - Наука
Thanks for all of the support and feedback on the video so far! I realize there are plenty of ways this video could be expanded upon. I need to make one correction about how I combine two keyboards together:
At 4:40 I said that the keys are added from the left of the split point from keyboard 1. What actually happens is that the keys are added starting from the right of the split point. The number of keys to be added from keyboard 1 is random. This means that if the number of keys to be added is greater than the number of keys to the right of the split point then we will "wrap around" and start adding the keys from the left side from keyboard 1. We then fill in all the remaining keys from keyboard 2 starting from where we left off from keyboard 1. This is also reflected in the code at 5:37.
I did all the coding for this video about 6 months ago and only just decided to make it into a video, which is why I misremembered how the keyboards were combined. Sorry for the mistake. Thank you again for watching.
at 9:42 you are wondering why the most commonly used keys are grouped on the left side of the algorithms best layouts.
I am pretty sure this happens because your code keeps the left side of the best keyboard and introduces randomness during the addition of the right side of the layout between generations. Seems to me that this would heavily favour moving all the commonly used keys to the left side if only one finger is used.
Great idea in any case. Seeing these improvements i would vote to change the layout.
Perhaps someone already mentioned this, but it would be cool is examples of programming code in various languages, would be included in the corpus. Perhaps abstracted like:
camelCaseWord(name: name, name: name) {}
especially to give weight to common punctuation syntax and letter case use.
Because I think coders are among the most interested in the topic.
@@FreeScience Also bring down _ for snake_case_words and also swap over - and _ so you shift for -
This is really neat. It would be interesting to see other language specific keyboards like German, French, Italian etc. Then it would be interesting to take a more universal keyboard that blends the various languages... Then perhaps weights them by number of speakers. So English would likely be more heavily weighted than German for example.
can you make a optimal keyboard for other languages? like french, spanish, portuguese
Something interesting about the design philosophy for Dvorak vs Colemak was that they not only wanted to minimise travel, but they had different ideas of ergonomics as well. Dvorak aims to maximise the alternating of hands when typing, which is why the vowels are on one hand, while the frequently used consonants are on the other. Colemak on the other hand, was trying to maximise "rolls", so letters that frequently appeared together should be placed such that they can be typed with adjacent fingers on each hand. These are clearly conflicting goals, and I'm not sure how these metrics can be integrated into your score, but it's worth thinking about it regardless.
I love this experiment. I will never use something so obscure but it inspired me to use Dvorak since it is widely supported and has almost the same travel distance as the AI keyboard, AND Dvorak is optimized for things your AI didn't check for, such as alternating/drumming/rolling the fingers, so I suspect Dvorak is better than the AI keyboard in real use.
I am not really familiar with Colemak or Norman layouts. Should I learn Dvorak or should I learn one of the others? I primarily write English and do programming in C-style languages.
Update: Thanks for all your suggestions. For me, after researching your suggestions, I am now sure that Colemak-CA will be the best! That's Colemak with Curl mod (also known as "mod DH", which moves two popular keys to finger curls instead of lateral extension), and Angle mod (puts the ZXCV keys at a more natural angle).
I avoid the Wide mod (which moves your right hand away from the home row "J" nub which is inconvenient) and avoid the Symbols mod too (the regular Colemak already preserves most QWERTY symbol locations and those are already great).
So if you see the word "Colemak-CAWS", run away because that's the "too much" version. "Colemak-CA" is the one that will fit most people the best.
I saw all of your replies and agree with the conclusions: Dvorak is outdated, and doesn't work well with computer shortcuts such as Ctrl-ZXCV. Colemak preserves the computer shortcuts. It also stands on top in comfort metrics, beating things like Halmak (another AI keyboard) and Dvorak by a lot. There's much more to comfort than just key travel distance. How much movement each individual finger has to do matters much more, and also whether weak fingers such as the pinky have to do a lot of movement or not. Colemak turns out to be very balanced across every strong finger.
I have grabbed Colemak-CA with the "Extend" feature that adds more layers of keyboard shortcuts by holding down modifier keys. It's awesome. I already feel less RSI/arthritis wrist pain.
But does it work only for Englisch? Would the score of these keyboards be vastly different in other languages?
@@realdragon Yes, the score would be different depending on the language.
@@MyAmazingUsername I would say that just about anything is better than qwerty, so just pick one and you’ll do fine. It’s also surprisingly much, much easier to learn a third layout compared to your second (you’ll suffer a lot in the process).
One consideration about Dvorak is that it makes no effort to preserve the keyboard shortcuts that you may be used to on qwerty. It takes some time to get used to, but it’s not that bad once you figure it out (some shortcuts are best performed with the right ctrl if you’re one handed).
For Colemak, I personally didn’t like how it hijacks your capslock key (that’s where the backspace is), because I tend to remap the capslock to something else. It’s easily fixed, but it was enough to annoy me on most default setups. Another thing to keep in mind is that a lot of people feel that the certain keys need to be swapped, and so there’s something called Colemak Mod-DH for it.
Workman/Norman/etc are all keyboards that are meant to improve some particular aspect of Colemak, and if you read around, you’ll find more articles about them.
Personally, I’m perfectly happy with just sticking to Dvorak. I feel that with the exception of Programmer’s Dvorak (which I use), everyone seems to not be too opinionated on making minor or major improvements to it like Colemak. Somehow it helps me with my sanity.
@@MyAmazingUsername I switched to Dvorak back in 2016 and program with C-style languages all the time. Apostrophies, commas, and periods are really accessible being where the Q W and E keys are and semicolons being on Z really makes it intuitive with the ring finger. There are special "Dvorak Programmer" layouts that swap the apostrophe for the semicolon but I got so used to hitting "z" with my ring finger for a semicolon to say that I'm happy enough with it.
Programming definitely feels better with Dvorak, and just regular typing in general as well. I never want to go back to QWERTY it feels really awkward to type once you learn Dvorak.
If you're trying to minimize time (maximize speed), "distance moved" is the wrong thing to measure. The maximum speed of each finger is different, so (on QWERTY) typing T is faster than typing Q, even though its distance is further, because the 4th finger is slower. (To demonstrate this, compare typing ftftftft... and aqaqaqaq...). Also, one hand can be moving while the other hand is typing, so when keys alternate hands, one hand can be moving while the other is typing, which makes the distance have less impact on time.
not feeling a difference typing ftftft vs aqaqaq
@@carlos6126 i do
i like your videos big fan
@@swank8508 hi lol
On phones they are identical
Ftftft aqaqaq
I've been using Dvorak for a long time now and this really intrigues me! The only minor thing that I think you missed out on is taking into account that by having two hands, it should be more efficient to split the board between letters that follow each other. Dvorak has all the major consonants on the right hand side and the vowels on the left because a vowel usually follows a consonant and vice versa. So typing should be quicker by going from right-left-right-left and so on. If you're ever up to redoing this one, I'd love to see that taken into account!
I'm a Dvorak typist too... what is also missing here is the strength of each finger. So the T and E (respectively the most used consonant and vowel in English) is under the most powerful fingers. One of these cited designs has the E on the pinkie. My pinkie would break before lunch on a typical work day! 😂
That alternating hand system I assume would mean every language needs it's own Dvorak layout, just like how layouts like QWERTZ and AZERTY exist.
everytime i came up with a question you addressed it almost immediately after such as different circumstances(two fingers) or different use cases(coder vs blogger), great video and well done.
I think something you've overlooked is that typing with the same finger in a row, is way less efficient and comfortable than "rolling" to the next finger. Would be really cool if we would get a v2 of this with some suggestions from the comments. Really cool video:)
Great point. That is a key consideration of the Dvorak layout
Alternating hands ("drumming") might also make the experience smoother. I think that this was the idea behind Dvořák's layout (since vowels are all grouped at one side), whereas Colemak is focused more on the rolling movements.
I think it also matters which finger is used, people probably write faster with their index finger than their small finger
@@michal_havlicek not everyone types faster with alternating hands, and not everyone types faster with keyboard rolling. I wouldn't say theres one keyboard layout that suits all people, it should still be up to the user to decide. I'm more of a roller type so I lean closer to Colemak at 140 wpm
@@arenmee540 Exactly! That's the reason why Dvorak and Colemak layouts coexist for so long, without a clear winner. Each tends to fit a different kind of typist. :)
Your RSTLNE setup is surprisingly easy to pick up. The only one that throws me for a loop is T. With that home row you could also call it RESTLINE, which is fitting for the design intent
I too wanted to propose that RSTLNE be at least pronounced like "rest line." I think this is intuitive and agree that it speaks to the design intent.
I also came here to endorse renaming the “Home Row” to the “Restline” as well but I knew in my heart it had already been said. +1 I agree!
There are dozens of us that agree!
Even better, RESTLINE is easier to pronounce!
I was thinking something more like “wristline” but rest line makes a lot more sense
I'm curious to see what the results would be in an ortholinear layout. I'm building a custom mechanical keyboard, and it could be interesting to see what layouts would work best if everything is on a grid instead of staggered. Not sure how much of a difference it would make, but it could be interesting to test.
Or other layouts as well, or even 3 dimensional shapes
I have been thinking about keyboards since I learned about alternative layouts like 30 years ago, but I’ve never used a keyboard that’s different than the regularly QWERTY one. I loved that you took this so deep and I nerded out on this! Thank you!!
A couple thoughts.
1. In most genetic algorithms, random mutations are usually introduced to reduce "local minima" like what your runs seem to produce fairly quickly. You may have done this but not explained in the video, but purposefully imposing "bad genes" into the pool can help get around these local ideals to help find even lower distance sets.
2. You mention that in the Java keyboard, the semicolon is moved closer to the home row, when in QWERTY, it is already on the home row, as right hand pinky, something not a part of older typewriter QWERTY, but solidified once computers became mainstream.
3. As others have mentioned, there are some optimizations to how you measure suitability. Some important factors I think should be accounted for in a follow up are:
a. Whole hand travel: if as an example, I go to type QWERTY, my fingers are not going to individually raise up off the home row, but are going to move as an entire hand up to the top row, and reset, making the first move for Q a standard move, but WER a 0 move, and T and Y two lateral moves of 1 each.
b. As others have pointed out, Dvorak not only tries to minimize travel distance, but it also tries to alternate hand movement, as opposite hands can be moved at the same time, so that should also be factored in to a suitability score, because if my left hand is dancing all over the left side of the keyboard to make a word using those keys, my right hand is sitting there doing nothing, cutting my potential speed effectively in half.
c. Others have also mentioned that not all fingers move and actuate with the same performance, pinkies especially, generally don't stretch as well and aren't a quick to move (bringing in time again) so going up to a Q or P or down to a Z or /? takes more effort than the rest of the characters in their respective rows.
d. The shift keys! Going off of some of the other points, using the shift keys locks up one pinky or the other, something that is generally avoided by having one on each side, but in cases where holding shift is more practical than using the caps lock (usually just from muscle memory of using shift instead of caps lock), the left or right pinky may be locked up, and the right hand especially may be shifted from JKL; as it's home keys to KL; making characters like HYN further away from right index.
this needs more upvotes
This, should have put a spice of randomness so the cycling through the algs didn't get to a dead spot, as fast. It COULD be the best, but it also could very well not be the best, since the alg went down the "best" path, but ended up being the "wrong" path at the dead end of it.
In the code spinnets he shows you can see that he added a 10% chance of mutation
There also will be a preference with the hand. e.g. being right handed or left handed. I type with two fingers. I just payed attention to it and I noticed that I use left for everything up to the RFV line with left and all the rest with right. This is basically because my left wrist is on the table and my right hand floats. This also because often I will need to use the mouse.
In all the typing analysis we see, we almost only look at the typing as if we are a secretary that types out a long letter or book. However that is not how we do things most of the time. The amount I actually type is way less and even if I would double my typing speed, the rest would stay the same. Stopping to type to think what I want to type happens a lot. The need to use the mouse in generic computer usage happens also a lot.
So I could see a system where you only use mainly 1 hand while the other is for mouse usage is a lot better. The other hand is only in case it is really needed. And then closer to the side of the keyboard so the travel form and to the mouse is minimal.
ye, but shift key doesn't have to be pinky, the algorithm should decide where the shift key should be.
I think the reason the commonly used letters (for the one-finger keyboard) were grouped to the left was how the left side was taken as a whole when combining the genetic material. Layouts with more common letters to the left will preserve their fitness better than ones with the letters to the right.
Maybe he should have made the part which survives random (I assume he didn't, tho I haven't read the code)
But they will also be more fit in the first place.
What I think would be interesting would be to see how different the results for a right-handed single-finger keyboard would differ from the left-handed ones shown.
You would expect to see a trend towards receiving mirror images with a balanced algorithm, but this one handles the left and right side of the keyboard in such radically different ways that you would have to predict that you'd get very different results.
It would be interesting if the two halves (that get either saved or swapped) were actually “the first and last quarter” plus “the middle two quarters”. I bet having the two parts being middle + outskirts would fix the off balance one finger results.
My thoughts exactly. Great analysis for y'all commenters.
Makes me wonder what the best method for combining the genetic material would be exactly. What about taking two keyboards, selecting a random key, say "H" for example, seeing where that key is on the second keyboard, seeing what letter is in the same spot on your first keyboard, and swapping them.
Take for example these two keyboards, 1 and 2, which become 3 and 4 respectfully.
1: HJKLG
2: GJHKL
3: KJHLG
4: HJGKL
In keyboard number one, "H" has been randomly selected to be swapped this round. It's in position 1 in it's own keyboard, and position 3 on the second keyboard. The "K" is in position 3 on it's own keyboard. So, the "H" and the "K" swap, and it becomes a new keyboard, number 3. That's the only change.
For the sake of it, I also showed keyboard 2 swapping it's "H" key. They wouldn't all have to swap the same key, but for sake of ease I did. "H" is in the 3rd position, and then the first position on the other keyboard. "G" is in the first position in it's own keyboard. So, the "H" and "G" keys get swapped, making keyboard 4. 2 keyboards go in, two brand new keyboards come out. Even if you specifically swapped "H" again on both, you'd get another set of totally new keyboards.
Do a couple random key changes like that each round. Then probably add a little random mutation and you're good! No left preference or anything. Completely random.
me training before starting an argument:
I just tried your online keyboard, and within the first line of text, I was already typing in step with the optimized keyboard. Fascinating. I'm off to buy a programmable keyboard immediately. Really impressive work.
rk84 if you acutally wanna do it
Just use power toys
One thing I immediately noticed when trying the 2 finger keyboard is that this design doesn't seem to be accounting for you being able to move multiple fingers at once. By that I mean, as i'm typing one key with the right finger, I can begin moving my left finger to the next key to increase speed. When I tried the example sentence, I immediately felt like I lost that back and forth cadence between my fingers and that one would regularly be hitting many characters in a row where it otherwise wouldn't be on the qwerty keyboard. Just an observation!
i think what the genetic algorithm (my guess) is trained on is minimizing distance from the main key, not accounting for where the finger might be after some letters. it's just a guess and programmers do generally make mistakes in implementations of AI.
in 10 finger keyboards, most if not all words are less than 10 letters, hence fingers don't have to move twice
whereas in 2 finger keyboards, they have to move 3 times on average.
That makes a lot of sense. The qwerty keyboard was designed for precisely that purpose, given that typewriter keys need to reset between keypresses.
hm yea i wonder if you gave it a larger area for each finger and used the time for finger movement instead of distance directly (with at the same time movement, and maybe something for entire hand movement), what sorta keyboard layouts you’d get
And i wanna not use my pinkies so thumbs down
This video was really interesting! Unfortunately the layout the AI generated isn't very optimal for real world use. Reducing finger travel is one element in making a more optimised layout, but there's many other factors not taken into account with your model. The main three that you didn't include are:
Same Finger Bigrams - a sequence of two letters pressed by the same finger. This is almost always slower (and less comfortable) than using a different finger.
Rolls - Typing two or more keys with the same hand, moving in the same "direction". For example, on QWERTY, SDF would be a roll, but SFD would not. Rolls are generally faster and more comfortable than jumping back and forth.
Alternates - Pressing a key with the opposite hand from the last press. This is usually faster than using the same hand (unless rolling).
Your AI layouts are probably better than QWERTY, but there's a lot more optimisation that can be done. For example the layout I'm using has less Same Finger Bigrams by a multiple of 4.96 to 9.76 times and has 6.13% to 8.65% more rolls.
I'm curious to see what your AI would come up with if given a few more rules to adhere to! :D
What layout do you use?
halmak is a good example of this done right
@@doltramir I use a layout called Aptmak
/ w f p x q l u y ;
r s t h b j n a i o
v c g d k z m , . '
With E on right thumb.
It took some adjusting to get used to having a letter on a thumb key, but E is about 13% of all keys pressed, which is huge when you consider that space is around 20%!
@@Xeptance How did you achieve this? Just by remapping the keys on your keyboard and moving the keycaps around? This sounds like a fun thing to play around with.
@@klekaelly yeah if you don't need to alter they key positioning (so the staggered rows of keys remain etc) you can just remap in software (and switch caps for ease of use). There are a few programs for that, and some keyboards with control software can do it as well. I've switched a few minor things around on my Razer keyboard using their companion app for example.
Love it! Would love a part two with more variables like ortholinear (and more languages). Nice work!
What’s the worst possible one then?
THE QWERTY Layout, probably.
I think there is a flaw, you should also take into account the dexterity of a finger, for some fingers a movement is easier. I don't thin it is just the distance
yep these are literally the exact same mistakes every "new keyboard layout" designer has ran into in their v1. also you don't need "AI" to calculate this, literally just need a word frequency list
@@LC-hd5dc I also thought that using AI might be an overkill here. But then you need to compute total score for each possible layout which is 30! and with my 2.9GHz PC it will take at least 2.9e+15 years and potentially much more. So you still need to use heuristics.
@@tunafllsh well you wouldn't need to compute all 30! layouts, because a layout with the 'e' in a corner will never be good
@@tunafllsh which for reference 30 factorial is equal to 265.25e+30 or 265.25 nonillion which is a few layouts to say the least
@@alg3n320 And how would you code "never be good"?
I haven’t finished the video yet but an idea for why the single finger keyboard groups the most common keys towards the left side is likely due to your programming. Since you split the best keyboards in half and kept the left side in order and the right side added in from missing keys that were left on the other keyboard, the right side was inherently more unorganized when assembled. On the left side, each generation the most typed keys were able to stay in place, maybe moved around themselves a bit depending on generation, but the right side likely moved around a lot more each generation. The left side was more stable, meaning it generates the best combinations for the most used keys on that side. Just an assumption from my limited programming experience but this seems right to me, and I haven’t yet thought of a way to prevent this disorganization on the right side. Feel free to correct me if I’m wrong.
I had the same thought. A simple fix could be to choose at random the left or right side from either keyboard (could also randomly select which keyboard has half of it taken)
Yeah I think a better solution to combining keyboards would be to randomly select key positions and then randomly select which keyboard to copy the key from, and implement some simple code to avoid duplicate keys on top of that, and then to handle the case where both key value options are taken up for different keys already you would normally save that key position as one to come back to when all other keys are settled to then assign the value of the key value that hasn’t been assigned yet but instead of this you could also just take the key value of that position from the third best performing keyboard
That was my first reaction to seeing his code. I don't understand why you would have a sexual algorithm rather than having an asexual algorithm that generates new keyboards through mutations such as maybe flipping the keys in two locations or smth
@@oliverdowning1543 I love that these monumental changes require updating just one method, assuming the code is well written.
@@FunkyTurtle yeah, if he's coded it cleanly he should just be able to drag and drop alternative functions in and out.
Great video, I love the background you use. It looks very good and gives something interesting while not being to overwhelming.
Don't forget to not only optimize by distance, but also to optimize the swapping of hands (or fingers for two finger phone typing) every other letter. The more swapping between hands there is, the faster you can type.
Also, your choice of dataset was a bit peculiar. It contains a great deal of grammar and vocabulary that isn't often used in day to day typing, which may sway the results. What I recommend instead is to use a data set with more common and daily-use style text.
It may not alter the results that much, but I do feel that it is significant to take into account potential differences.
The same exact two points I was thinking of when watching this video. There needs to be a cost function to promote alternating fingers(or more practical to implement: disincentivize using the same finger again)
Yeah and with only 35k word sample size mainly from physics research papers I’m sure it actually made a huge difference. And great point about the swapping.
1st: What do you mean swapping, like two-finger phone typing? The video includes that, or swapping left to right and right to left? (who would do that?).
2nd: I've tried it before manually(I'm not really good at programming), the most 200 to 500 to 1000 common words, I ranked switch-averaging E-O-T-A-N-R-S-I-L(in order). so I think his dataset was not very peculiar after all. since the "peculiar" words can be re-arranged to a common word.
3rd: Well, it may not alter the result "much more" than you expected.
@@maortredknight3925 he means no subsequent presses with the same finger. if you're finger is pressing A on qwerty keyboard, having to wait on your finger to release from A to press Q or Z takes more time than using a different finger. try it, what's faster, pressing AQAQAQAQAQAQ repeatedly or AJAJAJAJAJAJAJA.
According to his metrics, AQAQ would be faster cuz it's closer to the key. but eventhough J is further away from the key, you can buffer your other hand making it faster and more efficient.
☻️
For a software engineer I feel like you would need to add access to curly brace, square brace, quotes, slashes underscores, all those type of things. It would be interesting to get a list of the most used characters in software, and then design a keyboard based on that using a different number of keys.
That would probably be another special keyboard, generated with a bunch of code as the sample text instead of what was used in this video
He did take Java into account, I'm guessing it'll be different for Javascript/ruby
You can create one really easily with razer synapse and 3d printing or buying new custom keycaps
@Wolfette Plays you most likely wouldn't need custom keycaps. Just rearrange the ones you got.
Honestly it doesnt much matter. I'm an Android developer and work largely in Kotlin with a bit of XML. Due to auto complete I dont actually type all that much when programming but even still normal characters far outway special characters. Not to mention I probably type more characters manually in my administrative tasks (tickets, hour logging, etc.) And communication (slack messages, emails, etc.). Therefore I think optimizing for normal tasks and not putting the special characters on the otherside of the room would suffice.
This video is awesome! I just switched to a ZSA voyager keyboard with the Colemak DH layout and it has been a really interesting experience learning another layout. Great work, maybe we'll see more alternate layouts in the future.
As follows up, it would be cool to see a weighted version of this, where at least the pinky keys are considered lower priority (higher distance).
Also, I'd love to see how this works out for custom form factor keyboards, especially split boards.
Edit: Forgot to mention thumb cluster functionality.
add in capital letters, which means the pinky is already holding a shift key.
Your distance metric doesn't take into account that your hands can move at the same time, i.e., while typing a letter with your left hand, your right hand can already move toward its next letter.
Moreover, you might want to multiply the distance with some weight depending on the finger, because you have more control in your index finger compared with your pinky or ring finger. I assume this would lead to more common letters being put near the center.
Would be interesting to see how this new cost function changes the resulting layout.
I think your first point is not relevant for distances, rather time. If he had computed the time to write a specific text, yes he had to take into account the way hand can move asynchronously. For the distance, no matter when, your fingers on each hand will have to travel that distance to make the typing thus addition of both distances from both hand is ok.
However, your second point is clever although it introduces new parameters that the one building the model can potentially bias.
Best
Your first point wouldn't change the outcome for the most efficient keyboard for the better as the extra variable you suggested would only increase the speed not the efficiency. Once he has the keyboard the most efficient he could possibly get it. He could do what you suggested to see what the fastest time theoretically the perfect human could type.
The second point you mentioned has nothing to do with the keyboards efficiency, the problem is that we humans use our pinky a lot less meaning it is weaker and has less dexterity. In a perfect world this wouldn't matter.
@@capehote4220 I don't know if y'all noticed but... a faster keyboard is generally considered a better keyboard. Distance moved is just how we compute the speed indirectly.
I remember avoiding even using the left pinky to smack the upper left key on a manual typewriter. Too hard. Easier to reach over with right index finger. Or left. If one is left handed. I suppose left vs right hand is something to take into account too though then we'd have 2 layouts. And should the keys be staggered? Totally unnecessary on a keyboard. And if they are staggered, by how much is optimal? And should the keys be all the same size? Your fingers are not all the same size. So many parameters. And what she the thumb? Can it do more than just spacebar?
Totally agree. It'll be very interesting to see the most efficient layout in terms of speed and contol. Distance is not accurate function. Also pinky fingers are used a lot with shift and backspace - so we need to take into account accuracy of typing and capital letters as well. Also layouts in other languages (cyrillic for example) are already based on letter frequancy and considered to be much more efficient than qwerty.
This video was amazing. As a lot of people mentioned, we'd love to see an updated version of this video with some more ergonomic criteria taken into account (finger roll over, alternating hands while typing, having higher dexterity with index and middle finger vs lower with pinky and ring fingers, etc)
There have been keyboard studies that actually use timing data from real typists. For example, collect data about the average time needed between hitting any two pairs of keys, and you use that data in place of the distance. You can even then put a value > 0 on the time to type AA or any other same pair of keys. Obviously the next level is real human data and not abstract distance measurements.
You took the ideas right out of my head! I was thinking about how that has more impact than just the raw distances.
Yeah my pinky finger is useless, it is just too short so I usually use my ring finger for qwop (both the game. lol)
Hey Guys, It's been about month since I have been using the 2 fingered layout now and just wanted to share back my feedback. It was quite tricky at the beginning to get used to the new layout given the muscle memory i had built over the years on QWERTY although after a week i gradually started getting the hang of it. Personally, there is a slight speed improvement as of now around 10-15 words per min but i think it would turn out great eventually. Also, i customised the keyboard a little as per my personal use bringing some letters closer to type out some common words i use better and faster.
how'd u change it?
@@midoritrima Dunno if there's a better way outside VIA or QMK, maybe AHK is your best bet if your keyboard does not support reflashing/remapping.
@adumb, I taught myself Workman layout on a Kinesis Advantage 2 (ergo keyboard) in 2 months. That was in 2015 and I still type workman on that setup primarily. If you would be willing to run the model on a Maltron switch location I would absolutely be the person who learns and implements the most optimized layout with respect to common hotkey environments and content, as you say. I'm rebuilding a Maltron keyboard to run on a rPi pico and will include a mode select encoder for different layout maps.
I think a Maltron or Kinesis Advantage physical layout would benefit massively from this same treatment.
God speed man. Awesome vid.
The secondary aim of todays standard keyboard design was to minimize type jamming, as letters were spaced out at rest, but all strike the same tiny area in use, so a major concern was to spread out commonly used letters so the strikers wouldn't collide and stick, enabling faster typing.
That's also the reason why the keys are not aligned in vertical in an orthogonal layout, so that between two keys there was some more space for the type lever. This mechanical requirement of old typewriter has remained the same in all subsequent keyboard layouts.
Do you still use a typewriter?
@@SmartGamer1234 Do you understand that he was giving historical context to explain why something is the way it is?
@@SmartGamer1234 The transition from typewriters to computers happened in a fairly short amount of time, and once humans are used to something, they are unlikely to change.
Look at how many different plug types we have: when I first went to visit Chile before moving there for seven years, I didn't have the appropriate converted for my MacBook pro, and all the hotel had on hand was a Type B to Type I, and then a Type I to a Type C, so I had a Frankenstein adaptation going on (and being from Canada, I spoke no Spanish back then, so trying to find an electrical store was not really an easy option... especially with Chilean Spanish being what it is).
We can't even standardize what side of the road we drive on. Once something is established, it's psychologically hard to switch. We do have one software developer on our team at our organization who uses his own keyboard that he has mapped to a completely nonstandard layout and that has no symbols on the keys... a good way to make sure nobody comes into your office and starts trying to use your computer. 😆
Nice video, thanks!
Here are some ideas to go further:
- run the algorithm for AZERTY keyboard and French words;
- use Zipf's law to try finding an abstraction of your results for both languages;
- use a keyboard layout where the keys aren't offset (this was useful to prevent jamming in the metal branches of a typewritting machine but not anymore), run and compare this layout to the classic one.
Even further:
- check if muscles engaged in each finger use have the same capability, if not, add weights to the distance travel by fingers to simulate the relative difficulty of moving them;
- try a layout with separated parts of keyboard;
- try a layout with different sized keys with minimal area and a relation between area and mistyping the key.
And other languages, or run it on a multilingual corpus.
Ping me if the AZERTY/french one is online pls
While these are all interesting variables to mess with, I feel like removing the offset defeats the practicality of the experiment. Even split keyboards have an offset.
The idea is that you could change the inputs without hardware modifications, but a video about the best theoretical keyboard would also be very entertaining.
Comparison with Canadian French and Canadian Multilingual keyboards would be interesting too in the Azerty video if it ever happens.
Maaan, I would love to see that. Specially the Zipf's law
Your channel is amazing dude, very original and creative concepts, and really informative quickest subscribe of my life!
Saw this on my recommended and this is an amazing video! Keep up the hard work, you definitely earned my subscription!
9:31
Your training algorithm cuts the keyboard in half, it's very likely that the best keyboards had most of the most used keys on the left side, so they got to keep their keys unchanged during the "mating" process, and then this trend just continued as generations went by
Nice work! One of the aims of the Dvorak layout IIRC is to increase speed by having the letters in words alternate between left and right hands as much as possible. That allows one hand to reset while the other handles the next letter. You might also want to consider weighting the fingers, as I'd assume dexterity increases in order from pinkie to index finger?
Agree. another weight to add can be shifting distances of the whole hand, because you need to shift your whole hand to type qx, wc, ve on qwerty. i think this would force optimization for hand alternating as well as Colmak "rolls" mentioned by @Scykei
you are so creative and humble! Great video!
I think another cool experiment would be to design a hand and fingers, then figure the muscle fiber strain for each key. Not from the home keys but starting from where your fingers were previously located. Run that test for a while and see which combination of letters puts the least strain on the hand. And maybe a single key for extremely common letter combinations would be helpful.
I think that would be far more useful. The standard qwerty layout and equivalents are already plenty fast. And if you really need faster, then you'd likely want to switch to a stenographer setup anyways.
While efficiency might not be a reason to switch your keyboard layout, there are layouts that make typing more comfortable. If you experience RSI, you may want to change to a layout that uses the pinky finger less or one that has a low number of single finger bigrams (same finger for two letters in a row).
Yea also you might consider layouts that makes you alternate your left and right hand.
I actually have very short pinkies so I already type with more of an augmented 6 finger style since moving my whole hand to make use of the pinky is less efficient for me than just moving my longer fingers into place to type with, since moving my hand in that way changes the rest position of my wrists. The weird style I have created for myself means I often move my fingers off the home keys to minimize wrist movement, so I have textured keys to easily return to without looking. I can manage a sustained speed of 60-70 wpm with bursts of 100wpm, so it works for me, and I wonder if minimizing wrist movement and the smaller fingers like pinkies would also be efficient for a more generalized population that could have arthritis/RSI/etc?
I actually had that 3 years ago, bought Ergodox EZ, and started using Colemak .. now Colemak DH .. and found out that the split keyboard did not add as much difference ( even though I love it ) as the layout change from qwerty to Colemak did ...
hmmm! this intrigues me; do you have any examples I can look up?
@@DiaaKasem0 I'm planning to buy a split ortholinear like the Ergodox as my next keyboard, so I'm glad you shared your experience. I've not used anything but QWERTY yet, but I wonder if the ortholinear key layout has more impact than the split form factor.
I imagine the split would improve your posture by allowing your arms and shoulders to sit more naturally, without much affecting speed/efficiency. Meanwhile the ortholinear layout should reduce strain on the hands and fingers (at least that's my intuition). Again I can see how optimizing the layout of the letters might still be the best way to improve speed, while not (on its own) neccessarily improving the ergonomics as it relates to comfort, RSI, and fatigue.
Fascinating video anyway!
I like how RSTLNE looks like Rest Line, like it was always meant to be where your fingers rest lol
Beautiful man, you're the only one who could help me, I watched 8 videos and yours was the only one that saved me
holyshit, you’re videos are insanely good. Was surprised when I saw u only have 50 k subscribers, u deserve waayy more.
I think the reason for the 1 finger keyboard grouping the important parts on the left is because of your implementation of how they evolve. Since you split down the middle, the keyboards that grouped most of the common letters on one side of the middle outperformed the others initially and set the standard before a perfectly centered grouping happened by chance during breeding.
I think it might have to do with it was keeping the ones used least often on the sides where as the most used ones are near the center including the consonants
@@christopheriman4921 Well the question is why they were not in the center but to the left (9:35). And I think this is due to the fact that for them to be in the center there would have to be a keyboard that has half of the common leters left of the center and another that has the other half on the right so that when evolving they fuse together perfectly. The chance of this evolution happening is arguably lower than a keyboard that has all the relevant keys on one side of the center line as close to the center as possible leading to those dominating the early layouts and therefore likely the result.
@@cyrx-glg-1675 it seems like it would be a little more efficient for left hand left thumb styles of typing on a phone to me in abstract
@@grimsage5809 True but from how he said it in the video I’m assuming he did not bias for left or right hand
@@cyrx-glg-1675 aye, just an interesting abstract i'd thought of regarding it. would be interesting to see if the same key allocation would replicate in a new iteration or if the approach itself is flawed for single finger input
when testing one finger typing, did you still create further chromosomes by splitting the keyboard? that might explain why the algorithm preferred to group the most commonly used letters on one side.
Agree, if the algo is exactly how you described it the keys on the lefts are more likely to be passed to the next generation at that exact location, which explains why it is biased on the left as well. You may try to use ranges instead of starting always from the left most keys. To speed up exploration you can also introduced some random swaps of keys.
Really nice investigation and analysis! Now I fell I want to change keyboard layout but I also feel I am gonna regret it immediately afterwards;)
For One finger typing, The favour to left side felt weird for my right hand brain, but for someone left handed, It would be more optimal. Maybe adding a trait to balance dominating hand would be something to think about ....
Maybe it has to do with the amount of keys that surround the central key and the way they are slanted. if you pick D on a qwerty it's surrounded by 8 keys approximately at the same distance if you pick F or J on a qwerty you get 6 immediate neighbour keys because because of how the keys are slanted on the third row. Since you try to minimize finger travel and the position of the keys is fixed, having more immediate neighbours can drastically change your finger travel.
I disagree. The algorithm doesn't care if it is centered so much as the keys used together are close together, so the secondary keys are better grouped together as well resulting in the main keys being to one side.
yeah, perhaps sometimes taking from the right side instead would help with this
10:01 I thought of this way back in college. Awesome to see someone actually create a layout!
A few things to note
Most modern IDEs already have autocomplete systems in place. Meaning some letters might go up or down depending on how most words start. The closing brackets and tags become less important than the opening.
Still on the topic of programming. I'd like to try a one handed mode since I use my mouse a lot and changing between right side of the keyboard and mouse is inconvenient, and that's why I use 4 or 5 macros over there
Some more suggestions:
In the custom layout scene there are also more attributes:
Alternating hands, penalty for weak fingers like pinky, training set also for german, french and spanish texts.
Keeping CTRL-C and V and X easy accessible, maybe at same position. Optimizing for other languages by only swapping 2 letters (querty->quertz) makes it more support by the worldwide community.
And use of ortholinear key positions instead of 170 year old staggered layout makes it more ergonomic.
Why stop there? Let the keys move around and change shape, it may be easier to hit a massive key that's far away than a tiny key on homerow, but then you can fit them close together
Keeping ctrl-c and v and x in easy position is a bad goal, that's why some ugly layouts like Colemac or Workman exists. Another ugly decision of this kind is changing vim commands just for fitting cursor movement in same places. My opinion is that you either have a handy copy-past or having a handy layout. Same thing is with vim, you either have a handy cursor movement on Dvorak or a handy set of commands.
I have tried out different keyboard designs and I found much greater ease in typing letters from the index than the pinky.
There is no proper evidence to suggest that ortholinear is more ergonomic. In fact, as it is less closely aligned to the natural forward axis of the dextrous spread, it may be more likely to cause joint issues with time.
@@Eimrine There's also no reason why copy/paste HAS to be ctrl+c/v. We can just transpose the combos to whatever is actually in that position.
Dvorak also considered that the upper row is "closer" to the home row than the lower row, because it's easier for the finger to extend and hit the upper row, than it is for it to curl and hit the lower row.
this just got reccomended
and i love the vid sm
This is interesting, also add the function keys like shift, ctrl, alt, and enter because these keys also play a crucial role when typing; for example the pinky finger on the left hand will move more offsetting other fingers
I'm very conflicted by the fact you didn't call the RSTLNE keyboard "ReSTLiNE". It even makes sense...
This may be optimal for the constraints that you set up. However, I feel like there is a massive unexplored area an opportunities related to changing the physical layout of the keyboard by allowing different sized, shapes and locations for keys. For example, the upper and lower rows where originally offset to match the typewriter. The offset was kept for convenience and due to the natural curl of our fingers, but it still raises the question on if there is a more optimal arrangement. Furthermore, I've wondered if there's a feasible way to move the space bar and give a purpose or at least some keys to the thumbs.
There are ergonomic keyboards like this, the layout is slip in the middle (giving some space to separate the hands), the keys follows a bow pattern and the middle is curved allowing you to type at a 45d instead of forcing a flat position
Look up the Kinesis Advantage, I’ve used that amazing keyboard for years
I type on a niu mini. I have a small spacebar so that I can have buttons next to the spacebar that act as additional modifier keys. This lets me not have a number row for instance.
Look for the Planck, BM40, Niu Mini, Gherkin, XD75, Ferris Sweep, Corne, Lily58 Pro there lots of keyboards that improve upon the physical layout of the standard keyboard and they all have customizable firmware so you can change the function of every single key to suit what you like. I daily drive a Gherkin but I also own a BM40 and XD75.
Get a keyboard with thumb clusters. Also convex keyboard fit the hand better generally. Kinesis advantage has had this shape for decades.
This is a really unique interesting video, great job!
This was absolutely fascinating. Thank you. I’d be interested in an efficiency comparison to halmak and colemak dh layouts. (I started relearning with halmak)
Would love to watch a part 2 to this where better optimizations are used. I’ve got 2 ideas myself
1st is to change the way the fitness is measured. Ideally if a finger moves from 1 key to another, another finger can move at the same time. Instead of measuring distance, measure the time. This way typing something like qwerty only takes the time is takes to move a finger from a to q since all other fingers can move upwards at the same time.
2nd I think there’s a better way to combine the keyboards. Say keyboard a and keyboard b are selected to reproduce and form keyboard c. To generate c, select a random position on the keyboard p. Get the keys of a and b that exist at p and randomly select one to place at p. Keep randomly selecting positions on c to fill until the entire keyboard is (almost) complete. The instances where only 1 key is valid (because the key from the other already exists on c) just use the valid key. If both have already been used then set it to null. Once you have attempted to fill all positions on c, fill any null keys with keys that don’t already exist on c.
A different wording from what I was thinking, but the same idea.
7:07 - my inner programmer is sobbing
A great video indeed. Had fun typing on the RSTLNE keyboard
amazing video, might switch to your layout to streamline editing. Thanks!
I think it would be cool to go a step further, cross-referencing with ergonomic keyboard designs. Combining natural hand motion (as the highest), then most efficient button layout, I'd be really curious to see the distance results of that. Great video btw
The farther you go in efficiency, the farther you go from what people are used to, and when many can barely type faster than 30 WPM, a whole new system is just not practical. Except for court stenographers (who already have a far more efficient method of typing)
@@UnderscoreZeroLP also everyone in the world uses qwerty today, even the Japanese. I guess the ultimate kb would depend on the user and the use. A custom layout for every person in the world.
@@ariheino327 yea and you’ll find all of those ppl on reddit 😭
@@ariheino327 There are people that use Dvorak, and allot of people using custom keyboards these days. I use an ortholinear, but still use qwerty. I would be willing to try RSTLNE myself but I think it can be further optimized so I'll wait I really think pinky movement should be penalized.
@@ariheino327 not quite true. for example I use qwertz and I know a couple people that use azerty. And then obviously the people with alternative layouts like Dvorak, Colemak, Neo, KOY, Bépo, Ristome, and the rest of the wold west of layouts.
A few quick comments/corrections:
Dvorak is not pronounced/spelled like the name of the famous composer, Dvořák. It’s spelled Dvorak and pronounced the way it looks.
As other commenters have pointed out, there are many different metrics used to optimize the layout of a keyboard, and the one used here is a very simplistic one. Some others include Asset, whose goal was to remain as similar to QWERTY as possible to make switching easier; Colemak, whose goal was to keep commonly typed letters near each other and minimize changes from QWERTY; Dvorak, whose goal was to move common letters far apart; Workman, who assigned every key a (somewhat arbitrary) “difficulty rating” and optimized for lowering the difficulty rating while treating left and right hands as equals; and, finally, Norman, whose goal was similar to Workman’s while treating the right hand as better than the left because most people are right-handed and trying to minimize changes from QWERTY in order to make switching easier including Q, A, S, Z, X, C, and V as they are all commonly used for shortcuts and not moving them improves quality of life. Importantly, the Norman layout actually scores very well on the requirements set for all four of these other keyboards, and when compared to the others, often scores second or third compared to the other four keyboards ON THEIR OWN TESTS.
Finally, none of the tools used for this testing or designing in the past, such as Carpalx, have used or needed AI.
Yeah I was gonna say something about that, nothing about this problem requires the use of AI
Dvorak is a Czech surname. He pronounced it correctly.
@@dw9zg6kctnr23 Dvořák is a Czech surname, but Dvorak the keyboard layout was named after an American with an Americanised name, so it should be spelled as such.
@@noth1ngnss921 Indeed, August Dvorak's Wikipedia page states his name pronunciation was Anglicized.
I’ve just got into custom keyboards and want to teach myself to touch type again. I use my dominant right hand far more than my left and having long fingers, often click the wrong keys or two at a time. This was a really interesting video.
Great video. I would love to see what you could come up with using 5 fingers on one hand both left and right handed versions. Probably center on fghj.
This could be super useful for disabled people and people in certain workplaces, lots of production fields where your hands are full or dirty. And personally I've always used my right hand to type on its own lol just feels more natural for me.
could you do this experiment with the already defined keyboard layouts? Workman, qwerty, Colemak?
Also be cool if you included the {}() in the keyset too for the coding examples.
maybe even include other AI generated layouts, such as rsthd
thinking about programming ? Yeah it would be cool to do a similar experiment but this time taking open source code projects instead of research abstracts. For example depending on the coding language, words like String, int, if, for, function, class, etc are ultra common and fancy words like "preposterous" aren't used at all.
If ones can abstract this result using the Zipf's law and therefore design a keyboard layout for the abstract rankings of each character, anyone could just run an algorithm over a file to count the characters used and set the keyboard layout by its ranking.
Makes me wonder how high the distance would be with TNWMLC
I could see the results depending a lot on the editor one codes with. Something strongly keyboard-driven like vim could have different results compared to VS or similar.
Living in Belgium has caused me to first be taught the French keyboard layout "AZERTY", however, since I didn't even live in the French part of Belgium and I write in english more than anything else on my computer, I decided to switch to QWERTY.
It didn't take all that long for me to get used to it (although that might have something to do with the fact that they layouts are largely the same, the main difference are actually the extra symbol buttons, these are way more useful on a qwerty keyboard for me, since I rarely need to type french words that require special accents.
I found this interesting but i would also recommend adding a few more parameters.
1. If you use alternating hands/fingers your typing time decreases as your 1st hand/finger resets while the 2nd moves to the key; in some cases minimizing the use. It also can reduce hand fatigue, which can slow you down based on the amount that will be typed in any given session.
2. Fingers dont have the same length, dexterity, and strength. For example, my pinky is shorter bit more free than my ring finger, so i have to move my hand more to reach a key, but it can reach keys left and right easier. The ring finger is stronger but is more tied to the middle finger so a top key middle finger followed by a bottom key ring finger is more awkward/steining.
3. Left- or right-handedness may also play a role as well as incidental use. Forexample if you play a lot of games, you would become more accustomed to using keypatterns like QWER
ASDF
ZXC
That represent many keybinds for games with a mouse.
Interesting stuff. Glad you included programming code as part of the sample set. There will likely never be consensus on the 'optimal' layout as language keeps evolving and what you need to type varies too greatly depending on your field of work. A chemist or geneticist would use certain letters or words a LOT more than a lawyer or engineer. I think DVORAK was an attempt to make the average typed word (using all known or common words at the time) balance the work between left and right hands. The frequency of words (like 'the', 'or', 'and', etc) also is a significant factor. I think with a massive enough sample set you could determine a 'better' layout of keys based on what has been typed recently (think of all of wikipedia plus every National Geographic and all english newspapers for the past ten years for scale). Perhaps a word frequency plus letter distance to make those words formula could be devised (most frequent words should be the shortest for example [my head hurts just thinking of it]). I am surprised DVORAK had such a decent showing in the first distance metric.
My understanding is the (current) QWERTY layout is actually designed to SLOW down typists. When mechanical typewriters were invented it took time for the physical keys/hammers to travel from their home positions to the paper and back (they were spring loaded I think). One hammer had to clear the path of the next or there would be a collision which could lead to a jam or physical damage. Well, typists were able to type so fast that jams (and damage) were a frequent event. The engineers moved the letters around to reduce impacts and ALSO moved the letters to SLOW down the typists (not just balance the distribution of the letters to keep letter groups further apart). The layout has not changed largely due to momentum (every generation of typists learn the QWERTY layout and switching to another layout is just not viable (short of personalized keyboards which would also be impractical). So...QWERTY is here to stay. Enjoy your day.
As there is going to be a version two :). I would love to see the comparison with Colemak's, and would love to see for ortho-linear boards
Agree with this, as someone that switched from QWERTY to Dvorak to Colemak, this would be cool to see
You can move a finger into position while typing with another. When you need the same finger for both keys thats probably slower.
Definitely slower. That is one of the reasons why single finger or two finger typing is slower than 9 finger typing.
This video was a lot more interesting than expected!!
The fact that keyboards are used to type so many different things, in so many different languages, with human hands in mind, and in order to 'optimize' we have to keep all of those AND future possibilities in mind makes me not super surprised with how static keyboard layouts are. Not just changing but truly innovating in a way that stands up to many different use cases and stands the test of time is daunting to say the least. Very interesting video
I would love to see comfort implemented somehow, for example, it's much more comfortable to move your fingers up and down than side to side, which is why I use the Workman layout over something like Colemak or Dvorak for instance.
You can do that just by changing the metric slightly, just scale the up/down distance differently to the left/right distance. What I'd suggest is to run the metric for Workman and Dvorak, and tweak the parameters so Workman is *slightly* favored over Dvorak, then use that metric to train new layouts.
Imagine using an inferior layout lmfao
@@squaremarco Me resisting the urge to use nerd emoji for no reason
This seems like it would be true. I also would think that finger movement towards the middle of the keyboard would be easier than movement laterally outward from resting position.
I liked the video! Still some suggestions for v2, maybe consider including the dexterity of the finger (index > pinky) and/or ortholinear/columnar layouts (which normalize distance between rows)? Also I think it would be interesting to consider a list of words that is not scientific english, but rather a general list of word frequency in english as a whole. Abstracts have a bias towards more complex words.
These videos are always so interesting!
This is awesome! Thank you for sharing 😊
Funny thing about the RSTLNE name, it can be shorthand for restline. That's an apt name for this layout since all the most common letters are on the home row or the *line* your fingers are on when they are at *rest*
I made a very similar program for a group project at university. Some differences are the crossover function which better preserves the rough positions as well as the idea that your finger stays on the last key it typed. I also only just did single finger typing keyboards. What was cool is that the vowels got grouped in the very centre, leading to a very efficient typing method. You usually switch between vowels and consonants frequently, so this makes sense.
I know words with 7 letters but only one vowel.
This video is inspirational, I would be further researching regarding a good keyboard layout that is the best for Python programming for this month's Hackathon event. Thank you very much!
Great video! I would like to add to the numerous follow-up ideas presented in the comments, the study case of split ortholinear keyboards. They seem much more efficient and ergonomic to me than traditional one-piece staggered keyboards. I would like to see a similar video on those keyboards.
This is a cool research video! It's so hard to type with a differenty layout once you're used to the QWERTY, but man, it's awesome!
I've taught myself Colemak DH and Colemak DHM and was wondering what they would score on your AI compared to RSTLNE along with other alternative layouts like Workman and Dvorak. Another question I had is this: I know that Colemak prioritizes the finger being used, with the idea that the fingers closer to the center are the best to use and the pinkies are the worst. It would be interesting to see if/how you would implement that into an AI and what other results you might find. Otherwise, fantastic video and hope to see more!
which is better for you? DH or DHM? i just found out about colemak and im trying to learn it. Are DH and DHM better than the original?
@@coolsywhutatops3768 In my opinion they are both better than the original, but I don’t have anything to show for it. DHM is a matrix (ortholinear) version of DH, so they are basically the same to type on except the placement of Z. I have keyboards in both and switch between them with no issue.
@adumb Wonderful to finally see someone who appreciates and understands genetic ML! I especially love your design for the genetic crossover. I really appreciate that you ran the same experiment but defining keyboard distance for hunt-and-peck or hybrid typers like myself instead of just touch typists!
One other thing, actually. Because of how the home keys are defined in QWERTY, the positions where T, Y, B, and N are are actually furthest in terms of distance (P, ;, and / are considered less distance). I would suggest running the experiment with the home keys closer together, e.g. instead of positions F and J, test with positions F and H or F and G so undesirable characters your ML found like Z, Y, G, ;, ., and ? aren't in the center of the keyboard.
Also at 8:05 you said "slightly less INefficient." Should be "slightly less efficient" or "slightly more inefficient."
Noice! I like the algorithm and you explained it very good!
My first thought was that you can develop a process where you give the algorithm programming language documentation as an input and get the best layout specific for that programming language. Would love to see what the output will be for JavaScript.
What you really need to do is log your keystrokes for a year (or find a dataset of anonymized key logging data... spooky stuff right there, though) and use that to analyze the frequency of keystroke sequences. This could include things like the delete button, space bar, et cetera. Of course, this all assumes that our word selection decision making process isn't implicitly affected by any sort of tendency toward words that are easier to type...
Edit: A sample set including data from users of different languages as well as certain professions (e.g. coders) would be necessary for any serious attempt to create a new standard keyboard. It'd be worth experimenting with the actual layout of the physical buttons themselves as well.
Could probably even identify what kind of games they play with that data.
Thanks for your video. Loved it. Creating a two finger layout was a really customer focussed idea. (Though you deserve two thumbs rather than two fingers.)
I created my own keyboard in 2016, and have been using it ever since. I wrote a Windows native driver for it, so it's selected just like a Windows language.
I switch seamlessly in my brain between typing on it and then typing on an iPhone or an iPad. In my head it is just typing, responding to the visual cue that it's an iPhone/iPad. Thus, it is no problem switching between them.
There are some things you didn't measure and may wish to try:
- the distribution of key strokes between the fingers
- the distribution of keystrokes between hands
- the usage of common punctuation (treat it as a valid letter)
- the use of the same finger consecutively to type different letters
- common letter tuples (two letters, three letters: ct, ion)
- natural horizontal finger movement: like strumming the fingers inward from the little fingers
- flexibility of the fingers compared with each other (ease of typing with each finger)
- the use of shortcut keys like Ctrl-C etc
Mine took these into account as well as a lot more. In effect, it was reducing work (e.g. travel, relative finger workload, etc), and strain, etc.
I tested mine with a variety of keyboard efficiency metrics on the internet, and with a respected corpus of two million words. It is 'better' than QWERTY, DVORAK, Colemak, and Workman. I didn't choose to use the optimal one, but instead used one extremely close since I found it easier.
Over 85% of strokes are on the home row under the eight fingers. 100% of normal typing can be done on the three main rows, excluding numbers, %, currency, and some other characters. Also on the three main rows are brackets (normal, curly, square), quotes marks for European languages, and forward slash. Your hand doesn't dart about a lot: instead, you make an easy reach for the keys, effectively keeping your other fingers on the home row.
Backspace and the Enter Key are trivially easy to strike, since they are repositioned for this purpose. Delete previous word is an easy action: it is often quicker to delete a partial or full word and type it again rather than backspace it or move a cursor.
I built the keyboard using a standard commercially available keyboard, with custom keytops (since the physical design of the keys differs from row to row). The prototype/test keyboard was a £6.99 keyboard from PC World, with easily moved key tops.
You are right putting the Q top left, and putting punctuation down the middle: there is an ergonomic reason for this. Other of your conclusions are also sensible in practice (as opposed to theory).
My keyboard has other mind-blowing amazing features that make it highly commercial. It is not difficult to learn, and blind-typing is also easy.
I can use a blank keyboard, use a QWERTY keyboard and type as if it were in my layout, switch easily between the standard keyboard and mine (Alt-Space Bar).
However, it does not do spelling corrections automatically, or send emails (using only the main rows).
It is good at social networking typing tasks.
It can type natively in fifteen different languages without having to change the Windows language setting, and so you just seamlessly flip between them in the same sentence. Accents are a doddle, even in capitals. It can type the IPA spelling of five of these languages, although this uses a function key to temporarily change the key assignments. (IPA: International Phonetic Alphabet.) I designed it because I couldn't find any language layout that would let me easily type French, French IPA, and English when creating ANKI flashcards for learning French.
I struggled to type on a QWERTY layout and never was able to blind-type with it. My own is very straight forward since the most used keys are under my finger or a natural finger movement away.
I hope my comments give you other ideas and considerations for progressing your project. It is worth pursuing, if only for the mental agony.
Keep on with the project and progressively improve it. What a good application of AI. The number of comments is a hearty round of applause.
The cost of patenting worldwide is too high for me, and so it will die with me. [The good (that men do) is oft interred with their bones. W.S.]
This is a very simplistic way to analyse the efficiency of the layouts. Carpalx has already done very good analysis of keyboard layouts and I have been using one of his layouts for many years.
Colemak mod user here. I took the Colemak DH keyboard layout and modified it a bit to fit my style of typing and I have to say that I do enjoy typing on this layout way more that on qwerty. It would be interesting to see how different efficiency styles like the colemaks roll would change the AI's output. Love the video and I would probably try those layouts at some point but I would probably go back to colemak or workman for the very satisfying roll feeling when typing.
How do you find when you are forced to type on a QWERTY keyboard?
@@emersonnugent5419 well it is horrible. It feels unnatural and overall clunky. I allways carry a USB-drive with me that has a Colemak PKL on it (portable keyboard layout wich works via ahk) that I can allways type on a colemak layout.
I tried some existing keyboard layouts and found out that Norman works best for me. I was able to feel less stress on my fingers in fist few tries. I also asked some of my friends to try it out, both who know qwerty with high typing speed and who doesn't. Majority said they feed norman be slightly better. Few says they can't feed the difference and nobody said it was worse. So keyboard layout matter, especially if your job related to typing and I enjoy people to at least play a bit with different layouts.
Something interesting i found when learning the Dvorak keyboard, is that theres single-hand versions - where your index finger and little finger are on the two Home keys, with your hand in the middle of the keyboard.
Would be interesting to see how efficient you can get that kind of layout to be.
This is a really interesting idea that made me second guess how I type. I rarely use my pinkies for anything beyond Shift, Ctrl, or Enter. I also never noticed where I keep my hands resting until now.
It's an interesting idea and watching this video was really satisfying!
I wonder what would be the results if ML will take into account not only distance between keys, but also ergonomics such as
1. Make pinky fingers do less work to avoid RSI and leave all heavy work on index fingers. I agree that distance for the index fingers could be the largest, but at the same time index fingers are the most proficient fingers and all the ergonomic layouts are based on the idea to squeeze maximum effort out of this fingers. At the same time pinky fingers are the weakest and should avoid typing.
2. Place common letters combinations such as 'th', 'gh', 'ea', 'ou' and etc. in such a way that they could be typed as 'chords'. This combinations should have a higher weights for teaching/evolving ML model, because of the way human brains, habits and memory muscle works.
3. Even distribution of work between 2 hands to make switches between them as often as possible. I'm not sure how this should affect weights for the ML, but it would be nice to take into account.
If it would be possible to take everything above to teach ML model it might produce the most efficient and proficient keyboard layout ever existed :)
Layouts have already been made with many of these considerations 👍. Without going into too much detail, there isn't a single perfect layout because personal tastes are quite important, and the weightings of even just the metrics that you described will change the final layout (and the choice of weightings of those metrics is subjective). If you're interested in learning about layouts that optimise for these characteristics, I can help a lil.
Yep that’s the problem with these AI generated layouts, they are still heavily biased towards what the creator thinks should be taken into consideration.
@@smudge9603 that is true! Sometimes I prefer “less efficient” keyboard layouts because of some preferences and limited flexibility of my pinky
@@smudge9603 also what you use a keyboard for matters a lot. if you're typing english vs typing bahasa indonesia vs writing code in haskell, or if you use applications where it's difficult to remap keys (which there are workarounds for, but still...)
and ofc the shape, size of your keyboard and keycaps matter a lot, as well as your typing style (i never use the "home row" style due to excessive strain, instead my wrists float around the keyboard which allows me to reduce finger stretching and pinky usage)
And the "chords" are very language specific. Right now there are many languages that use a moderately adjusted QWERTY layout that respects different frequency of letters and the existence of other letters than the 26 of the english language.
But with a chord oriented keyboard, every language would need it's own. Possibly more than one layout per language, because different professions will have different chords.
I really love the neo2-layout, idk if you had a look into this. This is optimized for german language but has a lot of cool features, like multiple layers with special characters and much more :)
Simply awesome - thank you very much!
I enjoyed learning about your approach and the vocabulary of genetic algorithms; i acknowledge the sheer amount of work done in the background to generate these results and the impressive and persuasive figures; I was captivated seeing how a result lead to the next research question; I was most surprised to discover that after only 12 minutes I had none open question left.
And I admire the fine tuning you put into presenting your findings with graphs, pictures and animations so the complex topic is really easy to consume and understand.
Just how much time did you spend on all this??
Really amazing study. Thank you for sharing.
Super well explained and interesting video! Thanks!
Another thing to add to evaluate how good a keyboard is, is how many letter combination can be rolled or how often the hands can alternate. What I mean by rolling is typing multiple letters in one motion. I use the dvorak layout and on it you can type sch pretty fast by positioning your pinky, middle- and forefinger and pressing down on the three keys. It'd be nice to see these things implemeted in a follow up video.
It seems like this keyboard would naturally accommodate for that if its sample size of words is large enough because it aims to make more commonly used word patterns more accessible in the resting position.
If you feel the difference in terms of staying in the home row, alternating hands and rolling fingers with Dvorak, I suggest taking a look at Neo2, which improves even further on it.
The custom keyboard youtubers gonna have a blast with this shit lmfao
Fantastic video my guy. I really enjoyed the depth you went into for this. Super well done.
Awesome, i am waiting for next videos
This has probably already been discussed, but I don't favor each of my fingers and positions equally. For example the letter 'q' is very difficult for my left pinky to reach, where as 't', & 'y' are very easy for my pointer fingers to reach. You could use the same code that you have created but add penalties for certain keys that are generally hard to reach. like querty 'q'. Great video!
If you pronounce RSTLNE as Rest Line, you could refer to the home row as the "rest line."
Two things:
First, the reason your 1-finger layout has the common keys on the left, is most English typists are right-handed.
Second: Typewise is an alternate keyboard available in the Apple app store (it may be available for android, I don't have an android device). It has two alternatives, either of which can be set independently. One is honeycomb, hexagonal, positional layout. This gives you 5 interlocking rows, instead of four neat rows. The other is sveral alternate layouts, including Dvorak.
I like the swipe-up to shift, and the swipe-left to backspace, and the multiple choices for placement of the space key.
Bro I was thinking that you should also program the ai to prefer keyboards where the same finger is used the least possible times in a row.
This might actually be a key factor, especially given the hand structure.
You can also add finger strength, indexes and middle fingers being the strongest, the pinky being okay and the annular being the weakest.
I would be very curious to see how the results change with respect to these keyboards.
Great video, keep it up man
The pinky is stronger than the annular? Even if this is the case, the pinky is much more awkward for typing. I never learned to type "properly" so I use my fingers in a more intuitive way where I pretty much never use my pinky as it's just uncomfortable.
I'd be interesting to run this simulation not only for english, but all languages that use latin alphabet, and maybe even consider the number of native speakers for each language to get a keyboard that is efficient all over those languages and basically efficient for humans in general, that would be quite complicated I think
I don't think the number of speakers is the right variable to consider. It more likely depends on what those individuals are typing. The clue is you are limited by the design of your keyboard and typing technical texts, code, or in other languages determines your needs.
@@janlochman1985 plus people don't just type in their native language. And considering 13 of the 20 most wildly spoken languages (With about 500 million more speakers) don't use the latin script, even that doesn't work.