8 ms·

Halmak – AI designed keyboard layout

94 points by dsego 7y ago

mkl 7y ago
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.
spectramax 7y ago
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.
- jaytaylor 7y ago
  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?
  - rococode 7y ago
    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 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-tkl-60-and-more-a-guide-to-mechanical-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.
    - dlevine 7y ago
      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).
    - alpaca128 7y ago
      > 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.
      - Gehinnn 7y ago
        Have you heard of neo2? They have 6 layers, one only for programming characters and one for navigation. It's super practical.
        alpaca128 7y ago
        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.
- andreareina 7y ago
  For occasional numeric entry I find the number row is vastly superior to the numpad as I don't need to move my hand.
- intellix 7y ago
  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
  - egypturnash 7y ago
    I got an external numeric pad mostly for playing Roguelikes. :)
- aasasd 7y ago
  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.
  - shpx 7y ago
    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/ https://www.kaufmann.no/roland/dvorak/ Available on Linux with setxkbmap us -variant dvp
- mkl 7y ago
  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.
- Jaruzel 7y ago
  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.
pentaphobe 7y ago
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?
- amadeuspzs 7y ago
  From https://github.com/MadRabbit/keyboard-genetics 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.
  - pentaphobe 7y ago
    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?
1123581321 7y ago
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?
- hcarvalhoalves 7y ago
  > For example, what is the optimal position and size for a dynamic OLED touch interface on a keyboard? Far away.
deleted 7y ago
[deleted]
clircle 7y ago
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)
- ethhics 7y ago
  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 http://nikolay.rocks/2016-10-22-keyboard-analytics
equalunique 7y ago
Looks like an inverted Dvorak
- nemasu 7y ago
  As a Dvorak user, this was my first thought as well.
Trav5 7y ago
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.
xelxebar 7y ago
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 https://github.com/adereth/dactyl-keyboard But I wonder if the space of possibilities contains some wacky hidden gems that we are just missing.
- speedplane 7y ago
  > 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.
- aasasd 7y ago
  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.
shpx 7y ago
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.
- notacoward 7y ago
  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.
  - mcphage 7y ago
    > 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.
    - luma 7y ago
      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.
      - mcphage 7y ago
        Yeah, definitely. A layout that’s slightly worse for your fingers, but significantly easier to remember, might end up being superior overall
gwd 7y ago
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.
- equalunique 7y ago
  >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.
- vages 7y ago
  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.
- networkimprov 7y ago
  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.
  - mkl 7y ago
    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.
aasasd 7y ago
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 https://workmanlayout.org, and specifically the illustrative picture: https://raw.githubusercontent.com/kdeloach/workman/gh-pages/images/usage-viz-grid2.png 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.
- rkagerer 7y ago
  I use a Kinesis: https://en.m.wikipedia.org/wiki/Kinesis_(keyboard) https://en.m.wikipedia.org/wiki/Kinesis_(keyboard)
  - dkersten 7y ago
    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.
- dsego 7y ago
  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.
kerzol 7y ago
how it compares to https://en.m.wikipedia.org/wiki/Stenotype https://en.m.wikipedia.org/wiki/Stenotype ?
aplaice 7y ago
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/80e63f464c9a1c336e0f1d4e6aa201a8 https://gist.github.com/tdegrunt/80e63f464c9a1c336e0f1d4e6aa... [1] https://github.com/MadRabbit/halmak/issues/4#issuecomment-446316468 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 http://mkweb.bcgsc.ca/carpalx/?interpreting_optimization [4] http://mkweb.bcgsc.ca/carpalx/?keyboard_layouts http://mkweb.bcgsc.ca/carpalx/?keyboard_layouts [5] https://github.com/MadRabbit/halmak#comparisons https://github.com/MadRabbit/halmak#comparisons [6] http://nikolay.rocks/2016-10-22-keyboard-analytics http://nikolay.rocks/2016-10-22-keyboard-analytics
globuous 7y ago
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 https://bepo.fr [2] https://github.com/MadRabbit/keyboard-genetics https://github.com/MadRabbit/keyboard-genetics
zupa-hu 7y ago
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.
- deckiedan 7y ago
  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?
  - zupa-hu 7y ago
    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
    - zupa-hu 7y ago
      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.
