Initial Dvorak Layout

ADMIN NOTE

Sorry for not doing a better job specifying our initial goals for this thread up front.

Folks are 100% correct that there are a few different tasks we’ve conflated here. While we want your help to figure out the correct “logical” layout for the Model 01’s Dvorak layout, the thing we really, really, really need your help to figure out is the key legends that we’ll engrave onto our ‘standard’ Dvorak keycaps. The two go hand-in-hand, but the interesting features of the logical layout are something that will be much easier to change and customize later.

Ideally, the legends should be a relatively conservative default that most Dvorak typists can live with.

Based on typing on the prototypes for the last couple years, I have some fairly strong feelings about the layout (especially around metakeys), but I’d like to see what y’all come up with, so I’m going to keep my mouth shut for now.

-j

It would seem I misunderstood the request. If we’re only talking art, how many colors can we use? None of the examples above show the numeric shift symbols #, %, ^, etc.

Nah. We just didn’t do a good enough job of specifying and prioritizing tasks.

Because the labels will be engraved rather than painted, we’re limited to a single “color.” on the keyboards, though use as many colors as you want to help explain things on the reference images.

Indeed, we’ll eventually want to make sure we specify which shifted and function-shifted alternate labels end up on each key, though it’s not wrong to figure out the core part of the layout before going there.

The LED is underneath the lower left corner of the key, which means the primary legend should probably be in the lower left–it’ll be brightest.

Both sets, actually. The interior keys are definitely easier to hit than the exterior keys, though.

I’d strongly recommend those keys not be mapped to anything you want to reach without twisting and stretching.

1 Like

As far as I know, AltGr is the right Alt, usually, and the QWERTY layout in the KeyboardioFirmware sources uses Right Alt, so it does have AltGr, but lacks Alt.

1 Like

I wish this was threaded.

I’ve been typing on an old (UK) 105-key keyboard in Dvorak for 10 years, and I’m almost always in vim. The 105-key has some small differences from a US 104-key.

