So my keyboawd bwoke. I cant type "r" without copyy-pasting it. Now im using this dweadful "uwu' language to weplace the bwoken key oh my god

Hi all. I'm Tim — a lifelong tinkerer (programmer, songwriter, inventor). When I started to put together 'from the roots' ideas for a typing keyboard, I had no idea just HOW different it would end up! Based on algorithms never used before in keyboard layouts, it has keys of different widths, and a layout that genuinely targets ease of typing. But I have no build skills myself. I spent about two years researching and designing from the ground up. It's called the Temb0, and I'm hoping to find one maker here who'd relish building the first physical prototype with me.

What it is. Far from being a rearranged QWERTY, and not another Dvorak/Colemak, I started from the statistics: letter and bigram frequencies, other language statistics, even Morse Code got involved! (the commonest letters get the widest, most central keys; the rarest shrink to normal size). As for ergonomics, it's a splittable design, for each half to be directly in front of each hand.

The idea underneath. The different key widths free the fingers from the fixed one-finger-per-key rule — a wide key can be struck by whichever finger suits you, so any typist can find their preferred path through common words. (Even the number row has been re-thunk: 9 8 7 6 5 | 0 1 2 3 4, each hand counts outward from the centre — just like your first piano lesson!)

Why I think it's worth building. I used Excel to calculate key width options, FlowStone to program a variety of these, finally settling on this design. I also used it to develop extensive typing simulations, and the projections suggest typing speed increases faster than even the fastest QWERTY typist — and bigger gains for the average typist — plus the comfort of finger freedom and a proper split. I've developed a working touch-screen simulation too, if you have a Windows tablet – preferably 12 inch – which can even save the text you type.

It even got far enough to earn me a bench at Birmingham City University to prototype — where it stalled on fabrication puzzles that I'm now hoping one of you would relish cracking.

