Halmak – AI designed keyboard layout | Hacker News Reader

Halmak – AI designed keyboard layout

github.com

94 pointsdsego59 comments

Reading through his blogs, he keeps saying that one of the advantages of his layout is intentionally alternating keys between hands, and slags colemak for being "really bad" at that.

But when I was reading up about the colemak, they claimed that was done on purpose -- that in fact, at high speeds, coordinating alternating keystrokes between hands is very difficult, and that it's actually a lot more efficient to have "rolling" patterns where a single hand can type a sequence of characters in a smooth motion. I can definitely say that the "inter-hand coordination" is the source of an awful lot of my typing errors.

Made the same observation! And the rolling patterns are better if they go from in the pinkie-to-index direction than the other way around. An example of how Halmak does not take this into account is how the h and t keys are placed. It immediately jumped out at me as a Dvorak user.

The myth of alternating-hand advantage probably dates to the era of mechanical typewriters, when hammers arriving from opposite sides of the machine were less likely to jam.

Alternating hands was certainly better for my hand joint issues. I found Dvorak not really faster, but more comfortable, and the alternating hands is a big part of that. Alternating hands is much better than consecutive keys far apart on the same hand, and way better than consecutive keys on the same finger.

Actually they were more likely to jam. They hit the same place and if you hit a left and right key at the same time, they'd invariably jam, which necessitated going in and manually prying them back free (the keys sort-of fit into each other)

>at high speeds, coordinating alternating keystrokes between hands is very difficult

It's for this reason I believe the traditionally wide spacebar should be split up into a number of different keys. Having two sets of Shift, Control, Alt, and the Windows key on either side of the keyboard seems less sensible than one set that can be accessed by either thumb.

I for example use a custom layout that splits the Spacebar into both Space and Shift. Now I don't have to shift my hands to the left/right to capitalize a letter, make an exclamation/question mark, make a double quote, etc.

I always thought splitting the keyboard and number pad so I could put the mouse in the middle would be a great optimization. Finally did it last year and ended up with tennis elbow. Turns out having my mouse pad a good distance away from the keyboard gives me a chance to stretch out my arm. That tiny bit of extra movement was crucial in not pushing my body over the limit of too much tiny movements resulting in elbow/arm pain. There are other contributors like using my phone too much in the evenings. But for sure, the keyboard change pushed me over the edge. I now view micro optimizations like this slightly differently. Maybe this keyboard layout would be great! But I sure would pay more attention and watch for negative side effects now.

The thing about computer generated layouts (as with all computer optimizations) is that it optimizes an evaluation function and not the actual process of typing. And who knows how closely your function that scores how good a keyboard is matches the physics and physiology of typing.

And why do people use pieces of perfectly written text. The Backspace key is like one of my top 5 most used keys and it's always under the pinky.

If you were to read the OP, and especially follow the links to the articles the author has written about the development process, you'd see that these shortcomings are exactly what Halmak is trying to address.

> you'd see that these shortcomings are exactly what Halmak is trying to address

It’s still all dependent on how good the authors physiological model is. If their model of hand movements is incorrect, then any generated results will be incorrect, too. For instance: the author talks about developing a model of travel distance for various keys. Fine, but (a) it’s based on their own hands, so it might not be a good fit for others, and (b) the distances are all from resting hand position, which means that as your fingerS move over the course of typing a word, those distances should adjust as well. Does the author account for this? I don’t think so, but it’s not clear.

My larger concern is that human muscle movement involves a whole lot more than just the mechanical aspect. Any model that doesn't include some notion of human perception, cognition, and voluntary muscle control seems like it could be optimizing with the wrong evaluation function.

Yeah, definitely. A layout that’s slightly worse for your fingers, but significantly easier to remember, might end up being superior overall

One extreme is PLUM, which also includes the mnemonics KJVB, WXYZ, and READONTHIS.

https://en.wikipedia.org/wiki/PLUM_keyboard

I actually feel the other way; the cost of learning a seemingly arbitrary layout is probably less than the cost of using an inefficient layout, in the longrun.

> the cost of learning a seemingly arbitrary layout is probably less than the cost of using an inefficient layout, in the longrun

It might be—but that’s no consolation if you’re less likely to get to the long run. Or if you get to the long run, find out their models were off, and realize it was extra time wasted.

In the era of swiping keyboards, Touch Bar technology, and hyper keys, it would be interesting to see an expanded project. For example, what is the optimal position and size for a dynamic OLED touch interface on a keyboard? Which keys should do something different when held? What chords are worth putting on a keyboard? It would be especially interesting if usage over time and the cost of relying on a specialized environment were factored in.

