Sunday, May 1, 2022

An ortholinear split keyboard design

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.


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.

Sunday, July 30, 2017

The phases of work

Ordinarily, work is a gas, expanding to fill its containing time. Under intense pressure, supercool it and work can become a coherent liquid, but it is extremely difficult to get solid work. (If one puts enough energy into work it may become a plasma, but then one really wants to be sure it is safely contained or it will consume everything around it.)

Sunday, May 7, 2017

Spider-page Theme Song

Joking with a fellow page at the Silver Spring Library about becoming an extremely effective page by being bitten by a radioactive spider (given the generally understaffing at the library), eventually led me to thinking about "the Spider-page". I had a few general thoughts about a comic, but today I finished the "Spider-page Theme Song":

Spider-page, Spider-page. Working hard for his spider-wage.
Sorting books, fronting shelves. Outworking book-work elves.
Look out, there goes the Spider-page.

Is he smart? That's insane! He's got more than an average brain.
Can he read faded ink? His eight eyes never blink!
Hey, there! Work for the Spider-page.

When a book's out of place anywhere in the stacks
You will feel your heart race when you hear his web thwacks! (Shhh!)

Spider-page, Spider-page. Local library Spider-page.
Bonuses, he ignores. Order is his reward.
Look out, there goes the Spider-page.

Spider-page, Spider-page. Local library Spider-page.
Bonuses, he ignores. Order is his reward.
For OCD he has 'fessed up. Whenever things are messed up
Go find the Spider-page!

It is not a perfect parody of the Ramones' "Spiderman", but it seems somewhat decent.

While the "book-work elves" came only to make the rhyme, it did lead to the thought that in a comic most of the elves would be grateful for the Spider-page's work (perhaps allowing them to do more tradition book-elf work like repairing books) but one elf (perhaps an especially big and strong one, thinking that the book-elves would be like the shoe-brownies in size) would be annoyed at his special ability (physical strength) has been made less important becoming an antagonist.
In a comic, the "web thwacks" would be humorously inappropriate noise in a library (and contrasts Spiderman's quiet "thwip").

The obsession with order is probably not an uncommon feature for pages, and exaggerating such fits a comic. The changes to the last lines of four of the stanzas seems to also fit with the Spider-page being less agile and even less respected than Spiderman ("Look out, there goes the Spider-page" has more of a sense of "Watch out, coming through" vs. "Pay attention and you can see a superhero" and "Work for the Spider-page" and "Go find the Spider-page" imply that his OCD is somewhat abused to give him the less desirable tasks). The eight eyes also presents more spider-like features; in a comic, I think he would have a spindly limbed appearance perhaps with an expanded abdomen — incidentally fitting a particular nerdy stereotype so that there could be humor in his becoming more nerd-like in appearance after becoming a superhero. Where Spiderman has a tingling spidersense; the Spider-page could have a throbbing page-sense, the transformation enhancing a vocational/human trait rather than providing a quasi-spider trait.

I very much doubt that a comic will develop from this (not even a single story). While I could probably do a stick-figure mock-up with dialogue given a substantial time investment, a serious effort would require someone with skill at drawing. If I had strong motivation to work on such a project, it might be practical (artists can be hired), but so many other potential projects are so much more attractive (more suited to my skills, more likely to be useful/appreciated by others, better matching my affections) to me that making a Spider-page comic seems unlikely (though the concept seems fun).