keyboard_layout_optimizer VS trialyzer

Regarding evaluating, comparing and potentially even optimizing layouts, I would recommend my keyboard layout optimizer.

I recently got a new ergonomic keyboard, after just typing on my laptop for years. I've used an ErgoDox before, so I went with the Moonlander. While configuring the keyboard and playing with the location of the spacebar, I realized that putting it on the right hand side resulted in a really bad balance between the two hands – it seemed like dvorak was way more right-hand dominant, and that was confirmed when I started looking into it. Went down the rabbit hole of alternate keyboard layouts, and found this repo: https://github.com/dariogoetz/keyboard_layout_optimizer . You can specify the physical configuration of your keyboard and provide a sample text, and it will generate layouts for you, using simulated annealing or a genetic algorithm. Here's a screenshot of the generated layout, along with Dvorak on the bottom:

That's very interesting. I tried a genetic algorithm myself for my optimizer. In the end, I removed the crossover part, but mainly because I did not understand, how exactly it worked :)

You can find the code for the evaluator here. Apart from my own set of metrics, it includes the ones used in KLAnext and also the ones from Oxey's layout playground (with some caveats).

Regarding an evaluator with support for multiple layers that can be user-configured, supports "classical" hold layers as well as one-shot layers, and modifiers on "any key" (think home-row mods), I can advertise my own evaluator/optimizer https://github.com/dariogoetz/keyboard_layout_optimizer Saves you some time on a new project ;)

Identified (amongst others), by tweaked version of https://github.com/dariogoetz/keyboard_layout_optimizer

I want to introduce a pet project of mine that I have been working on in the last year - a keyboard layout evaluator/optimizer: https://github.com/dariogoetz/keyboard_layout_optimizer

Regarding your future plans, take a look at the trialyzer project. They follow a similar approach as far as I understand.

This is a table of trigram categories. The full explanation is here but we are interested in the sfs subcategories, which is my name for a DSFB in trigram form. sfs.alt is an alternating DSFB, the others are various forms of same-hand DSFBs.

As part of an analyzer, I typed a few thousand trigrams and measured the median speed of each. Here are the results. Each point represents the median speed of one trigram, broken down into bigram parts (the breaks down into th and he, which don't necessarily take the same amount of time each).

I actually made a whole layout analyzer based on physical experimental measurements of how quickly you can type various trigrams. Some sfbs were definitely slower than others, as you predicted, but all of them were far worse than non-same-finger sequences. The highest rated layouts (with the fastest speed ceilings, therefore the least strain required to reach any given slower speed) all had SFB frequencies of about 1.2% or lower, even when the heatmaps were a bit wonky--for a while, the top scoring layout had t in the qwerty v position. But it had less than 0.8% sfb!