It’d be useful for the other discussions to the see the current version of the default US qwerty layout. (I noted in Kaia’s post in the Dvorak thread that some minor changes had “recently” been made.)
Additionally it’d be useful to have highlighted the keys which ideally would stay the same for other layouts too, as far as is practical.
I’m guessing, for example, that the thumb keys, the inner keys (LED, any, tab, enter, esc, butterfly), the entire top row (prog, number keys, num) and the palm keys should stay as they are, if at all possible. Correct, or no such strong feelings?
What about the leftmost and rightmost columns; how important is it that they stay as in the qwerty layout?
Then for the other layers – what should stay the same as qwerty (and drilling into that, what stays the same per physical key versus what stays the same per key effect such as letter), and what is less important? For example, should the mouse controls stay put on the same physical keys? The cursors? (I’m looking at vim, where I use jkhl in their dvorak positions to navigate and it works just fine, so for me having the cursors over dhtn (same physical positions as qwerty) makes no sense at all. Not sure how much in the minority I am there.)
We’d do better at homing in on a consensus with more constraints, I think.
I agree that some more constraints would be useful for layouts.
@bjn I feel less is more when it comes to printing mod-layer keys - vim directions in particular are very personal, and think about it, you’ve probably been using them for years without a little arrow on the keys.
@mygnu My two cents are that PgUp and PgDn should be on the mod-layer, as they are gui commands (as opposed to printable characters) You never find yourself typing a sentence and needing to PgUp in the middle of it, whereas I use the pipe / backslash key quite often and they are always within other printable characters.
As someone who will remap those keys too, I still believe that the default here should be the same across the layouts. Even if that’s not perfect for a particular layout (QWERTY is not perfect either, and yet…), for the sake of consistency.
Since these contain stuff like ' (the apostrophe), that on Dvorak is on the other hand, together with the rest of punctuation, I believe it is important to have this symbol at its usual position on Dvorak. More important than keeping the leftmost/rightmost columns the same across layouts.
If it were up to me, I would not have the other layers engraved onto the keycaps. Take cursor keys: Many prefer the VIM layout of them, another large subset of people (myself included) prefer the traditional triangle/WASD-style setup. Others prefer the vertical/horizontal keys on different hands (see the ErgoDox EZ default keymap for an example of such setup). It is very personal. While the firmware can provide a default setup for them, printing on the keycaps?
Even among QWERTY users, the camp seems to be divided among the VIM/WASD people, with a minor split group quietly mumbling in the corner too.
A few more guidelines, or restrictions wold certainly help keeping our imagination in check.
Totally! But I was under the impression something was being printed, and I’d much rather have nothing printed than something which doesn’t make sense to me.
Yes; this is what I was looking for confirmation of, so that we can stop arguing about whether they should change in for example the Dvorak-specific thread!
Definitely! This is my point – I’d love to hear from J+K which ones they would prefer are left alone across all of the default layouts. Maybe they want to leave page up/down where they are, for example, and so we should stop suggesting putting other things there. (I don’t hold this view in this case, as I said in another comment above.)
It was sort of intentional that we didn’t start off with too many proscriptions about the layouts here. It seems like the brainstorming is getting to the point where, yes, we want to start zeroing in on a couple proposals for discussion. Folks have brought up some very good points that we hadn’t considered up to now, so I’m definitely not sad that we let discussion start off a bit wild.
In terms of blank keys - I don’t really want to leave a bunch of keys blank in QWERTY/Colemak/Dvorak. We expect to make sets of blank caps available at a price that isn’t terribly crazy, so that folks who want some keys unlabeled can do that without much trouble.
I feel fairly strongly that the keys currently on the thumbs and palms should stay where they are, but not so strongly that if 100% of you scream about that I wouldn’t consider trying something else.
I feel very strongly that R0C0, R0C6, R0C9 and R0C15 should NOT be used for keys anyone expects to touch-type in a default configuration.
R0C0 is used as the bootloader control key and should probably be kept as the ‘programming’ key.
The default arrow key locations on the vi keys aren’t something I’d want to change without broad consensus.
After we get the next backer update out, we’ll start to synthesize the feedback we’ve gotten in these threads into some concrete proposals.
One thing that does puzzle me about the default layout is making PgUp and PgDown first class citizens with keys all to themselves. I would have thought putting them on a different layer along with the vi style arrow keys (or asdf), home and end would have made more sense.
My point over in the Dvorak thread is that when typing Dvorak, hjkl aren’t in a straight line all together, so arrows on R2C10 through R2C13 don’t make sense. At least they don’t make sense to me – I move around vim with hjkl in their Dvorak positions.
I wonder if palming the fn key while using them would be just as nice, or almost? Enough for that to be default? Or is having them first-class perhaps a requirement only for qwerty?
Having PgUp and PgDown first class is not a requirement for variant layouts. I do strongly recommend that we not end up with a layout that involves using the pinky to chord, though
If you would consider making one change to the thumb cluster, then it should be to move shift onto R2. It is used a lot more often than alt/cmd and should have a correspondingly more natural location.
Fair enough, but does the programming function have to be in the top layer? I would have thought that after an initial period of experimentation, the programming key will become less used over time. It feels like a waste of a perfectly good key, especially if it means losing ASCII-printable scancodes into the embedded layer.
I don’t feel strongly about it, but it should be noted that an embedded 10-key under the right hand is a near-universal feature of compact keyboards (i.e. laptops).
(edit) The paging/arrow key arguments could be easily solved by a few extra key locations, e.g. a row of four on each outside of the thumb cluster, as per kinesis or ergodox. Perhaps an idea for Model 02…?
I also feel strongly about this. I feel that I’d accidentally hit Cmd/Alt often while going for Shift. @jesse, you’re the only one here who has experience. Is this a real concern?
I know we can always rearrange those keys, but I’m still concerned about the default.
Having a separate num layer controlled by a “num lock” key that’s not very accessible negates a lot of the benefits, it’s rare to only want to enter numbers and having only a toggle switch to enable the numkey layer would be a mistake IMHO.
