Default qwerty layout and how it relates to alternate layouts

Model 01 Layouts
82

@bjn, here’s what I’m responding to:

I have been insistent on this point not because I think you’ve been claiming that vim is better than what I use, but because you presented your opinions about the how natural, powerful, and comfortable it is to use your tool (as opposed to other tools) as objective and universal. There far more people who find everything about vim to be unnatural, including cursor navigation, than who find it natural. You seem to think that there’s something inherently uncomfortable about chording, but that’s not true universally, and I’m one of those people.

It is slower to type a combination of keys (but not necessarily slower to achieve the objectives of doing so). It is slower to move one’s hand farther to type a key than to type one closer to the home position (i.e. arrows vs. HJKL), but none of these things cause discomfort for all typists. It is also not easier, because there’s more to ease than how far one must move a finger. By your measure, it must be easier to type on one of Apple’s aluminum slab keyboards than an IBM Model M, because one doesn’t have to press as hard, and the keys don’t have to move down as far. I bet you’d agree that doesn’t make it easier to type on. The key combinations that I type are just as trivial as the single (but, to me, cryptic) keys that you type, because we have different training. Nor do I find them uncomfortable (as you seem to), perhaps because we employ different typing techniques. With my tools, I assure you, I find navigation in text files every bit as easy, comfortable, natural, and powerful as you do with your tools. And I’m not alone. Your tool is not as special in that regard as you think it is.

That’s the point that I am trying to correct you on.

83

After reading and rereading the last couple of posts, this argument seems kinda trivial. Its like asking what do you like better Fords of Chevys, blondes or brunettes, (and for the girls) height or abs. At the end of the day does it really matter? Whatever tools or widgets or process works best for you, great, use that.

I can only attribute this to a misunderstanding because of text only communication. Lost are inflection, facial cues, etc. @bjn merely answered my question - with I personally, denoting subjective metrics and not objective metrics.

As a non programmer and a user of vi, I don’t use ANY (arrow/HJKL) navigation. Since I am typically editing files and not creating files, I use jump to beginning of next word, jump to beginning of line, jump to end of line, and search to move around. I also don’t like alt-tabbing to cycle through my apps, its far easy to just trackball it (for me).

This doesn’t make my usage of peripherals wrong, its just different, it works for me. @bjn, staying on the keyboard works for him. @merlin, likes emacs, great. Now we could make a case for efficiency, but there are tradeoffs.

So I agree with @bjn, let’s not get into a pissing contest or start a holy war over something like my editor is better than your editor.

If anything, we should all be comparing notes w/o evangelizing. Coming up with suggestions on how to improve things given clearly defined objectives and metrics. Comfort is subjective to everyone due to how they type, arm placement, posture, desk height, etc. etc.

Its the holiday season (but even if it weren’t), let’s be a little more civil and grant each other a bit more grace.

1 Like
84

OK, how about I amend what I said before? The following makes no difference in meaning as I intended it, or in what I believe to be true (which is this), but I can see that it adds some extra clarity, which obviously was much-needed. Bolded the additions:

And then

Better? Let’s move on if so.

85

That’s still too general. Some people find chorded keystrokes less comfortable than non-chorded keystrokes. Some people experience no discomfort whatsoever from chorded keystrokes.

I now realize that my agitation comes not from your implicit claim of superiority of your chosen tools for a certain purpose, but from the fact that you either don’t believe that I could possibly be telling the truth about my own experience.

I believe that you experience discomfort from chording. From reading what others have written about this, I surmise that this often comes from stretching one’s fingers to reach two keys that are far apart with two fingers on the same hand. That’s what my 9-year-old is apparently being taught in school, as he has complained about it. I do not type that way. I never stretch my fingers to reach keys; I always move my whole hand, and in most cases, I use the modifier(s) with one hand while the other hand types the non-modifier key. I do this entirely without discomfort. With practice, you could probably do it, too, but that would probably not be of any use to you, because you’ve got different solutions to the problem that will probably work better for you.

The Keyboardio Model 01 probably makes a lot less sense for me than for most of the people on this forum, because my typing techniques are substantially different from most of yours. I don’t rest my wrists on anything when I type, because I find that uncomfortable. I don’t have any pain from typing. I like having my hands quite close together when I type. I’m skeptical that I’ll like the staggered columns any better than I like the staggered rows on “normal” keyboards. I move my hands laterally to type keys in the outer columns with my pinkies, which may make things difficult with thumb modifiers.

