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.
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.
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.
@@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.
i think alphabetical would be hard since you only consider how early or late a letter appears, mentally mapping earliest from left to right, descending to latest
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:)
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.
@@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'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! 😂
@@robcridland5457 Imagine the old manual typewriter where you needed to hit each letter hard enough to get a good dark letter while pressing down on the shift key for every explanation point, quotation mark and question mark. And then there is the other odd thing where sectaries weren't considered all that highly skilled...but the typewriter was constantly breaking. Overall, there is just something about the story of the invention of the qwerty keyboard that just doesn't work. I think it is much more likely that Mr Scholes copied it from the layout of a typesetters office than he actually invented it. If you were to layout your typesetters office in a manner that several employees need to run around boxes of type then it would allow for the maximum number of personnel working on the same manuscript.
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, 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.
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.
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.
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.
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.
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!!
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.
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
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.
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.
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
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.
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.
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.
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.
@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.
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).
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 ...
@@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!
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
@@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.
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.
You don't need a special keyboard - just a new driver for your current hardware. Plus, if you think it's important, some little character stickers - though my family never used them when switching between English and Russian.
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.
@@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. 😆
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.
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.
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
Yeah, a real easy way to weight the fingers is a 10/20/30/40 % usage weight for pinky to index, respectively. TBH MY pinkies feel pretty much useless aside from modifiers, but I've only ever used standard qwerty layout with normal keyboard stagger so IDK if that would change with a more optimized layout.
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
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.
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 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
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.
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.
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.
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.
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
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.
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
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.
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 think it would be fair if the used value for the fitness would be lower if a different finger is used for a letter. It is slower if you use the same finger for most keys, but faster if you can move 1 finger while you are pressing another
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*
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.
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.
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 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.
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.
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.
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.
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.
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.
nice video! the analysis of different number of fingers is also great from an accessibility point of view for those who have fewer limbs that they are able to type with.
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.
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 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 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.
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!
@@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.
Its very fitting that the name RSTLNE can be read as "rest line" as all the main keys lie in the middle row and since your hand don't move too much outside it serves as a resting line for your hand. After trying it out for a bit I think this layout should really be an official thing. I mean nowadays it wouldn't be a big deal as changing a layout doesn't necessarily involve changing physical keyboards, you can remap keys and get stickers over the caps. Newer generations could be trained on this layout while older generations can still use the qwerty layout and both could coexist with no problem whatsoever, until qwerty is eventually phased out completely. Absolutely liked the keyboard, its ease of use , quick learning curve and how comfortable it felt while typing.
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.
@@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.
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!
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.
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
I used an older AI generated layout called Halmak for about a year and a half, I actually really liked it. It shares a lot of features with the ones in the video, like punctuation in the middle with the forward slash on bottom and semicolon on top. I would go back to it, but rebinding all of my keys for games drove me insane.
@@DeltaInsanity I did for a few months, but I actually just switched back again after seeing this video lol. Feels way better. My problem before was that I changed the firmware on my keyboard to the Halmak layout, so I couldn't switch back to QWERTY for games. I'm just using software now, so it's way less of a problem.
@@wtftode Ahh gotcha, thanks for the info. Just out of curiosity, is Halmak the only alternate layout you've tried? If not, how does it compare to other layouts, and how was the learning process compared to others? I'm currently using Colemak DH and love it, but I'm always open to other options.
@@DeltaInsanity I think the learning process is pretty similar between any two layouts. Biggest thing to get used to is punctuation, but since you're on DH you probably know how that is already.
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.
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.
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.
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.
@@janlochman1985 I would suggest, as a ranking criterion for building a corpus for languages, you look at the number of documents published in $LANG$ in the last 20 years. You're not really bothered by historic documents, since people convert them, not type them. But really, between alphabetic languages, syllabic languages, and pictographic languages with syllabic variants, you're not going to have enough characters on a regular keyboard, or within reach of a pair of hands without having to move the whole hand towards/ away from the body. If you use multiple languages regularly, swapping logical keyboards isn't that difficult. If you don't do it regularly, it might *look* daunting. But it's not.
I would be interested in trying the following modifications: 1. Try different keyboard breeding algorithms; one that I can think of is: for every letter, randomly select which parent's position it inherits. If the winning position is already filled, choose the losing position, and if that's already filled as well, put it into a queue of keys to be placed randomly (mutations) at the end of the combination process 2. Try optimizing for time, rather than distance, by keeping track of motions that can happen simultaneously (i.e. sharing the load over hands); I can think of a few different tweaks to how this is implemented 3. Try optimizing for stretch, by assuming that neighboring fingers also move alongside, which would help to handle rolls between neighboring keys (personally this is the metric that I'm the most interested in as my goal is reducing the amount of arthritis and tendon pain I experience)
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.
@@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.
09:30 the reason the common keys are grouped to the left is because you always took the entire left of one keyboard then filled in the rest from another. So any common keys from the second keyboard are moved further right, making the result slightly worse. In other words, the ‘fittest’ keyboards will be ones where all common letters are solely in the left half.
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.
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 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.
The QWERTY keyboard layout, originally used for typewriters, was made to maximize the spacing between keys as to not have 2 adjacent keys fire at the same time and jam the machine. What you are trying to optimize in this video goes the complete opposite direction. By far, QWERTY is the worst for low finger movement.
For the one-finger experiment, the outcome might be due to rarer but dependent keys. E.g. Y and , are used less frequently but often come together (y at the end of words, comma immediately after); but B is also often used with Y (researchers love “by”). That’s why those are grouped together. I expect there is a certain dependency between the other keys, which caused them to be grouped together or pushed out by other groups. The rarer groups might therefore might have pushed the more frequent group to the side. Alternatively, seeing they all are ti the left, this may simply be an artefact of your algorithm: combining the keyboard halves, where the right half is a bit more random. Since the frequent group makes typing significantly more efficient, it has the most selective drive and thus gets to the more stable part of the keyboard earlier
Great video! Lots of comments already mention what I was thinking while watching (alternating hands, etc.), but I'm curious about one other idea. I type with *mostly* the correct fingers, but often the fingers I use for certain keys (namely the keys in the center of the keyboard) change depending on where my fingers were before that. In your code, the distance being minimized is the distance from the home row resting position, even though that's not where your hands are before every word. Changing this would make total distance extremely dependent on the order of the text being typed, maybe the distance would average out about the same anyway. Might be interesting, though!
y, i dont get why your thumbs are only on the space key. I mean i guess everyone adapts, but V to m ,etc. should be easy to typ with your thumbs... on the Qwerty
9:39 The reason you're getting clumping of consonant/vowels on left/right is because you have the split point implemented vertically (which even with a random vertical line, will average to the middle over many trials). So the optimizations are most optimized on the side that the algorithm has the most control over - the left. The algo then finds itself stuck in this local minima, and the right side of the board is left with the scraps. Following from this, it would be interesting if instead of a vertical left/right split, there was an attempt to introduce noise on a more per-key basis (in your example, the 'gene' level). Perhaps instead of adjusting by leftside/rightside, you randomly selected half of the keys each generation as a lock-in. I have to assume the same structural effect is in play for the other boards too, so it'd be interesting to see what happened to these style of boards using an alternative method.
Possibly simpler would be to alternate (or randomly select) which side of the keyboard you retain when generating each new generation. I'd probably go for randomising it, just to avoid "generation skipping" effects.
I've found that I type using my index, middle, and ring fingers most often. Also, would you be willing to release the algorithm you used to find these results so people can play around with it themselves?
The best real-life keyboard I’ve tested is the Korean keyboard when writing Korean. Since you write consonant->vowel constantly in Korean the left side of the keyboard is all the consonants and the right is all vowels. In a few minutes I started to naturally type it without much thinking which you can’t do with a qwerty keyboard for English when you start learning!
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.]
An analysis of a predictive keyboard, one that has an "accept" button to accept the computer suggested code, word, phrase,etc. would be interesting. Of course, prediction implementations vary by quite a lot right now.
I redid the experiment but made a few adjustments, I accounted for hand swapping (by simulating the way fingers move when typing), difficulty of pressing certain keys, and of course, distance as you did. Im really happy with the results and am actually using one of the layouts now
I’m glad many other comments pointed some things you missed. Things like finger rolling and alternating between hands for letters. Some fingers are weaker. And some aren't even limited in their areas, they can move to make other typing letters easier. The left middle finger is not limited to DEC, it can hit R or even F if necessary. Type out the word "CARB" it would be easier to hit R (Middle) and then B (index) than R (index) and then B (index) Looking at existing keyboard and their philosophies will really help. Take a look at how the Korean keyboard is set up whenever you have the chance.
For my Human Computer Interaction course I looked at making improvements to the keyboard without making changes to the existing QWERTY ordering. For example, using the SHIFT key forces you to change how you type because you have to hold that key with one of your pinky fingers. So a simple change I thought was to use half the space bar as a SHIFT and the other half SPACE. The feedback I got is that its terrible and most people would avoid a keyboard with that feature. Turns out, people are really resistant to change their keyboards.
@@cetin_ Interesting point of view you have and you are certainly entitled to your opinion however it is hard to judge my ability to design a keyboard based on a single design idea from one iteration of design. Let's discuss your idea then. You are suggesting that you'd use CAPS lock every time you want to type capital letters? Interesting but equally not likely. For those for letters in CAPS - I held the SHIFT key with my pinky, and I did it again there. That pinky extension is a strain and a likely contributing factor to carpal tunnel syndrome for those who type a lot. So changing the location of the SHIFT key to be in a location that does not need the extra extension of the pinky is likely a benefit for health. Would it be an improvement then in typing speed? My guess is yes, but it would have to be tested. Consider this, the extension of the pinky reduces dexterity of the other fingers. The thumb naturally rests in the location of the SPACE bar. Therefore, splitting the SPACE bar in half, would take an often used key like SHIFT and make it more accessible. Therefore, everything points to SHIFT being in this location would be a design feature you would want. The issue with HCI paper design is you are getting feedback based of the visuals, not the functionality. Asking someone if they would even try a keyboard with this feature just by looks leads to many people stating what you did in not so many words. "I like my keyboard the way it is so I won't try anything new." Lastly, consider that every keyboard is slightly different so you've been trying new layouts all of the time.
@@AxGryndr which side of the spacebar would become shift, which finger would be used to press it (the requirements for A, T, P and U are very different and use very different fingers on a regular, qwerty-derived layout), and what happens if you need a capital letter on the other side of the keyboard (would there be another shift)?
@@HappyBeezerStudios Really it doesn't matter which half, and with current technology it would be possible to have a setting to change which half. Obviously being in the location of the space bar, the natural flow would be to use the SHIFT with the thumb since on a typical QWERTY style keyboard, both thumbs perform the same function. Changing to using a thumb to be the SHIFT engager means your hands are always in the home row position. When you have to use SHIFT on a standard keyboard, you have to alter you hand position because the pinky has to stretch. If you need a capital A, then the key is now being hit by your ring finger.
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.
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.
i love this idea! you should try that with an ortholinear + and with shift for uppercase, on a broader, more normal to average people dataset. something like literature i guess. it would be very interesting how different values would be. if i had your skills i'd spend ages to find the most optimal layout xD
ortholinear would be very interesting here, also column stagger boards would also affect this. the problem with these boards is how does the keymap account for the keys that don't fit in a simple 3x10 grid. seems like for these alternate layouts everybody has a different way of handling those keys.
I'm glad you decided to take a small look at different use cases. A great keybord layout would be something that is applicable to both writing text (the most general use case), as well as respects other use cases enough not to make itself too difficult to use. For example coding with [ and { involves pressing a modifier key (for me it'd be Alt Gr). And scientific papers are often written using LaTeX, which involves heavy usage of \ which is also only available through a modifier. I've seen a few "bigger" keyboards that add keys for these between the rightmost keys and the Enter key. And similarly keyboards are already slightly different in some countries. For example on the German keyboard, Z and Y are switched and "Umlaute" like öäü are placed to the right of the L. Interestingly enough, layouts for asian languages use a different system, on the same kind of keyboard. Many of those languages (think Chinese) have way too many symbols to print on a keyboard, but they can use a combination of key presses together with a very intelligent suggestion system to even work great on phones. This has been one of the technological advantages of a few phone manufacturers like Samsung (though of course the same system is also installed on computers). Very interesting topic, which I presume to keep evolving slowly as more developments come up. Recently Microsoft added shortcuts for emojis to Windows for example (though the feature is not well known at this point).
In american layout (at least), symbols [, ], ;, and \ don't involve pressing a modifier. Shift modifier for representing { and }. I have grown used to the "American International with Alt Gr dead keys" layout, which is quite versatile. It behaves as a regular American layout most of the time but you have the AltGr modifier for umlaute and others (AltGr + " followed by vowel = ë, AltGr+S = ß, AltGr + > followed by s = š, and there are "shortcuts" such as AltGr+r = ë, etc.). This keyboard tends to make writing on your language a little more clunky but it improves a lot the writing of code. It is a tradeoff, and it is quite easy to get used to it.
@@mariussiuram Right, I could change this layout by myself - and since I mostly write English or code, it would probably be better. Might try it out next week, thanks for the idea!
@@mariussiuram I use approximately the same, but from a base of UK-English. And between accents and long-S ("eszett"), that does me for most of my other languages too. I've never needed to look at doing non-standard characters in Russian - for which I think I can thank Путор Болсоии.
Hey, I loved that video! Do you plan to make the code of the project available to the community? I would like to try it out myself in my own language. Also, it would be pretty cool if everyone could create their own layout according to their own priorities!
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 :)
It would be interesting if you made the neural network open to the public so that people could test their own sample text and get a somewhat personalized layout
Two things I haven't seen in the video or the comments so far: 1) the original layouts (qwerty, azerty, etc) were chosen not optimal on purpose : they were meant to slow down typing enough so that the mechanical typewriter keys wouldn't end up garbled together. 2) I knew a professional programmer that switched to dvorak to be "more efficient" : it took him weeks to become just a slow correct typer, and after more than a year he was sometimes still hesitating when typing his password on the login screen. I would rather become more efficient on the existing qwerty layout, that almost everyone also know and are already quite efficient with, than some "optimized" weird layout that everyone would have to train for.
It would be interesting to see how the optimal layout would look for languages other than english and for which language the qwerty keyboard (or its commonly used alteration) works the best
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!
Awesome video, love seeing AI used for effeciency streamlining. I was curious though, I use an ortherlinear split board. As such the keys are in a grid, have you done any tests where the physical arraingement of the keys is different than the standard?
I imagine it would've been more optimal to swap positions of a random 50% of the keys between the keyboards, rather than the odd splitting down the middle method you used.
Its a nice observation but i think there are other factors which are just as important to consider: grouping/ separating common combinations, place common letters at fingers that move faster or can be moved in a more ergonomic way (short pinky vs linger index finger) and even try to change the overall placement of the rows. But these factors are very difficult to use
I think it'd be interesting to run your code to find the most *inefficient* keyboard layout. I'm curious how it'd compare to the QWERTY layout. I've heard that the QWERTY layout was designed to be inefficient because before QWERTY was standard, people were typing too fast and breaking their typewriters. Apparently, they came up with QWERTY to make people type more slowly to avoid this issue. I'm not sure if this is entirely true, but it would be interesting to see how inefficient the QWERTY layout is compared to the least efficient layout...
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
What’s the worst possible one then?
THE QWERTY Layout, probably.
alphabetical
A layout where Q,Z,J,B,K,F are used as the home keys
@@dropkickedmurphy6463 Bad news given that J and F are the QWERTY home keys with K and B close by
i think alphabetical would be hard since you only consider how early or late a letter appears, mentally mapping earliest from left to right, descending to latest
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'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.
@@robcridland5457 Imagine the old manual typewriter where you needed to hit each letter hard enough to get a good dark letter while pressing down on the shift key for every explanation point, quotation mark and question mark. And then there is the other odd thing where sectaries weren't considered all that highly skilled...but the typewriter was constantly breaking.
Overall, there is just something about the story of the invention of the qwerty keyboard that just doesn't work. I think it is much more likely that Mr Scholes copied it from the layout of a typesetters office than he actually invented it. If you were to layout your typesetters office in a manner that several employees need to run around boxes of type then it would allow for the maximum number of personnel working on the same manuscript.
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.
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!!
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
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'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 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.
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.
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.
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)
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.
☻️
@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.
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!
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.
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
You don't need a special keyboard - just a new driver for your current hardware. Plus, if you think it's important, some little character stickers - though my family never used them when switching between English and Russian.
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. 😆
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.
10:01 I thought of this way back in college. Awesome to see someone actually create a layout!
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
Yeah, a real easy way to weight the fingers is a 10/20/30/40 % usage weight for pinky to index, respectively. TBH MY pinkies feel pretty much useless aside from modifiers, but I've only ever used standard qwerty layout with normal keyboard stagger so IDK if that would change with a more optimized layout.
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
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.
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
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
you are so creative and humble! Great video!
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
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.
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 like how RSTLNE looks like Rest Line, like it was always meant to be where your fingers rest lol
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.
Great video, I love the background you use. It looks very good and gives something interesting while not being to overwhelming.
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.
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 think it would be fair if the used value for the fitness would be lower if a different finger is used for a letter. It is slower if you use the same finger for most keys, but faster if you can move 1 finger while you are pressing another
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*
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.
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.
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.
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.
I'm very conflicted by the fact you didn't call the RSTLNE keyboard "ReSTLiNE". It even makes sense...
Love it! Would love a part two with more variables like ortholinear (and more languages). Nice work!
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.
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
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.
nice video! the analysis of different number of fingers is also great from an accessibility point of view for those who have fewer limbs that they are able to type with.
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.
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 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 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.
the Brazilian keyboard is also similar to the English one, the only difference is that it has Ç after L, the accents ´/` after P, and ~/^ after Ç
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.
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.
Its very fitting that the name RSTLNE can be read as "rest line" as all the main keys lie in the middle row and since your hand don't move too much outside it serves as a resting line for your hand.
After trying it out for a bit I think this layout should really be an official thing. I mean nowadays it wouldn't be a big deal as changing a layout doesn't necessarily involve changing physical keyboards, you can remap keys and get stickers over the caps. Newer generations could be trained on this layout while older generations can still use the qwerty layout and both could coexist with no problem whatsoever, until qwerty is eventually phased out completely.
Absolutely liked the keyboard, its ease of use , quick learning curve and how comfortable it felt while typing.
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.
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!
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.
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
I used an older AI generated layout called Halmak for about a year and a half, I actually really liked it. It shares a lot of features with the ones in the video, like punctuation in the middle with the forward slash on bottom and semicolon on top.
I would go back to it, but rebinding all of my keys for games drove me insane.
So did you end up reverting back to QWERTY?
@@DeltaInsanity I did for a few months, but I actually just switched back again after seeing this video lol. Feels way better.
My problem before was that I changed the firmware on my keyboard to the Halmak layout, so I couldn't switch back to QWERTY for games. I'm just using software now, so it's way less of a problem.
@@wtftode Ahh gotcha, thanks for the info. Just out of curiosity, is Halmak the only alternate layout you've tried? If not, how does it compare to other layouts, and how was the learning process compared to others? I'm currently using Colemak DH and love it, but I'm always open to other options.
@@DeltaInsanity I think the learning process is pretty similar between any two layouts. Biggest thing to get used to is punctuation, but since you're on DH you probably know how that is already.
I'd love to see a comparison between these layouts and the normal qwerty in a typing test like wpm
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.
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.
@@janlochman1985 I would suggest, as a ranking criterion for building a corpus for languages, you look at the number of documents published in $LANG$ in the last 20 years. You're not really bothered by historic documents, since people convert them, not type them.
But really, between alphabetic languages, syllabic languages, and pictographic languages with syllabic variants, you're not going to have enough characters on a regular keyboard, or within reach of a pair of hands without having to move the whole hand towards/ away from the body.
If you use multiple languages regularly, swapping logical keyboards isn't that difficult. If you don't do it regularly, it might *look* daunting. But it's not.
I would be interested in trying the following modifications:
1. Try different keyboard breeding algorithms; one that I can think of is: for every letter, randomly select which parent's position it inherits. If the winning position is already filled, choose the losing position, and if that's already filled as well, put it into a queue of keys to be placed randomly (mutations) at the end of the combination process
2. Try optimizing for time, rather than distance, by keeping track of motions that can happen simultaneously (i.e. sharing the load over hands); I can think of a few different tweaks to how this is implemented
3. Try optimizing for stretch, by assuming that neighboring fingers also move alongside, which would help to handle rolls between neighboring keys (personally this is the metric that I'm the most interested in as my goal is reducing the amount of arthritis and tendon pain I experience)
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!
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.
09:30 the reason the common keys are grouped to the left is because you always took the entire left of one keyboard then filled in the rest from another. So any common keys from the second keyboard are moved further right, making the result slightly worse. In other words, the ‘fittest’ keyboards will be ones where all common letters are solely in the left half.
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.
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.
The QWERTY keyboard layout, originally used for typewriters, was made to maximize the spacing between keys as to not have 2 adjacent keys fire at the same time and jam the machine. What you are trying to optimize in this video goes the complete opposite direction. By far, QWERTY is the worst for low finger movement.
For the one-finger experiment, the outcome might be due to rarer but dependent keys. E.g. Y and , are used less frequently but often come together (y at the end of words, comma immediately after); but B is also often used with Y (researchers love “by”). That’s why those are grouped together. I expect there is a certain dependency between the other keys, which caused them to be grouped together or pushed out by other groups. The rarer groups might therefore might have pushed the more frequent group to the side.
Alternatively, seeing they all are ti the left, this may simply be an artefact of your algorithm: combining the keyboard halves, where the right half is a bit more random. Since the frequent group makes typing significantly more efficient, it has the most selective drive and thus gets to the more stable part of the keyboard earlier
Great video! Lots of comments already mention what I was thinking while watching (alternating hands, etc.), but I'm curious about one other idea. I type with *mostly* the correct fingers, but often the fingers I use for certain keys (namely the keys in the center of the keyboard) change depending on where my fingers were before that. In your code, the distance being minimized is the distance from the home row resting position, even though that's not where your hands are before every word. Changing this would make total distance extremely dependent on the order of the text being typed, maybe the distance would average out about the same anyway. Might be interesting, though!
y, i dont get why your thumbs are only on the space key. I mean i guess everyone adapts, but V to m ,etc. should be easy to typ with your thumbs... on the Qwerty
@@monkeyraphinas7118 how do you stay in a comfortable resting position and manage to hot V without also pressing the spacebar?
9:39 The reason you're getting clumping of consonant/vowels on left/right is because you have the split point implemented vertically (which even with a random vertical line, will average to the middle over many trials). So the optimizations are most optimized on the side that the algorithm has the most control over - the left. The algo then finds itself stuck in this local minima, and the right side of the board is left with the scraps.
Following from this, it would be interesting if instead of a vertical left/right split, there was an attempt to introduce noise on a more per-key basis (in your example, the 'gene' level). Perhaps instead of adjusting by leftside/rightside, you randomly selected half of the keys each generation as a lock-in.
I have to assume the same structural effect is in play for the other boards too, so it'd be interesting to see what happened to these style of boards using an alternative method.
very good point
Possibly simpler would be to alternate (or randomly select) which side of the keyboard you retain when generating each new generation. I'd probably go for randomising it, just to avoid "generation skipping" effects.
I've found that I type using my index, middle, and ring fingers most often.
Also, would you be willing to release the algorithm you used to find these results so people can play around with it themselves?
A 6 fingered keyboard layout would be nice to see on the website as well, I'm a fellow six-fingered typist 😎😎
You can see the code at 5:38
@@redblock33 I am blind. Is it seriously all there? Smh.
@@RossWasTaken Keep it rockin' my man!
The best real-life keyboard I’ve tested is the Korean keyboard when writing Korean. Since you write consonant->vowel constantly in Korean the left side of the keyboard is all the consonants and the right is all vowels. In a few minutes I started to naturally type it without much thinking which you can’t do with a qwerty keyboard for English when you start learning!
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.]
An analysis of a predictive keyboard, one that has an "accept" button to accept the computer suggested code, word, phrase,etc. would be interesting. Of course, prediction implementations vary by quite a lot right now.
But if there was a speech to text keyboard like the one I am reusing (edit:should be using) right now
I redid the experiment but made a few adjustments, I accounted for hand swapping (by simulating the way fingers move when typing), difficulty of pressing certain keys, and of course, distance as you did. Im really happy with the results and am actually using one of the layouts now
What is it?
I’m glad many other comments pointed some things you missed. Things like finger rolling and alternating between hands for letters. Some fingers are weaker. And some aren't even limited in their areas, they can move to make other typing letters easier. The left middle finger is not limited to DEC, it can hit R or even F if necessary. Type out the word "CARB" it would be easier to hit R (Middle) and then B (index) than R (index) and then B (index)
Looking at existing keyboard and their philosophies will really help. Take a look at how the Korean keyboard is set up whenever you have the chance.
For my Human Computer Interaction course I looked at making improvements to the keyboard without making changes to the existing QWERTY ordering. For example, using the SHIFT key forces you to change how you type because you have to hold that key with one of your pinky fingers. So a simple change I thought was to use half the space bar as a SHIFT and the other half SPACE. The feedback I got is that its terrible and most people would avoid a keyboard with that feature. Turns out, people are really resistant to change their keyboards.
turns out you're terrible at designing keyboards also i want you to remember that caps lock exists
@@cetin_ Interesting point of view you have and you are certainly entitled to your opinion however it is hard to judge my ability to design a keyboard based on a single design idea from one iteration of design. Let's discuss your idea then. You are suggesting that you'd use CAPS lock every time you want to type capital letters? Interesting but equally not likely. For those for letters in CAPS - I held the SHIFT key with my pinky, and I did it again there. That pinky extension is a strain and a likely contributing factor to carpal tunnel syndrome for those who type a lot. So changing the location of the SHIFT key to be in a location that does not need the extra extension of the pinky is likely a benefit for health. Would it be an improvement then in typing speed? My guess is yes, but it would have to be tested. Consider this, the extension of the pinky reduces dexterity of the other fingers. The thumb naturally rests in the location of the SPACE bar. Therefore, splitting the SPACE bar in half, would take an often used key like SHIFT and make it more accessible. Therefore, everything points to SHIFT being in this location would be a design feature you would want. The issue with HCI paper design is you are getting feedback based of the visuals, not the functionality. Asking someone if they would even try a keyboard with this feature just by looks leads to many people stating what you did in not so many words. "I like my keyboard the way it is so I won't try anything new." Lastly, consider that every keyboard is slightly different so you've been trying new layouts all of the time.
@@AxGryndr makes sense
@@AxGryndr which side of the spacebar would become shift, which finger would be used to press it (the requirements for A, T, P and U are very different and use very different fingers on a regular, qwerty-derived layout), and what happens if you need a capital letter on the other side of the keyboard (would there be another shift)?
@@HappyBeezerStudios Really it doesn't matter which half, and with current technology it would be possible to have a setting to change which half. Obviously being in the location of the space bar, the natural flow would be to use the SHIFT with the thumb since on a typical QWERTY style keyboard, both thumbs perform the same function. Changing to using a thumb to be the SHIFT engager means your hands are always in the home row position. When you have to use SHIFT on a standard keyboard, you have to alter you hand position because the pinky has to stretch. If you need a capital A, then the key is now being hit by your ring finger.
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.
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.
i love this idea!
you should try that with an ortholinear + and with shift for uppercase, on a broader, more normal to average people dataset. something like literature i guess. it would be very interesting how different values would be. if i had your skills i'd spend ages to find the most optimal layout xD
ortholinear would be very interesting here, also column stagger boards would also affect this. the problem with these boards is how does the keymap account for the keys that don't fit in a simple 3x10 grid. seems like for these alternate layouts everybody has a different way of handling those keys.
I'm glad you decided to take a small look at different use cases. A great keybord layout would be something that is applicable to both writing text (the most general use case), as well as respects other use cases enough not to make itself too difficult to use. For example coding with [ and { involves pressing a modifier key (for me it'd be Alt Gr). And scientific papers are often written using LaTeX, which involves heavy usage of \ which is also only available through a modifier.
I've seen a few "bigger" keyboards that add keys for these between the rightmost keys and the Enter key.
And similarly keyboards are already slightly different in some countries. For example on the German keyboard, Z and Y are switched and "Umlaute" like öäü are placed to the right of the L.
Interestingly enough, layouts for asian languages use a different system, on the same kind of keyboard. Many of those languages (think Chinese) have way too many symbols to print on a keyboard, but they can use a combination of key presses together with a very intelligent suggestion system to even work great on phones.
This has been one of the technological advantages of a few phone manufacturers like Samsung (though of course the same system is also installed on computers).
Very interesting topic, which I presume to keep evolving slowly as more developments come up. Recently Microsoft added shortcuts for emojis to Windows for example (though the feature is not well known at this point).
In american layout (at least), symbols [, ], ;, and \ don't involve pressing a modifier. Shift modifier for representing { and }. I have grown used to the "American International with Alt Gr dead keys" layout, which is quite versatile. It behaves as a regular American layout most of the time but you have the AltGr modifier for umlaute and others (AltGr + " followed by vowel = ë, AltGr+S = ß, AltGr + > followed by s = š, and there are "shortcuts" such as AltGr+r = ë, etc.). This keyboard tends to make writing on your language a little more clunky but it improves a lot the writing of code. It is a tradeoff, and it is quite easy to get used to it.
@@mariussiuram Right, I could change this layout by myself - and since I mostly write English or code, it would probably be better. Might try it out next week, thanks for the idea!
@@mariussiuram I use approximately the same, but from a base of UK-English. And between accents and long-S ("eszett"), that does me for most of my other languages too. I've never needed to look at doing non-standard characters in Russian - for which I think I can thank Путор Болсоии.
RSTLNE: I am the fastest, am scientifically proven to be the best!
Speech-To-Text: Sure… :)
Hey, I loved that video! Do you plan to make the code of the project available to the community? I would like to try it out myself in my own language. Also, it would be pretty cool if everyone could create their own layout according to their own priorities!
The code is available through their patreon but I'm not sure if the license allows for modifying the code and all that
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 :)
holyshit, you’re videos are insanely good. Was surprised when I saw u only have 50 k subscribers, u deserve waayy more.
It would be interesting if you made the neural network open to the public so that people could test their own sample text and get a somewhat personalized layout
Genetic algorithms are not neural networks. In fact, they're totally different things.
AI and neural networks are not synonyms
Two things I haven't seen in the video or the comments so far: 1) the original layouts (qwerty, azerty, etc) were chosen not optimal on purpose : they were meant to slow down typing enough so that the mechanical typewriter keys wouldn't end up garbled together. 2) I knew a professional programmer that switched to dvorak to be "more efficient" : it took him weeks to become just a slow correct typer, and after more than a year he was sometimes still hesitating when typing his password on the login screen. I would rather become more efficient on the existing qwerty layout, that almost everyone also know and are already quite efficient with, than some "optimized" weird layout that everyone would have to train for.
It would be interesting to see how the optimal layout would look for languages other than english and for which language the qwerty keyboard (or its commonly used alteration) works the best
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!
Awesome video, love seeing AI used for effeciency streamlining. I was curious though, I use an ortherlinear split board. As such the keys are in a grid, have you done any tests where the physical arraingement of the keys is different than the standard?
I imagine it would've been more optimal to swap positions of a random 50% of the keys between the keyboards, rather than the odd splitting down the middle method you used.
Its a nice observation but i think there are other factors which are just as important to consider: grouping/ separating common combinations, place common letters at fingers that move faster or can be moved in a more ergonomic way (short pinky vs linger index finger) and even try to change the overall placement of the rows. But these factors are very difficult to use
I think it'd be interesting to run your code to find the most *inefficient* keyboard layout. I'm curious how it'd compare to the QWERTY layout. I've heard that the QWERTY layout was designed to be inefficient because before QWERTY was standard, people were typing too fast and breaking their typewriters. Apparently, they came up with QWERTY to make people type more slowly to avoid this issue. I'm not sure if this is entirely true, but it would be interesting to see how inefficient the QWERTY layout is compared to the least efficient layout...
This is a really interesting idea. I might try the code myself and see if i can get it to work.
@@BrainiacManiac142 Let me know if you do, I'd be interested in seeing the result!
me training before starting an argument: