A centered alphanum block?

[depletedvespene]

My attention was drawn today to a common enough factor on the keyboards' main cluster. Let's take a run-of-the-mill US ANSI keyboard layout (TKL for clarity) and mark the finger positions on the home row:

US ANSI keyboard layout with the home row finger positions marked.

centered01.png (22.48 KiB) Viewed 5903 times

As everyone and their dog and their cat knows, there are significantly more keys to the right of the right pinky than are to the left of the left one, and that's before taking into account the nav cluster and the numpad (not to say anything of the mouse). In another thread, I proposed a layout that moves the numpad to the left side so the keyboard would be more centered and I wondered... shouldn't this be done on the alphanum cluster as well? Could all the {1-0}{A-Z} keys be shifted to the right by one unit and then reorder the rest, for the sake of a keyboard layout where the home fingers are “properly” centered? Could this be workable? I fired up KLE and after fiddling around a bit, this is what I came up with:

Right shifted US (ex-ANSI) keyboard layout; first draft.

centered02.png (24.67 KiB) Viewed 5903 times

Main features of note:

• All the main alphanum keys ( 1..0 - Q..P [ A..L ; ' Z..M , . / ) have been moved one unit to the right... as well as the backquote (`~) key.
• The = ] \ keys have all been moved to cover the newly created rift. Note how the \| key is now 1U.
• The corner place vacated by the backquote key is now available and can be used for something like, say, Back Tab (more on this below).
• The 2.25U ANSI Enter key has been replaced by an ISO Enter; the latter is generally {citation needed} regarded as being easier to depress, and the former is favored by its users for being closer to the pinky... in this layout, the Enter key has the advantages of both.
• No tiny ISO left Shift; no excessively large right Shift.
• Since we're redoing the layout, I “went there” and separated AltGr into its constituent parts, as it should have always been; this layout has the four mods (Shift, Ctrl, Alt and Graph) on both sides.
• The comfortable accessibility of the Graph (formerly AltGr) layer would ease up full usage of it, avoiding with this the need for the extra ISO key between left Shift and Z (actually \|, as this stands now).

This, of course, needs further work. In this first draft, I got rid of the Win(+Menu) keys, but could be added back on both sides (this by making all the mods 1.25U instead of 1.5U and shaving a further 0.5U from the space bar); and, of course, the assignment of the symbols in seven of the keys ( `~ =+ ]} \| -_ [{ '" )... and perhaps the others as well, needs to be re-studied.


The addition of the Back Tab is a personal peeve; this key disappeared long ago from non-terminal keyboards, but the frequent use nowadays of Ctrl-Tab and Ctrl-Shift-Tab make me think that it'd be a nice addition... and one not too costly if for some reason it had to be taken away — in particular, if this layout were to be made into a 60%, having Esc move there in its place would certainly be much less of a fuss than stepping over the backquote key:

A possible 60% version of the right shifted US (ex-ANSI) keyboard layout.

centered03.png (19.02 KiB) Viewed 5903 times

This isn't to say that there wouldn't be other difficulties — compact layouts that rely on shortening the extant right Shift would run into problems. For example, a carelessly designed typical 75% would risk looking like this:

A poorly designed 75% version of the right shifted US (ex-ANSI) keyboard layout.

centered04.png (21.92 KiB) Viewed 5903 times

Other keyboard layout redesigns (Colemak, Workman, etc.) rearrange the entire layout, but seem to not bother shifting the fingers' resting positions away from the usual placing (for example, Dvorak's home row is {Caps}aoeUidHtns-{Enter}); in orthogonal layouts, it's common to see the ASDFG and HJKL; halves separated by one column or more (even sticking a numpad in the middle!), but not simply shifting the entire block. In this regard, I have to wonder...

So far, most of the times I've had a wacky idea regarding keyboards... someone else has thought of it before; sometimes it's even been implemented into actual, mass-produced units; I can't believe I am the first git to think of this. Am I? Really? In spite of that, could this be workable? Not taking retraining into account, could this help regular and/or casual users to type with less effort?

[mike52787]

eww

[depletedvespene]

eww

Sure. Now tell us why.

[Myoth]

what's the point

[armin]

I have a strong feeling this is not going to be as comfortable as you think it is.
Still, interesting approach, I'm interested to see if this works out or not in the end, but I could not live with this as a physical layout.

[AMongoose]

Nice.

On ISO you could also leave F where you are and move J two spots to the right, together with a angle mod it gets you a center cluster of 7 symbols usable by either hand. The down side is it fucks the number row up unless you also have a split backspace.

[depletedvespene]

what's the point

The idea is to wonder and test out whether would it be more comfortable to use a keyboard where all the (alphanum cluster) keys are at most at a 2U distance from the fingers, without upsetting the muscle memory involved in treating the main alpha+number keys as a single block — this unlike what's common in ortholinear keyboards, where both alphanum halves are often separated by one or more columns (upto a full numpad between 5TGB and 6YHN).

[depletedvespene]

Nice.

On ISO you could also leave F where you are and move J two spots to the right, together with a angle mod it gets you a center cluster of 7 symbols usable by either hand. The down side is it fucks the number row up unless you also have a split backspace.

That's another part of why I don't really like "split halves". It's not too bad to separate both blocks of letters by, say, 1 column, but it feels pretty weird to stick, say, a ;: key between 5 and 6.

[Muirium]

For what it's worth, my opinion is it's best to go whole hog with a split. A sneaky split is the worst of both worlds: throws off your typing whenever you forget that it's there *and* keeps your hands in the wrong orientation ergonomically. If you're going to split, split! Two separate keyboard bodies, or a wedge shape that allows each hand to work comfortably without a bent wrist.

There's a reason these boards exist:

wiki/Ergonomic_keyboard#Split

Adjustability is such a bonus in itself.

[depletedvespene]

For what it's worth, my opinion is it's best to go whole hog with a split. A sneaky split is the worst of both worlds: throws off your typing whenever you forget that it's there *and* keeps your hands in the wrong orientation ergonomically. If you're going to split, split! Two separate keyboard bodies, or a wedge shape that allows each hand to work comfortably without a bent wrist.

I don't doubt that split keyboards are best, but until these see mass acceptance and production, we're stuck with the regular stuff. My idea here isn't about splitting the keyboard, even if “sneakily”, but to work out better how to correct somewhat what you correctly called “thoughtless feature creep” by adding stuff to the right all the time (see keyboards-f2/post-a-picture-of-your-ide ... ml#p422875). After all, what we now call the "main alphanum cluster" has gone pretty much...

... from here...

fromhere.png (845.7 KiB) Viewed 5770 times

...to there.

tothere.png (256.93 KiB) Viewed 5770 times

I'm going to test this out on one of my keyboards and see how it goes. And yes, I know that even if I am on to something here, widespread adoption may be somewhat difficult.

[Muirium]

“Somewhat impossible.” But personal adoption is another matter!

[depletedvespene]

“Somewhat impossible.” But personal adoption is another matter!

First things first! Getting the Folly115 keyboard built with its modern, powerful numpad (and a good old, regular, ISO alphanum cluster) is the top priority. Afterwards, after I've showed them all, we can take the necessary steps to convince the world to do the alphanum shift.

Meanwhile, I'm cooking up the new logical layout that will best implement this. Me being me, of course, I'll start off with a modified Spanish (LA) one. Let's see what happens...

[Delirious]

Cool idea, I suggest keeping the bracket keys cluster together. On the home row, swap the positions of ] and ' keys. Just like the ibm multi station.

picture stolen from other thread

[depletedvespene]

Cool idea, I suggest keeping the bracket keys cluster together. On the home row, swap the positions of ] and ' keys. Just like the ibm multi station.

That's pretty much what I was thinking too; there's no place to put the brackets side-by-side anymore, so they should go into different rows in the same manner the terminal keyboards do. This is what I have now:

Right shifted US ISO keyboard layout; second draft.

centered05.png (15.96 KiB) Viewed 5716 times

The symbols marked in red are those that have been moved around (besides the right shifting); '/" is in the home row; = and + are now on the base layer and ` and ~ are both in the Shift layer. The symbols in green are further changes that I am tempted to do, but haven't decided yet if I should pull.

[Delirious]

I really like the aesthetic of ISO enter but it's always awkward for me to embrace the ISO life. My pinky finger reaches the very left edge of ANSI enter when I type, by shifting over a column I think I can finally enjoy ISO

[davkol]

what's the point

Polishing a turd.

Wide mods with actual benefits have been around for a while.

[sealclubber]

Ideal makes logical sense, but wasn't this the idea behind ortholinear boards? Like, making everything accessible to any finger within at least 2 units?

Personally this isn't my cup of tea from a subjective standpoint, as I use linux and spam the piss out of the tab key, not to mention being a left shift user. Actions that require the Control key would be much more tedious, not to mention the muscle memory.

[davkol]

not to mention being a left shift user. Actions that require the Control key would be much more tedious

Right Control is closer or about the same distance. If you alternate hands properly, there's no issue. If you don't, maybe work on that first…?

[Muirium]

Ah, the good old: you’re doing it wrong. When in doubt, blame the user. Of course, that’s how we wound up with monstrosities like QWERTY in the first place. Type harder!

[depletedvespene]

... and try harder at testing out new things, too? (who knows if some wacky idea actually works).

[depletedvespene]

Ideal makes logical sense, but wasn't this the idea behind ortholinear boards? Like, making everything accessible to any finger within at least 2 units?

Yup, but I'm confining myself here to the regular (staggered, non-split) keyboards. There are, after all, much more of those than there are ortholinears (split or otherwise).

Personally this isn't my cup of tea from a subjective standpoint, as I use linux and spam the piss out of the tab key, not to mention being a left shift user. Actions that require the Control key would be much more tedious, not to mention the muscle memory.

I assume you mean Control key in the "Unix" style (between Shift and Tab). Yeah, Tab and Control would be harder to depress, as they would be 1U further than what's usual. The advantages (say, a closer Backspace and an ISO Enter) and disadvantages (what you describe) need to be weighted in actual usage.

Split space bars usually assign the left space bar to Backspace or, sometimes, Fn. Would it be convenient to assign Tab to it, for Tab-heavy applications?

[davkol]

Ah, the good old: you’re doing it wrong. When in doubt, blame the user. Of course, that’s how we wound up with monstrosities like QWERTY in the first place. Type harder!

Would you prefer the competing "double keyboards"?

[depletedvespene]

So many keys... yet 1 and 0 are still absent.

Still, so many keys in such a compact form factor — we should call this a "dreadnought" (a shiftless dreadnought).

[davkol]

I~1, O~0 etc.

[depletedvespene]

I~1, O~0 etc.

We all know. Don't let typography fans hear you, though.

[Muirium]

Fun fact: I first learned to type on my mum’s compact manual typewriter. When she told me to type I for 1 and O for 0, I was categorically certain she was taking the piss!

My subsequent early keyboard experiences were: TRS-80, VIC-20 and Apple II. First ergo? Some Microsoft split board my brother bought in the late 90s.

[sealclubber]

Ideal makes logical sense, but wasn't this the idea behind ortholinear boards? Like, making everything accessible to any finger within at least 2 units?

Yup, but I'm confining myself here to the regular (staggered, non-split) keyboards. There are, after all, much more of those than there are ortholinears (split or otherwise).

Ahh gotcha.

Personally this isn't my cup of tea from a subjective standpoint, as I use linux and spam the piss out of the tab key, not to mention being a left shift user. Actions that require the Control key would be much more tedious, not to mention the muscle memory.

I assume you mean Control key in the "Unix" style (between Shift and Tab). Yeah, Tab and Control would be harder to depress, as they would be 1U further than what's usual. The advantages (say, a closer Backspace and an ISO Enter) and disadvantages (what you describe) need to be weighted in actual usage.

Split space bars usually assign the left space bar to Backspace or, sometimes, Fn. Would it be convenient to assign Tab to it, for Tab-heavy applications?

Assigning a split space to tab (at the user's discretion of course) would be awesome. Tabbing hard certainly helps when refactoring json, yaml, or (god forbid) python. It's along the same train of thought as the symbolics boards with the shift buttons that make parenthesis.

Sidenote: I'm making a very large keyboard with a very specific layout but I had no idea what to assign to the left side split bar. Totally gunna use tab now.

[depletedvespene]

Split space bars usually assign the left space bar to Backspace or, sometimes, Fn. Would it be convenient to assign Tab to it, for Tab-heavy applications?

Assigning a split space to tab (at the user's discretion of course) would be awesome. Tabbing hard certainly helps when refactoring json, yaml, or (god forbid) python. It's along the same train of thought as the symbolics boards with the shift buttons that make parenthesis.

Sidenote: I'm making a very large keyboard with a very specific layout but I had no idea what to assign to the left side split bar. Totally gunna use tab now.

Cool! I look forward to seeing that in action — I bet it'll be a great thing, both for tabbing and backtabbing (with right Shift) as well.

[Keybug]

Just adopt SpaceFN, then you can replace all the rarely used right-pinky symbol keys with Space+letter combos and save that pinky. Or, with SpaceFN, use the space bar as a far superior option to replace the shift keys. Those two keys will then be available as large additional hotkeys.

If it's the mouse arm extension to the right that bothers you, just mouse with your left hand, which is easy to do with any symmetrical mouse.

Alternatively, If money isn't a big issue, either go Rollermouse (see if operating it with the thumb might be a more convenient option for you) or get the left half of an Ergodox to place to the left of your 60/75% keyboard. The thumb keys on that numpad will do wonders for you if you want to navigate the cursor while number crunching.