Initial Dvorak Layout

Model 01 Layouts
83

My reading of the admin note suggests otherwise. A relatively conservative default that most can live with sounds English Dvorak to me.

Not if you use multiple computers, or don’t even have a fixed one, but plug your keyboard into other people’s computers. But you’d be right to say this is not a common use case.

I’m a Dvorak user writing plenty of Hungarian. My OS layout has been QWERTY since the dawn of time. I know a lot of other Dvorak users who write non-english, with a QWERTY OS layout, and use compose keys, macros and whatnot, because that gives them much more flexibility on where to put their national symbols.

If you look at localized Dvorak layouts such as Bépo, you’ll notice that it moves quite a number of symbols compared to the traditional Dvorak. So if you are a French Dvorak user, you are likely using Bépo. I don’t think we should consider that under the same hat as Dvorak.

Thus, the safest bet is English Dvorak labels, as far as labels are concerned, because localized Dvorak is too different, and fails the “standard” and “relatively conservative” parts of the admin note.

We don’t have 105 keys, though. As for laptops: at work, we use Lenovos and MacBooks, for both of them, those who want a Hungarian layout, have to ask for a Hungarian keyboard, so these do not support multiple layouts with the same hardware. (Where I’m counting keycaps as part of the hardware, even if a replacable part.)

What I don’t understand is, why is it a problem to have English Dvorak keycaps? You can’t engrave national symbols on it, because there’s not enough space, nor keys, and too many variations anyway. Once the symbols are ironed out, we can figure out how to match it in firmware, and what OS layout it should assume.

But, to be honest, I fail to see what the problem is. Take Hungarian: if the OS layout is US QWERTY, ; sends ;. If it is Hungarian, the same key inputs é. If the keyboardio assumes an US QWERTY layout, if I switch it to HU QWERTZ, then what used to input ; will input é. That’s what I’d expect. That’s what happens on every other keyboard, because the keyboard still sends the same code, as it does not know the layout was changed.

; / é may not be at the same position than on a traditional, non-split, staggered layout, but this is a split keyboard, so changes are to be expected. Same for the Y / Z swap. I change the OS layout, the firmware sends the same code, OS translates it to a different symbol - as one would expect.

I don’t really see a problem with this.

84

It’s not a problem to have Dvorak keycaps. My argument is lower level than that (and applies to all keymaps, not just Dvorak).

My argument is that we shouldn’t put ourselves in the position of having to make assumptions about what way the OS is configured, but instead design a default scancode layout that behaves reasonably under the widest possible selection of OS keymaps. Once that scancode layout is decided, the keycaps (for qwerty, dvorak, colemak, Hungarian, whatever) fall out automatically. Which keycap sets are physically produced is of course entirely up to the economics of manufacturing. But we shouldn’t think about them as being independently variable.

As you say, the key that produces one symbol under us-qwerty may produce something else under a non-English keymap, and many multilingual users will be content to remember this glyph-to-glyph mapping. But touch typists don’t care what is engraved on the key. They expect it to be in a certain place. And this keyboard is designed for touch typists.

1 Like
85

Aha, this is where our fundamental difference in thinking lies: I go with the assumption that the keyboard has a different physical layout than anything else, so one will have to retrain muscle memories anyway, thus, the physical position of keys does not matter that much. On a different keyboard, a wildly different one, having some keys elsewhere is to be expected. That happens even on full-size vs laptop keyboards, and the difference in size and form there is much smaller.

My thinking is, that since this keyboard has a distinct form factor, and we will all have to learn the layout, we have the freedom of putting keys wherever we want to. It should still be close to what one would expect from a traditional layout, but we can’t use the same - not enough keys, and a different physical form.

2 Likes
86

That’s not the issue here as far as I understand.

When you press a keyboard switch an elecrical signal is converted to something called a Scan Code, this is then sent to the computer. A Scan Code is not a letter like “A” or “B” or Shift, it’s a just a number between 0 and 255.
Each operating system than translates this number to a particular letter or key depending on the keyboard layout.

