[HN Gopher] The T-34 keyboard layout
       ___________________________________________________________________
        
       The T-34 keyboard layout
        
       Author : lawn
       Score  : 47 points
       Date   : 2021-06-07 10:44 UTC (12 hours ago)
        
 (HTM) web link (www.jonashietala.se)
 (TXT) w3m dump (www.jonashietala.se)
        
       | k2enemy wrote:
       | Just an FYI if the author is here. Benford's law applies to the
       | leading (most significant) digit of numbers, not all digits.
       | 
       | Nice article and analysis though. I recently built an Iris with
       | low profile keycaps and absolutely love the feel of it. But it
       | now sits on a shelf because it made working on other computers
       | too confusing.
        
       | sirodoht wrote:
       | Side note: awesome body font :) Used to have the same one in my
       | website.
        
       | codethief wrote:
       | > Nothing special going on with the function keys. Having them on
       | the same positions as numbers makes them easy to learn, which is
       | important for me as I almost never use them.
       | 
       | Unfortunately, most manufacturers of ergonomic keyboards seem to
       | think along the same lines, so they omit the corresponding
       | hardware keys and argue that you could always put the function
       | keys on another layer if you really need them. I, however, use my
       | function keys hundreds of times a day (mainly to switch
       | workspaces) and I do _not_ want to have press an extra key every
       | single time.
       | 
       | The key principle I follow with all my key bindings is this: The
       | more often I use a certain functionality, the more accessible it
       | needs to be, i.e. the less work (or, literally, _input_ ) it
       | should require in order to avoid putting needless strain on my
       | fingers and wrists. (I have suffered from RSI in the past.) In
       | particular, oft-used commands[1] should be available through a
       | single key (or a very short and accessible[0] key chord) if
       | possible. Unfortunately, the most common set of key bindings
       | (Vim/Emacs/IntelliJ/...) usually violate this principle.
       | 
       | Long story short, this is the single reason why I haven't bought
       | an ErgoDox/keyboardio/... so far.
       | 
       | Also, I don't think it really matters whether personally one uses
       | a key X or not. In my experience, you can never have enough keys!
       | And you will find an application eventually - provided the key is
       | in the right place ergonomically speaking, i.e. easy to reach.
       | 
       | [0]: The more often I use a key chord, the stronger the fingers
       | should be that push the individual keys - e.g. the thumb, index
       | and middle finger.
       | 
       | [1]: Commands, in turn, that are used only rarely should actually
       | not be available through a key binding at all - no one remembers
       | them and they only clutter the key binding space and cause
       | confusion when you do (accidentally) hit those keys. Instead,
       | those commands should be accessible through a searchable command
       | palette. (Think Shift-Shift in IntelliJ.)
        
         | neurotrace wrote:
         | > Long story short, this is the single reason why I haven't
         | bought an ErgoDox/keyboardio/... so far.
         | 
         | I don't really understand this conclusion. The point of these
         | programmable keyboards is you can make them as work-free as you
         | need. If you hit your function keys all the time, you can make
         | the number row produce a function key just by holding it for a
         | little longer or do like what OP did and make number chords
         | match a function key. Press 1+2 to get F1, 2+3 to get F2, etc.
         | 
         | I understand not wanting to use a layer for everything which is
         | why I don't care for ultra minimalist boards like the T-34 or
         | Plank but an Ergodox has plenty of keys for my uses.
        
         | Jenk wrote:
         | The entire purpose of these layouts is to reduce movement to
         | keys you most use. If you really are using the F-keys hundreds
         | of times a day then it very much is in your ergonomic interest
         | to bring those keys closer to the home row to make accessing
         | them easier than stretching out for them.
        
         | fouric wrote:
         | > In particular, oft-used commands[1] should be available
         | through a single key (or a very short and accessible[0] key
         | chord) if possible.
         | 
         | Wouldn't a _real_ ergonomic keyboard (i.e. Dactyl-Manuform or
         | Squeezebox) with thumb clusters fit this bill? Those put the
         | modifier keys on your thumbs, so a two-key chord (layer mod +
         | main key - > function key) should be relatively "short and
         | accessible", at least by my standards.
        
         | hsbauauvhabzb wrote:
         | If function keys switch workstations you're either violating
         | your own rule or don't use workspaces enough.
        
       | CarVac wrote:
       | I'm always saddened by how few thumb keys many of these ergo
       | boards have in comparison to the Mitosis layout, which lets me
       | entirely avoid having anything but the most basic momentary
       | layers, with no tap-dancing, latching, long-press-does-something-
       | different, or chording.
        
         | fouric wrote:
         | I think that the Manuform's thumb clusters, while having
         | slightly fewer keys (6 per hand vs 8), are more ergonomic than
         | those of the Mitosis, due to allowing the thumbs to use their
         | stronger movements (curling in vs. moving laterally).
         | 
         | But, more generally, I agree - there's very little excuse for
         | not having thumb clusters if you're trying to build an
         | ergonomic keyboard.
        
           | CarVac wrote:
           | Obviously the 3D sculpting of the Dactyl Manuform can be
           | better than a 2D layout, but the distinction I find in the
           | Mitosis layout is the fact that the main thumb keys are two-
           | tiered, letting me use one thumb to hit both shift and the
           | number layer key simultaneously, or one at a time.
        
       | barry27 wrote:
       | To achieve goal A I must first achieve goal B, which requires
       | goal C, etc. Turtles all the way down. Just get on with it qwerty
       | style.
        
       | geniium wrote:
       | Interesting, but that must be hell to learn using that new multi
       | layered layout.
        
         | 1MachineElf wrote:
         | Not plugging to promote it, just to call attention to a design
         | pattern I used in my 34-key layout (same number as the
         | author's) that made it less hellish to learn (albeit, one has
         | to know dvorak, but it's probably adaptable to something more
         | intuitive.) The layout has two layer keys that can be used
         | together to switch between 4 layers in total, with the default
         | one being dvorak alphas, the left one being Mods for modifiers,
         | the right one being Nums for numbers, and combined Mods and
         | Nums for extra modifiers. Here's an except from the readme:
         | 
         | Hold Mods + Tap E = Enter
         | 
         | Hold Mods + Hold Nums + Tap E = Escape
         | 
         | Hold Mods + Tap B = Backspace
         | 
         | Hold Mods + Tap D = Delete
         | 
         | Hold Mods + Tap T = Tab
         | 
         | So I found this was very easy to adapt to because the most
         | important modifiers are in places that are very intuitively
         | memorized. It's something to consider if you want to go down
         | this road.
         | 
         | Link:
         | https://github.com/1MachineElf/qmk_firmware/tree/_sb4dv/keyb...
        
       | DavidVoid wrote:
       | Always cool to see people make their own layouts. Those chords
       | are quite a neat feature.
       | 
       | If you want to try something that's a lot more chord-based and
       | which uses even fewer keys (basically just 23 keys), then I'd
       | recommend downloading Plover and learning Steno. It takes quite a
       | while to learn, but once you do it's very comfortable and can be
       | very fast.
       | 
       | Here's steno on a hobby machine at 202 WPM for example:
       | https://www.youtube.com/watch?v=APT7SN1iof8
        
         | sdfin wrote:
         | Does is work for programming? and does it work for typing in
         | different languages?
        
           | DavidVoid wrote:
           | > Does it work for programming?
           | 
           | Yes, you can customize your dictionaries as much as you like
           | and add common words/symbols that you use in programming, and
           | there are decent options for writing in camelCase etc.
           | There's also Emily's symbol dictionary which is good for
           | writing various symbols [1], here's a poster showing all the
           | symbols available in it [2].
           | 
           | > does it work for typing in different languages?
           | 
           | Yes. As long as there's an existing steno theory for the
           | languages you want to use, then you can download those
           | dictionaries and learn those theories. But if there isn't an
           | existing theory/dictionary for a language then you can just
           | use fingerspelling instead [3] (i.e., write letter by letter
           | like on a regular keyboard), although that's ofc much slower
           | than regular Steno is.
           | 
           | [1] https://github.com/EPLHREU/emily-symbols
           | 
           | [2] https://steno.sammdot.ca/emily-symbols.png
           | 
           | [3] https://steno.sammdot.ca/plover-fingerspelling.png
        
           | MivLives wrote:
           | The dev of it uses it to code the program itself.
        
       ___________________________________________________________________
       (page generated 2021-06-07 23:01 UTC)