Default qwerty layout and how it relates to alternate layouts

Model 01 Layouts
41

Both Fns for an Fn-Lock would be very easy to implement as a kind of plugin. No matter what the default firmware does, if you are comfortable with adding about two lines to the default firmware’s Arduino Sketch, and recompile, then I can have a solution ready for you before the keyboard ships.

The Planck has something similar, where you can hold down two layer switchers together to get to the third. This would be almost the same, just the action differs. (And I already have the code that can notice this state, just need to write a small callback that would lock the Fn layer.)

1 Like
42

@jesse, trying to steer back to the topic, I’ve gone ahead on the Dvorak thread and put forth that the following is ideally what would stay common between the various layouts. This is my guess at your view, partly from what you’ve said, and partly from reading between the lines.

base-layout.png992×446 19.3 KB

Editable version

Does this look about right? Or should some of these be blank, or suggested rather than strongly desired? (Maybe you don’t care much that enter and tab are in those spots, for example.) Ideally we could get from you one of these editable keyboard layouts highlighting a couple of levels of desire for common keys between layouts. This would help focus efforts.

1 Like
43

@bjn - Thanks for that. That looks like what I’d been thinking, with the exception that I had been planning to keep the vi-positioned home-row arrows.

I’m not going to 100% veto considering deviating from that layout, especially if there’s a strong layout-specific reason to do so.

44

@jesse,

Looking at base-layout (bjn’s 42). What was the reasoning behind the placement of R0C6 (LED) and R2C9 (Bfly)? C7 and C8 keys, if those are to be used as chorded options, why have R1C7 as Bkspc and R1C8 as Space?

Would it make more sense to have R2C6 as Bkspc, R2C9 as Space?

45

R2C6 and R2C9 aren’t as easy to reach as the thumb arc. They’re definitely better than they were on the earlier prototypes, but it’d drive me nuts to have to reach for space and backspace.

And really, pulling space off of the default position for somebody’s thumb is likely just a bit too “interesting” a layout change.

Butterfly is there for you to customize, definitely. LED is there to be just a little bit out of the way, but still let you change the LED fx :slight_smile:

Of course, everything is customizable if you don’t like the defaults.

46

@jesse,

ahh. Thanks for the explanations, I don’t have a model 01 to fiddle with so appreciate the reasons behind it. Does kb.io have a heat diagram detailing finger movement efficiency? Home row would be colored x (green), no finger displacement. Colored y for minimal finger displacement, colored z for maximum displacement, etc. or is the M01 similar to traditional straight keyboards?

Re: pulling space off the thumb as the default position. I understand the appeal, reason, and necessity to keep muscle memory. I however am a glutton for change/punishment and am willing to retrain with a layout that improves efficiently even at the expense of adopted usability.

47

We don’t have such a thing yet. Mostly, it just hasn’t been critical path to getting to shipping hardware. As folks get their hands on keyboards, I expect a lot of that sort of thing to appear. The layout is very much not like a traditional keyboard in that regard.

Understood.

Are you thinking about that in the context of this thread about QWERTY? If so, the biggest wins will come by switching to something 5 or 10 decades more modern :wink:

I fully expect that after more than a handful of people have had keyboards for a few months, we’ll start to get a sense of what some interesting second generation layouts would look like. I’m more than happy to try to do runs of other keycap legends once we get there. My current guess is that with even a few dozen interested people, we’ll be able to do custom key labels. But we really need to not be pushing hard on trying to ship the basic keyboard at the same time.

-jesse

48

Thanks, Jesse.

I really don’t think this makes sense for non-qwerty layouts. Please reconsider this.

Qwerty

First, I’m all for the arrows being there on the qwerty layout. Let’s talk about the qwerty users. There are two groups: those who already know that cursor layout (vim users) and those who do not. Those who do are fine – great! But those who do not would likely find the cursors to be more intuitive if they were in a diamond or inverted-T pattern rather than a straight line. However, it sounds like you’ve made up your mind that the inline way is the way you want to go. (That’s more than fine with me, but I’m biased as a vim user.)

