Debunking a legend about languages and keyboard layouts

[Sigmoid]

Call that "flame" if you like.
Apparently you find it difficult to accept critical comments not even directed at yourself,
but not to call someone an "asshole" based on a sheer assumption.

Wow. You actually went and cross-referenced my posts so you can make an observation about my character. I don't know what to say. (Yes, I find it highly offensive if someone actively goes out of his way to block someone on ebay after two questions based on him being a foreigner. And it wasn't directed at the guy being German. It was directed against blocking someone who was contacting him in a civil way.)

I called your post a flame because it was caustic, accusatory and clearly an attack, not on the patorjk tool, but on my opening post - which when I wrote, I was unaware of this deficiency of the tool. I assumed at worst that it decomposes accented characters and uses the base ASCII character if the accented character isn't present on the layout. Of course I was wrong. You're welcome to point that out, except Davkol has already pointed it out, so I have no idea why you found it necessary to point it out again - and to go on an angry rant about it.

Anyway. I'll probably look into retrofitting one of these tools for unicode - or writing my own.

[Madhias]

That is not only utterly non-scientific, it is just sheer nonsense. Absolutely ridiculous.

Have you just logged on and thought "wow man, what I really need right now is to flame someone"? Chill out.

That was no "flame" but just a grumpy (probably true regarding this tool) answer from kbdfr, who can - if you read a little bit here - be always at any time at any day grumpy! Actually you can say what you think here, that is not like your typical over-moderated forum

Wow. You actually went and cross-referenced my posts so you can make an observation about my character. I don't know what to say.

Well, that other topic was an interesting discussion, and there are not that many (new) threads on a daily basis, so if you read DT every day you do know what people write!

[kbdfr]

[…] I called your post a flame because it was caustic, accusatory and clearly an attack, not on the patorjk tool, but on my opening post - which when I wrote, I was unaware of this deficiency of the tool. […]

I can't help it if you just assume. Second, that my post was an attack on your opening post, which, as I already have made clear, it wasn't. First, that the tool holds what it pretends, without verifying it in the least.

Leaving the grumpy side, there is one aspect I always think is completely under-estimated when weighing pros and cons of diverse layouts: the fact that almost nobody will type in a continuous flow for even minutes on end.
Typing is one of the main features of my professional activity, which includes much more than that, so the typing itself is constantly interrupted.
Even when (this happens occasionally) I just transcribe audio files, the typing flow is more than often interrupted by pauses, so that I would say that in the end it doesn't really matter which layout you use, as long of course as it is adapted to the text being typed. The milliseconds lost by typing "d" and then "e" with the same finger when writing the French word "de" (which means "of" and is probably one of the most common French words) do not really matter, because you will soon break off typing for at least more than those milliseconds anyway.

I would compare that to driving with just over the speed allowed in order to not lose any time. You will have to stop at a traffic light anyway, or wait to allow pedestrians to cross the street, or anything like that, so in the end it will make nearly no difference to driving at just the allowed speed.

Of course using an "adapted" instead of a "classical" layout (or even, of course, an "ABCDE" layout) will yield better results, but I think as soon as you are proficient in touchtyping on any layout and it contains all characters you need, the "real life" effects will be quite negligible.

[orcinus]

Leaving the grumpy side, there is one aspect I always think is completely under-estimated when weighing pros and cons of diverse layouts: the fact that almost nobody will type in a continuous flow for even minutes on end.

This is why i could never understand layout nazis (pardon my... french? damn, i'm making it worse) and the fervour invested in layout wars. Can one layout be more efficient than the other? Certainly! Does it matter in the grander scheme of things? Not one bit. Unless all you do is count your WPM all day, or are a stenographer (in which case you likely won't be using any of the proposed layouts anyway, nor anything resembling a common vocabulary).

Ergonomics, though, are a completely different issue...

[davkol]

Eh?

Proficient typists are scarce. What if an efficient layout makes it easier/faster to master typing?
What's the impact of a layout on accuracy? If a layout promotes awkward motions or overloads certain fingers, it can be neither very comfortable, nor particularly fast as a result.

Speed is indeed directly useful only in the rather rare use cases that involve continuous data entry, but it's also a convenient measure of progress while learning to type.

[Mal-2]

