A split 34-key layout for iPadOS

A couple of weeks ago, I wrote about moving to a split keyboard with 42 keys; the Corne. I created a layout for it based on the one I made for my Planck, and it was quite a struggle. The fundamentals of the layout were good, and I’d already acclimatised to an ortholinear (matrix-style, non-staggered) keyboard, but the switch to a split setup was an eye-opener for me. I could immediately see how much I’d been compensating for weak and inflexible pinkie fingers by cheating on good home row position while typing, borrowing fingers from the other hand, and indeed repositioning my hands entirely for chords like keyboard shorcuts. With a split board, you feel the pain of those suboptimal manoeuvres tenfold.

Everyone reading this is already familiar with a tiny, and so called “forty percent” keyboard — your smartphone’s on-screen software keyboard is such a layout, complete with layers for symbols and numbers — but unless you’ve used one physically and for a sustained period, you perhaps won’t know that the challenge is never that you have too few keys. Instead, it’s that the ergonomic hand position that the form factor pushes you into will make you realise that you’d prefer to have as few keys as possible, but that their positions and reachability are critically important. Counterintuitively, it feels much more burdensome to have to move a finger one extra column on a small board than to lift your whole hand to another place on a larger one.

Perhaps you’ve noticed some contortions that you make yourself when typing. Using a different finger to reach up and right to Backspace instead of your short and weak pinkie, perhaps. I certainly noticed my own. Something had to change, so I made a change which may seem more extreme still, but which is actually a huge step of accommodation: I removed four keys from each half of my split keyboard, taking it down to just 34 keys in total.

Corne keyboard left half with four keys blanked

This is much more usable from a typing point of view, because the removed columns were previously the responsibility of my pinkie fingers. It’s understandable to give double duty to the strong and flexible index fingers, but it’s madness to ask the pinkies to accept the same burden. They’re just not as capable. I decided that one column of three keys, requiring no lateral movement at any time, was more than enough for each of my smallest fingers. The fourth removed key from each hand’s purview was the awkward inner thumb key, which required the thickest and most laterally-extendable digit to curl inwards on itself almost to ninety degrees, and then press down sideways. I won’t miss those movements at all.

Having done that, there remains only the comparatively much easier task of deriving a keyboard layout to suit just 34 possible finger-positions. To make it more fun, I had a number of additional requirements and constraints:

This is all perfectly doable with some thought, because after all a 34-key keyboard with four layers is at least potentially a 130-something-key keyboard overall. The challenge, as ever, is to make it all work in an intuitive and usable way. Let’s talk about those layers.

Base layer

Base layer

It’s immediately apparent that something has to give if we want the full alphabet and the most common punctuation for writing on the base layer, along with two layer-switching keys, on a 34-key keyboard. The most obvious things to reassess are the modifier and whitespacing keys. Shift and Space need to stay because they’re required at least once, and many times, per sentence respectively. The rest are good candidates for repositioning: Enter, Backspace, Tab, Command, Option, and Control (as well as Escape).

Modifiers — also called mods henceforth — have been the subject of considerable thought with regard to moving them. Originally just sort of tacked onto an updated version of a typewriter’s keyboard, they’ve never been well-positioned for ergonomic use, with the possible grudging exception of the keys immediately to the left and right of a moderately-sized spacebar, which can be hit acceptably with the thumbs. We don’t have that option with a split board possessing only two thumb keys per hand, all of which we’ve already committed: two to switch to the second and third layers respectively (and which when both held will produce the fourth layer), and the Shift and Space keys.

Broadly, and logically, there are two solutions: either have the mods be triggered by some sort of alternate action on the existing alphabetical keys of the base layer, or move the mods to a higher layer. In the former camp is the fairly popular concept of home row mods, which puts the four primary modifier keys as secondary (hold) functions on the four home-row keys of each hand. You of course require a matching set of mods on each side of the keyboard because otherwise you’d be unable to type certain combinations at all, specifically the combinations of a home-row letter and the modifier which it produces when held.