Yes, I may be foolishly trying to use a tool which is likely not that well-suited to me, but I’m going to give it a try anyway. And my experiences are real, and I’m not just making shit up to be contrary. I’m just asking that you don’t deny my existence or my veracity.

86

I typed a long response, but then deleted it because this is very silly and way off topic. I have not at any point denied your existence or veracity. Like you, I don’t experience any discomfort with chording, or at least the amount of chording I do. Like you, I type with without resting my wrists, and where practical I chord with opposite hands. And whatever works for you is great.

In short (and yes, this is an absurdly long example just to make the point) I am stating that ^a^b^c^d^e^f^h^h^i^j^k is more awkward/unpleasant/uncomfortable/difficult (or any other such adjective) to type than abcdefghijk, whichever way you look at it. If you disagree with that, then sure, I’m wrong, and I concede and let’s move on. If you agree with it, then we equally have nothing more to say on the matter.

87

You do realize that these two statements are directly contradictory, don’t you? I’m saying that the amount of awkwardness/unpleasantness/discomfort/difficulty in both cases is zero (for those who have practiced doing so). There is no difference on any of those measures. Zero is not greater than zero. The only measure in which they are different is speed, which is why I mentioned it earlier. It is slower to type ^c than c, but not more difficult or uncomfortable.

88

Drop it, both of you! Or start a separate thread for this argument.

9 Likes
89

I’ve been thinking that the more trivial it is to configure layouts for an end-user, the less critical some of these decisions.

For example, laying out arrows vim-style or standard-style and likewise with mouse. I imagine there are enough users on either side of that debate to warrant having some kind of built-in flagging for preferred defaults. Kind of like how with some applications you go through an initial configuration where you can make some binary (or ternary) decisions about default plugins/settings. These choices are indicative of mutually exclusive, highly contested preferences.

Of course we’re talking about how this comes by default with the firmware. As an end-user, I’d expect to see whatever is standard to a conventional keyboard by default. As soon as I plug it in and the drivers install, I’d want to see some kind of dialog where I could check some boxes or select some radio buttons to get it to be just a little closer to what I’m accustomed to. Then I could tweak via UI or firmware from there.

I think familiarity is worth volumes to everyone. To continue with the previous example, I personally prefer vim style arrows, but for many years I preferred standard-style. My preference may even change again some day. I think it’s worthwhile to respect common preferences as much as is reasonable.

1 Like
90

Lars is absolutely right and this needs to stop. We can argue elsewhere if you still want to.

91

I think what you’re suggesting is likely more complicated than you think. Having different options for where the cursors are on the function layer doesn’t only affect the cursors; it also affects whatever would otherwise be on the function layer of those keys. And if there are options for where to put the cursors, why not also options for where to put other features from the function layer? This seems to me like it will end up being a lot of combinations, and even if it’s just cursors this seems like a deceptively deep rabbit hole.

Better in my opinion to discuss any ideas, come to as much of a consensus is as possible (of course with J&K having the final word, whether or not an agreement can be made), and then use that as a recommendation for default layouts. Then the Model 01 being what it is, obviously things can be customized by each user from there.

Or maybe I’m overcomplicating things. How do you imagine it working?

92

The problem with having N different knobs is that most of the time, N-1 of those knobs will be completely unused, and just waste space on the keyboard, and make the default layout and firmware sketch all the more complicated. That, in turn, makes it considerably harder to start from the default firmware, and do something based on that.

What may help, and I hope we’ll get there, is to be able to store the layout in EEPROM, and have a way to upload it to the keyboard, with a little tool. That would make it very easy to rearrange the layout, as long as you don’t need to add extra plugins (but for moving arrows, you don’t).

This would mean that the default firmware sketch can remain reasonably simple, and instead of N pre-defined knobs, the end-user would have complete control over the layout, without having to compile anything at all. They’d just need a little program to upload the new layout, and a way to arrange that layout. For the latter, I’m working on a tool that can generate a keymap form a keyboard-layout-editor export. With that, the end-user would go to KLE, set up a layout in a browser, run a little GUI tool, and give it an URL, hit the upload button, and done. That’s it.

I believe that’s far more useful than having knobs and magic combos (those are useful too, but for different purposes).

93

@algernon

Agreed, simple minimalist design that is easily configurable by the end user would be the best. Most of the purchasers of M01 are probably IT professionals; programmers, sys ad, dev ops, etc.; to ignore their wants and needs would be foolish, but on the same token, to add so much complexity that alienates non-IT users would also be a travesty.

Keep it simple, and allow those that want configurations to easily upload a layout or edit/save configs on the fly would be awesome.