I would say that in the end it doesn't really matter which layout you use, as long of course as it is adapted to the text being typed. The milliseconds lost by typing "d" and then "e" with the same finger when writing the French word "de" (which means "of" and is probably one of the most common French words) do not really matter, because you will soon break off typing for at least more than those milliseconds anyway.

I would compare that to driving with just over the speed allowed in order to not lose any time. You will have to stop at a traffic light anyway, or wait to allow pedestrians to cross the street, or anything like that, so in the end it will make nearly no difference to driving at just the allowed speed.

I disagree in a way. I do most of my writing "from my head". That is, you may have a point that my typing speed is actually constrained by how fast I can think of what to say. This is actually correct. However, when I'm typing what is currently in my head, I'm only capable of thinking just into the future and what I want to say next. I do have to stop for major shifts in direction. However, the faster I can get done typing, the faster I can get to thinking about the next bit I want to write. A second here, a second there, it adds up. However, the fastest way to shave seconds may not be in an exotic layout, but in optimizing things that take a long time but happen frequently. That's why I have a set of permanent Control+something keys. It also saves me from having to make awkward hand stretches when I'm working on music rather than text, and doing so with one hand remaining on the mouse.

I mostly use Dvorak because it's easier on my hands and shoulders than QWERTY ever was. The speed is secondary — the switch would have been worth it even if my typing speed had remained exactly the same. (I switched long before Colemak existed.) However, if I did not have the typing speed that I do, I'd be harder pressed to keep my thought flow and output synchronized, and I'd end up losing more thoughts before I could transfer them into a tangible form. This most certainly happens when I'm forced to use QWERTY and my speed is cut in half. I don't type quite as fast as I can talk, but the fact that it's at least in the same ballpark allows me to think with a similar cadence. This really helps when writing dialogue.

Also, speeding demonstrably shortens drive times if you end up making more green and yellow lights, and driving at the speed limit causes you to catch more reds. When this happens (and it does), that's a failure of traffic engineering, and should be corrected on that end. If you end up stopping for all the same lights regardless of what speed you drive, then all speeding does is annoy other people, burn more fuel, and wear out your brakes faster from having to stop harder. It can even be counterproductive if you end up having to slow down or stop for lights that are timed to let you roll through them at the speed limit.

[orcinus]

If a layout promotes awkward motions or overloads certain fingers, it can be neither very comfortable, nor particularly fast as a result.

The bold part is relevant.
Speed is not.
That was my point.

[davkol]

You explicitly stated that efficiency doesn't matter in the grand scheme of things. Both speed and comfort are only consequences of efficiency though. Speed/accuracy is easy to measure. Comfort is not. (And if a more efficient layout allows typing at a higher speed, it's very likely that improved comfort can be simply achieved by slowing down… without losing productivity compared to a less efficient layout.)

[jacobolus]

All the programmatic layout analyzers I’ve seen are based on totally arbitrary heuristics, made up by their authors with little or even no support in any kind of evidence, or even convincing reasoned argument.

What’s needed to make a reasonably scientific model is to recruit a number of very experienced and effective typists, ideally across a few different logical keyboard layouts, and record the timing of their keystrokes when handling different combinations (ideally not just trigrams, but groups of 5–6 letters at a time) of letters with high precision, and then do some thoughtful and comprehensive data analysis, trying to figure out which letter combinations are fast or slow, accurate or inaccurate, and how the speed and accuracy relates to other factors like the break-down of a text into sentences, words, syllables, and common character combinations. Ideally high speed video would be captured, so that particular notable patterns in the data could have the associated hand movement patterns directly observed.

The reason this is necessary is because different typists have different fingerings for particular keys (or even varying fingering depending on context) and I suspect different ways of chunking up sentences and words into finger movements. By looking at the way typists who use different logical layouts deal with the same text, it should be possible to learn the way that word spelling chunking interacts with typing motion chunking, and figure out how to best align the two on a keyboard layout. Furthermore, it should be possible to learn (with evidentiary support) which finger motion combinations are most natural or most awkward for experienced typists at high speed, and to analyze the differences between different typists who use different fingering patterns, hold their hands differently, have different hand size/shape, etc.

But the existing layout analyzers have models such as measuring the physical distance in millimeters from the “home row” key for each finger to each other key, and then using that distance as a proxy for typing difficulty, arbitrarily assigning different fingers a score and then scoring keys based on which finger is used, arbitrarily assigning different rows on the keyboard a score, giving an arbitrary score to two-letter combinations on different hands vs. the same hand, giving a score based on the percentage of letters typed with one hand or the other, etc. All of these measures are complete crap, and should not be used for any kind of serious purpose. They have no typing data to back them up, but are purely conjectural.