But now let’s look at alternative-layout users. I only have experience with Dvorak, so that’s what I’ll talk about.

Dvorak

I’ve asked in Freenode #vim and ##dvorak, and all users I could find who use Dvorak and vim (only a handful in the time I was there) do not remap their keys: that is, they use the Dvorak positions of hjkl to move around. I’m among them, as is @andre. I concede that though my findings were that 100% of vim/Dvorak users operate this way, my sample size is very small. (Someone else in the #vim channel commented that only brand-new vim users ever ask about remapping things, which suggests that we’re not alone, though of course it’s not evidence.)

What that suggests is that no (or very few) Dvorak users have learnt dhtn (their equivalent of hjkl) as left, down, up, right. (Unless they previously used vim on qwerty of course.) So if we split Dvorak users into vim users and non-vim users we have the former group who is very comfortable with Dvorak hjkl as cursors, and the latter group who would likely prefer a diamond or inverted-T shape on a single hand for cursors. Neither group likely wants cursors in a straight line on the right hand (dhtn).

Therefore having cursor arrows printed on R2C10 through R2C13 (and the cursors mapped there in the function layer) doesn’t make sense for Dvorak. I’d wager it’s the same for other alternative layouts.

Others

While typing this I had a response on ##dvorak from a Carpalx layout user. He says he still uses his layout’s hjkl positions (even though they are insane – “left” is in the qwerty ; position for example) in vim, and would also use them that way when playing Nethack (read: lots of cursor use, with both hands on keyboard). I think this is rather telling.

Proposal

I argue that if you’re going with printed arrows on HJKL in the qwerty layout, on alternative layouts the arrows should be printed wherever the HJKL keys are in that layout (and the respective default mappings should be there too of course).

TLDR:

Having cursors mapped to/printed on R2C10 through R2C13 does not make sense unless those keys are HJKL. The arrows should either be not printed at all (and cursors mapped for those non-qwerty layouts to an inverted-T or diamond shape on one hand) or they should be printed and mapped to whatever keys in that layout are HJKL. I vote the latter, at least for Dvorak where the positions are somewhat intuitive.

49

I’m opposed to the ‘random’ placement of the arrows that results from putting system arrows on the local locations of h,j,k and l. I fully understand that individual users prefer these locations, but I think that for a broader default, it’s going to lead to a much more chaotic user experience for the vast majority of people who expect to have their arrow keys located near each other. I think arrows on the logical h,j,k and l keys for Colemak and Dvorak would be a less coherent design than leaving them on the home row, putting them on the home row shifted over by one or moving them to a cluster elsewhere.

As I said, I’d been planning to keep the arrows on R2C10-R2C13, but I’m not dead-set on that other than for QWERTY.

I’d be willing to look at proposals to put the arrow cluster elsewhere.

If there isn’t agreement on where the system’s arrow keys should be located, I’d be fine with leaving them off the printed labels, too.

50

OK – no scattered cursor labels on printed keysets. I somewhat expected this answer. I can accept that.

With that in mind, I’d put forward my arguments again regarding the inline layout of cursors for the default mapping versus a diamond or inverted-T shape – in particular, that no non-qwerty users (as far as I’m aware) would prefer them in a line since they don’t already use them that way.

My suggestion, then, would be that for any engraved layouts which don’t have hjkl in the qwerty positions, the guideline is that the cursor arrows are in an inverted-T in the right hand home position.

Advantages:

  • This is the same shape as standard cursor keys, and so intuitive for everyone
  • It means no hand movement and so everything is in its standard position for chording with the palm and thumb keys
  • If you take my suggestion for the mouse movement keys on board, it would mean the cursors are a mirror of the mouse movements on the other hand

[edit] As I pointed out in a comment later, this does cause a clash. So:

Disadvantages:

  • This causes a clash with the currently-planned position of the } key, which means braces would have to move for layouts which adhere to this inverted-T convention. I suggested (below) that braces each move one space to the left for both the default qwerty layouts and as a convention for others to mitigate this.