1 Like
94

Thanks, lars.

Indeed, [quote=“fishheadsoup, post:93, topic:128”]
Keep it simple, and allow those that want configurations to easily upload a layout or edit/save configs on the fly would be awesome.
[/quote]

Yup. At the moment, we’ve been focusing on making the firmware easily extensible in a way that doesn’t compromise its simplicity for newbies. One of my secret goals with all of this has been to trick programmers into teaching themselves embedded development. “Oh. This is C with helper functions? I can do this.”

The eventual goal is, of course, to have a nice GUI, but starting with nice firmware will make that and many other things easier.

I come from the Perl world, where, historically, we believe in giving users all the rope they could possibly want. The modern corollary to that involves also giving them sensible, consistent defaults, of course :wink:

95

My world is slightly different but we agree to disagree :slight_smile:

Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Readability counts.
Special cases aren’t special enough to break the rules.
Although practicality beats purity.
In the face of ambiguity, refuse the temptation to guess.
There should be one-- and preferably only one --obvious way to do it.
Now is better than never.
Although never is often better than right now.
If the implementation is hard to explain, it’s a bad idea.
If the implementation is easy to explain, it may be a good idea.

Shortened from:

5 Likes
96

I agree with at least 90% of that. The only one I would consider debating is:

But with “obvious” in there, I think I’m on board :wink:

97

@jesse: Back in #71 I gave a TLDR of this thread so far, and I don’t think things have really changed in this thread since. To repeat it:

  1. Ideally Jesse wants the top row, centre keys, palm keys, and thumb arcs to have the same functions between all “official” layouts, as far as is possible/practical. (See posts 42 and 43 above)
  2. Jesse is dead-set on printing left-down-up-right arrows on HJKL on the qwerty layout (I’m all for that because vim, but some others strongly disagree with it), but that notwithstanding I’m attempting to urge him to print them in an inverted-T instead on the right hand for layouts which do not have HJKL in a row in the regular qwerty positions. I have a lot of arguments for this above. Or not print them, but to at least recommend this as a default position for the cursors on such layouts.
  3. If the “recommended” positions for the arrows are as I suggest for non-hjkl layouts, the intended default position of the } key clashes, and so I’ve suggested moving the {} one space to the left each, for all layouts including qwerty. Yet to hear back about whether that’s acceptable. What I have in mind here mainly is consistency, which I think for default layouts is good insofar as it’s practical.
  4. There are strong opinions in both directions about whether arrows should be printed or not, no matter where the default maps in firmware put them.

Could you comment on this, please?

Over in the Dvorak thread things have started getting into where to place the various things on the function layer, but I’m attempting to stop this conversation going too far, since I think it would be best to match whatever the default qwerty function layer ends up being, as far as is practical.

But that means we need to know what that is, if possible.

So it would also be good to hear back any thoughts you have on the suggested changes, or any decisions you’ve made, like positions of brackets and braces, cursors keys, and mouse movement keys. Both in terms of final decisions on qwerty, and in terms of recommendations you have for other layouts.

In short, has the qwerty layout (and its other layers) changed at all, whether as a result of discussions here or otherwise? It would certainly affect and guide the discussion in the Dvorak thread, and I’d imagine for the other layouts too.

98

I think that one line is at the core of what differentiates between most programming languages and indeed probably few more so than Perl and Python but thankfully the world and it’s problems are diverse enough to warrant many different tools for different tasks and tool wielders :relieved:

1 Like
99

Sorry I didn’t reply earlier.

Ideally. If there is broad consensus for a change on a given non-QWERTY layout, I’m willing to take that under advisement.

It sounds like there is not a lot of consensus on arrow positions for non-QWERTY layouts. I suspect that leaving the arrows off makes more sense than putting them in one position.

I had the brackets shifted one to the left in an earlier prototype and found it to be a miserable experience. Right now, they’re aligned with the home columns. That’s where they’re getting printed on the QWERTY keycaps and positioned in the shipping firmware. If folks don’t want them printed on the other layouts, I could be sold on that.

Yup. And there’s no real way to make everybody happy. Which means that at some point, I’ll have to listen to everyone’s proposals and make some autocratic decision that’s going to upset somebody. I’m not exactly looking forward to that, which is probably part of why I’ve been avoiding weighing in.

100

So it sounds like nothing has changed at all for the qwerty layout or its function layer; is that correct?

Please also comment on the mouse movement keys thread, which I linked above.

101

That’s correct. I’ll reply to the mouse movement stuff over on that thread. Sorry I missed it before.