Keyboards need more alpha keys! But where to put them? How about in the middle?!

User avatar
depletedvespene

15 Jul 2019, 05:24

Obligatory disclaimer: I'm an ignorant doofus who doesn't know anything about anything! And my feet smell of xenon dichloride!

So I've been perusing keyboard pictures here and there, definitions for national layouts here and there, GMK keycap sets here and there, keyboard form factors here and there... and one thing I always come to is the pressing need for more alpha keycaps. And not just in the sense of the well-known problem of the 60% keyboards, where the ESC key and the BACKQUOTE key (the one with ` and ~ on the US English national layout) compete for the same place, or the need in European layouts to retain the NON-US BACKSLASH key (the one between LSHIFT and Z — its presence forces the former to be rather small, something ANSI users hate with a passion)... but in a more worrying sense: there are too many letters and symbols that need to be typed and not enough keys for them. It's not too bad in US English, but Western European languages hit a limit, and Central European languages suffer.

What to do? A full alpha row above the number row is unfeasible (in the sense of actual usage once a keyboard with it has been built). Extra columns on either side of the alpha block is also unfeasible, as that places too much effort on the pinkies. Some orthogonal layouts free up the number row by putting the numbers in a center numpad, another unfeasible thing to do in a normal, staggered keyboard.

The separation of the AltGr key, so keyboards will have four proper layers, is a must — but that isn't coming anytime soon (and that's maddening)... but there's one more option, one that hasn't been explored and could be interesting to consider, even if just as a thought exercise: what if we add alpha keys in the middle of the alpha block?

The core idea of this exercise is to insert four new alpha keys, between the columns 5TGB and 6YHN of the alpha block. Both those columns signify the limit of each hand's domain, so this new column could be used by extending the index fingers a bit further. On a staggered keyboard, this would mean that the left index finger would comfortably reach the new keys in R1 and R2, the right index finger would comfortably reach the new key in R4... and the one in R3 would be equally easy for both (so we should establish that right-handed users will use their right hand for it, while lefties will use their left hand).

Theoretically, this should not look like an exceedingly radical change, it would allow the retaining of MOST of the muscle memory the user already has and, by allowing a slightly larger separation of arms and hands, would be somewhat more ergonomic.

While we're at it, let's add a few extra requirements to this idea:

1) The BACKQUOTE key needs to be moved to this new column (or wherever else), so the top-left key can go back to being a mod. The 60% form factor could solve the Esc problem once and for all... and on the larger form factors, this key should be Back Tab, a formerly quite useful key that fell out of favor in the '80s and is sorely needed again (unlike Num Lock, who was born in the '80s and keeps on living despite it needing to die already).

2) The NON-US BACKSLASH key needs to disappear; in both "ANSI" and "ISO" variants, the LSHIFT and Z keys will be contiguous (therefore, the only difference between those will be about the Enter key and the accompanying BACKSLASH key).

Everything else should look more or less the same, except for some necessary, obvious adjustments.



Let's fire up KLE, load a TKL form factor (there won't be any differences on the alpha block for full-size and larger) with the US English national layout and tinker a bit.

TKL ANSI with extra column (US English national layout).
TKL ANSI with extra column (US English national layout).
DT_01_TKL-ANSI.png (49.04 KiB) Viewed 3092 times

