r/KeyboardLayouts

I was a die-hard MessageEase fan for years, but the move toward monthly subscriptions was a dealbreaker. I couldn't go back to cramped QWERTY keys, so I built Tessera Keyboard to revive that 3x3 flow, preserving the one-handed efficiency of the original while adding modern power gestures like Undo, Redo, Find&Replace. I also took the opportunity to give the classic design a fresh, modern coat of paint to better match today's mobile aesthetics.

So far there was no structured overview of keyboard input mechanisms. In my opinion understanding some basic concepts and outlining them in an overview can be highly valuable for anyone trying to find or create his personal "best" keyboard solution:

https://rpnfan.github.io/keyboard-heaven/deep-dive/keyboard-input-methods/

The core idea is a distinction between three categories of input mechanism that I think is often overlooked, or at least rarely made explicit:

• Free-timed — the timing window is controlled by your own physical action; output is always predictable
• Threshold-timed — the firmware or OS has a fixed invisible deadline; misfires are possible; you need to match your typing speed to the time-window or vice versa
• Context-aware / adaptive — the system watches your typing and modifies behavior automatically

Knowing which category a mechanism falls into immediately tells you what its tradeoffs are: reliability, latency, cognitive load, and learnability all follow directly from the category.

More explanatory text is coming, but the tables are already useful if you are trying to decide which approach fits your setup. They cover QMK, ZMK, Kanata, Karabiner-Elements, and all three major operating systems natively.

Feedback and corrections very welcome.

Hi! I made a small Python tool called KeyRecord.

I’m thinking about switching to a 60% keyboard, but before doing it I wanted to check if I actually use all the keys on my current keyboard, or if I only think I do.

The tool records my real key usage locally and helps me see which keys I use the most, which ones I barely touch, and whether moving to a smaller layout makes sense for me.

It does not connect to the internet, it does not upload anything, and it does not save words, sentences, passwords or text content. It only counts key presses locally.

Right now it supports ANSI and ISO Spanish layouts, because those are the ones I tested, but adding other layouts should be simple.

It’s mostly a personal experiment, and also a way for me to learn GitHub properly: commits, README, releases and documentation.

For people using smaller keyboards or custom layouts: what stats would be useful before switching to 60%?

Key frequency? Modifier usage? Shortcuts? Per-app usage? Layer planning?

GitHub repo:

https://github.com/adriaabad/keyrecord

I created a program Zero Reach Typing that allows you to type without removing your hands from the home row on a standard keyboard. It's a paid program. It's only useful for those who can already touch-type. If you can't, I've also posted a free touch-typing training program on the same website. Both programs are for Windows. Zero Reach Typing

I should probably preface this by noting that I haven't learned an alternative keyboard layout. I'm just going to show some visualizations that I made while considering how to go about learning a layout. I was inspired to do this while looking at the Norman layout site and following up on a mention of Minimak. Minimak's creator makes a good case that learnability matters, so Minimak has a three-stage learning process, each moving four keys around. I wanted to see if something similar was possible for Norman and other keyboard layouts.

To do this, I created a diagram of the remapping process. Essentially, I just made a list of where each key would move to on QWERTY. By making a diagram where each key points to the key it will move to, you can see whether there are any natural, distinct subsets that could be tackled independently. So long as we're just rearranging keys, the diagram will always consist of one or more closed loops.

Technical aside: I made the diagrams using Graphviz. The list of key movements become edges in a directed graph. Feed that into Graphviz (I used an online version), and you've got a diagram that shows how to define learning stages, without much effort.

Norman is quite amenable to a multi-stage process. The diagram shows four cycles: two 2-key swaps, one 5-key cycle, and one 6-key cycle. A feasible three-stage learning approach would be to learn the two swaps, then the 5-key cycle to position R and T, and finally with the 6-key cycle that cleans up the right hand keys.

For someone who has trouble with the longer cycles, the first stage for Norman isn't as attractive of a stopping point as Minimak's first stage. But instead of stopping with just stage 1 for Norman, one could instead go to SwapSix, since the two swaps are used there, as well. Alternatively, some minor changes to Norman can break the longer cycles, for example, swapping P and N on the Norman layout would turn the 6-key cycle into two 3-key cycles, which might be more manageable.

Colemak, on the other hand, doesn't admit a useful set of cycles, consisting instead of a 3-key cycle (L, U, and I) and a 14-key cycle. There aren't particularly useful stages here: the short cycle doesn't have the high-frequency letters, and the long cycle is not too different from the full set of changes.

I've read about Tarmak, which gives learning stages by repeatedly moving the J. You can see the Tarmak stages in the Colemak visualization. Start at J. You can either go forward or backward along the loop, taking a few characters at a time. If you go backwards along the loop, you get all the Tarmak stages, in order:

1. J > E > K > N
2. J > G > T > F
3. J > R > S > D
4. J > Y > O > ; > P

It makes sense to use J as the pivot for Tarmak, because it's a low-frequency character. We can use the visualization of the cycle to consider other options, too, by seeing what lies next to other low-frequency characters. There's moving forward starting from the semicolon, which doesn't seem as promising, but would support something like running Tarmak in reverse:

1. ; > P > R > S
2. ; > D > G > T
3. ; > F > E > K
4. ; > N > J > Y > O

There's also a version based on following the loop backwards from K, which positions both T and E in the first stage:

1. K > T > F > E
2. K > S > D > G
3. K > ; > P > R
4. K > N > J > Y > O

Just looking at the loops won't tell you if a sequence of stages is well chosen, of course. The most obvious is that following the cycle in one direction might not move high-frequency keys into position; following the loops in the opposite direction from what I showed above tends to do that. You might have a stage that causes problems because of combinations with other keys that haven't moved; I don't have an example of that, since this is all pretty hypothetical for me.

So what does a “perfectly fair and equal society” look like… for keyboard layouts?

Yeah, I know, that sounds dangerously philosophical for a keyboard subreddit. I swear this started as a technical problem, not a political manifesto 😄

I’m not into politics at all. In fact, I actively avoid it. But at some point, to separate subjective preference from objective reasoning, I ended up borrowing political metaphors to describe what my typing model is trying to do.

Figure 1 shows the result from my original, simple, straightworward, heuristic-based, definition: Using a corpus that is 100% English, on a standard 4-row × 10-column keyboard, and restricting the analysis to the 4 most popular layouts (QWERTY, QWERTZ, AZERTY, Dvorak), the model reconstructs the following “bridge population” between the real-world dataset and the fully uniform thought population:

- Dvorak: ~44%

- QWERTY: ~17%

Figure 2 shows the result using a definition proposed by Claude AI:

- Dvorak rises slightly to 46%

- QWERTY drops to 12%

So the numbers are not radically different. From the very beginning, my intuition was that a “reasonable” distribution should look something like:

- Dvorak ≈ 40%

- QWERTY / QWERTZ / AZERTY sharing the remaining 60%

But the important difference is qualitative, not numerical. Claude’s formulation is simply more _scientific_. It emerges more from accumulated knowledge over objective facts than from personal opinion or intuition.

What the model is trying to describe is an “ideal population”: an infinite world of users evenly distributed across the enourmous set of all possible layouts and all possible languages — or more precisely, across random character sequences.

That hypothetical population becomes the neutral environment where typing speed on any layout and any language can be estimated fairly and compared meaningfully.

What surprised me most is that Claude’s argument actually survived pretty aggressive criticism from GPT-5, plus additional challenges from Gemini, GPAI, DeepSeek… and even me trying to poke holes in it.

Knowledge-wise, I’m basically the student here. But in this weird academic AI debate, I wasn’t exactly the student, and Claude wasn’t exactly the professor either.

I was more like… a debate moderator armed with too many language models.

I used one AI’s criticism to push another AI into refining its ideas.

Not to manipulate them — I wasn’t trying to “win” for my own theory.

I wanted the most correct answer possible, even if it destroyed my original assumptions.

If I had to force the political metaphor one last time:

- I’m the public

- Claude is the executive branch

- GPT-5 is the judiciary

- The other AIs are the legislature

A chaotic government, but surprisingly productive.

There are still weeks of arguing ahead over details, wording, definitions, and edge cases. But mathematically speaking, the core definitions and theorems are now in place.

The debate has basically settled.

The AIs reached consensus.

This post was translated into English in free style by an AI.

#ArtificialIntelligence

#KeyboardLayouts

#Dvorak

#StatisticalModeling

#EntropicInference

Hello everyone. You can learn touch typing without spending time on lessons, just while you're working on your computer. The free program Transparent Keyboard displays an image of the keyboard on the screen and shows the key you pressed. If you know your fingers are on the home row keys (the keys with frames in the image) and can see the image of the keyboard, you can type by sliding your finger, using the image as a guide. The xml folder contains layout files that can be edited if desired. video. Transparent keyboard

I want to install non-angled Gallium v2 on Windows 11.

I first tried installing from https://github.com/GalileoBlues/Gallium but the keys did not match what i found at https://layouts.wiki/layouts/2023/gallium/ .

Then I found discord saying bottle139 has a fix but when I installed https://github.com/bottle139/Gallium, it says the layout is unavailable. Also, windows security tools kept trying to block me from the unverified publisher.

I then found https://www.reddit.com/r/KeyboardLayouts/comments/1posoxx/i_am_struggling_to_download_galliumgraphite_and_a/#:~:text=If%20you%20want%20to%20use%20the%20default,then%20download%20the%20Gallium%20V2%20KLC%20from but that seems like a major hassle. I'm not even sure if the Microsoft Keyboard Layout Creator works on Win11 and it also needs .NET Framework 3.5.

Do I have a better option than Katana? The documentation is not easy to read. I think it requires keeping the app open the entire time which is ugly.

I'm using the MK1300 V2 Ant Esports keyboard and I'm unable to type the "/" (forward slash) character.

I've tried different key combinations but can't seem to figure it out. Can anyone who uses this keyboard tell me how to enter "/"?