3 Likes
51

I would go along with this, with one modification. The mousing keys should be under the right hand, and the keyboard navigation keys under the left by default (we could have a hotkey to swap them around for lefties). Why? For the same reason that @jesse originally put pgup/dn under the left hand - because most people generally mouse with their right hand and use the left for navigation (this is one reason why gamers use WASD rather than the built-in inverted-t).

This means that a user will use the keyboard mouse with the same hand as they use a real one. It also means that the mouse button keys can be placed on Qwerty M<> (Dvorak MWV) so that they can be triggered by the same fingers that are used on a real mouse. Muscle memory and all that…

1 Like
52

As someone who has just recently stumbled into this whole keyboard-geekery thing (sorry) and who is not a vi user I would really hate to have vi-style arrow keys as the default on my keyboard. I can accept that many will like to have this, but I think the default should be an inverted-T.

3 Likes
53

I have a different reason for wanting to deviate strongly from QWERTY — my goal is to have something more modern, without destroying my ability to type on other keyboards. We’ll see how well that works…

I would definitely be interested in custom keycap labels in the future, if I can get them. I doubt anyone else would want the same labels as mine, though. I also wouldn’t want them until after I’ve had the hardware for a while; I’m certainly not going to finalize a layout until I’ve had time to use it for a while.

54

I’ve never been a vim user, and I expect the default QWERTY layout of the Model 01 to be completely unusable for me because of those cursor keys. I would prefer it if the arrows weren’t printed at all, but since I don’t plan to look at the keyboard much while typing, and am hoping for custom keycaps later on, that’s not a big deal. It might be a big minus for someone who doesn’t feel comfortable with customizing the software, though.

1 Like
55

@jesse — How certain are you that more people would want vim-style cursor keys on a QWERTY layout than an inverted-T? I would be surprised if any non-vim user would prefer HJKL, but I’d bet that most vim users are comfortable with the arrow keys on a conventional 101+ key keyboard.

2 Likes
56

Since Merlin put in $.01 and Lars put in $.01, I’ll put in $.01 too, making 3 cents and not two.

I look at the arrow incident as what is more naturally intuitive? I believe if we took someone who’s never typed before and asked them, that the inverted T would win, because up and down are opposite and stacked vertically, as are left and right on the x axis and opposite each other as well.

When you have all arrow keys inline laid out in a linear fashion, now I have to “learn” them. Is it left, down, up, right or left, up, down, right?

We could just leave the arrows off the legends to accommodate both camps. I would hate to have arrows printed inverted T if I’m accustomed to hjkl and vice versa.

57

What do the vim-style arrow legends represent? Are they actual arrow key scancodes found in the fn-layer? If so, vim users don’t need them - they will use vanilla hjkl from the unshifted layer, and non-vim users won’t like them because they’re in a non-standard arrangement.

Or do they just represent what the default action of hjkl mean in vim? In that case vim users still don’t need them (they know fine well what hjkl do), and non-vim users still don’t want them.

So I don’t really understand why they’re there.

3 Likes
58

As far as I understand it’s about placing the arrow keys (scan codes) on a second layer (FN) in the same positions typically used by Vim.

The benefit being that Vim users used to using QWERTY would easily adjust to using the arrow layout, it’s also more efficient to have all of the movement keys on the home keys rather than having to move fingers around to get all movements options.

Vim would still use the scan codes for the actual letters but since Vim isn’t like old style Vi it will also accept the arrow keys for movement which would be in the same location.

Personally I don’t use QWERTY and due to working on hundreds of systems I just use the arrow keys for movement in Vim, it’s not ideal but works well enough.

59

Indeed, but while all vim users are well used to both vim and inverted-t arrows, very few non-vim users will be familiar with vim arrows. I don’t think optimising for vim users is the best strategy here.

And I speak as a hard-boiled vim user.

2 Likes
60

I agree, I think for the default I would stick with ASDW as that’s the “most normal” entry level binding …