The point that’s being made is that the keyboard sends a particular Scan Code like the one for “Alt” that’s interpreted into a particular modifier by the OS depending on the layout, AltGr has a totally different Scan Code and is interpreted very differently depending on the OS and keyboard layout.

What this means is that if the physical keyboard is only capable of sending the Scan Code for Alt but not the one for AltGr then there is no way for the user to type on on the keyboard and get the letters they want.

87

I assume this is a reply to the Alt/AltGr discussion: yep, they are different keycodes. At the moment, the firmware can send both, but only AltGr is bound to a key. The Alt / AltGr issue is layout-agnostic, which is why I forked it off to a different topic :slight_smile:

1 Like
88

Aha. But the difference between a staggered and a straight-column keyboard is systematic. Keys in the same row are shifted consistently sideways by the same amount, meaning that although muscle memory may need to be retrained, brain memory does not. If a touch typist goes to hit M and hits the adjacent key by mistake, she doesn’t need to look down to hunt for M; it’s obviously just a little bit to one side.

(In my own experience, changing from a staggered to a straight layout was more about changing my hand position than learning from scratch)

So I don’t agree that we are starting from a blank slate. And I don’t agree either that there aren’t enough keys. Neglecting the numpad, PC-105 only uses 48 keys for printable non-whitespace glyphs (no matter the keymap). The Model 01 has 64.

89

Even with the layout you proposed, there are a number of keys in wildly different position than on standard Dvorak:

  • Backspace moved from top right to the thumb arc, and to a different hand, too.
  • Backslash / | moved from the right side to the left, one row down.
  • Tab moved from the first column to the seventh.
  • Enter moved from the last column on the right to the innermost one.
  • Both Shift keys moved to the thumb arc, from pinky positions.
  • Gui (or WinKey) and Alt moved to the thumb arc too.
  • + / = moved from the first row to the fourth, and even changed columns.

That is, compared to this.

That is plenty of change, and most of them bigger than having to reach a column or row further or closer. There is hand change involved too, and that is muscle-memory territory, and means that a touch typist will have to relearn at least some of the keys, no matter what.

(I’ll compare the Kinesis Dvorak layout to the same one I compared yours to, as I’m curious. But will have to do that later.)

90

Yes, that is inevitable given the physical limitations. And considering that moving modifiers, space and backspace to under the thumbs is the entire point of the Model 01, I’m not sure how going along with it can be held against me. :smiley:

I have tried to minimise unnecessary changes and confine them where possible to whitespace and modifiers. Moving return and tab to the centre of the keyboard was obviously a conscious design decision by J+K, and I think a justifiable one – particularly since the ergonomic improvement is obvious, and the effect is identical under all keymaps. Moving printable keycaps around does not compare.

Also note that no matter what layout of scancodes we use, backspace, return, backslash and the key next to backslash (“]” or “=”) must move, because the physical keys don’t exist on the Model 01. There is simply no choice.

So the only key that I moved that I didn’t absolutely have to was Tab. And if I didn’t move Tab, something else would have had to move to R2C7 instead.

This is the one change forced by the symmetrical geometry that I wasn’t able to minimise. At least one printable keycap has to swap sides and I picked one. If you can touch-type backslash on a standard keyboard, count me impressed. :wink: But if you think another keycap should move instead, I’ll understand.

91

This is what I’ve been trying to say too. I guess we ended up talking about (almost?) the same thing, with different words. :smiley:

On a standard keyboard, I can’t. I can’t touch type on a standard keyboard, never could. I could touch-type backslash on the typematrix, and I can do it on the ErgoDox too. (I have it next to L) .

92

I don’t understand this. I find it easy to reach and touch-type on a 105-key keyboard (it’s in the bottom left), and on a 104-key keyboard it’s a minor stretch.

93

Sorry, I was referring to pc-104 under US-ascii, where backslash is to the right of “]” (qwerty). On pc-105 it’s only in the bottom left “international key” if you’re using a UK layout; it’s to the right of " ’ " (qwerty) under us-ascii.

94

Indeed, it just took a while to dig out the root cause of the disagreement!

