That’s true. I adapted to Dvorak much quicker than I expected, and it’s always easier to change habits than you think.
Agreed, the kinesis rubber keys are bad and always annoy me.
2 Likes
The problem with the way the Kinesis Dvorak works is that the keycaps only apply to the internal firmware Dvorak mapping, and which requires you to leave the OS in Qwerty mode. If you leave the Kinesis in Qwerty mode and apply Dvorak in the OS you get a completely different mapping. On the other hand, if you leave the OS in Qwerty mode you cannot remap the kinesis to any language mapping that has keys which don’t exist in Qwerty (i.e. anything other than English). This is a fundamental limitation of firmware remappings.
The problem here is that we are conflating the physical layout of keycodes and the logical mapping of keycodes to glyphs. All that a firmware remapping can do is rearrange the keycodes. It can’t invent new keycodes because the OS won’t be able to interpret them. So if one is a non-English speaker one must be able to use the OS multilingual key mappings that use the standard keycodes. That places strict limitations on the physical layout, because a physical keycode must be usable under all possible mappings.
For example, the key to the right of “P” on Qwerty (or Dvorak) is a symbol key. One might think it harmless to move this elsewhere, but on most non-English keymaps this key is a letter key. You can’t simply move it to some random part of the keyboard; it has to stay to the right of “P”. To take an extreme example, Hungarian uses all five of the keys to the right of “P” and “0” as letters. This is obviously impossible for the model 01, but it does remind us that moving any key to a non-traditional position has a cost.
The following physical layout moves the least number of keys, and by a minimal amount. The only symbol key that changes hand is “”. I’ve shown it with both Qwerty and Dvorak keymaps, but it should be stressed that this is the same firmware layout; only the OS keymap changes. I have applied several other OS keymaps to this layout (French, German, Italian, Scandinavian and Hungarian) and found them reasonable – although I would prefer native speakers to confirm this (Hungarian is admittedly a stretch).
Qwerty: http://www.keyboard-layout-editor.com/#/gists/cc98ebfc32a81b089de852df4e383b48
Dvorak: http://www.keyboard-layout-editor.com/#/gists/2185a92906220de44aff3290c2c92276
If the standard Dvorak layout is suboptimal then fine – go ahead and update it. But update it the same way Colemak did, i.e. by using the OS remapper. Firmware is not the place.
3 Likes
This is where a mixed mode can do wonders: for symbols that exist on QWERTY, just use them as-is. For symbols that do not, use something like a Compose Key, and macros. For example, to input accented Hungarian symbols like Ű, on both Windows (with wincompose installed) and Linux, I can do AltGr, =, Shift+U to arrive at Ű. I programmed my firmware to send this sequence whenever I want to input the symbol. This way, the OS layout stays in QWERTY, and inputting other symbols is still reasonably easy. (For the record, I’m Hungarian, and I type a reasonable amount of Hungarian text on a daily basis, using QWERTY OS layout, and Dvorak in the firmware.)
If your OS supports Unicode input, you can even use that. I have a couple of keys that input λ and similar for me, using features natively provided by the operating system, all while the OS mapping stays on QWERTY.
While you can’t invent new codes, you can use features of the OS that help you input symbols for which there are no keycodes. But yes, we are indeed conflating physical and logical mapping. As far as labels are concerned, the logical mapping does not matter much at all.
This is mostly true. With a compose key, you do not need to change the OS layout, but that only works for some languages, like Hungarian. You do require some kind of assistance from the OS, be that a language-specific layout, a compose key, or unicode input.
Yet, one set of labels will not ever fit everybody. I think that - like most keyboards out there - having English labels is a compromise we have to make. Otherwise the labels would have to be localized for each language, and that’s not really scalable, or even viable in the context of an ergonomic keyboard.
The keyboard firmware can be reprogrammed in any way, even to assume a different OS layout than QWERTY. But for the best plug-and-play experience, having it default to QWERTY is the safest bet. That’s what most other keyboards that have a Dvorak layout do (TypeMatrix does that, Kinesis, and ErgoDox EZ too, and so on…).
While I disagree here, what the firmware does, and what is printed on the keycaps is very different. We can have a set of symbols on the keycaps, and two different layers: one that inputs the symbols on the keycaps assuming a QWERTY OS layout, and another that assumes a standard Dvorak OS layout. The keycaps are the same, but the keycodes being sent to the host are very different, but this does not affect the labels.
So in this sense, behaviour, and what keycodes are sent, does not matter. That’s a problem to solve on the firmware + documentation side, not on the “What to print on keycaps” side.
And now we’re conflating printed keycaps with both layout and keymap. 
Printed keycaps are a courtesy. Yes, we will have to make do with a small number of printed keycaps, and English/QWERTY, English/Dvorak and/or English/Colemak are probably the best choices. But that’s not my argument.
My argument is that the layout of the keycodes should be such that it is possible to apply a keymap in the OS that does not match the printed keycaps (say, if I am a French touch typist) and for the keyboard to behave reasonably as a result. Not perfectly, as the novel geometry imposes limitations, but it should be maximally usable.
Ah, I see. Sorry for the misunderstanding. I’ll have to think a bit more about these scenarios. For now, I’m still on the opinion that the firmware defaulting to expect an English QWERTY layout is the lesser evil, but you made me uncertain.
I couldn’t agree more… and would want to take it a step farther. As a programmer, my IDE requires tons of modifier chords (Ctrl+Shift, Ctrl+Alt, Alt+Shift, and the dreaded Ctrl+Alt+Shift). This is the biggest cause of typing discomfort for me. Minimally, I need to do all those chords on one hand, without major contortions, while typing the modified key on the other hand.
I’ve envisioned a layout where, on say the left hand, you use a thumb key that changes the layer of the left hand such that the Ctrl, Alt, and Shift keys are mapped to the home keys of the index, middle, and ring fingers. Thus chording of the modifiers is easily done with the left hand as you type the modified key with the right. A corresponding thumb key on the right just reverse the process.
That may be more than most users desire. For the sack of this discussion, I would basically want it so I could tweak the layout that one of the four thumb keys can be used for my alt layers. My current plan is to buy a set of Dvorak keys, used for most keys, and then blanks I can use for the few keys I tweak. I find blank keys a thousand time easier than a key with false info (due to a remapping).
3 Likes
I don’t think we need to compare evils. I think my layout works better under Qwerty than any other proposed one. But then I would! It’s (almost) how I currently have my kinesis programmed, after years of experimentation.
There is almost too much freedom to rearrange symbol keys under Qwerty because they’re “not important”. There’s no real reason to put them anywhere in particular. But once you start optimising for alternative keymaps, the number of useful layouts reduces to single digits pretty quickly.
My current plan is to buy a set of Dvorak keys, used for most keys, and then blanks I can use for the few keys I tweak. I find blank keys a thousand time easier than a key with false info (due to a remapping).
Yes, definitely.
In fact, I was thinking of asking Jesse and Kaia whether blank keys could be offered for a little less money (since they won’t need the labelling), in order to encourage people to do just that.
Thank you for letting us be a part of this process! It’s exciting, and I’m looking forward to seeing the result of everyone’s work on this keyboard.
To start, I’d recommend that the layout be kept to as standard of a Dvorak layout as possible–for acclimation of new users and to avoid any anecdotal bias. Then we power users can remap to add our personal preferences.
-
I fully agree with what the others have said to move the -_ key to the right of the ‘s’ (R2 C15). There’s no reason to deviate from the standard for this key.
-
Dvorak theory says top row keys are easier to reach than bottom row, so I’d move += to (R0 C15) instead of (R3 C15) to “slide” the three symbol keys and maintain the default layout. But a previous post said the top-right on the butterfly layout is harder to reach so I’ll assume bottom right is better even if it leap-frogs the -_ key.
-
My personal experience aligns with Jesse’s comment about having symmetric function keys so chording can be done with the opposite hand. Apple’s keyboards breaks this with the single Ctrl key on the left and it’s annoying. Since Ctrl is universal while Cmd and Alt are almost always screwed up across OSes, it makes sense to make two Ctrls by default. I’m not certain which thumb keys are “easiest” to type with, but in order of easiest to hardest I’d lay the thumb keys out in this order: Space/Bspc, Shift, Ctrl, Cmd/Alt.
-
Adding to pnunn’s and jesse’s comments, I agree having Enter at (R1 C9) is better than the Qwerty pinkie position but it was eye-opening when I had the Enter key right under my thumb on the Kinesis Advantage.
-
Most keyboards put the directional keys in a cross, so I’d shift the DOWN key down to (R3 C11), the UP key to above it (R2 C11), and shift the RIGHT key to compensate. This way when fingers are in the home position the middle finger controls up and down, and the index and ring fingers do left and right. You’d have to move the volume up/down but there’s plenty of room elsewhere.
-
I won’t be using the M. (mouse?) keys but wouldn’t it be better to shift them to the right so the ring finger controls the up and down when resting in the home position?
-
I can’t find the Delete key. Is it chorded somewhere? There’s no room for a dedicated key, so how about making it Fn-Bspc (R1 C7), so the Backspace does Delete similar to an Apple keyboard? L.Click and R.Click would need to be shifted to (R2 C7) and (R2 C8) respectively which doesn’t seem like that big of a change.
-
I’m not a fan of the placement of [{ and ]} across four keys instead of the standard two. Alternatives are not that great though. You could completely break from the standard and move them over to (R2 C0) and (R3 C0) since Dvorak already has the ;: symbol near it so logically there are three symbol keys together. If Any is not open for negotiations in this thread, my personal remapping might play with making Any (R0 C9) be [{ and Num (R0 C15) be ]}.
-
Interesting Esc positioning. I think I’ll like it, but I’m not a vi user.
-
No argument from me that Caps Lock is gone. But don’t forget to chord it somewhere.
-
If you wish, I can do a mockup of these suggestions.
My background: I’m a programmer and touch type Dvorak on a Qwerty Kinesis Freestyle with no remaps. I occasionally use a Microsoft Natural Ergonomic keyboard, and my at-home daily-driver is a MacBook Pro laptop mapped to Dvorak but with Qwerty keycaps. I used to have a Dvorak Kinesis Advantage until the E key stopped working after years of use.
Here’s a common Dvorak standard that I used for this post, https://www.microsoft.com/enable/products/dvlayout.aspx
3 Likes
I’m an Emacs user, so I tend to need Control, Shift, and Alt (Meta) pretty regularly. As compared to a MacBook Pro keyboard, I’m looking forward to my left pinkie not getting a constant runaround. 
I’m also a heavy vi user and I have a tendency to never use home, end, page up, or page down. I don’t even use them outside of vi. I will frequently scroll in editors that don’t support the vi bindings. I know this takes me off the keyboard, but I find the swipe scrolling on a mac to be a good way to scan code/documents.
What about embedded keypad under the right hand, and navigation under the left? Think WASD, but moved one to the right so that the fingers don’t leave the home keys.
1 Like
A legacy layout might entice more folks to buy an 01. Learning a new keyboard and learning a new keyboard layout are different things; sure, it might be only a few keys that are different, but for a touch typist, that means they have to slow down (or stop) and actively pay attention to what they’re typing.
If all your keyboards are 01s, then great. No problem. But if like many people you use a number of different computers in different locations and can’t (or won’t) cart a keyboard around with you, then perhaps buying multiple keyboards at once when the 01 is completed isn’t an option. Then you find yourself guessing, losing concentration, and throwing down keyboarding errors no matter what keyboard you’re on. It’s a hypothetical, sure, but I imagine that would annoy a good number of people.
Keyboardio will have to find the line between satisfying the largest number of people and keeping the keyboard geeks on their side. They’ll never please everybody, but a legacy layout will go a long way towards pleasing the largest number of people possible.
I find it easy to lose sight of the fact that Dvorak typists don’t even register statistically in most realms. We’re between a rock and a hard place - statistically insignificant yet vocal about it. I’m still annoyed at Apple for not coming up with a built-in Dvorak layout for their i-devices. You’d think THAT would be easy!
3 Likes
Keyboardio will have to find the line between satisfying the largest number of people and keeping the keyboard geeks on their side.
Programmability will keep the geeks on side. We’ve all been reprogramming our kinesis/ergodoxes for years so we’re not going to be satisfied with any layout that somebody else makes.
But if we want to have a model 01 at all to reprogram, it needs to sell. And that means not frightening the horses.
2 Likes
Let me break out the main design features from my earlier post:
-
Every 105-key international keyboard (regardless of language) has 48 printable non-whitespace keys. This fits perfectly into two 6x4 blocks. This means that all printable non-whitespace characters in any standard language mapping can be fitted into in the first layer of a model 01, half under each hand.
-
All other keys are fitted either under the thumbs, on the six spare keys in the centre of the keyboard or in the embedded layer.
-
An embedded keypad is under the right hand, in a home position, and a WASD-style navigation block under the left, again in a home position.
-
The number keys are scrolled to the left by one when compared to a kinesis. This is actually more natural for touch typists, because it better matches the stagger on a traditional keyboard (e.g. there is a school of touch typing where 6 falls under the left hand). This has two added benefits:
- The two keys to the right of “0” do not have to be moved
- The function keys F1-F12 can be located intuitively in the embedded layer.
-
A pc-105 keyboard has an “international key” to the left of Qwerty “Z”. This is retained in situ, as are the keys to the right of “0”, “P” and “;”. These are used quite commonly in international keymaps and there is no compelling reason to move them. The remaining keys (Qwerty “]”, “`”, and “”) are placed as close to their pc-105 positions as possible. This minimises confusion and should help to maximise adoption. (The only key that ends up in an “unusual” position is “”)
-
It looks like the centre two thumb keys on each hand are the ones that most closely correspond to the large kinesis thumb keys, in which case these should be used for space, backspace, and shift (and possibly enter). The remaining keys (Ctrl, Alt, Cmd, Esc, Return, Tab) are fitted in central positions.
(I find that only one thumb shift key is necessary on my kinesis, but I appreciate that others will probably want one on each side.)
I will keep updating the original post as I add bits and pieces to the embedded layers.
The left or right side of the keyboard is probably less important than the orientation of the keys relative to each other. This is assuming directional keys are being used for screen navigation in lieu of mouse movement so both hands are on the keyboard.
I definitely think WASD is much more standard than UP and DOWN being next to each other. There’s even an acronym for it! Since Dvorak is supposed to be about home rows and finger movement, centering it on ESDF (>OEU in Dvorak) requires less finger travel.
When you say embedded navigation keys on the left and embedded num pad on the right, do you mean pressing the Num key to start and stop this mode? For 10-key data-entry, having directionals are probably useful but having them on the left would make one-handed navigation and data-entry more difficult. I’m guessing it would be better to have a weird orientation than be on the other wing of the keyboard. Meanwhile, if I’m editing a document, it would be inefficient to always have to turn on and off the Num key even for small movements.
1 Like
@depaula The numeric keypad would still be the same, so you could toggle it between keypad and navigation mode using numlock. The WASD navigation under the left hand would be in addition. I don’t think there are enough keys under the right hand to have both numpad and navigation on the one side without using numlock.
When I say “embedded layer” I mean using the palm fn-key modifier. This is equivalent to the “keypad layer” on a kinesis.
One thing I don’t see in any of the proposals (Qwerty or Dvorak) is AltGr. And there’s only one Alt key so we can’t have both Alt and AltGr in the OS keymap… (?)
Given it’s history, I assume AltGr is going by the wayside? Personally, I’ve only ever been frustrated by it when the default keyboard mapping wouldn’t treat it as boring old Alt.