I'm almost 40 and learning my first alt layouts. We all learn at different rates but just sharing my time with it

After a bunch of digging on this sub and chatting with Claude, I went with Graphite but I left comma, period, and slash from QWERTY. Using a chocofi keyboard.

Keybr settings set to 25wpm to unlock new letters and where each word appears 3 times to help with building new muscle memory.

After about 15-20 mins a day for 11 days, all letter placements are memorized and I use it at work when I'm not pressed for time since my overall wpm is low 20s.

I'm slow as fuck but enjoying it.

going to increase the wpm required to unlock letters and repeat the keybr practice stuff until I'm at 40-50 better I completely switch over to it

I've bought this keyboard on vinted recently but I can't find the layout that corresponds to my keycaps I need your help.

The brand seems to be a Ajazz x nacodex Collab but the model I don't know. It's wireless.

I'm moving from traditional qwerty keyboard to an alt layout on a Glove80 and after some reading planning to use 34-key layout and probably Urob's homerow mods (any other "timeless" homerow implemention or successful non-homerow mods to consider as well?).

However, my workflow is heavily keyboard-driven with apps like tiling window manager, tmux, fzf, terminal, neovim, emacs (org-mode), etc.--maintaining it for keyboards of different keys to optimize for both might be a wreck.

I'm thinking ideally I would have a 34-key keyboard to use everywhere, but I'm wondering: do you guys still use builtin laptop keyboard often? Do you optimize its traditional keyboard layout which could make it very different than the split layout variant or do you trade ergonomic layout for less cognitive overhead by simply using your split layout mappings where possible? Trying to find a good balance between ergonomics and cognitive overhead. I also wonder if e.g. if one switched to an alt layout whether they can use a qwerty keyboard productively if they need to once in a blue moon (say once every 1-2 years).

At the moment I'm thinking of optimizing only for the split layout and re-use it as much as possible for the laptop. Not sure whether to still use homerow mods on laptop though or to keep it traditional only. I thought about low-profile 34-key keyboard that I can use as both desktop and laptop but I think I might value the ergonomic aspect of a concave keyboard and would probably want a different split board for the laptop (something like a Toucan which has a touchpad but a better implementation of the touchpad and without the display screen, maybe).

I want to share with you all that my new keyboard just arrived. I made an initial video and later I'll make a video to show how it fits in my setup:

https://www.youtube.com/watch?v=Ca7zK0NLyV8&t=262s

I wanted something better than a basic keyboard but didn’t want to spend too much, so I ended up getting the Aula F75.

So far it’s been good. Feels solid, sounds nice, and typing on it is way better than on the random keyboard I was using before. I use it for work, browsing, and a bit of gaming, and it’s been doing the job.

Main thing is it doesn’t feel cheap. That was the part I wasn’t sure about before buying it, but once it was on my desk that worry was gone pretty fast.

Nothing life-changing, just a good keyboard for the money.

If anyone else has one, curious how it’s been holding up.

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.

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

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.

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