Alternate history: what the Enhanced layout could have been if...

User avatar
depletedvespene

01 May 2019, 03:53

Obligatory disclaimer: I don't know anything about anything. Y'know, same old, same old.

There is no question the Enhanced layout, released in 1986 with the IBM Model M keyboard, was very well designed and hugely influential, to the point that it's still the standard layout, with most alternatives created since then, be them full-size(-ish) or smaller, defined as variations of it (including the currently "official" Windows layout, which is simply the standard layout with three extra keys that few people actually wanted in the first place (YMMV)).

M.png
Model M keyboard.
M.png (411.8 KiB) Viewed 1013 times

The Enhanced layout is, however, not perfect; its most glaring error is the overloading of the right Alt key as AltGr on "non-US" keyboards, breaking with this the design goal of having all the modifier keys present on both sides; it's safe to believe that whoever came up with that was probably thinking that it would be used for just a few symbols, an assumption that would have been quickly shown to be erroneous, even at that time, when studying some of the national layouts used in Europe (especially central Europe). On the other hand, it wasn't as obvious back then that a couple decades later, the Num Lock key would become a rather pointless relic (quite more so than other keys that unjustly get that flack, like Scroll Lock and Pause), because at the time it was still quite necessary to ease up the transition from the older XT and AT layouts.


There is one more gripe that I have with the Enhanced layout: the excessive area assigned to the right hand — not only the alpha block's right hand side is larger than the left one, the right hand is also expected to cover the the nav cluster and the numpad (not to say anything of the mouse). Even back in the late '80s I thought, while entering large amounts of data in spreadsheets, that it would be more comfortable to have the arrow keys on the left side, so I could move the cursor around with the left hand and type in the numbers with the right hand.

For the last few months I have been wondering, could the Enhanced layout have been done in a different fashion that addressed all these issues (including, of course, my pet peeves)? With the benefit of hindsight, decades of active usage, and my utter shamelessness, I fired up KLE and started fooling around with the layout, trying to come up with a new one that fulfilled these features/restrictions:
  • It should be recognizable (to modern eyes) as a variation of the Enhanced layout.
  • It should look like an extension of the preceding F AT layout, more so than the Enhanced layout.
  • The navigation keys should be placed on the left side.
  • Right Alt should be Alt, not AltGr, and a new modifier should be added to allow comfortable access to a third layer (and a fourth one) of extra letters and symbols.
  • It should look like it was made by IBM (among other things, this means that key blocks should be rectangular, with no offset columns on the sides).
Now, imagine it's 1985. Most keyboards are F ATs (or clones) and F XTs (or clones), and some of the older units, with their wacky (to our "modern" eyes) features (like a Control key to the left side of the Shift Lock key, and one more key, usually Alt, to the left of Left Shift as well), are still common sights.


FXT.png
Model F XT keyboard.
FXT.png (661.57 KiB) Viewed 1013 times

FAT.png
Model F AT keyboard.
FAT.png (418.55 KiB) Viewed 1013 times


Rumors abound that IBM is working a new line of keyboards with a redesigned layout, which will supersede the current AT keyboards; not many details are available, but it seems that these new units will have dedicated arrow keys and two more function keys, for more per-program action goodness! (yes, in the early advertising for the Enhanced layout, a big point was made of the inclusion of these new-fangled F11 and F12 keys)


Let us keep imagining: in this alternate timeline, as the main engineer in charge of designing the Enhanced layout tinkers with the positioning of all keys, his wife, a heavy spreadsheet user, talks him into moving the navigation keys to the left side, to ease up her working in Lotus 1-2-3. His sister-in-law, a professional typesetter, happens to see a draft layout and goes nuts when she hears that only "a few extra symbols" would be added onto the extra layer. Dashes, pilcrow, paragraph, diacritics, extra letters in languages other than English?! Where would those go? One is pretty persuasive when presenting her case; the other one doesn't quite convince him at first, but his doubts are abated when he realizes that all the cool kids at the office don't use plain ASCII, but instead use code page 437 (not to say anything about code page 850 being "big" in Western Europe): a keyboard that only supports ASCII, as even the F AT keyboard does, is condemned to obsolescence.