In this first approximation, we can see that this TKL looks like a... TKL.
  • The four light grayish blue keys in the middle of the alpha block are new.
  • The top left key in the alphablock is now a Back Tab key.
  • LSHIFT is untouched.
  • The function row now has plenty of space, enough to add a new 1U key there (since it definitely can't be F13, for the obvious reasons, we'll leave that for later). Note that it's now symmetric.
  • The US English layout remains essentially the same, with the only changes (marked in red) being that the BACKQUOTE key (containing ` and ~ ) has been moved to R4 in the middle column, and that I chose to move the plus and minus signs to the base layer, right between the numbers, because why not?
  • Green squares signify newly available positions on both the base and the Shift layers (the AltGr layer remains unused, obviously).
  • Tsangan-style bottom row, because we're civilized people here. The space bar would have been 8U, so I chose to split it into two 4U keys for now (more on this later on). Note that the bottom row is fully symmetric, and while the space bars aren't symmetric to the alphas themselves, they're both positioned with the same offset with respect to the homing keys on each side (F and J).


It's rather dashing so far! So let's see how this goes if we go with a smaller form factor. First, a 75%:

75% ANSI with extra column (US English national layout).
75% ANSI with extra column (US English national layout).
DT_02_75PC-ANSI.png (43.64 KiB) Viewed 3092 times

ANSI style again, alphas untouched. In the bottom row, the space bars have been shrunk to 3U, to accomodate the Fn key and the leftshifting of the RALT and RCTRL keys. The one thing I don't like of this layout is that the correspondence between the numbers and the F keys is lost after F5.

That said, some people have taken to use 0.25U separators in the F row of normal 75% keyboards... and in this wider form factor, this can be pulled off with little pain.

75% ISO with extra column and enlarged Fn key (US English national layout).
75% ISO with extra column and enlarged Fn key (US English national layout).
DT_03_75PC-ISO-Fn-alargado.png (44.92 KiB) Viewed 3092 times

The separators indeed solve the above problem.

Note also the ISO Enter key and the enlarged Fn key (with the space bars reduced to sizes that will look familiar to many).


What about a 60%?

60% ANSI with extra column (US English national layout).
60% ANSI with extra column (US English national layout).
DT_04_60PC.png (33.99 KiB) Viewed 3092 times

Whisk off the Win key to a side, put Fn keys where they belong, and it looks pretty usable! The only issue here is, again, the loss of contiguity between F5 and F6 (and it would probably be wise to ensure that that Fn-key assignment in between stays unused).

It's quite tempting to move the \ and the | characters to the middle column, make the 1.5U key an HHKB-style backspace, split the 2U Backspace key and put Insert and Delete there... but that should wait until a revised US English national layout is actually produced.


———————————————————————————


So I keep talking about form factors while using only the US English national layout (the ANSIest of them all), but what about ISO-based European layouts? Let's choose one, like, totally at random and stuff:

Regular TKL ISO (Spanish (Spain) layout).
Regular TKL ISO (Spanish (Spain) layout).
DT_05_TKL-es-ES-normal.png (45.53 KiB) Viewed 3092 times

The BACKQUOTE key has three symbols: º ª and \ ; the NON-US BACKSLASH key has two more: < and >. The five of them need to be moved because the former key is becoming a mod and the latter is disappearing. ALSO, I'm going to move the Ç letter, because the place it was assigned to back in the day is so piss-poor you can't actually write "URINE" with it.

TKL ISO with extra column (Spanish (Spain) layout).
TKL ISO with extra column (Spanish (Spain) layout).
DT_06_TKL-es-ES-con-columna-extra.png (50.09 KiB) Viewed 3092 times

Note how I repeated the moving of the minus sign and underscore characters (this time from its position at R4 instead of R1) and placed the plus sign and the asterisk immediately below. Only three green squares remain, instead of five (but do remember that the AltGr layer can be put to further good use).

The location of the Ç will surely be a matter of controversy for decades, but at least it's now among the letters, as it should be (don't get me started on the location of the interpunct, though).


———————————————————————————


As I kept testing this on different form factors, I came on to my own left-Enhanced layout. It's surprising, but not too surprising, how well it fits the idea of adding an extra column of alphas:

ISO Left-enhanced with extra column (Spanish (Spain) layout).
ISO Left-enhanced with extra column (Spanish (Spain) layout).
DT_07_left-enhanced-ISO.png (64.92 KiB) Viewed 3092 times

That unused key on the top right? Perfect place for Insert. Back Tab can't be on the top left, so it goes to R3, to Insert's former place to the left of Caps Lock. Note the modernized numpad.

This left-enhanced keyboard is still WKL and proud of it... but some people actually need the Win key, and some people don't really like split space bars, so let's see an alternative:

ANSI Left-enhanced with extra column (US English layout).
ANSI Left-enhanced with extra column (US English layout).
DT_08_left-enhanced-ANSI.png (64.92 KiB) Viewed 3092 times

This ANSI version of the left-enhanced keyboard sports an unsplit 7U space bar, symmetrical to the homing keys; between it and RALT, there's a single 1U Win key — in a place that will be both easily accessible and not a nuisance. So, Winkey-sporting WKL tsangan-like bottom row (and no Menu key whatsoever)? Ain't this great?




Sure, but what about the TKL form factor? As many of you know, I'm of the opinion that 75% form factors and under need a split space bar, while TKL and over don't really. So let's transport that unsplit space bar and that Insert key back to the TKL we saw first:

ANSI TKL WKL-WANG-unsplit with extra column (somewhat revised US English layout).
ANSI TKL WKL-WANG-unsplit with extra column (somewhat revised US English layout).
DT_09_TKL-ANSI-WANG.png (48.98 KiB) Viewed 3092 times

Same bottom row as the second left-enhanced keyboard; the Insert key has been placed to the right of F12 and the Delete key enlarged to a WANG-style 2U vertical key, a quirk some people really like.

I also took a second look at the US English national layout and made a few changes. The minus sign has been moved back to its original location. The plus sign is still on the base layer, but now on R1, between 5 and 6. The underscore is now between T and Y, both in the base and Shift layers, for the benefit of programmers who have to write LONG_CONSTANT_NAMES_WITH_THIS_FORMAT; five frequently used symbols, marked in teal, have been added.

This, of course, is just a first approach.

IF this extra column should be adopted OR if the AltGr debacle is finally solved (or, better, BOTH things happen), all national layouts will need to be revised and updated, to take advantage of the new possibilities a (hopefully) improved alpha block will provide.

Also, we could diminish the variance between ANSI and ISO versions of keyboards, and get rid of the problem of the "short Left Shift" key, with the critical plus of having the same number of keys on both.

The keycount for the form factors I've shown:
  • TKL: 93 keys.
  • 75%: 90 keys.
  • 60%: 62 keys (63 if splitting Backspace).
  • Left-enhanced: 114 keys (109 with an old-style numpad).
  • TKL WANG-WKL style: 90 keys

What do you think? Would you consider a keyboard with an extra column placed in the middle of the alpha block?

User avatar
Scarpia

15 Jul 2019, 22:57

First of all, impressive work! I love the attention to variants and the detailed explanations for every change. There’s a lot to like here!

A while back, I toyed with a solution to this problem myself, but I went with adding a column to the right of the alphas, and moving a few keys around to make it feel good. I got three extra keys out of it, which is sufficient for Scandinavian layouts, but at the cost of pushing the Enter, Backspace etc. keys 1u further away from the home position, which poses a real problem for touch-typists.

The center-column solution, while it seems to be a few iterations from its final form, is a lot more pragmatic and user friendly. I’d like to play around with a Scandinavian layout based on this.

The only thing I would challenge is the ‘ISO left-shift problem’. Consider the horisontal distance from the right homing key to the right shift: it’s 3.5u. Now the distance from the let homing key to the left ANSI shift: it’s just 2.5u - why does Shift need to be 1u closer to the left pinky than the right one? In contrast, the short left shift of the ISO layout is symmetric: 3.5u from the left homing key. Whether you like it visually or not, ergonomically it makes sense to have a key between the left shift and the Z alpha.

User avatar
depletedvespene

16 Jul 2019, 00:05

Scarpia wrote: 15 Jul 2019, 22:57 First of all, impressive work! I love the attention to variants and the detailed explanations for every change. There’s a lot to like here!
Thanks! :)

Scarpia wrote: 15 Jul 2019, 22:57 A while back, I toyed with a solution to this problem myself, but I went with adding a column to the right of the alphas, and moving a few keys around to make it feel good. I got three extra keys out of it, which is sufficient for Scandinavian layouts, but at the cost of pushing the Enter, Backspace etc. keys 1u further away from the home position, which poses a real problem for touch-typists.
That's part of a problem that I've talked about before: the right hand side of the alpha block (not to say anything about the rest of the keyboard) is larger than the left side, so any changes need to avoid worsening that issue (my old post about a a centered alphanum block was an attempt at tending to that).

Scarpia wrote: 15 Jul 2019, 22:57 The center-column solution, while it seems to be a few iterations from its final form, is a lot more pragmatic and user friendly. I’d like to play around with a Scandinavian layout based on this.
Me too! Albeit with Spanish and Iberoamerican layouts. :D

IF a keyboard with an extra column should become a new standard, all national layouts will need to be revised, as I mentioned in my post, and that would give everyone a good chance to fix mistakes from past designs (like that glaring one about the Ç letter in the Spanish (Spain) layout); I'm sure every nitpicky git from every country will have his or her own list of gripes with the national layout he or she uses.

Scarpia wrote: 15 Jul 2019, 22:57 The only thing I would challenge is the ‘ISO left-shift problem’. Consider the horisontal distance from the right homing key to the right shift: it’s 3.5u. Now the distance from the let homing key to the left ANSI shift: it’s just 2.5u - why does Shift need to be 1u closer to the left pinky than the right one? In contrast, the short left shift of the ISO layout is symmetric: 3.5u from the left homing key. Whether you like it visually or not, ergonomically it makes sense to have a key between the left shift and the Z alpha.
I'm trying to appease ANSIboys here! Don't screw this up!!! :mrgreen:

More seriously, yes, I understand your point and I agree with it: distances to the Shift keys in ISO keyboards are balanced (but LOOK very unbalanced, with a 1.25U and a 2.75U key). Distances on the ANSI keyboards are unbalanced but look better (2.25U and 2.75U keys)... and used to be even worse: many pre-Enhanced layout keyboards had an "ANSI" left shift and one extra key between the /? key and the right Shift (which was 1.75U); therefore, despite that the Shift keys should be both used more or less evenly, ANSI keyboard users tend to favor the left Shift a lot more... and that deepens their disdain for a "shorter, farther" key.

Perhaps the best compromise solution, extra column or not, would be to make the same repositioning of the alpha block I proposed in the "left-enhanced layout": chop off 0.25U on the right and move it to the left side. Both Shift keys would be 2.5U (with Ctrl and Alt remaining 1.5U; in the left-enhanced keyboard, those six mods are 1.5U) and would look well-balanced, while keeping a minor distance imbalance.

The collateral "damages" would be relatively minor, assuming we keep the layout the same: Backspace becomes 1.75U; the BACKQUOTE (what I want to be Back Tab) becomes 1.25U; ISO Enter becomes a thin ISO Enter (not a problem, unlike the anorexic ISO Enter key); ANSI Enter becomes 2.0U instead of 2.25U (few complaints from me in that regard) and the ANSI R2 BACKSLASH key becomes 1.25U (not a problem if an alpha, but people who prefer an HHKB-style backspace will probably dislike this size reduction).

Give me a few minutes so I can make a mock-up of that (for a regular TKL, with the nav cluster on the right side).

User avatar
depletedvespene

16 Jul 2019, 02:28

So, regarding the "balance" thing...

I had to make a few images to ensure we'd be talking about the same thing.

On an ISO keyboard, the distance from the homing key to the outward Shift key is the same — 3.5U:

Distance from homing to Shift keys (ISO keyboards).
Distance from homing to Shift keys (ISO keyboards).
01_distancias-en-ISO.png (16.24 KiB) Viewed 2820 times

While on an ANSI keyboard, the distance on the left side is smaller — 2.5U:

Distance from homing to Shift keys (ANSI keyboards).
Distance from homing to Shift keys (ANSI keyboards).
02_distancias-en-ANSI.png (15.73 KiB) Viewed 2820 times

Now, even though both Shift keys ought to be used more or less evenly, it's well-known that ANSI users tend to use the left Shift much more than the right Shift, to the point that in some of the poorer-thought-out ultra compact layouts, the right Shift is usually displaced or mutilated (or even overloaded with an alpha... like, EEEEWWWW!). Historically, this was even worse for the users of some keyboards that had one more key between /? and RSHIFT (a feature that survives in JIS keyboards, BTW):

Distance from homing to Shift keys (some older keyboards).
Distance from homing to Shift keys (some older keyboards).
03_distancias-en-algunos-antiguos.png (16.82 KiB) Viewed 2820 times


In the light of this, it becomes obvious why ANSI users would recoil at the suggestion that the "good and proper" distance between LSHIFT and F should be "so much larger" than what they're used to... and on a "tiny" 1.25U key, to boot!

We could attend the latter issue, by doing the -0.25U offset that I proposed in the left-enhanced layout and using that to make the mod keys look balanced:

Distance from homing to Shift keys (left-enhanced (or ANSI with -0.25 offset) keyboards).
Distance from homing to Shift keys (left-enhanced (or ANSI with -0.25 offset) keyboards).
04_distancias-en-ANSI-con-offset.png (17.94 KiB) Viewed 2820 times

But the problem remains, and it's due to the simple fact that the right side of the alpha block (not to say the entire keyboard) is larger than the left side:

TKL (ANSI with -0.25 offset) keyboard, with length markers.
TKL (ANSI with -0.25 offset) keyboard, with length markers.
05_distancias-de-teclas-Shift-TKL-ANSI-con-offset.png (50.78 KiB) Viewed 2820 times

Note that the 7U and 8U distances are for the alpha block of an offset keyboard — on a normal keyboard, they are 6.75U and 8.25U (the latter of which grows to 9.25 in the 75% and 65% form factors).

It seems to me that while the imbalance between left side and right side of the alpha block remains, convincing ANSI users of the goodness of equidistance of the Shift keys is going to be difficult (but we can try).

Post Reply

Return to “Keyboards”