Some general things:

  • Am I the only person who never remapped the cursors in vim from jkhl and uses them as-is in their Dvorak positions? (jk on the left hand, hl on the right?) They look oddly positioned like that as cursors, but I have never had a problem with them. Happily, up and down are the same way around as on qwerty and both on the same (left) hand, and the h and l are both on the (other) same hand with h to the left of the l, so it’s intuitive enough. I’d actually like the cursors engraved on the jkhl even though they’re not all next to each other. I don’t expect this to be a popular suggestion, but putting it out there. I wouldn’t want cursors engraved on dhtn. Do people really map those to be cursors in vim? Where do you then put what would be d (“delete”), t (“to before letter”), n (“next seach result”)?
  • I agree with those who are saying the -_ should be to the immediate right of s. That’s just part of Dvorak and that’s absolutely where it should be.
  • Vim users, why are you so keen on escape? Why not train yourself to use ^C or ^[ instead? ^C is easier to hit and doesn’t have the drawback on certain terminals that escape and ^[ have, where it’ll wait briefly to see if you’re doing an escape/meta sequence. If you really want to use escape, why not have it where the vi developer had it, left of qwerty q (so left of ' on Dvorak). Having said that, an escape key needs to be there for other terminal operations. It just doesn’t necessarily need to be easily hittable just for vim.
  • My layout has the number keys in the regular order but I would be willing to relearn with them as 9753102468 or similar. Likewise, I’d be willing to change up where the corresponding punctuations are, for example to put all the various brackets in a symmetrical way.

Here’s my attempt at a layout which matches my current UK Dvorak as closely as practical, with then some small tweaks:

edit link

The UK bits are

  • £ on shift-3
  • Euro with some kind of modifier on 4
  • '@ are on a key together
  • 2" are on a key together
  • #~ are on a key together, which would usually be to the right of what I have labeled as -_
  • backtick and ¬ are on a key together which would usually be to the left of 1
  • \| is thusly placed on a UK keyboard

I’ve suggested positions for page up/down, insert, home, delete, end here. I had nothing I could think to put as the primary use of what I have labelled as insert. Mostly I tried to keep all utility keys the same as keyboard.io’s suggested default mapping.

I’ve thrown arrows on jkhl because vim, as well as on the left hand home position in a standard cursor layout. I think both would be useful.

While I think the above might be a reasonable default for UK users, I think I’ll be retraining myself to do things a little differently. The below is what I have in mind. Its numbers and punctuation are partly based on this (I expect the author is here somewhere…?)

edit link

Things of note:

  • I’ve mainly kept the utility keys as in the default suggested layout.
  • I’ve recoloured the bottom centre keys yellow since when I used the prototype on its tour I found these keys much easier to hit with my thumbs than my index fingers.
  • I’ve moved =+ to left of a, since this is easier to hit than the bottom right key (which is labelled here as insert), and also because then plus on the left end of the home row nicely balances minus on the right end.
  • I’ve used the very bottom left and very bottom right keys as delete and insert, for balance and because I had nothing else to put there. Maybe they should be the other way around to match plus and minus? But then they’d be opposite to space and backspace…
  • I’ve staggered the numbers as in the blog linked above and used the author’s suggested punctuation layout, but I’ve moved F11 and F12 to the middle, meaning I can use “Prog” and “Num” as in the default suggested layout.
  • I’ve put \| and \~` in the centre bottom keys so they’re on the same hands as they would be on a 104-key keyboard.
  • I have some functions in grey which wouldn’t be printed (since they wouldn’t be for everyone) – play-pause on some mod+p, volume control on fn(+shift)-v, mute on fn+m, skip back/forth on fn(+shift)-n (a la next/prev in vim), rewind (I rarely use fast forward but often want to skip back 10 seconds and hear something again) on fn-r (“reverse/rewind”). I guess I could have fast forward on the same key there, one with shift and one without.
  • The bottom right labels are meant as number mode, with something corresponding pretty well to a standard num pad. Enter here may be surplus to requirement, given that the standard enter key would also be available with the same hand. I’ve added the proper mathematical characters for minus, division and multiplication, yet of course I’d want these to actually output hyphen-minus, slash, and asterisk.
  • I’ve put home and end as fn(+shift)-g, to correspond to gg and G in vim. I haven’t totally thought this through – what if you ever needed to type shift-end?..
  • I’ve put page up and page down as fn-f/b, to correspond with ^F and ^B in vim (“forward”, “back”).
  • I have put the various brackets symmetrically in keys in the middle. I haven’t actually tested this but I like the idea.
  • I’ve thrown escape in the “true vi position”, even though I don’t actually use it in vi. Nothing else I can think to put there, given that tab in the centre seems reasonable.

One more thing: I would likely use the “any” key as a “compose” key (which currently I have mapped to right alt). I think I might like it labelled “compose”, since while “any” is fun, “compose” is practical.

3 Likes

Here is the thing We are not debating whether you can remap the keys or not - of course you can my two cents are that we have an option to standard letters in dvorak but keep the controversial keys blank. :stuck_out_tongue_winking_eye: so evryone can be happy from an editor to a programmer.

1 Like

Here’s my variation on the template made by @algernon . Key differences,

  1. Put U.S. shift symbols over the numbers to get closer to what the keycaps would look like.
  2. My take on WASD arrows under the right hand.
  3. I put in the mouse warp keys from the default key layout that I found here. I personally don’t plan to use the mouse movement keys but it looks like a core feature?
  4. Turned NUM into a normal key to get one more key for symbols on the right-hand-side.
  5. Did another take on the 10-key layout–not sure if @algernon was using a confirmed standard? I’m not a 10-key user so I can’t speak to the usability of either.
  6. Put Delete on an arbitrary thumb key. I still like the idea of putting it on Bspc but that would move L.Click.

Link to the template

1 Like

>OEU are the keys I use for gaming, precisely because it lets my hand stay on the home keys.

I used to use a Touchstream LP (Fingerworks), which had space / enter on right thumb, and delete / backspace on left thumb, and I really liked that layout. I’m currently using a customized TEK at work (programming, Mac) and the built-in windows Dvorak at home (gaming, Windoze).

algernon raises a hand, I’m here :slight_smile:

The 9753102468 number layout is nice, if you happen to use the numbers with similar frequencies I do, and like the symmetry of it. It would be a big mistake to have that engraved on the keycaps, though. I can imagine the reactions, and most of them would be shock and horror.

Oooh, nice! I secretly hoped it will be so, because I planned to put Alt and Ctrl there for my own layout. It is reassuring to know that it is as I expected. Thanks for that bit of info!

I suppose a lot of people will do just that, and go with a mix of blanks and labeled keys. However, having a default keyset with half blanks, half labeled look weird, in my opinion. One of the reasons I never bought any sets for my ErgoDox that had child kits for the board, is because the child kits were almost always blank, while the rest had labels. Just felt unprofessional, and like admitting defeat.

As a customer, I’d rather have a fully labeled set (with an Any key, because that’s fun), and a blank set, so I can mix and match. Feels better, to me.

I think I copied it from the QWERTY layout. I don’t use the numpad, either.

Likely unfit for a default setting, but Shift + Backpsace for delete? That would not conflict with mouse keys. But then, if you don’t plan to use mouse keys, it doesn’t matter, you can remap the layout to not have the mousey things.

1 Like

My riff off of @depaula’s variation of @algernon’s proposal - Template

  1. shift mouse arrows so the warp keys are in their natural positions
  2. move left click to the center of the mouse keys, freeing Fn-backspace to be be Del
  3. move media keys to left side
  4. add symbols inspired by Fingerworks programmers punctuation pad to the Fn layer on right side

This might get difficult to click and drag if you want to with just on hand
although I’m not planing on using mouse keys for now

I think you need to make the architecture decisions first. How is swapping keyboard layouts handled in the multi-layout use case? Do I do it in the OS or in the keyboard firmware?

If I do it in the OS, then you cannot treat the Dvorak keycaps in isolation from the Qwerty ones - the OS keymap will do what it does regardless of what is printed on the keycaps.

If I do it in firmware (say, by a hotkey), then we will either need to program our own layouts or have a library of them somewhere for download. But why reinvent the wheel? The OS has a comprehensive library of keymaps already. And you can’t program a non-English layout in firmware if the OS still thinks you’re using US-Qwerty.

(BTW, how do you pass shifted keys to the OS when they’re located in an unshifted embedded layer? I’m thinking of your proposed “{” and “}” placement in particular. Do you send shift-down + “[” + shift-up? Won’t that guarantee an abstraction leak?)

I don’t think these are mere implementation details that can be ironed out later; they go to the heart of how this keyboard will be used and will have knock-on effects across the entire scope of layout design.

1 Like

Hmm, that’s a good point… I don’t have a good feel for what it’ll be like to actually use the mouse keys.

With that in mind, I think it makes more sense to put the mouse clicks in the Fn layer of C8 (right thumb keys), in order L M R as I saw suggested by someone else.

Most non-US keymaps require an AltGr key to reach some symbols that are in the top layer on US, e.g. square and curly braces, due to the symbol keys being used for accented letters. Non-English-native programmers tend to prefer US keyboards for this reason, but non-programmers generally have the opposite preference, because they need accented letters more often than symbols. My point is that we really should accommodate both.

I personally quite like compose key, but it’s only practical for occasional use. I’m forever looking up the (OS-dependent) shortcut tables.

Assuming that we only care about English/Dvorak, I’d go with doing it in the firmware, at least for the default layouts. Why?

This is why. Because doing the emulation in the firmware gives us more flexibility about where to put certain symbols. It also means that you can hit a key on the keyboard and switch from QWERTY to Dvorak or vice versa, without the OS knowing a thing. That is a powerful thing, loved it when I was learning Dvorak on my old TypeMatrix.

This is also the choice most other keyboards that come with a Dvorak option do. This is the least surprising, and from the firmware point of view, the easier and more flexible.

This is what QMK does, and works pretty well: allows you to program your layout, and also has an extensive library of layouts, most of them user contributed.

Yep, but they all require setting up the OS to use that layout. It’s not as easy as plugging in the keyboard and just having it work. (Assuming that the OS layout is set to QWERTY, a reasonable expectation, considering most other keyboards assume the same.)

A non-English layout will require tweaks. Can’t support everything with one layout. I believe we should concentrate on English only. The labels will be for English, that’s what the default firmware should handle, too. Anything more is far too complicated, in my opinion.

In case of the curly braces, the firmware sends Shift+[ on press. The release is done in a creative way: the report is cleared every cycle, and any key that is still held the next cycle, remains held. In case of {, since it was synthetic, it will not re-register. Unless you hold it, or hold Shift or [, because that part will re-register. So holding Shift and pressing and releasing { will result in Shift being held, and never released, and [ being pressed during that time.

Whatever is on the keycap, we can input them. Whether we end up assuming that the OS is in QWERTY or Dvorak, we can input any symbol we put on the labels, if we stick to English. We may have to do a trick or two, but that can be done later, after the labels are decided upon.

Since you can replace the firmware, and there will be alternative layouts, if the keyboard ends up shipping with the firmware assuming QWERTY on the OS side, it will be very, very easy to reflash it with another firmware that assumes Dvorak on the OS side, if that’s your thing. The same keys will still input the same keycodes, in both cases.

1 Like

There is an AltGr on the right thumb arc, so those who require AltGr, already have it. It’s labelled Alt on the images, but in the firmware, it sends the code for Right Alt, which is AltGr.

But then you don’t have vanilla Alt.

I think this is a debatable assumption. :slight_smile:

Which is something you only need to do once. And if you’re a foreign-language or dvorak user, you’re well used to it.

Most other American keyboards. :slight_smile:

PC-105 supports all language keymaps with one hardware/firmware layout, as do most variations on it such as laptops, so it can be done. Changing too much away from pc-105 will impede adoption by the casually interested due to unfamiliarity. And we power users will remap everything no matter what default you choose. :slight_smile:

I really want this to work, and the way it works is if lots of people buy the product. Needlessly ignoring large portions of your potential customer base strikes me as short sighted, that’s all.