Design Log and OpenSCAD code repo for Custom Split Keyboard
Design Log and Code Repo for ''''Customizable'''' Split Keyboard
Thanks to this ever-growing and enthusiastic community, there are several options for split scooped keyboard designs and if you are willing to put some effort into printing and building a pair, you can have your very own as well. However, once I began to play around with them, they raised more questions than what they seemed fix: typing experience of thumb cluster and pinkie columns improved, but still felt awkward at times, necessity to still move my wrist in order to access inner index columns, why not account the key orientations and contour radius to actual fingers motion? etc. etc. I could no longer justify why I need to suffer physically by design concepts of kind and knowledgeable, yet intangible netizen smug with their take on this modern torturing device. I want in on smugness quotas, too. So began my financial woe and mental suffering... And here you are, dredging up this repo page somehow and before your waning attention span exhaust, I will attempt to describe my concepts and experiences of this process in details you have never asked for.
Glory to Datahand and Tron, our ergo forefathers.
Mapping finger flexion to a placement function: To achieve a minimum finger movement, more aggressive row wise contour is desirable. Let us define two arcs of a finger tip during a flexion: inner (distal and intermediate flexion) and outer(distal, intermediate, proximal flexion) with palm side of metacarpal phalangeal joint as the origin. These arcs are mapped to a parametric functions defining the radius of an arc at a given angle from origin with 0° as neutral full extension and 90° as full flexion. They simulate trigger motion and grab motion respectively and it is assumed that optimal row placements of keys reside somewhere between two such functions.
Using a CAD program I devised following ad hoc rules that will accommodate switches in the arcs.
path radius offset: for shorter fingers (ring and pinkie for me), switches origin must be offset to accommodate the switch and keycaps to avoid collision.
roll angle: When I fold my fingers, fingertip does not stay parallel nor in-plane with respect to vector spanned by proximal phalanx and metacarpal. This deviation becomes noticeable with high contour column and column origin transformation does not correct it.(such as adding yaw: see below section). Therefore, roll transformation was added to reorient switches out of columnar plane to bring key orientation closer to natural path of finger tips.
Each origins of columns defined above can be transformed to fit the natural spread and orientation of fingers. For better (ergonomically) or worse (design complexity), We can loosen the orthogonality restriction between columns and gain the freedom to yaw and roll the columns to conform to the arch of palm. With the traditional mx switch and keycap, the out of plane features collide with adjacent columns when optimized for correct placement. Without desperate measures, as we will discuss later, the compromised placement with a high contour leads to a typing experience that was subpar at best, given my finger length and spread. Major issue was that the outer most keys such as outer index and pinkie top rows required wrist motion and exaggerated extensions to hit the keys. This may not be the case for those with longer fingers and requires inputs from those who is willing to try this design.
Notes on some of the observations made during the design iteration on each columns without applying compact switches.
My initial intention of this project was to keep the design accessible by limiting to commercially available switches and keycaps, I did not wish to invest time redesigning key profiles; however, what was available no longer sufficed to the requirement: narrower design something along the line of alps SKCM compact was needed. These are not readily available in large quantities and keycaps more so. As a desperation, I resorted to lopping off the LED compartment of MX switches as well as few keycaps to test the feasibility of such. The result was not pleasing to say the least, but it allowed optimization. Not entirely enthralled, but few test prints proved that the pro out weighed the cons:
Custom key caps brought some benefits as well:
Notes on column with compact switches.
I have created stick representation of my thumb in OpenSCAD and initial attempts sought to pack as many switches near the ideal thumb motion without considering collision. While keys were accessible they did not produce efficient press and produced strain because thumb position. I've replicated and tested other notable design philosophy: datahard, manuform, and dmote to ended up with following design criteria ordered in priority:
Compromising this is the cardinal sin of design and it is exacerbated when number of clutter keys density increases. To accomplish this for ErgoWarp, C1R0 (secondary index bottom row) was removed and replaced with C0R1 (ternary index home row) which allowed thumb cluster to come closer to its optimal location.
Natural thumb position should be measured with ones hand down by one's side not at the typing position (arm out); thumb abduction will be exaggerated leading to incorrect optimization
Prefer actuation with palm sides surface (adduction and flexion and not abduction and extension)
Most compact split keyboards rely on 1u thumb clusters, with it We are accustomed to pressing space bar with side of the thumb, so much so that I was recreating this bad design despite given the opportunity to correct them. All three mentioned forerunners have broken out of the box albite with their choice of priorities and compromises. When press orientation becomes thumb flexion near the neutral thumb position, the use of heavy switch must be avoided, as the torque will shift wrist position which creates strain when chording with same hand fingers. DataHand breaks this design philosophy, but it is the result of adapting light low travel switch irreplicable with mx switches. manuform follows this to the t, but by reducing the priority to minimize motion. dmote also follows this, but prioritize cluster density over correct orientations. needs edit
Minimize travel distance while maintaining correct press orientation
This also means that high concave contour designs that conforms to the key profiles should be avoided. To reiterate, avoid adapting datahand like welled cluster with mx switches; they may reduce travel somewhat, but it is in no way a comfortable design nor do they allow accurate chording. The design goal seems conflicting statement with normal mx switches, but by uti
Ability to chord press
It is desirable to place modifiers and layers on thumb cluster, but without the ability to chord them effectively, their utility is hampered. especially when this design takes away conventional bottom row modifiers. Utilizing super, hyper modifiers, layers and tap modifiers are well intended, but compromised solution adding mental load when good thumb cluster design can do it all. Avoiding awkward wrist position and motion when chording requires all mentioned design goals.
result is a compact six key design akin to dmote. justification and description of each position below:
first three are neutral position cluster requiring minimum movement to actuate. T0(red): actuated by a neutral tip addution, simulating a pinching motion. it is the most comfortable press and since its motion separate, least prone to miss-press. thus it is the home key. T1(blue): neutral tip. this can be actuated by combing distal flexion. allows fast transition from homekey and is best suited for layer or shift. T2(green): placement-wise this is closest to the true neutral position of thumb by flexing medial joint the switch can be actuated, or by sliding. also efficient allows chording between T3 and T4.
the next three are outer sets that T3(white): adduction with flexed distal faster of outer set. T4(purple): T5(yellow)
cylinder represents the thumb. (thumb cluster ver2)
Thumb cluster desirable traits:
dox like style attempt to minimize travel by having normal cluster and maintain chording to a degree, but often the thumb home is too. but problem with side adduction press is that it produce strenuous press when combine with high extension.
manuform break the compact cluster criteria to achieve correct orientation. but by doing so with normal switches produce longer travel distance and loose efficiency on outer keys.
datahard I have not tried, but cluster similar to such layout did not pass. mainly due to mx switches fails due to its longer actuation throws. similarly high concave contour was not good enough
dmote overall cluster press orientation is mostly correct, but chording is not ideal, home is too far from neutral(with my thumb length) and high collision with index columns. Clustering seems to be prioritize over orientation for anterior presses and seems awkward.
with compact mx switches
wrist rest
putting load on nerve path of hand and palm all cost and distribute the load properly.
a supporting structure that conforms to the cavity created by the natural arch of the palm.
they are modeled by a sweep of traversing center with a ellipsoid
a supporting structure that conforms to the cavity created by the natural arch of the palm.
they are modeled by a sweep of traversing center with a ellipsoid. palm support alone is insufficient in my opinion as they do not distribute weight enough and not enough constraints as the hand moves and slips out of the support. an additional support were required.
a distorted ring that supports thumb metacarpal and it's ellipsoidal blob, but avoid index/thumb nerve channel.
a distorted ring that support pinkie metacarpal and it's ellipsoidal blob when angle of tenting becomes sufficiently high >30 a proper support is required at edge side of the palm to discourage slippage while allowing free movement of pinkie finger.
###Trackpoint Prototype 1, 4, and 5 were made with Trackpoint in mind, but due severe drifting issue I could not completed usage test. After some input from another forerunner, to The cause of the drift was most likely due to me roughing around the module housing and poor mounting which applied constant distortion on module. TODO Repeat test
####Trackpoint with Switch integration
An adapter for MX key stubs to trackpoint stub. compounding with navigation layer was attractive. Tried with prototypes 4 and 5. produced mushy feel and noise.
###Trackball: under construction
The effort map changed considerably to a point that I felt it was a valid excuse to consider my own layout. Vertical downward transitions are faster and Workman layout philosophy jived well on initial trial. With the reduced effort to actuate bottom row, allocating higher frequency letters was less of an issue. Generous thumb cluster also made sense to adopt maltron like thumb layout. As a personal preference, emphasis on rolling and same hand typing were also considered.