And how about software that watches you type and suggests a more keyboard-heavy workflow as your speed increases?

> For example, what is the optimal position and size for a dynamic OLED touch interface on a keyboard?

Far away.

Dunno if the author took this into account, but the fingers that do the work also matter: the index and middle finger are considerably stronger than the ring finger and especially the pinky. See e.g. the Workman layout: https://workmanlayout.org, and specifically the illustrative picture: https://raw.githubusercontent.com/kdeloach/workman/gh-pages/...

This also means that Windows/Linux and especially Emacs users are sorely screwed by the prevalence of the Ctrl key in shortcuts. Somewhat ironically, MS' Natural 4000 keyboard with its gigantic Alt keys is eye-openingly great on MacOS where those keys serve as often-used Cmd, right under the thumbs, the strongest digits. And, when Emacs was created, Control was also under the thumbs.

Also, as a bilingual, I'm pining for a design consideration that punctuation is on the same keys between the layouts in different languages.

I use a Kinesis: https://en.m.wikipedia.org/wiki/Kinesis_(keyboard)

I almost bought a Kinesis back in 2009 and in the end didn't because of the cost. I eventually got one in 2017 and now I greatly regret not buying one back in 2009. Best computer purchasing decision I ever made.

I was wondering if anyone used different switches on the same keyboard, say heavier ones like mx clears for index and middle, and browns for ring and pinky.

Cool project

Keen to know what sort of typing samples he used - was it mostly people writing prose, operating shells, other?

Imagine you'd need a fairly large and varied sample set to land good generality?

From https://github.com/MadRabbit/keyboard-genetics

"I used a series of articles from various online media. I don't have copyrights to provide them with this project, so you will have to use your own source."

and

"Create the text folder and fill it in with *.txt files which you'd like to use as the test data source. "

It would be interesting to see what a layout full of source code/terminal history would generate - although you'd have to take into consideration all variety of autocomplete functionality (tab key usage) in text editors to get accurate input data, not to mention window switching shortcuts etc.

Ah good find, thanks!

Yes, would be very keen to see what sort of result you'd get if (say) you captured keystrokes directly from a collection of engineers (or indeed a broad variety of individuals)

Might be trickier though, as I anticipate you'd need to somehow semantically separate the keystrokes into logical units. Maybe just a time-between-strokes threshold would be enough?

Weirdly, it seems[0][1][2], that the layout doesn't do particularly well by Carpalx's keyboard effort estimator[3], as it gets a total effort score of 2.260, compared to 3, 2.098 and 1.842 for Qwerty, Dvorak and Colemak, respectively[4] (lower is better). In contrast, the halmak repo claims[5] an efficiency gain of +134% over Qwerty for halmak, compared to +77% for Dvorak and +84% for Colemak. Since (one would assume) efficiency and effort should be approximately inversely correlated, these results don't square.

I have no idea whether Carpalx's or Halmak's keyboard layout (efficiency|effort) evaluator is more accurate (indicative of real (efficiency|effort)), but the huge disparity between the two is troubling.

(Obviously, Carpalx and Halmak use different optimisation methods — Monte Carlo simulated annealing versus an "evolution algorithm based AI" — and these could well give different results, even with the same scoring method, due to getting stuck in different local maxima etc., but the issue is that the scoring methods themselves give different rankings of fixed keyboard layouts.)

Edit: quickly reading through all of the halmak author's blog posts, it seems that they're aware of the Carpalx project. They describe their (current?) effort model here[6]. It seems heavily data-based, but it's still difficult to determine whether it's "better" than Carpalx's.

[0] https://gist.github.com/tdegrunt/80e63f464c9a1c336e0f1d4e6aa...

[1] https://github.com/MadRabbit/halmak/issues/4#issuecomment-44...

[2] I haven't done the analysis myself and can't be sure that it was done correctly

[3] http://mkweb.bcgsc.ca/carpalx/?interpreting_optimization

[4] http://mkweb.bcgsc.ca/carpalx/?keyboard_layouts

[5] https://github.com/MadRabbit/halmak#comparisons

[6] http://nikolay.rocks/2016-10-22-keyboard-analytics

Neat project, I've wanted to give it a try for a while but never got around to do it, great job !

Interesting that it put the comma at the same place as the bepo [1] ! It obviously recognized that vowels should be placed on the home row on a single hand, it has it on the right hand when dvorak/bepo have them on the left hand.