The carpalx method, to take one example, is a total joke. It has no reasonable basis for any of its scoring model, but it masks that by making the model so complex to understand that it’s impossible to guess what the relative scores will be for two letter combinations without explicitly working out the details. (Then if you actually compare specific combinations of letters and do work out the details, the scoring bears no relation whatsoever to real-world experience typing the same combinations on a physical keyboard.)

[orcinus]

You explicitly stated that efficiency doesn't matter in the grand scheme of things. Both speed and comfort are only consequences of efficiency though.

No, they are not. They can affect one another, but they are not coupled by default.
They do not map 1:1.

Speed/accuracy is easy to measure. Comfort is not.

Are you saying we should strive to improve only those things that can be easily measured?
Silly me, i thought this is about day-to-day use, not WPM tests and heat maps from synthetic corpora.

Look, i'm not saying an increase in speed doesn't signify an increase in comfort.
I'm saying that it does not *necessarily* signify an increase in comfort. And so far, everywhere i've looked, that's the only indicator that was being used to judge the merit of a particular layout. Yes, comfort is hard to quantify, but it's extremely easy to qualify - does it feel better or worse (to you, the layout user)

There's plenty of "hidden" pitfalls to a layout that you might not glean simply from the increase/decrease in speed. The ring and little finger action, for example, might be more efficient in a particular layout, but end up more tiring in the long run. Increased use of chording for some characters might be more efficient in the short run, but end up being an ergonomic nightmare. Heck, user's own hands might be used to favouring particular fingers far more (than average), rather than using them in accordance with some standard, somewhat even model.

Yes, at the extremes/poles (think Datahand), reducing the motion (i assume that's what we're both calling "efficiency" here, but i might be wrong) does equate speed to comfort. But there are some very shady areas in between.

[orcinus]

(NB: all of the above pulled out of my arse - meaning based purely on personal opinions and with 0 citations.)

[kbdfr]

I am pleased to see that now a more relevant discussion is taking place - not about which layout supposedly allows "better" (i.e. faster/easier/more logical/more comfortable/etc.) typing, but about whether it is at all possible to define valid criteria which will allow such a definition.

There are a few such things which I think are usually omitted when reflecting on typing performance:

• the impact of mouse use, i.e. of occasionally removing the hands from the keyboard
• the impact of Ctrl/Fn/whatever combos in terms of physically slowing down typing
• the impact of such combos in terms of having to retrieve them from (mental) memory
• the impact of possible misstypes when typing numbers on the number row instead of the numpad
• name more

All those points do not relate primarily to the keyboard layout (in terms of which characters are on which keys), but more to the physical configuration, including the keyboard's form factor.

[GuilleAcoustic]

Hi fellow Deskthorians, I feel like joining the discution too. Hope you don't mind it .

I recently moved from AZERTY to Ansi international. While it was better at the begining to enter accentuated characters, it's slowly becoming frustrating. The dead characters and composing allows all letters, lower or upper case é É ç Ç but it's really not comfortable for long typing session.

A day worth of typing is like 50% english / 50% french with a mix of coding and writting. Writting is either casual or professionnal (read wall of documentation) and either in french or english.

Neither AZERTY nor QWERTY / US inter suits me to be honest. Both have pros and cons, and while US inter allow me to write proper french (read upper case accentuated characters), it's a PITA to do so. Maybe bépo could be a solution, as anyone tested it for writing and coding ? Both english and french ?

[pietergen]

1. Please read the many keyboardlayout discussions on colemak.com, geekhack , MTGAP, the ADNW user group and Carpalx.

2. Keyboard layouts are an exercise in compromise. Most layouts want to have
- much used keys must be at easy to reach positions, the most used keys should be on the home row (or close to it)
- low same finger use
- low row jumps, low home jumps
- hand balance (left hand 50% of the effort, right 50% of the effort),
- a certain distribution over fingers (pinky, ring, middle, index)
- certain finger sequences are wanted / not wanted - Dvorak tries to avoid adjacent finger use, especially pinky<-->ring. Colemak wants adjacent finger use, they call it "rolls"
- some optimal hand alternation, for instance 2 strikes left, 2 strikes right (LLRR, on a qwerty board this would be for instance AFKL)
- prevention of long one-handed strings (like stewardesses on qwerty). All layouts WILL have akward words, the task is to reduce this to the minimum (btw, minimum is another qwerty long string)
- optimized for everyday use, meaning one or more languages, code, spreadsheet work, browsing, etc.
Good luck optimizing for all aspects in one layout!

