For QWERTY, the default position of the arrows isn’t something that’s up for discussion.
Hrrm, oookay. But in that case I would really like you to not put arrows on the keycaps. 'Cause those arrows will be moved…
@lars - This is something that has been part of the design since the very first prototypes. For the default QWERTY keycaps, the arrows will be printed on HJKL.
We’ve committed to offering blank keycaps for folks who want to design their own layouts and I’m thrilled that it looks like we’re going to be able to pull off Dvorak, Colemak and, I think, the runic/symbol keycaps, too.
It’s my hope that we’ll be able to do a bunch of other custom key legend options at reasonable prices in the future and we’ve been working with our vendors to ensure that we can. I know that no design choice will please everybody and I’m sorry about that.
Best,
Jesse
1 Like
I agree with this, but the reason I didn’t suggest it is that it would be breaking away further from the precedent set in the qwerty layout, so I’m not sure if it’d fly with J&K.
OK, something I hadn’t taken into consideration here is that the up cursor would then be clashing with the default qwerty layout’s position for the } symbol, and so alternative layouts which would adhere to my suggestion would no longer be able to have the braces in the same place as they are in qwerty.
I propose in light of this that by convention the braces would be on R1C10 and R1C11 (that’s qwerty Y and U), which is one space to the left of the current design. To be totally clear, I mean to include the default qwerty layout in this.
This in turn displaces “play/pause”, but I’m assuming the placement of that was somewhat arbitrary and so its relocation would not be a problem.
Any thoughts?
@jesse Well, that is your prerogative as this is your baby! The good thing is that it finally allows me to make up my mind; I’m going for the blank keycaps 
.
3 Likes
The more I think about it, the more I think I’ll get blank ones, too, on account of where those arrows will be on the QWERTY keycaps.
1 Like
I don’t understand why printed labels for Vim arrows is such a big deal. Vim users have been using those keys without labels for decades. If there were a single category of user that would not miss a printed label, it would be the Vim user on Qwerty.
It’s the non-Vim user that will be confused and say “where are the arrow keys?,” regardless of which layout they use.
1 Like
Just so I understand… because this thread is approaching TLDR… are we talking about the logical layout, or the printed key caps? Or both?
Proposal is to choose between (printed layouts):
Scenario 1:
print inverted-t arrows on WASD (left half)
print arrows on HJKL (right half)
Scenario 2:
Or do we want to print inverted-t arrows on the right half (and not use HJKL)?
Or print arrows in line on GFDS (left half)?
If its scenario 1, why can’t we just print inverted-t arrows on WASD AND print arrows on HJKL?
If 1 slice of bacon is good, wouldn’t too be better? And if 1 slice of bacon is bad for you, wouldn’t none be better?
If its too confusing to have arrow keys printed on, then leave them off; I’m sure the more “serious” users will map arrow keys anyway.
In regards to the default logical layout, if we print the arrows on the legend, we should program the firmware accordingly, if we do not, then we should just let the end user configure their M01 however they like it/according to their needs. Match it please, default logical layout should match what the printed key caps show.
My original intent for this thread was to get an idea of what J&K wanted to stay the same, as far as is practical, between the qwerty layout and the other default layouts.
The hope was that this would help focus the efforts to come to a consensus on the various non-qwerty layouts, by way of more restrictions. Less blue sky thinking, more practicality.
I didn’t necessarily mean it only in terms of printed keycaps, but that is presumably a more pressing concern than the subtleties of the layouts (which could be tweaked until launch time and even beyond, as long as they line up with what is printed), so it should likely be a focus.
The TLDR is essentially this:
- 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)
- 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.
- 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.
- 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.
Regarding your scenario 1, I don’t think anybody was discussing printing inverted-T arrows on the left half at all. The currently planned layout (shown on the front page of the website) is to have mouse movement keys on WASD on the function layer. I started a separate thread about these mouse movement keys which you may be interested in. In it I propose putting them at the qwerty ESDF positions instead of WASD, and the impression I got was that most users agree. But I don’t believe there are any plans to print arrows on the left half, whether in one position or the other. That could be another discussion. I’d be all for it, I think, as long as they’re on ESDF!
Your scenario 2 of arrows in a line on GFDS isn’t a good idea in my opinion – the idea of arrows in a line is largely (as far as I know) only because a chunk of programmers (those who use vi and qwerty, essentially) are used to movement actions being on HJKL, and that’s specifically there, such that having it on the left hand instead would be no good.
I don’t think anyone’s arguing against matching what is printed to the default logical layouts! 
2 Likes
Thanks for the summary @bjn.
How about (if feasible) we just print 2 sets of HJKL, one with arrows, one w/o arrows? @jesse may need to figure out if its standard or (if) additional cost(s) are involved.
And yes, while I understand that GFDS isn’t standard and probably isn’t in use at all. This is the time to rebuild from scratch, so I just threw it out there. Of course, if you don’t want to rebuild/retool, then you don’t have to; it is/would be easier to transition then to break old habits and retrain new ones.
Question for the programmers - when writing code, do you mouse/trackball at all? Or is it mostly just keyboard and you’d prefer navigation from keystrokes?
I personally am a vim user, and I think vim users especially tend to be more mouse-phobic, preferring to keep their hands on the keyboard as much as is possible. This, in no small part, is because of how natural and powerful the movements within a file are in vim, from the keyboard. As an extension to that, I control my window manager (which window is focused, moving windows around, etc) with the keyboard, and often my browser too. Though I do use my mouse for those things too. But when in an editor, it’s very rare that I touch the mouse.
1 Like
That’s very close to what I expect to program mine to be - cursor inverted T on left hand home row, mouse inverted T on right hand home row.
I’d also like to chime in agreement with those advocating leaving the cursor arrows off of the printed keycaps for Dvorak.
1 Like
I’m not a big fan of vim myself, but ever since I installed VimFx on Firefox, I’ve nearly eliminated mouse usage in my browser and have grown fond of the vi-style layout. I can of course change the bindings, but it’s hard to find something more efficient.
There are nice things about inverted-T though. One of my laptops has the PageUp and PageDown keys nestled in the gaps of the T to form a lovely little navigation block. Most programs use Ctrl+PageUp/PageDown to cycle tabs. Keeping those particular navigation keys close together is convenient in some ways. On the other hand, VimFx has tab switching set to Shift+J/K which I’ve found to be more comfortable.
The one thing that has always bugged me about the vi-style navigation is the asymmetry of the H key. It’s the only key that requires you to move a finger. Granted, it sees quite a bit less use than JKL, but it’s still a little annoying to me. It goes to show that the optimal layout depends on the most frequent use-case.
I don’t think there’s anything special about vim in this regard. Everything you said here is also true of emacs, for example. Facilities for efficient navigation using only the keyboard are a basic feature of any decent text editor.
From what I hear there’s a lot less chording in vim than in emacs and other non-modal editors, making it more comfortable for navigation.
“Less chording” != “more comfortable for all users”.
I use emacs, not vi or any of its derivatives. I know plenty of others who also use emacs, and I’m not aware of any emacs user who reaches for the mouse to navigate in a text file. I certainly despise using the mouse when editing text, and I could not find vi more awkward or less comfortable for navigation (or any other purpose). I would also not characterize emacs as a “non-modal” editor; it is extremely modal – just not in exactly the same way as vi. Yes, there’s a lot more chording in emacs (at least with most configurations), and if you find that uncomfortable, so be it. But that doesn’t mean I find it uncomfortable (not that I need modifiers to do most kinds of navigation in emacs, anyway). I’m quite happy with keyboard-only navigation in emacs; the only thing that the mouse ends up being really useful for is if I want to let someone else step in and use my editor for a few minutes (something that almost anyone can do with emacs, but only vi users can do with vim).
Just because it’s a more exclusive club doesn’t mean it’s objectively superior, or even functionally different for a trained user.
Let’s not have the holy war here.
All I was trying to say is that pressing a key without chording it is easier and more comfortable than pressing that key while chording it.
And all I’m saying is that “faster” != “easier and more comfortable”. Speak for yourself about subjective matters. I find “C-x C-c” to be faster, easier, and more comfortable than “:q!” (the only vi command I know). I haven’t made any claims of superiority of one tool over another; I’m just trying to point out that you’ve made some incorrect generalizations about things that are true for yourself (presumably), but which do not apply to everyone else.
Nobody was talking about speed.
Both sides are chording here, so it’s not a very relevant example. This isn’t what we’re talking about anyway.
Sure. Nor did I intend to. That argument is definitely not one I want to start. (Why are you?) I was pointing out that vim uses less chording, because it was relevant to what I was saying about comfort navigating a document without using the mouse.
No. Like I said in my previous comment, all I’m saying is that pressing one key at a time is easier than pressing two keys at a time. I don’t see how this is in any way subjective.
This is really silly. Go back and read @fishheadsoup’s question, which was asking whether programmers tend to stick to the keyboard or how much we use the mouse. That’s what we’re talking about; we’re not having an editor war.
1 Like