# Leaving QWERTY Behind I never particularly liked the QWERTY layout. It's obviously not that efficient for speed or comfort, but it's also what the majority of English speakers learn by default. By the time I learned to type properly (instead of only pecking at the keys with 2-4 fingers), swapping to a more effective layout seemed like more trouble than it was worth--at least until I started developing extreme wrist pain earlier this year. I debated going to a medical professional but, much to everyone's disappointment, decided this was an engineering problem instead. And then I dove into the rabbit hole of keyboards and keyboard layouts... So this all began because of wrist pain. A lot of it, for me, stemmed from modifier key presses forcing a pinky stretch with other fingers depending on the intended key combo. Some pain came from the wrist ulnar deviation from twisting my wrists while quickly hopping around the keyboard As an exercise, for an hour--or even just 10 minutes--of regular typing, try to keep track of how many times your hands leave their default positions; I guarantee it’s more frequent than you think. Because this pain was so sudden and so intense for me for months, I assumed it would only get worse if I didn't change my typing habits quickly. This led to a couple of hardware decisions that I will expand on in another post, but for this post it's important to note that I ultimately landed on using a split keyboard with 36 keys, including 3 keys on a thumb cluster for each side. ## Alternative Keyboard Layouts At the beginning I was vaguely aware of QWERTY alternatives like Dvorak and Colemak, but I didn't fully understand their benefits beyond what others would mention in passing. What stuck the most was people saying it was better for programming, which turned out to mostly be a [[symbol layer thing]], not an alpha layout thing, with the exception of modal editing with something like vim. Particularly the `hjkl` keys used in navigation. Because of that, I wanted to understand the _actual_ benefits of alternative layouts, since the programming angle wasn’t very persuasive on its own. And to be fair, there really _are_ improvements to typing comfort and efficiency, especially with Colemak. If you don't know, Dvorak came about in the 1930s and Colemak in 2006. The world of typing has changed a lot, even since the early 2000s. Research into typing comfort and finger movement, the rise of speed typing, and the diverse assortment of keyboards with numerous downstream effects from the deviations in standard hardware have all really changed the game. While some of the metrics by which we measure a keyboard layout's efficiency existed, many more have been defined and analyzed. And there are more coming with the advent of adaptive keys. Some keyboard firmware has grown complex enough for enthusiasts to program different behaviors beyond what standard keyboards can do, including having keys that type different letters, or words, based on what was previously typed. This is a rabbit hole in itself that has different branches for the competitive speed typists who loyally stick to the the 1 character per key press ideology to the complex chording of stenography. I'll revisit this in a future post, but for now let's stick to the normal alphabetical layout. Let's break down some of the metrics currently used in keyboard layout optimization: - **Bigrams/Trigrams** - Two/three characters in a row in a word or typing sequence. These are the most common chunks we think about when optimizing a keyboard layout. Every language has its own set of most common bigrams/trigrams, as do programming languages, keyboard navigation, and more. This is one of those things where your most common bigrams/trigrams can be very individualized depending on your use case (multi-lingual, programmer, modal editing, etc). I've considered building a tool to help develop a personalized corpus to properly see my real bigram/trigram (and other chunks) breakdown. - **Same-Finger Bigrams (SFBs)** - Two consecutive keys typed by the same finger, usually in the same column. QWERTY has a lot of SFBs, like `ed`, `un`, `rt`, `ol`, much more - Same-Finger Skipgrams (SFSs) - When two keys are typed by the same finger with another key pressed in between by a different finger - **Lateral Stretch Bigrams (LSBs)** - When two keys are pressed by adjacent fingers but one requires a horizontal stretch to reach its key. This one I underestimated in the beginning, thinking higher LSBs weren't too bad a tradeoff for better metrics like pinky off. If there was one thing I would want to change about my current layout (pictured at the end of the post), it would be finding a different spot for `P`. I dislike that stretch for such a common letter every time. - **Repeat** - How frequent a letter repeats (e.g. `EE` in `SPEED`) - **Rolls** - Sequence of keys typed by one hand. They can be in-rolls (outer fingers toward index/middle) or out-rolls (inner fingers moving outward). - **Roll ratio** - Balance of inward vs outward rolls. This and rolls metrics can be used to tune how "flowy" a layout feels. - Alternation - When a series of keys are pressed by opposing hands one after another. This metric is often reversely proportional to rolls metrics and while both can be good, it ultimately comes down to preference. - **Redirects** - When the direction changes mid-sequence (e.g. `YOU` on QWERTY). There is an additional classification of this called a weak redirect which is the same mid-sequence redirect not involving the index finger, which is particularly uncomfortable. - **Scissors** - When two keys are pressed by adjacent fingers but the fingers are separated by one or more rows. This is particularly bad for 2+ row differences or when neither key is on the home row, so I tried to avoid having common bigrams sitting in these positions. Scissors can be a controversial topic depending on which fingers are doing a specific stretch. Finger length plays a factor and also the degree of shared tendons between two fingers. The index is more independent than the ring so it can handle a bit more, even though they are the same length. - **Alt Fingering** - When keys are not pressed by their usual fingers either for better efficiency in a common bigram or trigram or for better comfort. I only use this for two keys in my current layout. The upper pinky keys are pressed by my ring fingers for better comfort. This might be because I need to increase the column stagger of the keyboard itself, but I won't know for sure until I build the next one. For now the lateral stretch of my ring fingers annoys me significantly less than lateral stretches on my index finger. - **Finger load** - Total percentage of keystrokes assigned to each finger - **Hand load** - Distribution of keystrokes between left and right hands - **Hand/Finger Travel** - Aggregate movement of the hand/fingers with exceptional attention on the index and pinky fingers. This can also be reframed as home row deviation, and in my case resulted in constructing a key discomfort matrix to value certain finger movements and stretches over others. This portion of layout optimization is essentially a pathfinding problem to find the least amount of uncomfortable hand and finger movement for a given corpus. These metrics are not perfect. They are our best approximations currently for what is comfortable and efficient. We need something less simplistic and abstract, possibly diving more into hand biomechanics, to further optimize this. Suffice to say that the world of keyboard layouts has exploded in research and analysis leading to once great layouts being more middle of the pack or obsolete, especially with the emergence of layout generators and analyzers. Dvorak and Colemak are the most common alternatives, but swapping to one of them felt like finally breaking out of a box to then be restricted by a slightly better box. I wanted to understand why there were all these options and what made people pick one over the other so I could pick, or even make, the right one for me. ## Overlapping Communities: Speed Typing, Stenography, and Rhythm Gaming The pursuit of a comfortable typing experience led me down a rabbit hole of research that tunneled into a variety of other communities with their own wealth of knowledge and resources. The overlap in similarity with my goals is greatest with the speed typing community. While the primary factor to optimize for is different--speed vs comfort--the strategies for improving speed often benefit comfort (to a point). I stole the bulk of my knowledge starting out from this community. I had to learn to pick and choose a bit when to ignore their "sacred tenants" of optimal layouts. There are two big ones that come to mind, one being frequent letter placement (especially `e`). You see, with common letters like `e`, it's hard to find other letters to fill out its column and neighboring columns that don't interact negatively with it (i.e. avoiding SFBs, SFSs, etc). From a pure numbers perspective, the most efficient placement of `e` is in the least destructive spot on the home row: the pinky. The only key that would be even more uncomfortable on the pinky would be `SPACE`. No thank you. I'm willing to sacrifice some efficiency for exponentially more comfort. The other "sacred tenant" I ignored from speed typing was an obvious one. Speed typing has rules like any sport or competitive environment. One of the main ones is that a single key press can only produce a single character. Well, I'm never competing, so I don't need to live by the same restrictions. For most key presses this doesn't change anything, but it does allow for some typing improvements with adaptive keys and chording, which is where some of the overlap with stenography comes in. The stenography deep dive is still ongoing, partially for time restraints but mostly because it requires significantly more mental focus and time to learn. Learning this is similar to learning a new language; it requires a tiered, iterative approach, and right now I'm still learning and practicing the foundational parts. The core idea though is to use single or multiple key presses to produce multiple character outputs. They don't have to be alphanumeric characters either. One of my favorite uses for this is in window and app navigation or other common key sequences. These can take the form of adaptive keys that either look at previous keys pressed to determine what to output or setting an arbitrary timer and looking at the key presses following the adaptive key to determine what to output. (One of the projects I'm working on is a combination of both of these in a single adaptive key.) Another approach is just proper chording, or pressing a combination of keys at once and producing a determined output based on the combo pressed. The last community I visited was that of rhythm gaming. I should have recognized this immediately since a significant portion of the speed typing community overlaps with different rhythm games, but it wasn't until I started learning different layouts that I saw the similarities. Typing isn't a game for most people, so it didn't click until I saw the common elements of chunking, predictive pattern recognition (looking ahead and preparing for certain patterns, or in the case of typing reading ahead), economy of motion (with whatever body parts are relevant to the rhythm game), and flow state. I learned how to type "properly" later than most and never really got fast at it like others, so I never learned the correct techniques and tricks to get fast. With this project I was able to fully dive into it and recognize the similarities, especially between the speed typing sites and rhythm gaming interfaces and practice tools. It has helped me identify where I need to improve, how to improve, and make the experience a bit more fun. ## Theorycrafting and Layout Hopping I started out, after quite a bit of research, building some of my own layouts and hopping between them, trying to learn what felt comfortable and efficient. It mostly felt foreign. There is a mountain of data showing what makes a layout inefficient, but when it comes to making the *best* layout, it is impossible to satisfy all the competing factors. Worse, some positive factors (e.g. rolls vs alternation, center column usage vs pinky off usage, etc) are inversely proportional to each other. There's no concrete evidence which factors are superior, if there is an ideal balance, or if there is just a range of preference, so I've mostly gone with intuition to fill in the gaps. This leads into the local optima problem, or better known by another name: hill climbing. There are numerous explanations out there, but the core idea is simple: imagine you're trying to find the highest peak (best performing layout in this analogy), but you're blindfolded. All you can feel is the ground beneath your feet. So in order to find the highest peak, you only take steps that take you uphill. Take a step downhill by mistake? Turn around and try a different direction next time. You'll eventually reach the peak with this, but only local to where you started. Because of the blindfold, you don't know if there are larger peaks in the distance that would require you to walk downhill first. Pretty much all keyboard keyboard layout development I've come across has gotten stuck on this problem using simulated annealing, and while there are other algorithmic approaches to get around this problem, most people (i.e. me) are not willing to build a new tool to truly push through this optimization problem, though I have seen some attempts with genetic algorithms. At this point most hills have been discovered and it's a debate over what factors make a hill taller than another, and ultimately, I needed to swap to something quickly with my hands in the terrible state they were. So climb some hills I did until I found the one I liked. ## The Hills I Climbed While I looked at various implementations of the popular ones (Dvorak, Colemak, and many others), I didn't try any of them out for a long enough time to say I gave them a shot. I was constantly coming across things I didn't like either in research or practice. The first one I got hooked on for a bit was a variation of Gallium. I noticed an immediate improvement on many of the metrics I cared about, and compared to QWERTY, it's a world of difference to have the majority of key presses be on the home row. > I made the following images using Oxey's layout analyzer which can be found here: https://o2.oxey.dev/. Also, ignore the `;` key in each of the images. I don't keep `;` on the alphabetical layer. Instead there is an adaptive key in its place (something I'll dive deeper into in another post). ![[gallium.jpg]] Something that caught my attention around this time was the existence of thumb layouts. When most people type, they only use one thumb and that's mostly for the space bar. Transitioning to a split keyboard makes this more apparent--in normal typing one of my thumbs gets a lot less use than every other finger. This led me down the rabbit hole of figuring out which letter is best moved to the thumb. I tried many keys: `e`, `s`, `t`, `r`, and `n` got the most consideration. I really wanted to make `e` work on the thumb key, but 1) it didn't solve as many metric bottlenecks as other characters and 2) it has a very common repeat frequency compared to other letters which I don't prefer on my thumb. The letter `r` ended up being my favorite among the options. While it's not the most common letter, it's common enough, and it sits in an awkward spot in English bigrams; it appears more commonly in consonant clusters (e.g. `tr`, `cr`, `gr`, `pr`, `br`, `dr`) than other letters. Isolating `r` onto the thumb led to the best metric improvement in testing. I tried multiple variations of this gallium layout with different letters on the thumb, but this is the `r` version. ![[gallium_thumb.jpg]] After this I did a ton of hill climbing since Gallium wasn't originally optimized around a thumb key. My layout swapped a few keys at a time every couple of days as I learned my own typing preferences and found new column blocks to try. At this point I found a couple hills that peak at around similar metrics that mainly just came down to preference, and this is the final result I landed on: ![[custom.jpg]] I've been using this keyboard and layout for months now, and my wrist pain gradually diminished and eventually disappeared altogether. To be honest, this is connected more to the change in keyboard hardware than the layout change, but my fingers are certainly moving a lot less after leaving QWERTY behind. This was a bit longer than I intended and I left quite a bit out without even talking about the hardware, QMK/ZMK, layers, etc, so I will likely do a follow-up post or two at a later point.