An evolved 34-key layout for iPadOS
I’ve previously written at length about my various custom keyboard layouts for my several mechanical keyboards. I’m about to do so again here, so if that’s not interesting to you, you should most certainly bail out right now with my blessing.
The only constant with this hobby is change, and there’s always a decision to revisit, or a perspective to adjust. I do have a Magic Keyboard for my iPad Pro, which has 65 keys in its UK variant, and it’s definitely far too large for me; lots of keys means lots of stretching and hand-movement. I can type very quickly and comfortably on it, and that should be enough for most people, but I find it aesthetically displeasing — in terms of theoretical efficiency, rather than visual design (in the latter regard, it’s just… Apple-like; clean, but with no discernible personality at all). I also want to remark upon the ludicrousness of it having a key, in the top-left position, which types § (section) when tapped, and ± when shifted. I hardly think either of those symbols deserve a whole physical key. But I digress.
Let me openly acknowledge what you already know to be true: I don’t need multiple keyboards, and I don’t need to experiment with different layouts and design them myself, but those things are enjoyable for me. They keep my mind occupied and distracted from my anxiety about world events and basically everything at all times, so here we are. I’ll be the first to admit that none of this is necessary, and that almost everyone will be perfectly happy and productive with whichever keyboard came with their computer. I envy them, and their respective balances of both disposable income and leisure time.
Back to keyboard layouts. I’ve gone as low as 30 keys, which is entirely workable: by using layers, you can fit more virtual keys onto a 30-key board than you’ll find physical keys on the largest keyboards. A small board also requires less stretching, and almost no hand-movement. I designed a 30-key ortholinear layout, which was itself a descendant of my previous 34-key Corne layout. The problem with my 30-key layout is that I focused on compressing everything into the alphanumeric block, which is fine until you realise that you’ll want to involve your thumbs too. Trying to use your thumbs to occasionally actuate keys on the lowest of the three alphabetic rows is a path to pain; the ergonomics are terrible.
I learned an important lesson: if you have decades of muscle memory which make you want to type certain keys with your thumbs (which for me means the Command key with my left thumb, and Space with my right), then you’d better have keys for those functions in a suitable physical position for your thumbs — i.e. below the alphanumeric block. To use a board with just three rows of ten keys without discomfort, I’d need to tape my thumbs to my palms or some such thing. No thanks.
Thus I’ve come back to a 34-key layout, in this case implemented on a Corne split keyboard. Cornes by default have 42 keys: three rows of six keys, plus three thumb keys, per hand. For me, that’s too many, especially for the thumbs. I find that I’m most accurate when my thumbs have only a single responsibility each, but I can stretch to two keys per thumb if those keys have quite distinct positions, as on a Corne’s innermost two pairs of thumb keys. Keep in mind, the goal is to create a layout where there’s minimal stretching of fingers, and no moving (i.e. lifting and repositioning) of hands at all.
Accordingly, this layout uses three rows of five keys, plus two thumb keys, per hand. This leaves eight key positions unused across the whole board; I’ve simply removed not just the keycaps but also the underlying switches, leaving the plate exposed at those positions, with nothing to press or rest upon. I have some little plastic covers on the way to make it all a bit more pretty.
A brief note on the thumb keys, of which I have two per hand. I very much like using a Planck-style (that’s the ortholinear keyboard, not the German physicist) layer setup, which just means that you have four layers overall, and two layer-switching keys which are always in the same place on each layer. Holding the first layer switching key changes all the rest of the keys to be those from your second layer. Holding the second layer switching key gives you your third layer. Holding both at the same time gives the final layer. This is exactly how the Shift key on your keyboard works, or indeed any modifier key like Command, Option/Alt, and so on. Releasing those keys brings you instantly back to your first, or base, layer. It’s easy to understand, then, that the best digits to devote to layer-switching are your thumbs, because you can hold your thumbs down while still allowing your remaining fingers a huge degree of motion.
Everyone has used virtual layers on keyboards, of course; there’s the aforementioned Shift and other modifiers, and indeed you can actually see the layers system if you use the software keyboard on a touchscreen phone or tablet. Even so, there does seem to be a mental barrier for many people regarding additional, non-standard, layers — especially since you’ll be “typing blind” in all but your base layer, because only your base layer will correspond to what’s physically printed on your keycaps (unless you have an extremely fancy keyboard with little screens on each key, or a projected key matrix, or some other novelty). The most common question I get isn’t about some nuance of my chosen layouts, but rather how I can possibly deal with jumping between multiple entirely different configurations if I don’t happen to have my own custom keyboard with me, or if I’m using someone else’s machine, or when I create a new layout to try.
The answer is simple, and it’s so simple that it probably sounds flippant, but I assure you it’s not meant to be; it’s just one of the basic truths of cognition and intelligence. Keyboard layouts are exactly like languages, or musical instruments: if you only know one, then learning the second one is hard. But if you know two, then learning another one (or two, or three) is much easier. Naturally, it also helps if you’re the sort of person who enjoys applying yourself to such challenges. Most people aren’t, I think, and that’s absolutely fine and sensible. You’ll find no judgement here.
So, let’s briefly cover my requirements for this new layout. It’s very heavily based on my previous 34-key Corne layout, but filtered through my experience with that layout and also its 30-key descendant, and a further 42-key non-ortholinear board I’ve been using — for which I designed a split-Space layout where the two Space keys doubled as layer-switching keys when held. I’ve had a few months with each of those intermediate layouts, and they all have shortcomings, inevitably. So will this layout! But those experiences have let me refine my checklist of needs and wants, as follows.
- Planck-style four-layer setup, as discussed
- Consistent thumb keys, i.e. identical on every layer
- Right-hand Space, for my own lifelong typing style
- Right-hand cursors, for consistency with most keyboards I’ve ever used
- Cursor and mouse movement keys should be in identical positions
- A numpad instead of a num row, because it’s much easier to touch-type with speed and accuracy
- Autoshift (i.e. hold a key for its shifted variant), except on the base alphabetic keys
- One-shot modifiers (see below) in all non-base layers
- Repeating patterns wherever possible, to aid recall
A few notes on those points. Having keys which are identical on every layer is often called transparency in keyboard layout parlance, because notionally the base layer lies “below” all other layers, and if a key on a non-base layer has no assigned function and isn’t explicitly deadened, the keypress will “fall through” to the base layer (or indeed to an intermediate active layer, but that’s a more complex idea). It’s just like transparent areas on a given image layer in a graphics application; you can see through that area to what’s on the uppermost non-transparent underlying layer beneath it. Suffice it to say that a key on a given non-base layer which has no layer-specific function, and will thus default to that key’s function on the base layer, is said to be transparent.
Also, the term one-shot modifiers may be unfamiliar. In general, one-shot means something that’s only active for a single action, or rather that it only takes effect at one time. This is a rather vague way of describing a simple thing: a one-shot modifier is a modifier key (like Shift or Command or Alt) with the additional special behaviour that, when tapped, the key doesn’t actually “fire” immediately, but is instead queued up until you press any non-one-shot key — at which point the whole lot is sent to the computer at once. Traditionally this is an accessibility technology for people who have motor difficulties, and who would thus struggle to press multi-key shortcuts like Command+Option+Control+A. Most modern operating systems allow invoking a mode whereby modifier keys have a one-shot behaviour, so that the user can press each of those modifiers one by one, and then when a non-one-shot key is pressed, that final key is sent alongside all the queued-up modifiers as a single chord, as if they’d all actually been typed simultaneously. This allows inputing arbitrarily complex keystrokes using just one finger, with no urgency or physical strain.
As it turns out, one-shot functionality is also extremely useful if you have a physically small keyboard which has multiple virtual layers: you can use it to keep your modifier keys on layers other than the base layer, and when you need to type a complex multi-key keystroke, you simply switch to the relevant layer, invoke each required modifier either in sequence or together, return to the base layer, and press the required letter key (or number key, or anything else) to invoke the whole shortcut. Note that the final non-one-shot key may reside on the same physical key as one of the modifiers you just invoked, just in a different layer! The nature of the one-shot behaviour allows you to effectively “carry” keystrokes between layers, offsetting the otherwise insurmountable limitation of a keyboard which is physically too small to hold the entire alphabet plus the four or more modifier keys that most of us are familiar with.
Lastly, autoshift is extremely handy on number keys to generate symbols, and on punctuation keys for the same reason, but it’s not generally useful for the ordinary letter keys, where variations in typing speed (or rather, in typing rhythm and stacatto) can produce false positives. I also have a habit of resting for a moment on the letter key of keyboard shortcuts, probably to reassure myself that I’ve triggered it properly since I’m from a generation long before pervasive autosave. You don’t want unintentional Shift keys added into your keyboard shortcuts, thus triggering an entirely different function. For those reasons, I don’t autoshift my alphabetic keys.
With that said, on to the layout. I’ll embed layer-by-layer diagrams here, but you can also view a full diagram of all layers if you’d like. Let’s begin with the base layer.
Yes, it’s still QWERTY. Changing my basic alphabetic layout isn’t an optimisation I care to make right now, but if that’s something you want to explore, there are many, many options; my advice would be to look at Colemak DH first. But my real advice would be that the cost-benefit ratio will likely be much more favourable if you just make some optimisations of the non-alphabetic portions of your layout. If you’re having serious problems with RSI, though, the metrics indicate that Colemak and its variants will help you — albeit after a very significant learning curve.
Allow me to wax philosophical for a minute. All specific, custom keyboard layouts are dependent on which general alphabetic layout you’re used to, and what you use a computer for, and what operating system you’re using, and what your own unique typing style is, and probably other factors too, so there’s a lot of variability. I can only speak for myself, and I can only theorise regarding those who are substantially myself-adjacent, as exemplary as those paragons of humanity undoubtably are. With those caveats, then, here’s my assertion: I think that if you’re a QWERTY user, mostly writing prose rather than coding, and you can touch-type, then 34 keys may in fact be the ideal number. That’s with four thumb keys, in particular.
Two of those thumb keys are for layer-switching, as I’ve detailed; one per hand. For me, the additional thumb key for my right hand is the Space key, and for my left hand, it’s the Command key. If you’re using Windows, you’d presumably want Alt instead; the point is to have the operating system’s primary keyboard shortcut modifier there, to allow you to input as many shortcuts as possible without recourse to borrowing one-shot modifiers from other layers.
I feel that there’s a certain ergonomic irreducibility of the base QWERTY layer, with the obvious acknowledgment that I have indeed removed keys from it — but only modifiers and certain punctuation. Given the choice between sacrificing the semicolon or quote key, I of course chose to keep the quote key, because I write prose with dialogue every day. Beyond that, I don’t feel any hardship from the base layer I’ve selected. In particular, it’s a bit of a blessing in disguise to offload both Enter and Backspace to another layer (and thus, to a chord), because it makes those functions just a bit more intentional. Each has impactful meaning in keyboard-navigation and control of modern operating systems, respectively confirming or submitting forms, and cancelling commands or navigating backwards. I’m grateful for my inability to strike them inadvertently while adjusting to a more compact layout.
This brings us on to the interesting parts, namely the non-base layers. The first of these is shown below, and it’s one that I refer to as Nav, or Navigation and Shortcuts. (Note that the coloured keys are not any attempt at categorisation, but rather my chosen LED backlight colours, used as a quick visual mnemonic. I tend to disable backlighting entirely after a layout becomes ingrained in my memory.)
This layer would correspond to the Raise layer on a default Planck, and it’s where I have my system shortcuts (including pasteboard commands, Spotlight, and app-switching), and controls for cursors, paging, and switching tabs. It also contains my Enter, Backspace, and Escape keys, and in common with all non-base layers, it has a set of one-shot modifier keys.
Virtually positioning keys which were previously physically present on a larger keyboard is as much art as it is science. I wrote a very lengthy piece on the subject, and I hope you’ll forgive me if I refer you to it. To brutally summarise, I’ve found that the best strategy is to first pay attention to your mistakes as you learn a new layout, and thus determine where your brain expects a given key to be, and then consider whether that key’s position is encoded in your mind as:
- Relative to the alphabetic keys (such as punctuation might be);
- Relative to the top edge of the keyboard (such as numbers, or Backspace); or:
- Relative to the bottom edge (such as Space, cursor keys, or modifiers).
Then, place the keys in suitable positions on your chosen layers, thus preserving as many axes of familiarity as you can. My aforementioned article goes into unsettling, concern-causing levels of additional detail.
To summarise even further, I find it most intuitive to compress a familiar larger layout by superimposing keys onto layers, with respect to the physical landmarks upon which my muscle memory seems to rely. My Nav layer in this keyboard makes use of this principle in several ways:
- The modifier keys are in their familiar left-to-right order
- Pasteboard (and Undo) functions are superimposed upon their usual letter shortcut keys
- Escape and Backspace occupy their conventional upper-left and upper-right positions
- The cursor keys are in the expected inverted-T arrangement
I’ve also made accommodations for usability in some cases. For example, Enter is one key removed from its usual position just under Backspace, to avoid accidental invocations of a diametrically opposing function. Also, the Page Up and Page Down keys are positioned to the left of the cursor cluster in the right hand, since the forefinger is much stronger and more accurate than the pinkie finger. Further, the Globe key (idiosyncratic to Apple platforms) is placed to the right of Command rather than to the left of Control, because Globe is a comparatively new modifier, and it relates to system-level instead of app-level shortcuts on iPadOS; it is thus “above” or “greater than” Command to my mind, hence its position here (and, for what it’s worth, is rarely used).
The final point of note is the Switch App key, which is unique: it’s a swapper key, meaning that when first pressed, it virtually holds down the Command key and taps the Tab key, which on iPadOS (and iOS, and macOS) displays the App Switcher overlay and advances the highlight to the next app. The swapper keeps the virtual Command key held down, and upon subsequent presses of the Switch App key, will just simulate tapping the Tab key again. This has the effect of allowing the Switch App key to first invoke the App Switcher overlay and then cycle through the apps shown within it. As soon as any other key besides Switch App is pressed or released, the virtual Command key is released, and the App Switcher overlay disappears. It’s a subtle feature, and it’s made necessary by the fact that a simple tap of Command+Tab won’t actually show the App Switcher at all on the Apple operating systems; instead, it just instantly switches between the two most recently-used apps. Having a swapper allows for invoking the overlay and moving through it to precisely select any running app using just a single key.
The next non-base layer, in the position which would be called Lower on a default Planck, is my Num layer — or Numbers and Symbols.
Of the four layers of this keyboard layout, the Num layer is the one which most reflects my personal needs and preferences. There’s a numpad instead of any attempt at a numbers row; dedicated keys for my beloved em-dash and en-dash; symmetrical back- and forward-slashes; parentheses promoted to first-class keys; and of course the return of the semicolon which was excised from the base layer. This layer also provides a home for the Tab key, again following the principle of landmark-adjacency by placing it at the top-left of the layer.
A few notes on what might be some perceived eccentricities:
- The zero key is moved away from its usual numpad position below the 1-2-3 keys because of my core principle of keeping the thumb keys transparent on non-base layers. Since zero is always in a special position on any numpad or indeed phone keypad, this seemed to be an acceptable adaption.
- The grave (backtick) key is periodically useful when writing in Markdown syntax, as I do all day long. This is also the most common scenario in which I use (square) brackets, which are thus adjacent to the grave key, and also vertically aligned with their cousins, the parentheses. The parentheses are in the top row because they’re also in the top row (as shifted numbers nine and zero) on most English QWERTY keyboards.
- Em-dash is much, much more useful when writing prose than en-dash, since the latter is used largely for spans and ranges, whereas the former is used for interjections, conclusions, and other such clauses. Thus, I have em-dash under my left forefinger and en-dash under my pinkie, for the same reasons of comparative strength and accuracy mentioned previously for the Page Up and Page Down keys in the Nav layer.
One final small touch is that each layer has a theme colour, which illuminates that layer’s layer-switching key while held (or both layer-switching keys, in the case of the fourth and final layer, which we’ll discuss momentarily). While the colours for the second and fourth layers were chosen purely aesthetically, the theme colour for the Num layer is the same soft green which backlights the numpad keys themselves. Between you and me, this is because the Phone app on an iPhone has a vivid green icon, which has created a strong association in my mind between keypads, numpads, and the colour green.
(Let’s gloss over the fact that a phone keypad — including the one on iPhones — has 1-2-3 at the top, whereas a computer numpad such as the one on this layer has 7-8-9 at the top. If you’ve never noticed this inconsistency before, then I apologise for contaminating the remainder of your life with such accursed knowledge.)
At long last, then, we come to the fourth layer, reached by holding both the Num and Nav layer-switching keys at the same time. On a default Planck, this would be called Adjust, but for me it’s the Mouse and Media layer.
The similarity of the right-hand portion to that of the Nav layer should be immediately apparent. The mouse controls mirror the corresponding cursor and paging controls as much as possible, with left- and right-click buttons placed in positions which echo how the hand sits on a physical mouse (if you’re right-handed). On the left hand, the playback and volume controls are arranged according to the principle that toggling is in the centre, and decreasing or backwards navigation are on the left, with increasing and forwards navigation on the right. This avoids any ambiguity about, for example, where Mute lies in relation to Volume Down and Volume Up. There’s also another set of one-shot modifiers, of course, with the exception of the Globe key since we’re using the position for something else. The remainder of the layer will benefit from some notes:
- The power-symbol button in the top-right is in fact Lock Screen. This simply invokes the Command+Control+Q shortcut, which you can use on any iPad, iPhone, or Mac for that purpose. If you’re an iPad user with an external keyboard who has always hated having to reach for the physical power button, then you’re very welcome.
- Eagle-eyed readers will note that I’ve placed Mouse Wheel Down above Mouse Wheel Up. This is deliberate, and is due to the fact that iPads and iPhones are touchscreen devices, and thus use content-relative scrolling rather than viewport-relative. It functions the way you’d want, where tapping the upper key scrolls up, and vice-versa.
- The two Mouse Acceleration buttons on the right edge of the left-hand half of the layer are momentary toggles, i.e. they only take effect while they’re held down. As their names imply, they alter the acceleration factor of the mouse cursor when it’s being controlled by the mouse-movement keys on this same layer. In practice, I only use this feature rarely, but there are some scenarios in which it’s handy, especially with iPadOS 16’s support for increased display resolution and large external displays.
And that’s about it. If you’ve read this far, there are two possibilities I can think of: either you’ve been struggling through this article in the hope that it’ll get more interesting, in which case I must disappoint you, or you already find it interesting and thus you have the same odd obsession with this nerdy subject as myself, and I’m allowing you to indulge that behaviour instead of steering you away from it. I thus feel that I must certainly owe you an apology, no matter which group you fall into.
In closing, this is all incredibly subjective and personal, and is presented for your amusement and/or pity as appropriate. I really do find it fascinating, and I’m driven to continually refine these ideas and layouts in pursuit of something I can’t tweak any further. I very much hope I’ll never achieve that goal.
This brings us to the end of more than four thousand words about keyboard layouts. I’d be remiss if I didn’t invite you now to either take a look at my books (none of which deal with keyboards in anything but an incidental way), or indeed to buy me a coffee. I’d say that each of those actions would spur me to write future articles on this subject, but you and I both know that I’ll almost certainly do so regardless.
Thank you for reading.