The engineer refines draft after draft, taking inspiration from DEC keyboards (more so than in our own timeline) and overcoming the technical limitations a fourth modifier implies; to ensure the main alpha block will remain a rectangle, as IBM likes, he makes the radical decision of chopping off 0.25U on the right side of the alpha block, and uses it on the left side, easing up the allotment of keys over there. Once he is done, this is the layout he has produced:

LE1.png
"Left Enhanced" keyboard layout (horizontal Enter, US national layout).
LE1.png (30.25 KiB) Viewed 1013 times

Indeed, it looks like someone took an F AT, modified somewhat the alpha block, then moved up the F keys (and Esc) and added a bunch of new keys where the F columns were.

Let's go over the main features of note in the alpha block:
  • On the right side, Backspace has been shortened to 1.75U, the \| key to 1.25U and the (horizontal, "ANSI") Enter to 2U.
  • The modifier keys (Shift, Control and Alt) are present on both sides, and all of them are 1.5U in size.
  • Both Shift keys are accompanied on their respective outer sides by a 1U Graph key. Those two new modifier keys take on the function of that "AltGr" thing from an early draft, allowing easy, comfortable usage of a third layer for extra symbols and letters (and a fourth one along with Shift, so those extra letters will have their lower and upper case forms!).
  • On the top left corner, a dedicated 1.25U Delete key makes a counterpart to the Backspace key on the right side.
  • To accomodate the above, the `~ key has been eliminated — not that it's needed, as the backquote ('`') and tilde ('~') characters will be readily available in the Graph layer.
  • Tab has increased to 1.75U.
  • Caps Lock has been reduced to 1U, and the Insert key, also 1U, has been placed to its left. With this, the Insert key is readily accessible but relatively "out of the way" of navigation keys.
On the left, the navigation cluster:
  • DEC's inverted T arrow cluster has been copied wholesale, albeit not fully raised by 1U, as in DEC keyboards. Instead, there is a small space between it and the non-inverted T HUDE cluster; this slightly complex shape will allow the left hand fingers easily find their way without the user looking.
  • On the supranav row, Pause is now on the left side, so it remains a "corner" key, and away from Esc, to avoid accidental presses.
And what about those keyboards in Europe? The extra key between Left Shift and Z disappears... not that it matters much, because its characters ( '\' and '|' in the UK layout, '<' and '>' in many other countries' layouts) can be easily placed in the Graph layer. Vertical Enter can be easily done as well, albeit with what we now call a "thin ISO" (1.0/1.25U instead of 1.25/1.5U) key:

LE2.png
"Left Enhanced" keyboard layout (vertical Enter, UK national layout).
LE2.png (30.27 KiB) Viewed 1013 times

The reduced width of the Enter key isn't much of a problem, as long as the numpad remains separated by 0.5U, as the standard calls for. Even BAE (or NSBAE, in this case) can be done with little pain (because, again, the characters from the disappearing \| key can be taken in by the Graph layer).


Let us also take note of the numpad: it's pretty much the same as always, with two exceptions: the Num Lock key is tucked away with Scroll Lock (as was done later on in the IBM SSK); in its place, an equals sign is added, something spreadsheet users of the time would have definitely approved of. Also, somewhat more controversially, a comma key has been added, because lists of numbers, even in the good ol' USA, are separated by commas.


This is all well and good, but... what about difficulties in this layout?

When (our) Enhanced layout came out, the repositioning of the Control key was resisted, to the point that not few people to this day prefer to swap the left Ctrl and the Caps Lock keys. In this layout, doing that would mean either getting a measly 1U Control key above Shift, OR replacing both Insert and Caps Lock with a single 2U Control key (something perfectly doable, given what we all know about the IBM Model M keyboard) and then moving those to where left Control and right Control are, like this:

LE3.png
"Left Enhanced" keyboard layout (NSBAE Enter, US national layout). Note the stepped Tab key as well.
LE3.png (30.83 KiB) Viewed 1013 times

Do bear in mind that at this point in time, the Insert was widely used, so getting rid of it was not an option — besides alternating between insertion and overstriking text editing modes, it was also used to copy and paste text with Ctrl-Ins and Shift-Ins, a usage that would be codified in 1987 in the Common User Access (CUA) standard.


So, what to put under the Graph layer(s)? Oh, plenty! Thinking exclusively in terms of the code page 437, there's 127 caracters that could have been added:

Codepage-437-marked.png
Code page 437, with the high bit characters marked.
Codepage-437-marked.png (7.93 KiB) Viewed 1013 times


One possible extension to the US national layout could have been this:

USG.png
A possible US national layout that uses most of code page 437.
USG.png (24.64 KiB) Viewed 1013 times


Note that in this thought experiment, I've limited myself to what I think IBM at the time could/would have done. Had it been for me, I'd have added a sixth row to the numpad (with keys for '(', ')', '^' and the letter E), but this escapes the purpose of the exercise. Same goes for splitting the space bar, another later development (in this case, and with this layout, I would have split the 7u space bar with three keys, 3U, 3U and 1U, as seen from left to right).


What do you think? What would you, with the benefit of hindsight, have done differently on the Enhanced layout, as it was released in 1986?

User avatar
Polecat

01 May 2019, 05:00

Well, I know even less than everyone else, so nobody should listen to me about anything whatsoever.

One of the reasons I gravitated towards Northgate keyboards back in the '80s and '90s is that they had the Control key to the left of ASDF, like the IBM Model Fs. Gen 1 Northgates all came that way, while Gen 2 and 3 let you swap Control and Caps Lock with a dipswitch and came with the extra keycaps to match. This was a big selling point at the time, and was important to Wordstar users like myself, because Control A-S-D-F moved the cursor word left-character left-character right-word right, respectively. This was long before the mouse was in common use, and is still supported by Star Office and a few other word processors and text editors. Once you get used to moving around this way with your left hand (and I'm not even a touch typist) it's incredibly irritating, and fatiguing, to have to move from the keyboard to the mouse and back every time you want to move the cursor. So *if* the mouse hadn't come about, and *if* Wordstar hadn't been replaced by WordPerfect (and later Microsoft Word) as the WP of choice (...and pigs hadn't grown wings and the moon was still made of green cheese...), the Enhanced layout from IBM might have been just a little bit different.

User avatar
zrrion

01 May 2019, 07:19

I think the reason the right side of the Enhanced Keyboard layout is so open is because a lot of people criticized the XT for its cramped right side, so IBM made sure to give people room on that side.

However, in a hypothetical world where IBM made their decisions to enhance the keyboard differently I think it might look something like this:
Image

The alpha block is 14.5u instead of 15u which reduces the number of different cap sizes thus reducing the cost of manufacturing and has a few other benefits.
  • 1.5u backspace is easier to hit than the 1u backspace of the AT.
  • The right and left shift are the same size, allowing an ISO style split left shift to be used on both sides of the board as needed by variant layouts.
  • Graph replaces Caps lock on the right. With this key occupying such a prime spot on the home row it would make sense to put a key that would be needed for non-US layouts here. For the US version the 127 characters mentioned in the OP would be a great thing to be able to type with this key. Even if they aren't, this adds an extra modifier that is accessible from the left hand, which would otherwise not be doing all that much as compared to the right hand.
As for the numpad, making it a 5x5 grid instead of a 4x5 doesn't make it much larger but does give it ample room for layout changes. Since it functions as a combination numpad/nav cluster I've taken to calling it a data block. Additionally, since the data block only has 1u keys, it can be easily repurposed for POE or other specialty uses without needing to change the manufacturing process.
  • Prior to widespread adoption of the mouse it doesn't make any sense to put the arrow keys on a numpad layer as they are the only way to move the cursor. Moving them just below the numpad keeps them in reach without unnecessarily increasing the size of the board.
  • Putting the lock switches on the left side of the data block puts them in a position where they can be easily reached from both the data block and the alpha block.
  • The lock keys are placed in the order of the indicator lights. This looks nice.
  • Insert is a toggleable function and as such has been added as a lock switch with an indicator LED as well.
  • All of the functions in the data cluster that can be accessed when num lock is off can also be accessed with Shift+number, meaning that these keys can still be accessed easily without constantly toggling numlock.
The oddity for this layout is Pause. Keeping the lock lights lined up with switches meant that there ended up being an empty space on the right. It would be irritating to hit Pause by accident and moving it away from everything else solves that I suppose.
The big benefits of this layout are that it removes 4 cap sizes from the standard layout, reducing manufacturing costs, and it condenses the right side considerably, leaving more room on the right for a mouse without removing any functionality.

Anakey

01 May 2019, 11:37

I guess another 'benefit' to the above layout would be the force adoption of ansi layout given the reduction in alpha width which would reduce ISO enter key to a 2u key similar to the XT. That number block just looks plain ugly although i do like the idea of making insert into a lock key. Personally i would have moved the Home, Pg Up, Pg Down, End legends from the numpad and placed them instead on the arrow keys similar to the 5140 IBM portable and use them in conjunction with a FN key placed where print screen is currently. The Delete function i would have on a shifted backspace meaning the numpad would consist of just numbers so Num Lock would not be needed. The print screen i would move to the Num Lock space making way for an FN key next to the arrow keys to use the nav commands.

User avatar
depletedvespene

01 May 2019, 14:35

zrrion wrote:
01 May 2019, 07:19
I think the reason the right side of the Enhanced Keyboard layout is so open is because a lot of people criticized the XT for its cramped right side, so IBM made sure to give people room on that side.
Excellent point. This applies to the AT layout as well.
zrrion wrote:
01 May 2019, 07:19
However, in a hypothetical world where IBM made their decisions to enhance the keyboard differently I think it might look something like this:
Image

The alpha block is 14.5u instead of 15u which reduces the number of different cap sizes thus reducing the cost of manufacturing and has a few other benefits.
  • 1.5u backspace is easier to hit than the 1u backspace of the AT.
  • The right and left shift are the same size, allowing an ISO style split left shift to be used on both sides of the board as needed by variant layouts.
Indeed. At that point in time, the Brazilian standard layout would have required it:

M-ABNT2.png
Model M keyboard, ABNT2 standard.
M-ABNT2.png (450.8 KiB) Viewed 864 times

(but, of course, the idea behind the Graph key was to avoid the need for the addition of extra keys)

zrrion wrote:
01 May 2019, 07:19
As for the numpad, making it a 5x5 grid instead of a 4x5 doesn't make it much larger but does give it ample room for layout changes.
……
  • Insert is a toggleable function and as such has been added as a lock switch with an indicator LED as well.
This is the only flaw in your proposal (IMHO, YMMV). At the time, the status of the locks (caps, num and scroll) was thought of as properties of the keyboard, while insertion or overstriking mode depended strictly on each program; you could well work in the command line in insertion mode while switching the mode around on the Qedit text editor as needed, and at the same time be invoking a TSR program that was used in overstrike mode only. I don't think DOS at the time could have handled knowing which mode was active on a per-program basis, to then turn on or off the "Insert Lock" light as needed (Windows 3.0 onwards probably would have been able to, but surely in a piss-poor manner).

Building on your idea for the proposal, and taking this correction (IMHO, YMMV) into account, the numpad could look like this instead:

numpad-zrrion-plus.png
5×5 numpad, with Insert as a regular key.
numpad-zrrion-plus.png (10.41 KiB) Viewed 864 times

Insert and Del are dedicated keys again; the "loss" of a lock light allows moving the PrtSc key up. Further changes could still be made.

User avatar
depletedvespene

01 May 2019, 14:54

Anakey wrote:
01 May 2019, 11:37
I guess another 'benefit' to the above layout would be the force adoption of ansi layout given the reduction in alpha width which would reduce ISO enter key to a 2u key similar to the XT.
Actually, even less than 2U: the ISO Enter key is 1.25/1.5U in size; the "thin ISO" Enter key shaves 0.25U, to produce a 1.0/1.25U key; cutting 0.25U more produces a 0.75/1.0U key — an atrocity that I call, with derision, "anorexic ISO". That thing is actually uncomfortable to use (at least for me, it's actually less uncomfortable to use a simple 1×1U key)... not that it hasn't stopped certain people with less sense of substance than of form to actually implant it on keyboards (and then have the nerve to expect users to be happy with it):

m0110-iso.jpg
Apple M0110E keyboard with an "anorexic ISO" Enter key.
m0110-iso.jpg (114.25 KiB) Viewed 857 times

nickg

01 May 2019, 17:17

personally i wish they woulda done it with the 10key on the left and nav cluster on the right kinda like :

https://www.amazon.com/Ergonomic-Handed ... B001DEUPIE


if i had an m or even f with that it would be perfectish

User avatar
zrrion

01 May 2019, 17:18

If Microsoft can make the windows and app keys standard then I think IBM could absolutely have made insert a system wide lock if they were so inclined. I do like the alternate numpad you've got there that woks with standard insert behavior though, and is what I would go with if I didn't add insert lock.

Findecanor

01 May 2019, 17:25

I think the design process should have happened when the Model F AT had been designed.
With only a few minor tweaks, it could have been better and the the Model M layout would not have been necessary.
modelf.jpg
modelf.jpg (57.22 KiB) Viewed 795 times
  • The Escape key in the normal position.
  • Numpad-5 gets an additional up-arrow. That makes it an inverse-T cluster, on the home row. The Model M has got it too low IMHO. The nav keys around it are not bad once you are used to them, which people were.
  • Add \ and * to numpad, active during Num Lock, but Sys Request/Scroll Lock otherwise.
  • "Unix-style"Backspace (delete) and (forward) Delete locations. Alternatively, use a 2u Backspace with Del on the Num Lock's position and move Num Lock to the upper/right corner instead.
  • Reduce size of Space bar and move modifiers to its sides for use by thumbs. Move key below shifts to make them easier to find by touch. Note that Ctrl, Alt and Shift are symmetrical: Ctrl and Alt drawn inwards the same amount from its Shift key's inner edge.
The issue with the Alt keys is not in hardware but in software. If it had been used as a Graph key also in English-language MS-DOS back in the day (which it was on Mac and Amiga, BTW), then we would not have any division between Alt and Alt Gr. Today the left Alt key is pretty useless everywhere -- its functions should have been mapped to the Control key or to function keys already back then.

User avatar
depletedvespene

01 May 2019, 17:30

nickg wrote:
01 May 2019, 17:17
personally i wish they woulda done it with the 10key on the left and nav cluster on the right kinda like :

https://www.amazon.com/Ergonomic-Handed ... B001DEUPIE


if i had an m or even f with that it would be perfectish
I'm actually testing out a similar set up during these weeks (an SSK with a numpad on the left side)... and it's not going too well. I intend to make a lengthy post about it this weekend.

User avatar
depletedvespene

01 May 2019, 17:44

Interesting perspective, Findecanor. I do have one question:
Findecanor wrote:
01 May 2019, 17:25
The issue with the Alt keys is not in hardware but in software. If it had been used as a Graph key also in English-language MS-DOS back in the day (which it was on Mac and Amiga, BTW), then we would not have any division between Alt and Alt Gr. Today the left Alt key is pretty useless everywhere -- its functions should have been mapped to the Control key or to function keys already back then.
Let's say that we move all commands away from the Alt key (to use it exclusively as a Graph modifier) to the Ctrl and the F keys... wouldn't have that put pressure on their capacity to house commands? Back in the day, F11 and F12 were made a big point of, so had the Enhanced layout been designed as you specify, would have it been a good idea to keep just ten F keys, or would have it been better to go all the way up to fifteen of them, whether on a third vertical column, or in the top row, as was done on the Model M?

nickg

01 May 2019, 17:59

depletedvespene wrote:
01 May 2019, 17:30
nickg wrote:
01 May 2019, 17:17
personally i wish they woulda done it with the 10key on the left and nav cluster on the right kinda like :

https://www.amazon.com/Ergonomic-Handed ... B001DEUPIE


if i had an m or even f with that it would be perfectish
I'm actually testing out a similar set up during these weeks (an SSK with a numpad on the left side)... and it's not going too well. I intend to make a lengthy post about it this weekend.
did ibm make a stand alone model m numpad or you using a different one?

User avatar
depletedvespene

01 May 2019, 18:12

nickg wrote:
01 May 2019, 17:59
depletedvespene wrote:
01 May 2019, 17:30
nickg wrote:
01 May 2019, 17:17
personally i wish they woulda done it with the 10key on the left and nav cluster on the right kinda like :

https://www.amazon.com/Ergonomic-Handed ... B001DEUPIE


if i had an m or even f with that it would be perfectish
I'm actually testing out a similar set up during these weeks (an SSK with a numpad on the left side)... and it's not going too well. I intend to make a lengthy post about it this weekend.
did ibm make a stand alone model m numpad or you using a different one?
I'm using an M50 macropad in lieu of an actual numpad (if you happen to know where plentiful M15 numpads might be found... score me one! :mrgreen: ). This quick peek of my current set-up should be good enough:

quick-peek.png
Model M SSK and an M50 to its left.
quick-peek.png (356.93 KiB) Viewed 759 times

andrewjoy

01 May 2019, 18:23

Findecanor wrote:
01 May 2019, 17:25
I think the design process should have happened when the Model F AT had been designed.
With only a few minor tweaks, it could have been better and the the Model M layout would not have been necessary.

modelf.jpg
I quite like your layout however that caps lock needs to go away and be replaced with control . The left control can then be a super key.

Oh and you need a tab on the number pad.

User avatar
AJM

01 May 2019, 19:34

Findecanor wrote:
01 May 2019, 17:25
I think the design process should have happened when the Model F AT had been designed.
With only a few minor tweaks, it could have been better and the the Model M layout would not have been necessary.
That's the best suggestion so far. (Although even there you have changed more than necesarry.)

From my point of view there's absolutely no need for a <Del> key in the main block. You need that key only after moving around with the cursor keys, so it makes more sense there. I would simply swap <Del> and <Ins> in the numpad, so that the more important function gets the bigger key and is easier to reach with the thumb.

The <Ctrl> keys should move to the sides. They're unreachable with the thumbs. Even the right <Alt> is a bit too far out.

Oh and the <Caps Lock> belongs somewhere out of the way - replacing <SysRq>. (I haven't needed a <SysRq> key in my whole life and the XT keyboard didn't neet it either.)

nickg

01 May 2019, 21:51

depletedvespene wrote:
01 May 2019, 18:12
nickg wrote:
01 May 2019, 17:59
depletedvespene wrote:
01 May 2019, 17:30


I'm actually testing out a similar set up during these weeks (an SSK with a numpad on the left side)... and it's not going too well. I intend to make a lengthy post about it this weekend.
did ibm make a stand alone model m numpad or you using a different one?
I'm using an M50 macropad in lieu of an actual numpad (if you happen to know where plentiful M15 numpads might be found... score me one! :mrgreen: ). This quick peek of my current set-up should be good enough:


quick-peek.png


no idea where to find m15 numpads sadly, but personally I think id rather have the m50 that thing is beautiful :O

Findecanor

01 May 2019, 22:04

depletedvespene wrote:
01 May 2019, 17:44
Let's say that we move all commands away from the Alt key (to use it exclusively as a Graph modifier) to the Ctrl and the F keys... wouldn't have that put pressure on their capacity to house commands?
I don't think so.
In a text prompt or document editing mode, I see little point in having two command keys.
In menu mode, there is no point of a key that is exclusively for graphic characters so you could very well continue to use it there to select menu items.
The Alt/Option key is not used exclusively for graphics characters on Mac today but is used in lots of shortcuts.

Numbered function keys are inferior to mnemonic shortcuts with the Control key IMHO.
They remain because of established convention and to encourage the user to move the left hand more often. It is bad to keep the left hand, wrist and arm stationary over the small left side of a keyboard for too long.
Yes, if this had been a design the interface for a platform from scratch, I would also choose to put the numpad on the left, but this is supposed to be an incremental change to an established platform.
AJM wrote:
01 May 2019, 19:34
You need [the <Del>] key only after moving around with the cursor keys, so it makes more sense there.
Interesting point. I also feel that Del, Backspace and cursor keys belong together somehow, but I could not put it in words.
This is also why I the nav cluster on the left side feels wrong for me: it is too far from Backspace.
AJM wrote:
01 May 2019, 19:34
I would simply swap <Del> and <Ins> in the numpad, so that the more important function gets the bigger key and is easier to reach with the thumb.
I had the same thought, but there was established convention from Model F XT.
AJM wrote:
01 May 2019, 19:34
The <Ctrl> keys should move to the sides. They're unreachable with the thumbs.
I'd rather move them further in than out. With your pinky on Shift, you can reach the Ctrl key with your thumb. I think your view is tainted by how you press the key now.

Other points with moving keys away from the sides is to expose the Shift keys, to make them easier to find by feel (avoid confusing Shift+Caps Lock with Shift+left Control). As a consequence, it would also allow you to press right Shift with the right thumb when using the numpad/nav cluster. You can't press Shift+Cursor with the right hand on a Model M, but I did it all the time on the Amiga back in the day.

Post Reply

Return to “Keyboards”