leotaku 7y ago
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.
- gedy 7y ago
  I agree and one reason I've mapped spacebar when held down to be shift.
godDLL 7y ago
Colemak user: too much pinky use, Cmd+[qxz] is weird
chansiky 7y ago
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?

94 points by dsego 7y ago

mkl 7y ago

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.

spectramax 7y ago

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.

jaytaylor 7y ago
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?
- rococode 7y ago
  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 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-tkl-60-and-more-a-guide-to-mechanical-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.
  - dlevine 7y ago
    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).
  - alpaca128 7y ago
    > 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.
    - Gehinnn 7y ago
      Have you heard of neo2? They have 6 layers, one only for programming characters and one for navigation. It's super practical.
      - alpaca128 7y ago
        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.
andreareina 7y ago
For occasional numeric entry I find the number row is vastly superior to the numpad as I don't need to move my hand.
intellix 7y ago
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
- egypturnash 7y ago
  I got an external numeric pad mostly for playing Roguelikes. :)
aasasd 7y ago
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.
- shpx 7y ago
  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/ https://www.kaufmann.no/roland/dvorak/ Available on Linux with setxkbmap us -variant dvp
mkl 7y ago
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.
Jaruzel 7y ago
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.

pentaphobe 7y ago

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?

amadeuspzs 7y ago
From https://github.com/MadRabbit/keyboard-genetics 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.
- pentaphobe 7y ago
  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?

1123581321 7y ago

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?

hcarvalhoalves 7y ago
> For example, what is the optimal position and size for a dynamic OLED touch interface on a keyboard? Far away.

deleted 7y ago

[deleted]

clircle 7y ago

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)

ethhics 7y ago
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 http://nikolay.rocks/2016-10-22-keyboard-analytics

equalunique 7y ago

Looks like an inverted Dvorak

nemasu 7y ago
As a Dvorak user, this was my first thought as well.

Trav5 7y ago

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.

xelxebar 7y ago

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 https://github.com/adereth/dactyl-keyboard But I wonder if the space of possibilities contains some wacky hidden gems that we are just missing.

speedplane 7y ago
> 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.
aasasd 7y ago
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.

shpx 7y ago

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.

notacoward 7y ago
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.
- mcphage 7y ago
  > 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.
  - luma 7y ago
    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.
    - mcphage 7y ago
      Yeah, definitely. A layout that’s slightly worse for your fingers, but significantly easier to remember, might end up being superior overall

gwd 7y ago

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.

equalunique 7y ago
>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.
vages 7y ago
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.
networkimprov 7y ago
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.
- mkl 7y ago
  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.

aasasd 7y ago

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 https://workmanlayout.org, and specifically the illustrative picture: https://raw.githubusercontent.com/kdeloach/workman/gh-pages/images/usage-viz-grid2.png 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.

rkagerer 7y ago
I use a Kinesis: https://en.m.wikipedia.org/wiki/Kinesis_(keyboard) https://en.m.wikipedia.org/wiki/Kinesis_(keyboard)
- dkersten 7y ago
  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.
dsego 7y ago
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.

kerzol 7y ago

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

aplaice 7y ago

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/80e63f464c9a1c336e0f1d4e6aa201a8 https://gist.github.com/tdegrunt/80e63f464c9a1c336e0f1d4e6aa... [1] https://github.com/MadRabbit/halmak/issues/4#issuecomment-446316468 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 http://mkweb.bcgsc.ca/carpalx/?interpreting_optimization [4] http://mkweb.bcgsc.ca/carpalx/?keyboard_layouts http://mkweb.bcgsc.ca/carpalx/?keyboard_layouts [5] https://github.com/MadRabbit/halmak#comparisons https://github.com/MadRabbit/halmak#comparisons [6] http://nikolay.rocks/2016-10-22-keyboard-analytics http://nikolay.rocks/2016-10-22-keyboard-analytics

globuous 7y ago

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 https://bepo.fr [2] https://github.com/MadRabbit/keyboard-genetics https://github.com/MadRabbit/keyboard-genetics

zupa-hu 7y ago

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.

deckiedan 7y ago
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?
- zupa-hu 7y ago
  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
  - zupa-hu 7y ago
    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.

leotaku 7y ago

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.

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

godDLL 7y ago

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

chansiky 7y ago

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?