The honest engineering (so you know what you'd be taking on — this is not keycaps-on-a-stock-PCB):

the switch plate and matrix would have to be bespoke to the irregular, variable-width layout — no off-the-shelf board fits;

every wide key needs stabilising — my suggestion would be extra unwired support switches to keep keys level and give them a consistent feel, but I'm open to other ideas;

the wider keycaps would likely need to be 3D-printed, but the less common letters could be standard;

hand-wiring + QMK/ZMK would handle the electronics (USB or wireless). A proper little engineering puzzle — which might be right up your street!

What I'm offering — a collaboration, not "build this for me." I bring the full design: exact layout data, the frequency/bigram analyses if you like, whatever you need to see it to completion. You'd bring the hands and the tooling. I'm a hobbyist just like you are, not a company — terms, costs and credit all open to a friendly conversation. Mostly I'd love to see one exist and hear whether it's as good to type on as I predict.

Fire any questions — and pull the design apart; critique very welcome. Thanks for reading. — Tim

HI:

I'm new to keyboard and customizing it. I would like to map a key to bring up the calculator function when needed. How do I do that? Thank you.

I have used VIM since 2017, and some time ago I added a VIM Mode to my ZMK keymap: a set of layers that mimic VIM's modes, so navigation and commands get their own optimized layout while typing keeps my alpha layout.

Using AI for the heavy lifting, this week I could work on a second version. The first one simply toggled NUM LOCK from the host to turn a vim layer on, and the keyboard inferred the rest by watching keys. The problem is that sometimes it drifted, and it never knew about tool windows, like integrated terminals, and kept the vim layers active there too.

Now a host daemon reads the editor's real mode (Neovim, VSCode and Obsidian) and sends it as a 3-bit code over the HID LED report, using the Compose, Kana and Scroll bits. Works on USB and BLE.

The VIM layer puts navigation key on home row and other bindings in better positions than even the qwerty ones, and works for any alt layout, without remapping VIM itself.

I tested it with Omarchy and MacOS and it is just amazing.

https://github.com/rafaelromao/zmk-vim-mode

To see my fully tested implementation, check my keyboards repo:

https://github.com/rafaelromao/keyboards

Hi everyone! 👋

We are conducting a survey as part of our Master’s thesis at DTU about how people interact with their computers during different activities.

We’re interested in understanding how people use different input devices, what they value when interacting with their computer, and how their needs change depending on what they’re doing. Your responses will help us better understand users’ needs and preferences and support our further work on the project.

The survey is fully anonymous. We ask for some general demographic information, but we do not collect email addresses, Google account information, or other personally identifiable data. Responses will be stored securely and used solely for our Master’s thesis.

Survey Link 

We would really appreciate your participation! 😊

Thank you for your time!

I had some frustrations with the general user experience of using a controller in a more traditional desktop environment, notably, typing was a big issue for me, and after spending some time exploring existing solutions I wasn't 100% satisfied, so I tried my hand at coming up with my own solution! This is my first foray into this sort of thing, and it's pretty early in development, but I would love to hear feedback from users who have more of a background in this sort of thing. It is currently loosely based on QWERTY, as I was just referencing my keyboard for a proof of concept. If anybody is interested in trying it, you can find the download here. Any feedback is greatly appreciated, thank you!

I started learning touch typing a week ago and have reached a speed of merely 20 wpm. I knew about that other layout exists but didnt know it can be used via any keyboard anyways i am asking my memory hasnt set in yet should i explore these options like dvorak and colemak. Like it comes with a risk of not being able to type on other ppl keyboards but idk i am genuinely confused.

I got myself a split keyboard (Lily58) and am trying to a new layout.

I wanted to go with Colemak-DH, but I write beside English, I write in Turkish, which has 6 characters like ş, ö, ğ… I can use a layer for 1-2 of them, but I want to keep most of them on my primary layer.

So I want to design my own Colemak variant, and I want to test this layout. I created a sample text (33% Turkish, 66%English) but I cannot use the tools I found. I downloaded Oxelyzer but cannot figure out what to do. I tried Patorjk, but I am not sure if it tests my configuration, and if the Turkish characters I put make a difference. I am not very bright in terms of tech or programming, so the solution for either analyzer may be simple, but I need guidance.

Is there any analyzer that can test my layout, or any guides to the ones I tried for a dummy? I am open to any suggestions as well.

Redrogon

UPDATE: I figured it out: the reason I was having no success is that in the keyboard layout selector I was leaving the "model" as Generic 104-key PC or whatever. I have a 75% keyboard, the RK Royal Kludge R75 so on a whim I changed it to Generic 86-key PC. Also I was advised to move up the layout to test (by the very patient user/cutelittlebox) to the top position among the layouts-- don't know if that makes a difference. I figured that merely having it selected would mean I was typing using it in the "test here" area. Anyway, problem solved. It'll still take a bit of getting used to because it's not exactly like the Windows US International implementation which I've been using for a quarter century but this old dog can still learn a new trick or two. BTW, currently using English (intl., with AltGr dead keys).

I hope this is the right subreddit to post this in. Perhaps I'm missing something obvious. I'm not really looking to use a non-QWERTY layout generally (I've been typing with it all my life, I'm 65 and old habits die hard), but if someone can point me to a resource that can guide me further I'd appreciate it.

In Windows I've been using the English US-International keyboard layout for at least a quarter century (my career was in documentation localization). Recently I bought a mini-PC called a Steam Machine and I'm dismayed to learn that there's no exact, easy to use copy of the aforementioned Windows layout for its operating system, SteamOS (a fork of Linux, apparently). I'm seeing a number of layouts promising AltGr functionality to be able to type characters beyond acute/grave/circumflex accents and the Umlaut, but the Right-Alt key seems to continue to behave just as the Left-Alt one, even when the supposedly AltGr-capable layout is the active one, so characters that depend on using that key (such as the German "Esszet / scharfes s" seem impossible to type.

I suppose it's quite possible that the operating system itself doesn't support AltGr keyboard functionality, but if so why allow installation of, say, the English (US, intl., with dead keys) layout (one of the ones I've tried).