3. Offline tools I know of that calculate and assess layouts: carpalx, adnw, mtgap. All of them have questionable criteria and weights. Of course, carpalx rates the carpalx-layout best, adnw will give most points to adnw-layouts etc. My completely subjective feel is that ADNW is the best. But please feel free to have a different opinion
Mtgap yields Colemak-like layouts; Adnw gives Dvorak-y layouts.

4. Typing shortcuts combos with one hand puts strain on the muscles, may induce RSI. ctrl-z; ctrl-v and so on are better typed 2-handed. Having 'nice rolls' usually means also having more 'akward clusters'

5. Colemak seems easier to learn than Dvorak and is definitely better than Qwerty. This differs per language though. For Dutch, Colemak is not very good. And Dvorak seems to be better for German than for English (although it was made for English!).

6. My own preference is ADNW. " Stock" ADNW is optimized for a mix of German and English. Other versions exist for German only or English only. I calculated a version for my personal use, which is (mainly) a mix of Dutch and English.

7. As always, think for yourself, feel free to differ

[kbdfr]

[…] Most layouts want […] the most used keys should be on the home row (or close to it) […]

Taking just this example, I wonder if this "rule" is based on more than a "isn’t it obvious?" feeling.

One could as well find that on the contrary, it is advisable to make as much use as possible of e.g. the pinkies in order to have them well "trained", instead of trying to use them as little as possible, which will result in them having less accuracy and less strength when they are needed and thus considerably disturbing the typing flow.

I’m not asserting that, just trying to question well-established and seemingly unquestionable assumptions.

By the way, excellent examples for that are the Backspace and left Shift keys.
Most users prefer a 2u Backspace because a 1u key is "difficult to hit", but getting used to a 1u Backspace is no problem.
The 1.25u ISO left Shift is widely used without any problem, while most ANSI users wouldn’t want to shorten their 2.25u left Shift even though they could then have one more key.

[Sigmoid]

- certain finger sequences are wanted / not wanted - Dvorak tries to avoid adjacent finger use, especially pinky<-->ring. Colemak wants adjacent finger use, they call it "rolls"

I think everyone who has learned to type on a typewriter understands this. I first learned to type on a portable mechanical typewriter when I was 6. It was ridiculously heavy, especially for my fingers as a little kid. You don't want "rolls" on a typewriter - they wouldn't "roll" very well.

In contrast, on a low-profile Macbook keyboard, a "roll" is one of the most comfortable moves in my experience.

4. Typing shortcuts combos with one hand puts strain on the muscles, may induce RSI. ctrl-z; ctrl-v and so on are better typed 2-handed. Having 'nice rolls' usually means also having more 'akward clusters'

Mouse use really messes this subject up actually.

[Mal-2]

[…] Most layouts want […] the most used keys should be on the home row (or close to it) […]

Taking just this example, I wonder if this "rule" is based on more than a "isn’t it obvious?" feeling.

One could as well find that on the contrary, it is advisable to make as much use as possible of e.g. the pinkies in order to have them well "trained", instead of trying to use them as little as possible, which will result in them having less accuracy and less strength when they are needed and thus considerably disturbing the typing flow.

I’m not asserting that, just trying to question well-established and seemingly unquestionable assumptions.

By the way, excellent examples for that are the Backspace and left Shift keys.
Most users prefer a 2u Backspace because a 1u key is "difficult to hit", but getting used to a 1u Backspace is no problem.
The 1.25u ISO left Shift is widely used without any problem, while most ANSI users wouldn’t want to shorten their 2.25u left Shift even though they could then have one more key.

1. Clarinettists have to "train" their pinkies a lot due to the nature of the instrument. There are at least four keys under the command of each one, and often five or six. It helps that most of these are deliberately duplicated in both so that they can alternate duty, but the fact remains that repetitive stress is more of a problem on clarinet than it is on, say, flute or saxophone, because so much of the work is being done by weaker fingers. You can (and will) develop the speed, but that doesn't change the fact that the tendons really weren't meant to do that so much. Violinists (and to a lesser extent, violists and cellists) also have this problem because the pinky is the finger with the greatest reach up the fingerboard, especially once you get past the point where the thumb can sit on the back of the neck.