Home row mods (HRMs) aren’t for everyone, though. They require extensive personalised configuration with regard to timing and behaviour, and will always to some extent produce both false positives and negatives (where you do or don’t get a modifier when you intended the opposite). They also obviously require a lot of relearning, especially in that you must learn which hand’s modifiers to use when combining with each of the eight letter keys they’re superimposed upon. That’s not for me. I appreciate the compactness, and the elegance of the concept, but it’s just a bridge too far at the moment. If you’d like to try HRMs, I wish you good fortune.

The other option is to put the mods on a higher layer, which of course raises the obvious question of how you can then combine those modifiers (which are keys that must be held down, after all) with the alphabetical keys on the base layer. Fortunately there’s a ready-made solution for this too: the concept of one-shot, or sticky, modifiers. These are keys which once tapped and released remain virtually held down until a non-sticky, non-modifier key is pressed — and thus are combined with them, from the computer’s unsuspecting point of view.

Here’s a simple example. You want to press Command+Shift+T in Safari, which will reopen the last tab you closed. With one-shot mods on a momentary layer, you’d do the following:

  1. Hold your layer-switching key, which will toggle you into the required layer to obtain your mods.
  2. Tap, in sequence, each of the mods you want to apply to the final, virtual keypress.
  3. Release your layer-switching key, which returns you to the base layer and the alphabetical keys.
  4. Tap the T key. The computer will see Command+Shift+T being sent simultaneously. Your keyboard will release all three keys an instant later.

This is similar to how the software keyboard on your phone works. You tap the Shift key, which is sticky on software keyboards unlike the real thing, and the letter keys change to being uppercase. Then you tap an uppercase letter. The app you’re typing into just sees a single, shifted/uppercase letter keypress, as one event, happening at the time of your final keypress. Then your phone automatically releases the Shift key ready for your next input. You’re already familiar with the idea; you just perhaps hadn’t thought about it in procedural, consequential detail before.

Most implementations of one-shot mods (OSMs) in keyboard firmware rely on timers: sticky keys remain stuck only for a certain period of time, or perhaps a period that’s renewed if a further sticky key is pressed within the first period and so on, and then they automatically unstick themselves even if you’ve not performed an actual (non-sticky) keypress. This presents challenges when you’re also navigating layers at the same time, and I’d prefer that my one-shot keys remain virtually pressed until I explicitly either commit a combined keypress or abort the procedure. No timers required, and no problem for layer-navigation, as long as you can “carry” the stuck-down keys with you as you move between layers.

This latter type of OSMs is informally called Callum mods, after their creator, and it’s those that I chose to use. I made the tweak of adding Caps Lock as a fifth one-shot modifier, because I remap that key in iPadOS to act as the Globe (or Fn) key which is only present on Apple-manufactured keyboards. iPadOS 15 and later provides a higher tier of globally-scoped keyboard shortcuts which semantically-appropriately use Globe instead of Command as the signifying modifier, so it’s useful to be able to treat Caps Lock just like the other four mods here.

The only other thing of note on my Base layer is that I chose to keep the quote key instead of the semicolon key, even though the former now occupies the latter’s usual position. I write fiction, and dialogue is substantially more common than semicolons or colons in most fictional prose, so it’s a good tradeoff. My semicolon remains accessible on a higher layer, as you’ll see.

Next, the Nav layer, reached by holding the right thumb layer key.

Nav layer

This layer has a few purposes: cursor keys, a set of mods, whitespacing keys (including Escape), the most common system and clipboard shortcuts, and general movement between pages, tabs, and apps.

The important thing to notice is the placement of the two primary elements — the cursors and the mods. They’re on the home row, of course, requiring no finger movement at all to press Command, Option, Control, Shift, and the Left, Right, and Down arrows. A single-unit movement of a single finger produces all other functions, with the only diagonals being required for Page Up or Redo, each comparatively uncommon. Escape, Backspace, and Enter are all in logical and immediately-learned positions which reflect where they relatively lie on larger keyboards, and the mods are in familiar order on the left side.

