Author Topic: On the need of a larger numeric keypad for modern usage requirements.  (Read 31857 times)

0 Members and 1 Guest are viewing this topic.

Offline depletedvespene

  • Thread Starter
  • Posts: 861
  • Location: Chile
  • Old, used-up vespene geyser.
    • Keyboard-related resources.
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.

Offline Gorbon

  • Posts: 42
  • Location: Greece
Re: On the need of a larger numeric keypad for modern usage requirements.
« Reply #1 on: Mon, 29 August 2022, 08:07:49 »
You could get most of the way there with your current numpad, by using layers.

You could use "0" as layer toggle (press and hold) and have something like this:

There are plenty of keyboard remappers/customizers that could do this, or it could even be done through the keyboard firmware (if supported). It'll take some getting used to, but if you use it often enough, it'll become second nature.

Offline depletedvespene

  • Thread Starter
  • Posts: 861
  • Location: Chile
  • Old, used-up vespene geyser.
    • Keyboard-related resources.
Re: On the need of a larger numeric keypad for modern usage requirements.
« Reply #2 on: Mon, 29 August 2022, 08:21:35 »
You could get most of the way there with your current numpad, by using layers.

You could use "0" as layer toggle (press and hold) and have something like this:

(Attachment Link)

There are plenty of keyboard remappers/customizers that could do this, or it could even be done through the keyboard firmware (if supported). It'll take some getting used to, but if you use it often enough, it'll become second nature.

That is one approach, but it does suffer from the numpad0 key doubling as both Fn and 0, a heavily used digit. In some usage cases, like coordinates (as shown in my initial post), it's not too much, but in some others, like IPv6 addresses, it is. Even after training, typing will be inherently slower (think of, for example, an address like "f00f:e07a::abc9::fff0"). For the latter, even adding just one row, so A..F are placed in the base layer, would be quite the gain.

Another option would be to make the 2U numpad0 key become only Fn, move the number zero to the numpad-period key, and make the necessary adjustements to the rest of the layout.

Offline TomahawkLabs

  • Posts: 115
Re: On the need of a larger numeric keypad for modern usage requirements.
« Reply #3 on: Thu, 05 October 2023, 12:08:33 »
What an interesting idea. I also agree layers are an unnecessary hurdle for typing when the idea is muscle memory and speed of input. It would be a natural evolution to introduce a 5th row and maybe expand the numpad by a U either left or right or both to gain more keys. I do think at that point you are creating a customized macropad vs a natural integration into a full size keyboard (ultimately creating a 105-110% board). Adjusting this idea to a hyper-focused macropad would allow users to choose left or right side orientation and allow the user to use the keyboard layout they may be accustomed to, like ergo or alt layouts (Dvorak).

The only other major consideration would be in keycap legends and their respective profile. Outside of keycap profiles like G20 or XDA, keycaps are created for the intended row associated with the sculpt of the keycaps. Definitely a lot of research and thought went into your post. Good luck with your idea.
Always looking for Alps SKCM/SKCL switches. Feel free to DM.
AMD 5600x | RTX3080 | 2x 1TB NVME + 4x 4TB HDD | B550M Pro-P | 32GB RAM | RM850x | Node 804 | Schiit Modius/Magnius + Audeze LCD-2 | Dell S3422DWG
GMMK 1 Full Size Barebones | Zealio 67g ; Apple M3501 handwired | Alps SKCM Damped Cream
SA: Camping