Obligatory disclaimer: I am a braindead idiot who doesn’t know anything about anything, and has the habit of presenting his own opinions as unquestionably unquestionable facts.To say that computing has evolved during these last eight decades is... quite the understatement. Computers are used everywhere nowadays, hardware has improved, software has changed dramatically, and turns out that even some terminology is outdated — in particular, the word «alphanumeric»: strictly, it refers to “a character that is a letter or a number”, but is also widely understood to include all printable characters... including typographical symbols, which have grown from little more than a couple dozen during the sixties to several hundreds in the present, if not more.
Back in the day, adding a simple 4×3 block to the right-hand side of the keyboard, to be able to comfortably type numbers, was quite the improvement.
That block grew later to 4×4 or 5×3, depending on the computer system...
... and then up to 5×4, the size and shape that was fixed and codified in the Enhanced Layout; there have been no major changes in the last four decades.
The “common” 5×4 numpad has the digits 0 to 9, a period (or a comma, in some national layouts), an Enter key and the four most common symbols (the four basic math operators:
+,
-,
* and
/), as inspired by pocket calculators. And yet...
Nowadays, this layout falls short with an alarmingly high frequency. There are just too many usage cases where other symbols are utilized as frequently, if not more, than at least two of the above four. Think of, for example:
- “Plain” hexadecimal numbers: 4b1d, b00b135, 1337f001, et cetera.
- IPv6 addresses: 2022:d1db8:8a63::5d8f:6150:1ee7.
- Money: $123.45, 6,78€, etcetera.
- Date and time stamps: 27/08/2022 12:34:56 -0400.
- Coordinates: 33° 26′ 50.9532″ S, 70° 40′ 25.2336″ W.
- Simple number sequences: 1, 2, 3, 4, 5, 6.
What is the point of keeping the numbers in the numpad if the hand has to go repeatedly from the numpad to the alpha block and back? The other option would be simply to type the numbers within the alpha block, but then what is the point of the numpad? Sure, it’s fine for occasional usage, but repeated data entry of the same kinds of inputs as in the examples above certainly warrants some kind of review.
Ultimately, 17 keys (20 if the numpad’s keys should be fully unsplit) are not enough.
There is also the matter of placement: back in the day, no one batted an eye at the numpad being an integral part of the keyboard, on the right-hand side, but nowadays this has changed. The high usage of the mouse has made the “tenkeyless” keyboards rather popular, separated numpads are a common sight, and within the “custom keyboards” community we have seen the rise (moderate, but rise) of keyboards with a left-side numpad (which does pose a series of problems about the numpad’s layout — some fully mirror it, some partially, some not at all).
So... we need to take into account more usage cases, we need more keys, and we need to consider the position of the numpad relative to the alpha block.
Adding one row wouldn’t be enough. Adding one column wouldn’t be enough, either. Two rows or two columns would be unwieldy to operate with a single hand. Adding one row to the left and one column above (for a maximum of 30 keys) seems best. Also, four decades (and more) of users’ muscle memories constitute an unavoidable mandate to keep the basal assignments unchanged (with three exceptions, as noted). This, then, would be the starting point:
Other than the extra keys, the main differences are:
- Numpad+ is split onto two keys.
- The assignment of Num Lock in the top-left corner is shamelessly erased. Sure, it needs to be available in the keyboard, for compatibility, but there is simply no valid reason to maintain it in the base layer, occupying prime real state, to boot. Heck, IBM itself moved Num Lock to Shift-Scroll Lock on the SSK back in 1987, and that’s fine and dandy, and should have become the standard long ago (i.e.: 1987).
- Numpad0 is shrunk to 1.5U, while numpad-period grows to cover its space. Given the importance of the number zero, it was important to avoid shrinking its key to 1U, but keeping it 2U wide complicates things for left-side numpads. Making both keys the same width, as was done in some old terminal keyboards, is best. It’s for the same reason that the bottom-left key is 2U tall, to mirror the numpad-Enter key.
Note that splitting the 2U keys, or joining up the two 1U keys above them into single 2U keys is not unfeasible — on IBM Model F/M keyboards this is trivial, while on modern custom keyboards, PCB makers know well how to make “holes” for both possibilities.
With the hardware more or less decided upon, it’s time to start populating the key assignments, and this is where divergence starts.
Generally speaking, the four more often-requested or custom-implemented key assignments are, in rough order:
- Backspace
- Tab
- Equals sign ('=')
- Comma sign (',')
Other assignments vary wildly, as will be seen below.
We should start with the modifiers. The bottom-left 2U key should be an
Fn key (doubling as
Shift on some keys, to be seen later on).
Tab and
Backspace naturally fall on to the top-left and top-right corners... although there is something to be said about the convenience of moving them to the lower half of the numpad, if their expected usage frequency should be high enough (after all, the hand should be mostly on rows 3 to 6, move up to row 2 with less frequency, and all the way up to row 1 occasionally).
Although each and every user will have his/her/its/their own preference, let’s go for now with a “mods on corners” scheme. With the basal assignments and modifiers already in place, we should place the needed and welcome additions. Let’s start with a numpad intended for general usage.
Besides the already mentioned comma and equal signs, the colon sign, parentheses and the degree sign
(the only non-ASCII character... so far) all come naturally to mind as often-required.
The English (
en-US and
en-UK, among others) layouts use a
numpad-period key, while many other layouts (
German and many of its derivations,
Portuguese (Brazil), etc.) opt for a
numpad-comma key. Placing the comma above the
Enter key on the former group and flipping both on the latter both preserves compatibility with the extant national layouts and allows both to be comfortably used, as both signs are, indeed, frequently used. Note the placement of the colon, also a frequently used symbol when mixed in with numbers; its usage on time markers is, by itself and even if all other usages were to be discarded, enough to merit its placement in one the keys closest to the digits.
The symmetrical nature of this numpad allows for easily mirrored versions.
Some people like their numpad fully mirrored, some partially, some not at all. In my personal experience using a left-side numpad, I’ve found that swapping
only the
numpad0 and
numpad-period (or numpad-comma, as the national layout may dictate) keys works best for me.
The
Fn/Shift key can be used to access a few extra symbols that are not as frequently used but are nevertheless convenient to have on the numpad.
But this, so far, is for
general usage. How about some specialized usage cases?
Hexadecimal numbers have been around for quite long in our industry, and yet they have barely been subject to proper input mechanisms. A couple “hexapads” in old keyboards are known, arranged in a 4×4 key block:
... but this would clash with the muscle memory of modern users. In not few cases, the
numbers A to F were shoehorned into a 5×4 cluster, resulting in a rather inelegant arrangement:
It’s just best to take advantage of the sixth row and keep the logical progression. But then, the associated typographical symbols (
and letters) vary wildly from computing context to computing context, to the point that we can easily design three different (modern) hexapads for distinct sets of needs:
Note how here referring to the bottom-left key as
Fn/Shift pays off: thinking of it as
Fn allows dissasociating numbers from symbols for the “additional characters” layer, but it’s best to think of it as
Shift when dealing with letters, as most of the time they will be wanted as lowercase, but sometimes in uppercase (contrast, say, "\u00f3" with "U+00F3").
Other specialized usages can be easily thought of.
It's easy to see people who type coördinates a lot clamoring for a numpad like the above (or, more probably, calling it a
decent enough starting point and then piling on adjustment requests). People in financial institutions might get a kick out of the two financial-oriented designs above (note the hardware variation, where two alphas have been enlarged to 1.5U in height).
The idea of adjusted designs doesn’t have to be just for industries — it’s easy to see the benefit of general-use numpads “localized” for different countries. For example, in Chile, ID numbers are typed in
a lot in all kinds of contexts; these have a modulus-11-based verifying digit, where
K stands in as the 11th one (so: 12.345.678-5, 12.345.684-K, etc.) and it stands to reason that adding said letter would be a
very welcome addition, even if everything else was left unchanged. The currency symbol ("
$") is also used a lot. It makes sense, then, to pull in something like this:
The trend of making ever-smaller, multi-layered keyboards for typing text and navigating within the same main (“alpha”) block has the idea of keeping the hands on that block as much as possible as one design goal. Curiously, this same design goal is what drives the need of a larger numeric keypad (integrated into the keyboard or as a stand-alone unit), to allow this to happen while typing in numbers and number-composed values (IP addresses, money, timestamps, coördinates, etc.).
Yes, I am aware that some modern stand-alone numpads add a separated sixth row (typically with
Esc,
=,
Tab and
Backspace), but that doesn’t address the need for a full redesign of the numeric keypad for modern needs; the extra row comes off as just a nice extra, but is still lacking basic, too-commonly used symbols (the colon being the prime example).
With all that said... now what?
Building the hardware is not difficult; 27-key numpads and 114/115 “Enhanced++” keyboards (left-side and right-side) can be crafted, their controllers loaded with with QMK, yadda, yadda, yadda. But then there is the software, computer-side.
The easy thing would be to ship a numpad with its own driver, but that would not cover the
Enhanced++ (or “fuller-size”) units.
All major operating systems should be able to natively support the enlarged numpad, where
most but not all scan codes already exist... and where each national layout would have to define only one layout for the numpad, as is done today. For the enlarged numpad to be truly useful, the operating system should be able to treat separately the logical layout for the alpha block (or the
tenkeyless segment, if you will) and the one for the numpad, which smells of a major change.
With that done, though, it would not be difficult to then define a few numpad layouts for the most common specialized usages, as we already do with, say, MSKLC. The ones I've presented here are my own ideas about how to make them, but surely others will have differing opinions about some placements and also come up with other special-context usage cases that I haven't mentioned.