The system shortcuts for the pasteboard are placed in their correct positions with respect to the base layer and a notional number row respectively, and the app-switching keys are easily accessed with compact movements. A dead key is deliberately left between Backspace and Enter, each of which is comparatively dangerous in its own way.

Shift and Space remain available from the Base layer below, and the fact that this layer requires holding the rightmost thumb key leaves the left thumb free to contribute Shift to any modifier combination if preferred to the dedicated Shift key on this layer, which is of course critical for use with the cursor keys when editing text. On a larger keyboard, use of the cursors (notwithstanding emacs-type shortcuts and similar) would require lifting the right hand entirely away from home position; not so here. Likewise, Command+Return, Option+Backspace, and so on are all readily triggered.

Next, the Num layer, reached by holding the left thumb layer key.

Num layer

Num layer

This layer’s responsibilities are simple: to provide a numpad (with autoshifted symbols the same as those on a conventional number row), a selection of commonly-needed other symbols, and a duplicate set of one-shot mods for convenience. Here we find the Tab key, the relocated semicolon key, a handy pair of explicit parentheses as well as the usual bracket/brace pair, mirrored slashes which are a lot easier to find than on larger keyboards, a better-placed grave/tilde key for terminal usage, my often-needed em-dash (and occasionally-used en-dash), and of course the wonderful numpad grid which is vastly superior to a number row for quick and accurate numeric input.

The zero key is offset by necessity, overriding the Space key on this layer only. Autoshift is used to obtain the shifted characters on the number keys, such as % on the 5 key etc; autoshift is a QMK firmware feature whereby holding a key for a fifth of a second — or configurable other interval — will produce its shifted character instead. These are the only distinct hold-functions in the whole layout. You can, of course, also use the dedicated Shift key on this layer instead.

The presence of the duplicate set of modifiers is useful here for two reasons: first, you don’t have to remember which layer-switch key will give you mods, and secondly there are many apps with keyboard shortcuts involving number keys; often to change views. The presence of the duplicate mods here make such shortcuts easy to trigger.

Lastly, the Adjust layer, reached by holding both thumbs’ layer keys.

Adjust layer

Adjust layer

This layer’s name follows the Planck tradition, but its responsibilities are wider: it provides both media keys and screen-related shortcuts, a slightly altered tertiary set of mods, and mouse functionality with scroll-wheel. A few points of note:

There’s an unoccupied block of keys on the right hand too, if I think of future shortcuts that might be useful enough to deserve a dedicated key.

Closing thoughts

If you’d like to try this keymap for yourself, it’s available on github. This particular keymap is for a QMK-powered Corne with per-key RGB LEDs, but you can adapt it for your own purposes easily enough. If you’d just like a consolidated diagram of all the layers, you can find one here.

This layout was immediately superior to my last one, and it’s such a relief to not have to stretch those pinkie fingers to a whole additional column of keys, throwing my orientation off and causing errors. Cutting off the sixth/outer column for me was the missing piece of being pushed into a strict home-position style of typing by using a split keyboard. I’d recommend not trying one without the other.

I think I could get down to 32 keys easily enough if I wanted to. Maybe even further. But getting to 26 (one column of 3 per finger without any lateral movement at all, plus only one key per thumb) remains dauntingly impractical for now — but you never know. That’s the thing with this hobby, or field, or whatever it is: there’s always something else you can try.

Thanks for reading. If you’d like to talk about this, I’m @mattgemmell on Twitter.

Addendum: The keymap diagrams in this article are the output of a Python script I wrote, to auto-generate an illustration of my layout and its RGB LED setup from the actual C keymap file itself. While it’s entirely dependent on my own specific keymap file, you’re most welcome to adapt it for your own use; you can find it here.