I have spent some time developing a keyboard concept; I am proud enough of the design to want to share it even though I seem unlikely to actually implement it.
Layout and Rationales
The general design is inspired by split keyboard designs such as the Corne keyboard described in one of Matt Gemmell's blog posts. While the orthocolumnar key positions and angled thumb clusters are clearly more ergonomic (the fingers' rest positions are not arranged in a line and the thumb moves at an angle rather than up and down; the natural reach for the index finger is also lower than the rest position), I chose an ortholinear layout as an aesthetic choice with some expectation of psychologically easier adaptation and possibly some manufacturing advantages. The design also differs substantially from the Corne in having: six thumb keys (vs. three), an extra column for the little finger, four extra keys on each of the thumb upper rows, and eleven hard-to-reach keys (yellow in the image). A little bit of experimentation using a number pad gives me some confidence that the extra keys (excluding the difficult eleven of each hand) are not unreasonable, though such gives almost no indication of actual discomfort from extended use. The extra thumb keys in particular seem important to have all five modifier keys (shift, alt, layer, system, and — with the index finger — ctrl) available for each hand; even if holding the modifier key while typing was not required (e.g., tap setting the modifier for the next keystroke with another method to lock and unlock a modifier), there may be some advantage for hand use balance and possibly ease of learning. Having space (tab when shifted), backspace (backtab when shifted), enter, and delete as thumb keys is similar to Matt Gemmell's use for the Corne — since his layout has shift only on the same thumb cluster with space and backspace, he cannot use the mnemonic of emphatic/shifted space and backspace for tab and backtab (I am a little concerned about mapping backtab to a shifted destructive key, but undo functionality is common).
The letter placements are clearly inspired by Dvorak and Colemak, but the extra little finger column on each hand allows the four least used letters (z,x,q,j) to be moved to make room for ctrl and one symbol key on each hand as well as another distant (but still comfortable for the little finger) symbol key and action key (pause, menu) for each hand.
I am rather proud of the symmetry of the layout. The enclosure marks are in the same position for each hand; «,?» and «.!», «\`» and «/%», «-_» and «+|» are in the same position for opposite hands; and for the base layer letter or symbol positions are the same on each hand. The letter placement is largely guided by frequency and having vowels on the right hand (I am guessing that having the vowels on one hand may also help in the learning process). The placement of F and P in the same row and P and B in the same column may help in learning because of the sound association; U and V have a visual similarity (while the separation may reduce mistakes); M being adjacent to N seems likely to be helpful. The shifted symbol mappings also has significant mnemonic aspects; '$' is associated with numbers (#), '+' with or (|), '*' with and (&), ',' with '?' (pause), '.' with '!'. The more angular enclosure marks ('<>' and '{}') are shifted from the visually closer enclosure marks ('[]' and '()').
The page up (🡅) and page down (🡇) keys may be frequently enough used to justify being accessed by the index finger. The arrow keys are in standard positions but for the left hand. The home (⇤) and end (⇥) keys are on the main row and have positional mnemonics (⇤ is the leftmost left hand home position and ⇥ is a rightward reach for the index finger) as well as letter mnemonics ("home" begins with 'H' and "end" ends with 'D'). I might have preferred using shift arrow for the more "emphatic" movements, but shift-navigation-key is used for text selection.
Many keys in the number/navigation layer do not have any special assignments. Keeping '+', '-', '*', '/', '.' and '=' in their base position would provide all the keys associted with a typical numberpad in that layer without having multiple positions for a key (depending on the layer). (Keeping '(' and ')' would provide a reasonable calculator interface. And having capital A-F in the same shifted positions would provide hexadecimal number entering in that layer with only the requirement of shifting.) Even with so much key "transparency" between base and num/nav layers, there would still be many keys available for new uses; however, I have not been struck by firm inspiration for uses. (Page/document set "start/top", "end/bottom", "previous", "next", and "up" could be useful — "down" is less useful because in a tree organization down is not specific, though it could mean "next downward". History navigation is also different from text navigation and document set navigation.)
I am hoping that these layout factors will significantly facilitate learning; quoting Matt Gemmell: "When moving to a new and thus unfamiliar layout, remember there are other things to capitalise on: consistency, logical arrangement, personal needs, symmetry and so on. These can become the basis of a new familiarity, and will aid learning."
(Earlier, I had planned for a one-piece keyboard with significant hand separation. Adding three or four intermediate columns would provide seven or eight key separation of the hands compared to two key separation on a typical keyboard. Even without that addition — or placing a trackpad in the middle ☺ — the separation would be three keys more than a typical keyboard. A 17- or even 19-key-wide keyboard might be practical on a laptop.)
I am not absolutely convinced that the assignments are the best possible for the spatial layout nor that the spatial layout is the best management of the tradeoffs of aesthetics, familiarity, and ergonomics. However, I do think that this is a solid design.
I am slightly concerned about the use of a layer to access numbers and navigation. Since I am already a little familiar with a number pad arrangement and the layer key on each hand seems less difficult to reach (located where the zero is for the right hand on a typical number pad) than the shift keys on a typical keyboard, I am hoping that entering numbers will not be problematic. The advantage of having numbers be more reachable and less subject to error than when using a number row seems to justify this choice.
The yellow keys positions seem of questionable utility, but there presence would not affect the width even of split sections. I do think that providing F0 through FF for function keys is cute. The other six yellow keys might be useful for infrequently used operations for which quick access might still be useful (e.g., mute, screen lock).
Adding more layers has some attraction. Highly modal operations (such as navigation and system control) would seem to fit the layer model. While double-tap of the layer key might reasonably 'lock-in' a third layer (with a tap of the layer key to unlock), accessing additional layers would seem to present some learning challenges.
Motivation
My motivations for this effort seem to include the general fun of spatial design with some analysis of tradeoffs, a desire for a more ergonomic keyboard — particularly in moving modifier keys off of my little fingers, one of which has developed bone spurs —, and a desire for a sense of accomplishment in a simple hardware-ish project.
The earlier mentioned article by Matt Gemmel was very helpful in guiding my thinking about key placement. I am a little jealous of his four-layer system ("base" with letters and some common keys; "navigation" with both mouse and cursor controls; "numpad" with numbers and symbols; "adjust" with media and screen controls). I am not certain I could learn to manipulate a mouse pointer well with a keyboard, but the concept is intriguing. Media controls would seem to map easily (in terms of remembering the mappings) to the navigation (page up and page down for volume control, left for rewind, right for fast forward, down for play/pause ("here"), up for stop (intensified [above] pause)
My design has 62 "essential" keys (excluding the 25 "yellow" keys) compared to the Corne's 42 (though four modifier keys are replicated for each hand), so there is less pressure to add layers, but layers can take advantage of associations and exploit modal activity.
Implementation and Future Considerations
If I were to implement such a design, I would be rather inclined to use rubber dome pressure switching primarily for lower cost (financial as well as time and effort, both start-up and incremental) but also from some concern about noise and required finger pressure. The concern about noise and finger pressure could be addressed by using more expensive, quiet linear switches; even without such added costs, the barrier to trying is high enough that I seem unlikely to try. I very much dislike being stuck with relatively expensive items that I am not going to use and that I can not give away to someone who really wants such. (I also have considerable issues with fear of failure, sometimes including self-sabotage — if one does not hope to succeed and does not put in the required effort, failure is not a crushing statement of how worthless one is. Thinking about things until there is no risk is generally not a productive strategy.☺)
With more intelligence in the keyboard, double-tap and hold could be distinguished from a regular keypress, some idioms could be automatically composed without having to use the compose key (e.g., "--" → "—"), and perhaps the repeat rate might be usefully configured differently for different keys (including different acceleration). There might also be some uses for multiple non-modifier key presses at the same time, at least for the home row.
While a split design would require more modifications to a typical keyboard case and complicate the electronics (with financial and effort costs), it might be a little more portable, has some ergonomic advantages, and has a little more "coolness". If a separate microcontroller was used for each hand, it might be easier to increase the number of overloaded keys (supporting simultaneous pressing). A split design would also complicate the connection; implementing this as two USB devices might be simpler for an initial prototype. Given my motivational issues, getting something earlier that mostly works could be important.
If I actually successfully produced a version of the above design, I might well be tempted to pursue a "second system" to include additional features. Including a USB hub seems especially desirable as such would provide for convenient insertion of a thumb drive and a Ubikey as well as a mouse. Adding a USB hub would require considerably more expensive hardware, but it would also add some fun of considering how ports should be placed. I suspect two rear ports and two side ports might be a good basic design; the rear ports might be reasonable for attaching persistently present devices such as a mouse while side ports might be a little more accessible. Vertical ports would seem to avoid potentially having to hold the keyboard to insert a device but such might be difficult to fit in the keyboard form factor.
(I am surprised that including USB ports in keyboards is not more common; even most of the (somewhat expensive) ergonomic keyboards seem not to include such. Plugging a mouse into one's keyboard would allow for a shorter cord — yes, I am aware that wireless mice exist, but I am turned off by having one more set of batteries to deal with and a little uneasy about reliability — but having USB ports readily at hand for Ubikeys, thumb drives, and mobile devices seems even more significant. Supporting fast charging through a keyboard might be expensive, but for my uses that would not be necessary.)
It would be really cool if this design (or one similar to it) was popular enough to support a modest production run (~100 devices), but that seems very unlikely.