2. A 1U backspace is easy enough to hit if and only if there is space to the right of it. If there is a keypad immediately adjacent to it, it makes it much harder to get used to. My backspace is 1U, but it's on the far right of the entire keyboard. Over-reaching means an airball. When I had the number pad there, I had to assign that position to Num Lock and put a rubber band under the key to make it hard to press because I was hitting it constantly.

3. It's not the length of left Shift that concerns me. Make it 1U for all I care (both of my Shifts are 1U, I have a matrix keyboard). Just don't move it further out to the side, increasing how wide I have to spread my fingers to use it. If you want to add a key there, add it on the outside. I've seen a few keyboards that did this, and they weren't kezboards. Similarly, if you want to cut 1U off the outside of Right Shift and put a key there, go right ahead. It won't affect my use of Shift one bit. In fact it would make it more stable by virtue of being smaller.

I'm to the point where I kicked [ and ] out of the main alpha area to pull the right side in one column closer (another reason the small Backspace is less of a problem, it's closer), which also necessitated moving =+ back to its QWERTY position in the number row rather than row 2. They're still accessible (in the modifier row), but also AltGr'd onto 9 and 0. Sometimes one is more convenient, sometimes the other. Both are admittedly a bit slower than usual, but the only time I use them is typing pseudo-HTML on forums.

4. Typing shortcuts combos with one hand puts strain on the muscles, may induce RSI. ctrl-z; ctrl-v and so on are better typed 2-handed. Having 'nice rolls' usually means also having more 'akward clusters'

Typing them one-handed is still better, provided they're mapped to dedicated keys which don't require the use of a modifier. That's the best of both worlds.

I am reminded of a lesson I received as a bad golfer. If you want to shave strokes off your score RIGHT NOW, don't go to the driving range, go to the putting green. Optimize what you do the most, first, until there's nothing left worth squeezing out of it. Then move to what you do next-most. That's not to say you shouldn't work on driving, or that it's not fun to whack a bucket of balls to blow off stress, but it's not going to show up on the scorecard nearly as quickly.

[jacobolus]

Taking just this example [of recommending home row use], I wonder if this "rule" is based on more than a "isn’t it obvious?" feeling.

It’s not based on anything more than that. Also note, on a standard keyboard the “home row” is only very roughly where the fingers sit while in a neutral relaxed position. Personally I think prioritizing particular rows rather than looking at keys on a case by case basis is a mistake.

One could as well find that on the contrary, it is advisable to make as much use as possible of e.g. the pinkies in order to have them well "trained", instead of trying to use them as little as possible, which will result in them having less accuracy and less strength when they are needed and thus considerably disturbing the typing flow. I’m not asserting that, just trying to question well-established and seemingly unquestionable assumptions.

This seems pretty implausible.

By the way, excellent examples for that are the Backspace and left Shift keys. Most users prefer a 2u Backspace [...]

Actually the backspace, right shift key, and ISO left shift are all terribly positioned. There shouldn’t even be keys in those positions on the keyboard at all, and certainly not such important ones. 2u vs. 1u top corner backspace is like poking one eye out vs poking both eyes out.

[Mal-2]

Actually the backspace, right shift key, and ISO left shift are all terribly positioned. There shouldn’t even be keys in those positions on the keyboard at all, and certainly not such important ones. 2u vs. 1u top corner backspace is like poking one eye out vs poking both eyes out.

Backspace is the easier problem to solve. The Colemak "turn CapsLock into a Backspace" concept works without changing anything else. I use it on a Dvorak layout (in addition to the original Backspace, not in place of it), but I moved CapsLock rather than eliminating it entirely. I use it to generate another layer through the OS via the SGCAP function, which primarily allows me to overlay a numeric keypad onto the alpha area even though the Cherry programmability does not allow for this. (It doesn't do layers at all. Any key that isn't a straight-up scan code is a single-function macro.) I also use it to generate lookalike characters (а for a, о for o, і for i, etc.) to get around some really stupid word filters in various places. (For example, one 8chan board thought it would be cute to word-filter all instances of "moot" into "cuck", which means the word "smooth" gets automatically changed to "scuckh".)