It'd be interesting to train it on code as well and see where it positions the special chars. I personally really like the bepo's choice of putting them on alt_gr+[right_hand_key] as it allows me to reduce finger stretches to hit them, that's what was causing me pain on QWERTY, especially with js, and convinced me to make the move to bepo. I fins lisp is BY FAR the healthiest language when it comes to fingers, though you do need shortcuts to manipulate lisp code sanely.

Is the keyboard-gentrics [2] src code the only way of knowing how this was designed ? I've skimmed the github page and blog it links but cannot find anything. It looks like its a genetic algorithm ?

[1] https://bepo.fr [2] https://github.com/MadRabbit/keyboard-genetics

Would be curious to see what happpens if we let an optimizer go wild with tye keyboard structure as well. For a while, I've been wanting to try a Dactyl:

https://github.com/adereth/dactyl-keyboard

But I wonder if the space of possibilities contains some wacky hidden gems that we are just missing.

> Would be curious to see what happpens if we let an optimizer go wild with tye keyboard structure as well. ... But I wonder if the space of possibilities contains some wacky hidden gems

These "wacky hidden gems" are not at all that wacky or hidden. Any future "AI" keyboard won't use typical letters or symbols, it would capture strokes that convey thoughts or meaning. We already have this to some degree with mobile keyboard software that turns gestures into commands and swipes into words and predictive sentences.

Considering that fingers rotate on joints instead of extending forward, and don't crook to the side while doing that, the Maltron/Kinesis/Dactyl shape and ortholinear layout are pretty intuitive. It's flat boards and the typewriter-inherited staggered layout that don't make sense in the age of plastic.

If you're going to go through the effort of redesigning a faster layout, why not fix everything from the ground up? Why design a layout with key stagger still a property when we all know that it was a relic of technological limitations that are not nor will ever be present in any future keyboards?

As a software dev, the biggest gain for me was incorporating the arrow keys under my right hand fingers via a layer switch, and having movement modifiers under the left (jump word, end-of-line etc).

I think one moves around so much in code that anythng else is micro optimization.

YMMV.

I switched to a Kinesis advantage some years ago, and the arrow keys are such a massive improvement.

I was thinking about using layers like you suggest for movements, but outside of vim where you need to shift+move to select text, isn't that going to be quite awkward?

I see yours allows for 300 keypresses in macros, that's pretty cool. I'm using the Vortex Pok3r, it only allows for 32, which is 99% okay, but I did run into this limit.

On the other hand, how do you access the macros? I can't see any special keys on it, except for maybe the `progm` key on the top right, but it is out of reach.

On the Pok3r, I have remapped the CapsLock key to be the layer modifier key, so while it is pressed, the special macro layer is active. I barely need the Caps key, so it is a minor annoyance to have lost it, but the gains are way bigger. That way, I'm using IJKL as my arrow keys. I have remapped Space to mean Shift, thus while it is pressed, I can select anything while moving around with the arrows. Also, I remapped F to Ctrl for jumping words (I'm on Windows, F stands for Fast :P). U -> start of line, P -> end of line.

It's sure not as powerful as vim, but the fact that this is available everywhere, even while I'm typing a comment on HN, totally outweighs it for me.

So nah, it's not awkward for me. Or does it come across like that?

Edit: typo