This is what I meant above by “architecture decisions”: do we consider the Model 01 layout to be a blank slate (or more accurately a collection of blank slates, one per layout), or do we consider it evolutionary? If it is a blank slate, then let our imaginations run free. If it is evolutionary, then we are constrained.

I vote evolution. Firstly, if we start with a blank slate then the options are effectively endless - and the arguments also endless. Principled constraints drive decisions by narrowing the parameter space. Secondly, evolutionary change allows us to re-use decades of common practice in the form of the pc-105 keymap library that comes preloaded in every modern OS. And thirdly, we want to avoid anything that would make what is already a niche product even more niche. Manufacturing economics demands no less.

1 Like
95

Yes, I know where it is on both keyboards; I have both and addressed both in my comment. My right pinky hits the backslash on a 104-key US keyboard just fine with a minor stretch:

I use backslash and pipe often enough that I don’t want to stretch that far for it; all I’m pointing out is that it’s not impossible to touchtype it. Or maybe I have freakish hands…

1 Like
96

Howdy all…I’m getting a late start but will work at reading the entire thread over the next couple days.

My daily keyboard is the Kinesis Advantage Pro (with foot switch) with Qwerty keycaps and macOS mapped to the Programmer Dvorak variant layout (http://www.kaufmann.no/roland/dvorak/). The primary difference is this key layout puts common programming symbols (&[{}(=*)+]) on the number row and requires a shift mode to access number characters.

I’ll try to confine my comments to vanilla Dvorak as I can. I’m excited to see the design and layout unfold!

-robert

97

I’m not sure how this lines up with everyone else’s priorities, but I’m hoping for Dvorak labels that try to reproduce the “default” Dvorak layout that’s provided by macOS, Windows, and Linux. I mainly type on a couple of Kinesis Advantage keyboards today, but I had to start with their Dvorak layout and then manually adjust some punctuation keys (most notably backtick/tilde). IMO, it would be super great to have a Dvorak starting point that’s as standardized and unsurprising as possible, and we can create fancy layouts from there.

:open_mouth: I thought I was the only one. How about that. I started using Vim years after switching to Dvorak—I didn’t realize it at the time, but I have no idea how to use Vim on a Qwerty layout at all.

2 Likes
98

Me too. How does my suggested layout above suit you? (Message 42)

99

Unfortunately it makes several changes that would be a huge inconvenience for me. :confused:

For my use, it’s a fairly big deal to be able to chord the application switcher easily with one hand. The relevant shortcuts are ⌘⇥ (cmd-tab, the application switcher), and ⌘` (cmd-backtick, the application switcher in the opposite direction). On a “standard” Dvorak layout, backtick is directly above tab. (That’s the change I specifically called out in my previous message as something I had to manually change on the Kinesis to make it match the default Dvorak layout more closely).

I’d also really, really like to be able to push space, enter, backspace, and delete with my thumbs, but it’s looking like I might have to give up some chording flexibility to get that.

1 Like
100

Maybe instead of (explicitly) mapping out the thumb keys, we can use symbols, then people can map it in their brains and logically as they wish? Right now as its stands:

L1 = Ctrl
L2 = Bkspc
L3 = Cmd
L4 = Shift

R1 = Shift
R2 = Alt
R3 = Space
R4 = Ctrl

With palm = Fn on both sides.

Example (Playstation attribution)

L1 = Circle
L2 = Triangle
L3 = Square
L4 = Hex

R1 = !! (or other currency symbol)
R2 = British Pound Sign
R3 = Euro Mark
R4 = Yen Mark

This way Circle = ctrl, shift, alt, cmd, del, etc., whatever the user wants it to be… I’d rather NOT mirror/match the left and right sides. L1 = R4 = Circle, L2 = R3 = Triangle, L3 = R2 = Square, L4 = R1 = Hex.

101

That can be done if you’re willing to replace the right shift key with return, to make it more like a default kinesis.

102

Internally, the firmware calls the thumb keys R0C7-R3C7 for the left (counting outwards) and R0C8-R3C8 for the right thumb (mirror image). Probably best to stick to these labels.

There’s a specific discussion about thumb keys and chording on another thread, which is probably a better place for this, as the same issues apply across all layouts.