On a keyboard with Fn and the ability to define the function of keys, it shouldn't be too off-putting to move CapsLock to FN+its current key, and reclaim the base state for Backspace. I can't do that, but I do have plenty of other places to put it. Since I primarily use it as a Number Lock, and I have a 1U "real" Num Lock key (but don't have a 1U Caps Lock), it's marked Num Lock but it's really Caps Lock and lights the "A" indicator LED, not the "1".

Shift has legacy reasons for being where it is. On typewriters with type bars (both manual and electric), pressing Shift actually lowers the carriage so that the character at the end of the type bar hits the paper rather than the one lower down. This is made much simpler mechanically by pushing said Shift keys out to the far left and far right. Backspace may have similar mechanical reasons for being at the edge. At the very least, it's a tough key to press on a manual typewriter, as you have to provide enough force to oppose the carriage spring to move it backward. You aren't going to be doing that with your pinky unassisted. (You also had to use some sort of correction ribbon or white-out for every error.) Return/Enter wasn't even a key until electric typewriters came along, you had to use your entire arm (and the left one, not the right) to throw the carriage all the way back to the beginning, simultaneously advancing the paper one line and re-loading the spring so that the carriage would once again move one space left with each key pressed.

[jacobolus]

Here’s my proposal for a minimally altered QWERTY layout which fixes the worst problems with the standard IBM (ANSI/ISO/whatever) layout without fundamentally changing the shape of the keyboard:



Backtick & equals (and somewhat 1, 6, 7, & minus) still suck to reach, but most of the worst keys on ANSI (backspace, escape, right shift, backslash, control, meta) have been fixed, not to mention the ones that suck on ISO (enter, left shift), and the only keys moved to a different region of the board are the brackets.

Obviously it’s possible to do better with a split-hand column-staggered board, but this version should be very fast and easy to learn, for someone used to the standard keyboard. Also, it’s about the same size (or even a bit smaller) than a standard TKL, and much better centered.

[Mal-2]

Here’s my proposal for a minimally altered QWERTY layout which fixes the worst problems with the standard IBM (ANSI/ISO/whatever) layout without fundamentally changing the shape of the keyboard:

What you did with the [ ] keys is not too far off what I did with them. However, I have reason to believe the placement of the Ctrl keys would not work out well at all. I find that any key below my spacebar gets inadvertently pressed at least some of the time, because the thumbs come down rather parallel to the plane of the keyboard rather than poking into it like the rest of the fingers. What could work is to put the spacebar below the modifier row. Also, instead of two adjacent Ctrl keys, why not just one big one?

I understand that you made Space and Backspace the same size so they could be interchanged, but personally I need to press Space with both thumbs: with the right when typing (unless my right hand is out of position), and with the left when gaming. I left Shift in Row 4, but made it equidistant in both hands: one out and one down.

dv-right2.png (48.9 KiB) Viewed 7780 times

I leave the lenses off the spacebars (they're really the + and numpad Enter keys, rotated 90 degrees) so they sit a few millimeters lower than the modifier row, which means I can thumb any of the center four buttons without being so likely to press a spacebar. The other vacancies are deliberately chosen to avoid accidental keypresses by the heels of my hands, or in the case of the arrow keys, to make it easy to locate without looking. I leave Alt/AltGr closer to center so that either hand can use either one. This neatly dodges one problem of sacrificing Right Alt for AltGr, having to make awkward hand stretches, and does likewise for AltGr, which can otherwise only be done with Left Ctrl and Left Alt at the same time (which can and sometimes does induce ghosting due to a lack of rollover, especially when you need Shift on top of that).

The cursor pad could be off to the right without significantly affecting the core concept, but I wanted to get my normal right hand position as close to the mouse as possible. It also turns out that being able to use the mouse and the cursor keys at the same time is rather nice. I can also hold Shift with my left thumb and highlight selections with the cursor keys, but this would be equally possible to do with the right thumb if the pad was on the other side.

This is not a paper layout or speculation, either. I'm typing on it right now, and have had it set up this way for a few days now. I had a few hiccups at first, mostly pertaining to reaching right for the cursor keys, but I've really gotten to like having them on the left. They're not just taken out of the space between right hand and mouse, they're actually more useful over there.

[jacobolus]

However, I have reason to believe the placement of the Ctrl keys would not work out well at all. I find that any key below my spacebar gets inadvertently pressed at least some of the time, because the thumbs come down rather parallel to the plane of the keyboard rather than poking into it like the rest of the fingers. What could work is to put the spacebar below the modifier row. Also, instead of two adjacent Ctrl keys, why not just one big one?

Keys in the spacebar row need to be extra tall, and the keys in front need to be quite low. It works great.

For example:


(Even if they’re the same height though, it’s mostly fine; notice that on my proposed design the spacebar extends quite a bit to the side of the keys in front.)

Two ctrl keys because you might want to remap this keyboard to a different layout.

[jacobolus]

This is not a paper layout or speculation, either. I'm typing on it right now, and have had it set up this way for a few days now. I had a few hiccups at first, mostly pertaining to reaching right for the cursor keys, but I've really gotten to like having them on the left. They're not just taken out of the space between right hand and mouse, they're actually more useful over there.

Your keyboard has like twice as many keys as I ever expect to need. I don’t think I could handle the confusion, and I dislike straight matrix boards, but I’m glad it’s working for you.

[Mal-2]

Keys in the spacebar row need to be extra tall, and the keys in front need to be quite low. It works great.

(Even if they’re the same height though, it’s mostly fine; notice that on my proposed design the spacebar extends quite a bit to the side of the keys in front.)

Having to curl my thumbs in to press the spacebar without accidentally the row below is not my idea of "mostly fine". The differing heights isexactly what I am doing to give the necessary clearance, I've just switched the order around.

Two ctrl keys because you might want to remap this keyboard to a different layout.

That I can understand. I still find it quite comfortable to drop the spacebar(s) one row and pull the mods into the middle.

Your keyboard has like twice as many keys as I even expect to need.

Yet it's the width of a normal TKL. It's deeper, but that has zero impact on where the mouse ends up.

You admittedly don't need the green, blue, or Macro keys to make a basic layout, but I have that space and I see no reason not to use it. The green keys are particularly specific to my needs, but they could be used as still more Ctrl+something keys or longer macros.

I don’t think I could handle the clutter/confusion, and I personally despise straight matrix boards, but I’m glad it’s working for you.

It doesn't have to be a matrix, though that certainly makes the concept easier to implement without having to roll your own from scratch.

As for clutter, all you need are the red and yellow boxes, and the cursor section would probably be on the other side for most people.

[jacobolus]

For me, the ideal keyboard needs about 60 keys (I could get by with <50 probably). That’s all that can be comfortably reached without moving the hands. The overall physical dimensions (assuming I’m using this on a desk and not carrying it around in my bag) doesn’t really matter too much.

Your keyboard has 120 keys, or 90 in the red + yellow boxes. That’s way too many for me.

More importantly, any key which requires hand motion IMO must be easy to feel out, without needing to look at it. Big undifferentiated grids of keys are in my opinion the absolute worst, especially when the keycaps are all uniform and reasonably flat. Instead, functional groups should be limited to about 4–6 keys each, and separated by lots of space.

If for whatever reason you absolutely need a gajillion extra keys, they should be something like:


(Note: I’m not trying to be too negative or make this discussion personal; as always, people should use whatever suits their preferences. I’m just explaining what my own biases & preferences are. Hope I don’t give any offense.)

[Mal-2]

Big undifferentiated grids of keys are in my opinion the absolute worst, especially when the keycaps are all uniform and reasonably flat.

I agree with you. This keyboard came with nothing but flat-topped relegendable keys. Touch-typing was utterly impossible. It was like trying to touch type on a laser-projected keyboard. It was a uniform wall of keys, I could barely even discern the spaces between them. That's why I had to steal the "real" keys from the other G86 keyboard I have. This makes all the difference in the world. It took what felt like a cash register and made it feel like something designed for typing.

That's also why I have bumps on U and H, the empty spaces in the cursor pad, Escape standing 3 mm higher than everything else, lenses on just four of the Function keys (so I can feel the groupings without having gutters), and a piece of cardstock in the crack between the cursor pad and the alpha area (so I feel it instantly if I wander too far over). The separator card was a lot easier to see when it was a piece of a credit card and wasn't black, but that first attempt was too thick and caused the adjacent keys to make scratchy noises. The current separator is a bit too thin and has a tendency to rise up out of the crack. I still have yet to find the ideal separator, but it's the best I can do without having a gutter. A gutter would be preferable (like .25U) but since I didn't build the keyboard from the ground up, there's not much I can do about that unless I want to leave an entire blank column. (I tried that, the card works just as well and saves reaching.)

My "non-optional" keys number 90 versus your 82. I don't see that as dramatically different. Three of them are PrtSc/ScrollLock/Pause which you have omitted. One more is a duplicate Backspace. That means I'm really only incorporating four more core keys than you are. One of them is due to splitting the spacebar, which I do mostly because I don't have any 4U keys. That reduces the number to three.

I've tried to make the point that despite ending up in considerably different places, we started out with many of the same intentions. Different opinions on how thumb keys feel and should be used led us to invert them relative to one another. You don't like a matrix. I thought I wouldn't either, but found it to be completely natural once I centered it properly. The alpha area of a normal keyboard, even a TKL, is pushed out to the left. This makes the stagger help to compensate for the fact that all reaching is itself slightly slanted, so it feels somewhat natural. Once I squared up the alpha section dead in front of me, the lack of a stagger felt natural in a matter of hours. In both cases, I raise my elbows to reach up the keyboard, and lower them to drop down.

I've toyed with the Function keys being on the left, AT-style (except twelve rather than ten). I've played with them being in a 3x4 group, a 4x3 group, and a 2x6 group as you have them. Frankly, they're all acceptable. The reason I have them where they are is simply that I have twelve spaces there that I'm not otherwise using, and nothing else fits neatly into those twelve spaces. If I needed to drop a row off the top, moving those to the left would be a quick and easy way to do it, but I don't need to.

[kbdfr]

I always wonder what a holy fuss is made about optimizing keyboard layouts
when still using a pointing device not placed in the middle.

[Mal-2]

I always wonder what a holy fuss is made about optimizing keyboard layouts
when still using a pointing device not placed in the middle.

Trackpoints have their place but I personally can't use them as precisely or as smoothly as a mouse or trackball, or even a trackpad. I wouldn't mind having one, but they do wreak havoc on the relocation of keys for alternate layout, and having my keys match reality is far more important to me since I need the mouse out there anyhow. I'm much too twitchy not to have one, because when I need that single-pixel precision, it is much simpler for me to white-knuckle and use muscles in opposition to overcome shaking. Tiring, but simple.

Also, the relative importance of pointing device location changes depending how often you have to reach for it, and what you do once you have it. If it takes one second to grab the mouse and one second to get back in position, and you're doing this every five keystrokes, it's probably worth trying a trackpoint. If you're doing this every few hundred keystrokes, not so much. Also, time saved reaching is not so valuable if it is then burned by being slower with the device itself. I have a trackpad under my right pinky. I have it disabled at the Device Manager level because it is not very useful. The only place I use a (very large) trackpad is with my wireless keyboard, and I don't attempt to do any serious work with it. Even then, I tend to get very frustrated with my inability to precisely control the pointer. It's not the device's problem, nor the hardware settings. It's that the easiest way to overcome my own shaking is to squeeze harder. I can't do that with an empty hand.

[bhtooefr]

Regarding keyboard layout analysis, I think a keylogging analysis tool would likely be best, that gives time stamps. Bonus points if there's a camera aimed at the keyboard that's also analyzing which finger is in use, to give more accurate weighting.

Of course, the comment about rolls and how they're affected by the different keyboards is an interesting one, too. A Model M won't roll as well as a MX blue (which has higher actuation IIRC), which won't roll as well as an Alps SKCM (which has both higher actuation and shorter travel), which won't roll as well as a short-throw scissor-stabilized board (the one I'm using right now has less travel than a Model M takes to get to its actuation point).

[kbdfr]

I always wonder what a holy fuss is made about optimizing keyboard layouts
when still using a pointing device not placed in the middle.

Trackpoints […] [lengthy considerations about own problems with those as well as mice and trackpads]

That's not my point, I'm not arguing in favour of a particular device.

What I'm saying is that one cannot seriously argue about [milli]seconds lost or won through a particular layout
where keys and/or whole clusters are placed in order to optimize typing speed and accuracy
and at the same time not consider the time lost moving a whole hand to the side (and then back to the home position).

Perhaps you will have noticed that I have precisely not been taking my (quite) particular layout as a reference.
What I'm interested in is general criteria, such as (see my previous post)
reliability when touchtyping numbers on a numpad vs. the number row
or the time impact of having to retrieve combos from memory.