For anyone is interested, if you are on Windows, you can write an Autohotkey script to emulate this, although it will be buggy because of key shadowing (google if you don't know what it is).

I can even send my script to anybody interested to try it out. But you will really need a proper keyboard for this to work where each key has its own dedicated wire.

Mmm... good idea. I also put common marks in the middle:

http://www.keyboard-layout-editor.com/#/gists/75c4808455c07a...

(This is my main driver now)

Wow, aren't those too far to reach?

And... What is this website? I can't make any sense of it. Seems to be some powerful configuration tool to do.. What exactly? :D

Yeah, I made some design mistakes (more at https://www.reddit.com/r/MechanicalKeyboards/comments/9wjpg0...)

This site is part of a few that are used to made your own keyboard.

It looks like this makes q easier to type than w, which seems a bit strange, and wh seems particularly awkward. "What", "where", "when", "why", and "who" are all pretty common.

Looks like an inverted Dvorak

As a Dvorak user, this was my first thought as well.

What I find the weirdest with all these "efficient" keyboard layouts is that seemingly none of them ever move things to/from any of the Ctrl/Alt/Shift keys.

E.g. I find that for me, reaching for the Shift key majorly contributes to slowdowns and fatigue.

I agree and one reason I've mapped spacebar when held down to be shift.

I am surprised to see no changes to the top row of 1-0. Can we just get rid of the number keys and put them in a numpad format on the side? Sequential numbers on the top are (arguably) worse than numpad.

What is the argument for sequential numbers up top being sub-optimal?

Some issues and questions:

- Many notebook keyboards will not accommodate a number pad.

- What is the plan for !@#$%^&*()_+ and "~"?

- Where will the backspace key be located?

Not to say that I think it's particularly practical, but there is a somewhat well-established "40%" keyboard design that doesn't have a number row. They typically rely heavily on modifier keys or layer switching.

Here's an example:

https://www.amazon.com/dp/B01MS3PWS0

If you're interested in different keyboard sizes:

https://www.keyboardco.com/blog/index.php/2017/08/full-size-...

I personally use 75%, my opinion is for serious coding it's inefficient to go smaller than that.

I have used a 60% for the past 4 years or so, and have found it to be just fine for daily coding. I use VIM keybindings in my text editor, so my navigation keys are on home row and I don't need them (for non-VIM contexts, I just use FN+WASD, which is pretty effortless). I also mapped Caps Lock to ESC, since I never need that anyways, and it's more efficient. I don't think that the F-keys or Home/End/Pgup/Pgdn cluster are really critical for coding (plus the F-keys can be emulated with FN+numkeys). Obviously, some editor bindings may require those keys.

It really seems to me like the only thing you lose with a 60% is the arrow keys, and you can always go to a 65% layout if you need them. I use a 40% Planck for a while, and honestly didn't really like it much (got some strain in my pinky after a while).

> my opinion is for serious coding it's inefficient to go smaller than that.

I'd say it depends. With a "normal" layout probably true, however I found I am at least as quick with programming on my ~45% keyboard.

Mainly it's because I moved all the special characters and arrow keys down to the letters on a secondary layer. That allows me to enter anything without moving or stretching my hands, which I find very pleasant and at least feels very efficient. The layers are switched with thumb keys, so they're always accessible quickly.

For me it was the best approach(especially compared to Dvorak, Colemak etc.) because it's still fully compatible with Vim and other programs without needing to relearn and reconfigure everything. Although I must admit when I'm typing on a qwerty keyboard I always need a few minutes to get used to it again.

Have you heard of neo2? They have 6 layers, one only for programming characters and one for navigation. It's super practical.

Any layout that changes the positions of letters is super unpractical in my opinion, as it first requires many months of practice to get back to speed and then it's incompatible with many programs like Vim. Also typing on any other keyboard becomes a nightmare.

For occasional numeric entry I find the number row is vastly superior to the numpad as I don't need to move my hand.

I'm using them all the time for entry and shortcuts. Cmd + 1 for switching to the first tab/item/thing.

Even bought a tenkeyless gaming keyboard. I was having the opposite thought that we should deprecate the number pad and just leave it as an additional hardware add-on for accountants

I got an external numeric pad mostly for playing Roguelikes. :)

I've heard that pre-computer typewriters actually required the ‘shift’ key pressed for numbers, and had symbols available without ‘shift,’ so numbers as primary symbols in the top row are an invention of computer engineers. Though looking at photos of typewriters suggests differently.

You can switch the shift-behavior with some software, e.g. Karabiner for Mac.

You can also use Programmer Dvorak, where you have to use shift to type numbers instead of symbols and the numbers are laid out as in Dvoraks original keyboard, so that the index fingers are typing the most common ones 7531902468

https://www.kaufmann.no/roland/dvorak/

Available on Linux with

    setxkbmap us -variant dvp

I tried a custom layout that did that for a while. I put the arrow keys in the centre (Qwerty's y, g, h, b), I think along with some other usually far away things. Then the letters needed to extend up onto the number row, so I made the function keys the numbers, and the numeric keypad the function keys.

I used it enough to touch type at a decent speed, but I didn't keep using it for long, as at that point I was better off avoiding keyboards entirely.

Numbers only on the numeric keypad would be awfully inconvenient for programming.

As a lefthander I find using the numpad difficult as it is on the wrong side on standard keyboards. As I use more than one machine daily, having a custom reversed keyboard is not an option. As such I basically never do number entry using the numpad.

Interesting, but it suits the marginal user. Ideally, I'd want to analyze my typing patterns to tailor to that (that is, a Bayesian solution where I can supply my data)

Using the author’s projects, I believe you can make your own “effort map” and run the genetic algorithms to make your own optimal layout.

c.f. http://nikolay.rocks/2016-10-22-keyboard-analytics

how it compares to https://en.m.wikipedia.org/wiki/Stenotype ?

Colemak user: too much pinky use, Cmd+[qxz] is weird

Reply on news.ycombinator.com