Ergonomic brainstorm

[hoggy]

Just for fun. No need to justify ideas.

What do you think is missing from the products available (or even projects in development)?

To provide a context to get us started - combinations.

I'm thinking I'd love a tkl with a built in roller mouse...

[davkol]

Adjustable column staggering. I know someone has made a protype and there's a thread about it somewhere, but hell, this would be awesome.

Feet in the front. I haven't seen it anywhere but on some MS Natural and split BTC rubber domes.

Tripod mounts, even on ordinary keyboards. It would be a great replacement for the ridiculously expensive (or bad) trays. I haven't seen it anywhere but on Matias Ergo Pro and some custom ErgoDox mod.

[jacobolus]

Tripod mounts, even on ordinary keyboards. It would be a great replacement for the ridiculously expensive (or bad) trays. I haven't seen it anywhere but on Matias Ergo Pro and some custom ErgoDox mod.

I’ve recommended this to the keyboard.io folks. I’m not sure if they’ll do it though.

[jacobolus]

In general:

better integrated pointing devices. I want trackpoints, fine-precision analog dials/scrollwheels, multitouch trackpads/touchscreens, 3D-rotation trackballs, 6DOF joysticks, etc. These should feed into the keyboard firmware so that end users can map whatever output they want to the input that comes in.

Solenoids with adjustable voltage so that the volume of click sounds can be adjusted.

Switches that are very tactile but relatively low force (comparable to MX blue/brown, or perhaps slightly stiffer). I’m personally a big fan of: SMK “monterey blue” switches, Alps plate spring switches, clicky/tactile Matias switches with lower-force springs, clicky Hi-Tek “space invaders”, Model F buckling springs, and Marquardt “butterfly switches”. None of these switch types is offered in any radically “ergonomic” keyboard shape.

Firmware that supports on-the-fly macro recording, more complete types of GUI navigation using the keyboard, and various other fancy features.

Keycaps of smaller width and maybe also slightly smaller length, which can be placed more precisely where they’re relevant for fingers; the 19x19mm square keycap base is too big and therefore demands suboptimal uniform placement.

* * *

More specifically:

(a) Something with column stagger and lots of thumb keys that manages to be extremely portable; it would be great to see a foldable Cherry ML or scissor switch board, very small and light-weight, for using on the go. Something like 45–60 keys is enough; use layers. I think short-throw compact switches could be better than scissor switches or Cherry ML, but that would take new switch development, so that’s not immediately feasible for small-scale projects run by hobbyists.

(b) For split-flat keyboards:
(1) sufficient column-stagger between fingers
(2) sufficiently profiled keycaps (in my opinion the use of DSA on the ergodox makes it substantially less ergonomic than even DCS would be). With a column-stagger board, it’s possible to be much more aggressive with height steps in keycaps than is possible on a row-stagger rectangular keyboard. (cf. http://geekhack.org/index.php?topic=62444.0)
(3) enough thumb keys, easily reachable by the thumb; I’m unhappy with any existing split flat keyboard’s thumb layout
(4) well-designed systems for rigidly mounting the keyboard to a table or joining the halves for lap use, with very well chosen (or adjustable) separation and angles for pitch/roll/yaw.


(c) For fully sculpted keyboards:
(1) more careful angling of switch axis; the Maltron, Kinesis Advantage, and similar keyboards get this wrong for many keys in my opinion
(2) more careful spatial positioning of keys; smaller keycaps would help a lot with this
(3) more flexible options for adjusting the two hands’ position and orientation, for use by people with different body sizes or postures (standing vs. high stool vs. standard office chair vs. reclining chair all require slightly different positioning IMO).
(4) programmability

[davkol]

Oh, and one more thing. Switches with 5+ mm maximum travel and progressive springs.

[hoggy]

Dip switches large enough to see without squinting and don't need a sharp object to flip. 

[jacobolus]

Oh, and one more thing. Switches with 5+ mm maximum travel and progressive springs.

This might be nice, but I think 4mm travel is also okay; I personally want actuation at about 1mm into the stroke, followed by a very steep drop in force, and then gradual increase further on... I think 3mm of post-actuation travel is enough with the right force curve; even 2mm might be enough. Ideally, the return stroke should bounce the finger back up, as soon as release is desired... that is, it should be easy to hold a switch down, but as soon as the switch is obviously on its way back up the switch should with higher force spring the finger back above the actuation point, so that it’s maximally fast and easy to do fast multiple presses. This is non-trivial to get right, and a bit hard to do with a purely mechanical design, but I can always dream. :-)

In practice, Alps plate spring switches are quite nice IMO, though they actuate a bit further into the stroke than my preference, and they’re not as loud as I’d like. But an Alps plate spring keyboard with a solenoid would be pretty good. Marquardt butterfly switches are a somewhat similar design but even better. But they’re very rare, and non-trivial to build into a custom-shaped keyboard. I’ve heard HaaTa talk about a desire to resurrect the Marquardt butterfly switch and fabricate new versions of it.. that would be really fantastic I think, but I’m not sure how likely it is to happen, or how long it would take.

[hoggy]

Wordprocessors such as word could offer auto completion based on your previous typing.

Ergonomics like that could be built into desktop operating systems. Macros and the like.

[jacobolus]

Wordprocessors such as word could offer auto completion based on your previous typing.

Ergonomics like that could be built into desktop operating systems. Macros and the like.

As long as the autocomplete takes a keystroke to invoke, that would be fine. Anything that happens “automatically”, which is to say, without my explicit invocation, I find to be a tremendous pain in the ass.

[hoggy]

How about, instead of pressing shift and a key, I just hold down the key a little longer.  Hold the key a bit longer than that to repeat the key.

[davkol]

How about, instead of pressing shift and a key, I just hold down the key a little longer.  Hold the key a bit longer than that to repeat the key.

Meh. Sticky keys FTW.

[Findecanor]

How about smaller keys for the pinky columns, because it can't reach that far without moving the hand.

I have been thinking of instead of having a Return key to the right of the pinky keys, have a lever that is activated by moving the hand to the right.
The same type of lever can be to the left side of the right index finger columns and also for the left hand. It could be used for tab, esc, etc. not modifiers.

Wordprocessors such as word could offer auto completion based on your previous typing.

I hate it when I edit inside a paragraph in OpenOffice/Libreoffice and it auto-completes to a long word that changes the layout of the rest of the paragraph, and sometimes the rest of the page pushing the next paragraph or box to the next page.

[jacobolus]

How about, instead of pressing shift and a key, I just hold down the key a little longer.  Hold the key a bit longer than that to repeat the key.

This sounds really annoying; it’s a feature that imposes a built-in speed limit on your typing.

Much better is to either have a key that you can type to capitalize the previous letter, or a key that you can press to capitalize the following letter. (Assuming you’re not willing to hold down shift)

For key repeat, it’s better to have an analog input (trackpoint/scrollwheel/touchpad/trackball) that you can spin to repeat the previously typed letter when you spin it one way, or undo/backspace when you spin it the other way.

[jacobolus]

How about smaller keys for the pinky columns, because it can't reach that far without moving the hand.

Absolutely. Having slightly smaller switches and smaller keycaps for all the keys lets you position the keys slightly closer together on most fingers, and substantially closer together on the pinky.

I have been thinking of instead of having a Return key to the right of the pinky keys, have a lever that is activated by moving the hand to the right. The same type of lever can be to the left side of the right index finger columns and also for the left hand. It could be used for tab, esc, etc. not modifiers.

I definitely don’t want this, but try it out!

[islisis]

i really like jacobolus's ideas. like i wrote in the kinesis advantage idea thread, i would love a trackpoint and mousewheel+buttons for the left hand. also, if it were possible to source lower-force switches than cherry browns this would be ideal.

for sculpted boards, how about thumb keys which are aligned with 'vertical' movements (radial) rather than 'lateral' (palmar)? my left thumb tendons have taken over a year to recover from extended mod key holds on the kinesis, due to lateral overstretching. i would like to see more trials of alternative orientation in real keyboards.

[jacobolus]

for sculpted boards, how about thumb keys which are aligned with 'vertical' movements (radial) rather than 'lateral' (palmar)? my left thumb tendons have taken over a year to recover from extended mod key holds on the kinesis, due to lateral overstretching. i would like to see more trials of alternative orientation in real keyboards.

Most unambiguous way of describing these motions is:

Pressing down with the thumb on a standard spacebar / in the direction of the table is abduction of the thumb’s carpometacarpal (CMC) joint. Lifting the thumb in the opposite direction is adduction of that joint.

Squeezing the thumb inward toward the fingers is flexion of the metacarpophalangeal (MP) joint, with some slight flexion also of the CMC joint. The opposite outward motion is extension of these two joints.

The CMC joint is the joint down at the base of the thumb near the wrist, and it can move along two separate axes. The MP joint is the joint near where the skin of the thumb attaches to the palm, and it only moves in one axis.

Personally I want to try to build a keyboard where modifier keys on the thumb are roughly vertically oriented and operate through flexing the MP joint, but press-and-release keys (spacebar, backspace, etc.) work through abduction of the CMC joint. Because the MP joint is smaller and weaker than the CMC joint, I suspect that for a key like the spacebar it could get quite tiring to use MP/CMC flexion for it, but when holding a key down, this is not as much an issue, and additionally I think the thumb can get some assist from movement of the whole hand (arm muscles) for holding down a modifier key.

Have you ever tried a Maltron? I think the Maltron gets the positioning and orientation of the thumb keys slightly better than the Kinesis, though I’m mainly thinking about the primary keys (spacebar etc.) not the smaller other thumb keys; I haven’t tried either keyboard for a long enough period (longer than a day) to weigh in on how tiring the modifiers are over an extended period.

[islisis]

thanks, i haven't done much research into finger orientation so i was hoping those terms would be easy enough >_<

in my opinion the thumb switch orientation of the kinesis and probably the maltron (which i haven't tried) is not significantly different from any other flat keyboard. if you are going sculpted, i would have thought it'd be an opportunity to implement thumb activations through the MP joint. currently, from my experience and reports on the ergodox design i do think CMC joint poses a hazard for long modifier presses, especially at extended positions where support from muscles is weakest.

despite the relative difference in strength between MP and CMC joint, i would still like to see how they compare on a real keyboard, since the layout, usage pattern, motor control (not bottoming out) should affect the resultant strain greatly, and as you mention hand position, too.

it's true also that the weight of the hand can relieve some of the activation strain for either joint, but the problem for key holds is that the return force of most switches is high enough to induce thumb stress once the hand position moves to reach for finger keys. in a sense simply reducing the switch force would be effective for eliminating thumb strain.

horizontal orientation has its advantages - i actually use the kinesis thumbwell for dual-role mousekeys and window-tabbing with the fingers, while resting the (left, non-mousing) hand below the keyboard. flat is more convenient for intermittent reaches to the keyboard for single presses. but i would rather have independent keys for this and a true ergonomic layout for home-position typing

[jacobolus]

it's true also that the weight of the hand can relieve some of the activation strain for either joint, but the problem for key holds is that the return force of most switches is high enough to induce thumb stress once the hand position moves to reach for finger keys.

One solution: get rid of any keys you have to reach for.

[vivalarevolución]

for sculpted boards, how about thumb keys which are aligned with 'vertical' movements (radial) rather than 'lateral' (palmar)? my left thumb tendons have taken over a year to recover from extended mod key holds on the kinesis, due to lateral overstretching. i would like to see more trials of alternative orientation in real keyboards.

Most unambiguous way of describing these motions is:

Pressing down with the thumb on a standard spacebar / in the direction of the table is abduction of the thumb’s carpometacarpal (CMC) joint. Lifting the thumb in the opposite direction is adduction of that joint.

Squeezing the thumb inward toward the fingers is flexion of the metacarpophalangeal (MP) joint, with some slight flexion also of the CMC joint. The opposite outward motion is extension of these two joints.

The CMC joint is the joint down at the base of the thumb near the wrist, and it can move along two separate axes. The MP joint is the joint near where the skin of the thumb attaches to the palm, and it only moves in one axis.

Personally I want to try to build a keyboard where modifier keys on the thumb are roughly vertically oriented and operate through flexing the MP joint, but press-and-release keys (spacebar, backspace, etc.) work through abduction of the CMC joint. Because the MP joint is smaller and weaker than the CMC joint, I suspect that for a key like the spacebar it could get quite tiring to use MP/CMC flexion for it, but when holding a key down, this is not as much an issue, and additionally I think the thumb can get some assist from movement of the whole hand (arm muscles) for holding down a modifier key.

Have you ever tried a Maltron? I think the Maltron gets the positioning and orientation of the thumb keys slightly better than the Kinesis, though I’m mainly thinking about the primary keys (spacebar etc.) not the smaller other thumb keys; I haven’t tried either keyboard for a long enough period (longer than a day) to weigh in on how tiring the modifiers are over an extended period.

The modifiers on a Maltron are not that tiring over extended periods of time.  On my Maltron, the Ctrl and Alt are in the upper far cluster, and those keys are the farthest reach for my thumbs.  I imagine if I used those keys more often, it would be a more noticeable issue.  The thumb keys I use more often--space, E (on Maltron layout), tab, enter, the arrow keys, backspace, delete--I find them easy to use and not too fatiguing.

Doesn't the Datahand somewhat accomplish the goal of utilizing the flexion/squeezing inward with a couple of those thumb keys?  According to the legends, it seems to use the inward motion for Return and Space.  I wonder if a Datahand user could comment on the fatigue factor of that thumb motion for such commonly used keys.  Datahand adherents tend to be more devoted to their product than almost any other keyboard fandom.

[Oobly]

Maltron thumb keys are better than Kinesis to use, but I still prefer to use flexion to press the thumb keys. It's the motion used when gripping items and IMHO is the strongest and can handle the longest and most presses with least fatigue, but that's just based on my own personal testing and experiences. I believe abduction and adduction to be good for positioning, but not as good for presses requiring strength or long term pressure.

It could just be personal, as I have said, maybe my guitar playing background has had an effect on the relative strengths of the different thumb movements for me, but it still seems to make more sense to me to use flexion for pressing and I have yet to experience thumb fatigue when using my ergo board (with space, shift, enter, backspace, ctrl, alt, tab and Fn layer on thumb keys).

I like the idea of smaller keys for all fingers, but especially pinkies.

I also like the idea of using pressure sensors (simple resistive strain gauges on a soft rubber layer may suffice) and small solenoids with relatively strong switch springs to achieve Jacobolus' goal of "springing the finger back". Once the pressure on the cap is enough the solenoid actuates to help pull the key down (like an active tactile point). When you release enough pressure, the solenoid deactivates. The pressure sensor will need to have "dead" time immediately after actuating or deactuating the solenoid when it doesn't try to change the state of the switch, but I think it's fairly easy to achieve with a bit of microprocessor coding. Since the pressure sensor controls the switch state there is no need for switch contacts. The switches could be calibrated for light or heavy pressure so you can have different settings on the same board ranging from superlight to extra heavy. You could even assign different weights to different keys with different functions, such as modifiers vs alphas vs space, etc. Voila, keyboard with customisable individual key weighting! Perhaps even switchable profiles for different tasks / people. That would be a truly "Mechanical" keyboard.

Instead of solenoids it could use pneumatic or hydraulic pressure, too. Or steam....? True steampunk keyboard anyone? Maybe that's taking it a step too far, though.

[JackMills]

Wow, all such well thought answers with interesting ideas (the lighter switches are making me considering MX Browns on my next purchase).
I was thinking about features that would improve standard keyboards, without becoming really ergonomic boards. So keep in mind that I thinking from a standard keyboard (non-split, non whatsoever) in order to get something which can be achieved by any keyboard maker.
What I was thinking about was negative tilting, which can be easily implemented. I don't understand why I get the ability to tilt but not to negative tilt.
I would also like a flat keyboard with keys contoured to form a curve over the different rows. Flat to keep the height of the keyboard as low as possible. I don't see the need for contoured keys on a staircase case as you can find now and curved plates only make production harder.
Symmetrical staggering could be implemented without much effort and could be coupled to more thumbkeys (like a microtron but without being split).
I am also in favor of a trackball, personally I would like to see a trackball somewhere near to the spacebar to opperate it with my thumb(s).

[jacobolus]

I was thinking about features that would improve standard keyboards, without becoming really ergonomic boards.

It’s somewhat limited; the standard layout is quite bad.

What I was thinking about was negative tilting, which can be easily implemented. I don't understand why I get the ability to tilt but not to negative tilt.

Adjusting the overall position and orientation of the keyboard is pretty easy with any keyboard: get a height-adjustable desk and chair, and stack stuff under the front or back edge of the keyboard until the angle is right.

I would also like a flat keyboard with keys contoured to form a curve over the different rows. Flat to keep the height of the keyboard as low as possible. I don't see the need for contoured keys on a staircase case as you can find now and curved plates only make production harder.

I don’t understand what this means. Could you draw a picture or something?

Symmetrical staggering could be implemented without much effort and could be coupled to more thumbkeys (like a microtron but without being split).

I take it you think keeping the keyboard in a rectangular shape with all the keys angled the same direction is an important feature?

Here are some ideas:
http://geekhack.org/index.php?topic=59396
http://geekhack.org/index.php?topic=56095

[vvp]

I also like the idea of using pressure sensors (simple resistive strain gauges on a soft rubber layer may suffice) and small solenoids with relatively strong switch springs to achieve Jacobolus' goal of "springing the finger back". Once the pressure on the cap is enough the solenoid actuates to help pull the key down (like an active tactile point).

If you are putting a solenoid there then you do not need a pressure sensor. The solenoid can serve as an analog sensor for the actuation depth too. Spring, ferrite stem and a solenoid will do.

[JackMills]

I was thinking about features that would improve standard keyboards, without becoming really ergonomic boards.

It’s somewhat limited; the standard layout is quite bad.

What I was thinking about was negative tilting, which can be easily implemented. I don't understand why I get the ability to tilt but not to negative tilt.

Adjusting the overall position and orientation of the keyboard is pretty easy with any keyboard: get a height-adjustable desk and chair, and stack stuff under the front or back edge of the keyboard until the angle is right.

I would also like a flat keyboard with keys contoured to form a curve over the different rows. Flat to keep the height of the keyboard as low as possible. I don't see the need for contoured keys on a staircase case as you can find now and curved plates only make production harder.

I don’t understand what this means. Could you draw a picture or something?

Symmetrical staggering could be implemented without much effort and could be coupled to more thumbkeys (like a microtron but without being split).

I take it you think keeping the keyboard in a rectangular shape with all the keys angled the same direction is an important feature?

Here are some ideas:
http://geekhack.org/index.php?topic=59396
http://geekhack.org/index.php?topic=56095

I was trying to handle your remarks one-by-one but kept screwing up the layout, so this will be just one long response.

My point of view on the entire ergonomics brainstorm was about what needs to be changed so that a standard keyboard can become better, without scaring people away. I didn't want it to be about drastic ideas.
My experience with ergonomics (automotive) is that individualization is the ultimate goal, but it is only attainable for a few. The next goal would be to have your design be as adjustable as possible, but the problem here is that nobody is the same size, so ranges can become large, which can have a huge impact on your design. So my take was, what are minimal adjustments that can be beneficial to a lot of users.
Key here are minimal adjustments, to the keyboard and to the user, so starting from a rectangle keyboard with a standard layout and a user that is not going to look for solutions if they are not build-in features.
Most people in my office use tilted keyboards, if you explain them that they should try it flat, they try it. When you explain negative tilt, then they say that it cannot be tested because there are no legs to do so, end of discussion. So I suggest putting some legs there to make it possible. if possible legs like those under refrigerators to level them, they would provide better steps. You could do this by yourself, as I do with a piece of wood, but that is not what most people want to do.
I think that the microsoft Natural Ergonomic Keyboard could be a good starting point. It keeps it familiar and accessible/recognizable for the layman. But it would be better with symmetrical staggering and a split spacebar giving space to implement a thumb driven trackball.

As for the threads that you linked, essentially you have drawn out how manufacturers should iterate a standard keyboard so the concept of ergonomics gets more accepted by the masses.

As for the keycaps, this is what I tried to explain:



After seeing the drawing it looks more like DCS or so, but it seemed better in my head

[Oobly]

I also like the idea of using pressure sensors (simple resistive strain gauges on a soft rubber layer may suffice) and small solenoids with relatively strong switch springs to achieve Jacobolus' goal of "springing the finger back". Once the pressure on the cap is enough the solenoid actuates to help pull the key down (like an active tactile point).

If you are putting a solenoid there then you do not need a pressure sensor. The solenoid can serve as an analog sensor for the actuation depth too. Spring, ferrite stem and a solenoid will do.

The solenoid coil cannot sense the position of the rod using simple means. It could sense the position of the rod if you have two coils, one with AC current applied and one for sensing eddy currents, though. But how do you know when to release the solenoid? Pressure sensors are simpler to implement I think.

A truly ergonomic keyboard should not have more than three rows of keys, so the keycap profile and stepping becomes fairly unimportant, IMHO. Any more than three and you have to start moving the hand up or down. Extension to one row above and below home row is not a big issue, but contoured and stepped caps would help.

[JackMills]

A truly ergonomic keyboard should not have more than three rows of keys, so the keycap profile and stepping becomes fairly unimportant, IMHO. Any more than three and you have to start moving the hand up or down. Extension to one row above and below home row is not a big issue, but contoured and stepped caps would help.

This is something I agree with, keeping the movement as minimal as possible. Personally I am not a fan of full keyboard layout because most key are not accessible without moving my hand away from the home row. I also don't like that I have to move my right pink much to reach 'enter' for example. For me, a Nostromo or other gaming pads (Saitek, razer) look like a good base for an ergonomic keyboard.

Edit: just saw your avatar, looks great, that's something I would like to create eventually

[vvp]

The solenoid coil cannot sense the position of the rod using simple means.

Is this that complicated?
Since this is supposed to be a brainstorming:
We will push some current to the coil, then disconnect the voltage and measure how quickly the current drops through a ballast resistor.
The resonant frequency of the spring/ferrite/stem/keycap assembly will be somewhere around 250 Hz.
So if we can do the sensing in the MHz (or higher) range then it will not have a significant impact on the stem position.
That means we could time multiplex solenoid driving current with sensing the ferrite position. The sensing duty cycle should be somewhere in the 1e-3 range.
The solenoid inductance will be probably in the range of 10 μH to 20 mH depending on the ferrite position. Here I can be off quite a lot but we can compensate with the size of the ballast resistor (edit: well not much, the voltage would be too high, a better idea may be to increase sensing duty cycle to 1%).
If the inductance estimate is correct then we need only about 20kΩ ballast resistor to get to the MHz range (time constant τ = 20e-3/20e3 = 1e-6 s).
Looks like doable. I would definitely investigate this more before adding one more sensor (the pressure sensor).

Edit: If it would not pan out well then the sensing coil needs to be separated from the driving one. But when we are already winding driving coil it looks better to me to split its lowest layer and make sensing coil from it (compared to adding a separate pressure sensor).

[dante]

I think people are making it more complex than it needs to be.

IMHO I'd like to see something like this:

Take a your standard staggered tenkeyless keyboard - and break it into two half keyboards like the Ergo Dox.

THATS IT!!! DONE!!! FINITO!!!

If I had to make it more complex I'd add a vertical Enter key right next to the arrow keys - it's something I miss when the numberpad goes away.

[hoggy]

I'd like a split keyboard with interchangeable halves. 

Left could be normal stagger, symmetrical stagger, or matrix. Going further, it could have function keys on the left or even have the cursor and navigation cluster (as in in left handed tkl)

Right could be normal stagger or matrix.  Going further, right could be tkl, 60% or full.

[jacobolus]

I'd like a split keyboard with interchangeable halves. 

Left could be normal stagger, symmetrical stagger, or matrix. Going further, it could have function keys on the left or even have the cursor and navigation cluster (as in in left handed tkl)

Right could be normal stagger or matrix.  Going further, right could be tkl, 60% or full.

Can you draw a picture?

[jacobolus]

My point of view on the entire ergonomics brainstorm was about what needs to be changed so that a standard keyboard can become better, without scaring people away. I didn't want it to be about drastic ideas.

The most minimal very positive adjustment you can make is splitting the spacebar into two pieces and turning one of them into a delete (“backspace”) key.

The keyboard with the least possible change to an available shape that still offers great improvement is the Cherry G80-5000:


The Model M-15 is also pretty good, though its little ball and socket joint is very fragile:


The largest ergonomic change you can make without fundamentally requiring new muscle memory is something like the Matias ErgoPro:


There are reasons to prefer a non-split to a split keyboard (portability, lap use, ...) but the split is otherwise overwhelming improvement. You can get an okay result with something with halves that rotate outward, but the full split is substantially more flexible.

I think that the microsoft Natural Ergonomic Keyboard could be a good starting point. It keeps it familiar and accessible/recognizable for the layman. But it would be better with symmetrical staggering and a split spacebar giving space to implement a thumb driven trackball.

Symmetrical staggering would defeat a lot of the purpose: it requires weeks of catch-up time to get back to former speed when you start mucking with the stagger; the keyboard would be a lot harder to sell people on.

I agree on the split spacebar; as I said above, I think this is a radical improvement that is very easy to achieve, assuming you put some other useful function (e.g. delete (“backspace”), which is a big reach on a standard keyboard).

Whether the thumb trackball would work (with a modified Microsoft ergo board) depends a lot on its position and the implementation.

As for the keycaps, this is what I tried to explain:

Show Image

After seeing the drawing it looks more like DCS or so, but it seemed better in my head

You’ve got the right general idea, but the closer-than-homerow row (on QWERTY the “ZXCV” row) should have keys of about the same height as the home row. I agree that a steep top angle for this row is helpful for grabbing the fingertips when the fingers flex inward. The top angle of DCS on this row is pretty good; OEM profile isn’t as good IMO. It might be possible to get even more aggressive than DCS for a column-layout board.

On the further-than-homerow rows (“QWER” and “1234” rows) the ideal height step and angle depends quite a bit on whether you’re using a column-based stagger or a standard layout. On a standard layout, if you get too aggressive with height step, it starts causing problems because different fingers have a different positional relationship to the standard keyboard rows (because hands are not shaped like a standard keyboard). I think the sculpted top shape of IBM beam spring boards or old Honeywell boards is a reasonable compromise. Note that SA (assuming angled keyswitch stems; I think SA must stand for “spherical angled”), SS, DSS, DCS are all based on this shape.

Personally I think that it’s possible to get a bit more aggressive than this on a standard layout keyboard. But on a column-layout board, it’s possible to get much more aggressive with the height step. (I’m not sure that top angle of the key for further away keys makes quite so much difference.)

If I could get a column-stagger flat keyboard with one kink, I’d go for something like:


(Or maybe even more aggressive still with the height steps, if I could design the keycaps.)

[qihqi]

I could like a matrix Poker II.

[hoggy]

Qihqi, have you seen the access akc090?

[Oobly]

The solenoid coil cannot sense the position of the rod using simple means.

Is this that complicated?
...

Yes, I think your post shows how complicated it is. It's not a simple matter of sensing, you need to add some driving AND sensing circuitry and should probably use a separate coil. And you still have no way of sensing when the user releases pressure on the switch, so the key will remain down. In which case, why not use a simple resistive strain gauge instead? It will probably give a more consistent response to actual pressure than only sensing the position (you may have small inconsistencies between springs), too.

I agree with Jacobolus, step one is splitting the board. It provides the largest ergonomic benefits with the smallest change in muscle memory. I think mapping the least used half of the spacebar to Shift also makes sense, since it's easier to hold it down with your thumb than with a pinkie and won't take much to get used to. IMHO, step two should be a large one, from horizontal stagger to vertical stagger. It feels natural quickly and is another big ergonomic improvement. Step three is thumb clusters (with a maximum of four per thumb), trimming off excessive keys and using layers. The positioning and angle of the thumb clusters could be discussed further, but I believe the existence of one is major benefit. At least these are my thoughts, and they're echoed in my DIY board design.

Jacobolus, I really like your angled bottom row concept! I may try something like this for the arrow and edit clusters of my next prototype at a less extreme angle if you don't mind me using your idea.

Hoggy, I think I get your concept (sort of a modular design, but just the connector and signaling protocol needs to be the same), where you can interchange a few different options for either half. So you can use a normal layout right half with a matrix layout left half for instance. Personally, I wouldn't use it like that. I'd choose a layout that works best and stick to it, don't want to learn different  muscle memory for each type of half, but it's an interesting concept.

I'd like to try an idea I posited in my DIY thread, putting a controller in both halves, so you can use either one as a standalone gamepad or hook them up with either one connected to the PC, the other will go into "slave" mode automatically. Also, with programmability, either half could act as a one-handed keyboard for those with disabilities.

[yasuo]

I'd like a split keyboard with interchangeable halves. 

Left could be normal stagger, symmetrical stagger, or matrix. Going further, it could have function keys on the left or even have the cursor and navigation cluster (as in in left handed tkl)

Right could be normal stagger or matrix.  Going further, right could be tkl, 60% or full.

Can you draw a picture?

like ergo driver

[vvp]

Yes, I think your post shows how complicated it is. It's not a simple matter of sensing, you need to add some driving AND sensing circuitry and should probably use a separate coil. And you still have no way of sensing when the user releases pressure on the switch, so the key will remain down. In which case, why not use a simple resistive strain gauge instead? It will probably give a more consistent response to actual pressure than only sensing the position (you may have small inconsistencies between springs), too.

Detecting the force with which the user pushes the key is the same problem for both inductive sensing and resistive sensor.
In both cases: F_user + F_drivingCoil = K*X + F_{positionSensingElement}
X - switch stem position (how much it is pressed)
K - spring force constant
In both cases you need to estimate F_drivingCoil(*) based on the current you push through it. All the forces F_? will also depend on the switch stem position X.

(*) and also F_{positionSensingElement} but that should be small (possibly can be ignored)

Or did you mean that the force sensor will be between the stem and the keycap? Which would mean that the force sensor will be moving and that means hoping the connection to PCB will last long enough even when the connection wires will be bending all the time (or sliding contacts will be moving all the time).

As far as I know, the prices for force sensors are in the rage of $10 and higher. Prices for small coils are in the range of $2. If it is possible to use an inductive sensor (i.e. a sensing coil) then it should be done. But I agree it is a good idea to separate the driving and sensing coil. The solenoid coil needs to be wound anyway so separating e.g. its bottom layer for sensing should not add much to the price.

This may even fit 2.5W maximum power of USB 2.0.
User maximum typing speed is about 200 WPM so the maximum time for the ferrite core press by the driving coil is  1 / (200 * 5 / 60) = 0.06 s (assuming there are 5 characters in a word by average).
Assuming 100g springs and 5 mm switch travel, we get: 1 N * 0.005 m / 0.06 s = 0.083 W
Since it is a spring and does not start at 1N but at 0N, then we actually have  0.042 W per switch.
That means definitely not more than 60 simultaneous assisted key presses at once since 2.5 W / 0.042 W ≅ 60.

Looks like 6KRO is possible. Barely may be enough for layering on small keyboards some people prefer. I may try to actually build this after I'm done with my Katy keyboard. Well I'll probably need an SLS printer first

[Oobly]

Yes, I think your post shows how complicated it is. It's not a simple matter of sensing, you need to add some driving AND sensing circuitry and should probably use a separate coil. And you still have no way of sensing when the user releases pressure on the switch, so the key will remain down. In which case, why not use a simple resistive strain gauge instead? It will probably give a more consistent response to actual pressure than only sensing the position (you may have small inconsistencies between springs), too.

...
In both cases: F_user + F_drivingCoil = K*X + F_{positionSensingElement}
X - switch stem position (how much it is pressed)
K - spring force constant
In both cases you need to estimate F_drivingCoil(*) based on the current you push through it. All the forces F_? will also depend on the switch stem position X.

...

Or did you mean that the force sensor will be between the stem and the keycap? Which would mean that the force sensor will be moving and that means hoping the connection to PCB will last long enough even when the connection wires will be bending all the time (or sliding contacts will be moving all the time).

...
This may even fit 2.5W maximum power of USB 2.0.
User maximum typing speed is about 200 WPM so the maximum time for the ferrite core press by the driving coil is  1 / (200 * 5 / 60) = 0.06 s (assuming there are 5 characters in a word by average).
Assuming 100g springs and 5 mm switch travel, we get: 1 N * 0.005 m / 0.06 s = 0.083 W
Since it is a spring and does not start at 1N but at 0N, then we actually have  0.042 W per switch.
That means definitely not more than 60 simultaneous assisted key presses at once since 2.5 W / 0.042 W ≅ 60.

Looks like 6KRO is possible. Barely may be enough for layering on small keyboards some people prefer. I may try to actually build this after I'm done with my Katy keyboard. Well I'll probably need an SLS printer first

First of all, how do you detect the finger pressure if the switch is bottomed out by the solenoid? If you solve that one, then I think position sensing with coils could work and would be easier from a construction perspective than pressure sensors. Maybe a 2 stage spring so it doesn't bottom out with just solenoid power, so finger pressure still adds a tiny measurable distance to the movement? I think this would be an issue unless the springs are VERY precisely made and don't get weaker with use. I think some other solution is needed.

<EDIT> If we use 100cN springs and say 60cN solenoid, we could still use position sensing to detect when to release the solenoid (actuate at any chosen position, release when the position is less than it would be for the combined solenoid force + say 20cN?), but the "tactility" will be less than if we use a stronger solenoid and bottom out the switch with it. </EDIT>

The forces will depend on the switch stem position AND the spring constant. Inconsistent springs = different pressure at a given position (position sensing) OR different position for a given pressure (pressure sensing). Position sensing will be like normal switches in terms of actuating at a certain position, pressure sensing would of course be based on pressure instead, so the switches could actuate in different positions based on the spring force.

Pressure sensor on the stem with magnet wire through the centre is what I was thinking. Minimises bending of the wire. Can be a small resistive strain gauge, I found some 5.1mm x 4.2mm 350 ohm gauges for about 50 cents each. Haven't figured out the exact mounting method yet, but it may be hard to make the assembly robust enough for swapping keycaps.

<EDIT> Another way to do it is to mount the pressure sensor between the solenoid and keyboard case. That way all pressure measured will be due to the weight of the solenoid / keycap and finger pressure. Don't have to worry about contacts going to moving parts. </EDIT>

At the moment it's just throwing ideas out there, actual prototype devices may or may not be practical. 

Good job on the power calculations, looks like it could be feasible from that angle

<EDIT> Lots of editing, sorry... Looks like you're calculating the power based on 0.06s pulse per press... What if you hold the key down, like when playing a game? I'd assume the solenoid needs to run continuously in that case, so they may need an external supply and possibly even heat dissipation of some sort. </EDIT>

[hoggy]

I'd like a split keyboard with interchangeable halves. 

Left could be normal stagger, symmetrical stagger, or matrix. Going further, it could have function keys on the left or even have the cursor and navigation cluster (as in in left handed tkl)

Right could be normal stagger or matrix.  Going further, right could be tkl, 60% or full.

Can you draw a picture?

like ergo driver

Ergo diver is an excellent example - a combination of stagger and matrix.

Something like this -

Pick one from the left, and one from the right.

Of course, it would only work if made by one manufacturer, or if there was a standard...

[vvp]

First of all, how do you detect the finger pressure if the switch is bottomed out by the solenoid? If you solve that one, then I think position sensing with coils could work and would be easier from a construction perspective than pressure sensors. Maybe a 2 stage spring so it doesn't bottom out with just solenoid power, so finger pressure still adds a tiny measurable distance to the movement? I think this would be an issue unless the springs are VERY precisely made and don't get weaker with use. I think some other solution is needed.

I do not think that springs need to be precise. Moreover, we can calibrate the driving current of solenoid if changes in spring constant would be a problem. Maybe I should have written it in more detail. Notice that:
F_user(x) + F_drivingCoil(x,i_driving) = k*x + F_{positionSensingElement}(x,i_sensing)

Functions use capiltal letter. Variables/constants use small letter.
k - spring force constant
x - how much the switch stem is pressed (length)

F_user(x) is a function defining force the switch is going to exert on user finger when the switch is pressed x mm down. This is the force/travel diagram of the switch. The function returns different values when stem is going down and different when it is going up. This force travel diagram will be defined in firmware. This is what we want to change and experiment with.

F_drivingCoil(x,i_driving) is a function which defines the force solenoid is exerting on the ferrite core when the core is at position x and the driving coil current is i_driving. This is a proper function. It has a partial inverse function I_driving(x,F_drivingCoil) which tells us how big driving current we must feed to the driving coil to get given force on the switch stem (which is at position x). Our firmware needs to control one variable current source for as many switches as we need to drive at once. (E.g. in case of 6KRO we need 6 variable current sources and a demultiplexer to feed them to the selected switches.)

F_{positionSensingElement}(x,i_sensing) is the function defining what force our sensing element will exert on the switch stem at position x. i_sensing is average sensing current. We can consider only average current here since we are going to sense in the range of MHz, while the stem resonant frequency is somewhere in 200Hz range. This is well separated. Anyway this can be probably designed so that it is negligible. So lets assume F_{positionSensingElement}(x,i_sensing) = 0 for all x and the applicable i_sensing. But even if we could not assume this is 0, it does not change the rest fundamentally (it is not a show stopper).

Ok, so the simplified equation:
F_user(x) + F_drivingCoil(x,i_driving) = k*x

From this: F_drivingCoil(x,i_driving)  = k * x - F_user(x)
Or more simpler: F_drivingCoil = k * x - F_user(x)
x is what we will sense using our sense coil
k is a constant
F_user(x) is what we read from our force/travel diagram in firmware - so is is known number for each applicable x
So we can compute required driving coil force (F_drivingCoil) for any given position x!
Now from the function I_driving(x,F_drivingCoil) we can compute the required driving current and control the current source to apply it to driving solenoid.
In other words we use I_driving(x, k * x - F_user(x))
Notice that is only a function of x which we can get from the sensing coil.

Definition of the function I_driving(x,F_drivingCoil) is defined in firmware. It can be derived analytically but it is probably just easier to define it as a table in firmware and interpolate.

So I do not see any problem with measuring user force, since we actually do not need to measure it. It is enough to measure how much the switch is pressed. Based on that we will provide the right counter force (using spring and driving coil) as required from whatever force/travel diagram user likes most.

<EDIT> If we use 100cN springs and say 60cN solenoid, we could still use position sensing to detect when to release the solenoid (actuate at any chosen position, release when the position is less than it would be for the combined solenoid force + say 20cN?), but the "tactility" will be less than if we use a stronger solenoid and bottom out the switch with it. </EDIT>

This looks like you want to drive the solenoid with either full current or nothing. I assume a variable current source. Now, micro-controller typically do not have it. But it not a big deal we probaly can simulate it with DAC & ADC (and maybe also amplifier) combo.

The forces will depend on the switch stem position AND the spring constant. Inconsistent springs = different pressure at a given position (position sensing) OR different position for a given pressure (pressure sensing). Position sensing will be like normal switches in terms of actuating at a certain position, pressure sensing would of course be based on pressure instead, so the switches could actuate in different positions based on the spring force.

Ok, it really looks like you assume only digital driving for the driving coil.

Can be a small resistive strain gauge, I found some 5.1mm x 4.2mm 350 ohm gauges for about 50 cents each.

Can you post link to the part specification?

<EDIT> Another way to do it is to mount the pressure sensor between the solenoid and keyboard case. That way all pressure measured will be due to the weight of the solenoid / keycap and finger pressure. Don't have to worry about contacts going to moving parts. </EDIT>

OK, but that means that you need to compute the pressure user exerts at the switch the same way I indicated above because solenoid force is added to the user press force. So you probably already found the answer to your first question.

<EDIT> Lots of editing, sorry... Looks like you're calculating the power based on 0.06s pulse per press... What if you hold the key down, like when playing a game? I'd assume the solenoid needs to run continuously in that case, so they may need an external supply and possibly even heat dissipation of some sort. </EDIT>

That is the reason I mentioned 6KRO only. If user presses more than 6 keys at once then any additional keys will not get the solenoid assist and user defined force/travel diagram. They will be only dump linear switches. 6KRO looks like possible almost for sure. 60KRO is not possible from USB power only.
Additional power source would be a show stopper for me. I already have enough cables around here

[hoggy]

I seem to use the punctuation on the number row more than I use the numbers, it would be handy to have the numrow permanently shifted, so pressing 2 would give me " and I suppose I'll need the odd number now and again, so shift and 2 would give me 2.

[Oobly]

@vvp, your calculations are great, nothing wrong there, but I assumed the user will be bottoming out the switch and that the solenoid will be doing most of the work, which means you cannot sense the finger pressure from the position since just the force from the solenoid is enough to bottom out the switch. This is in order to provide very strong tactility and get that "pushing the finger back" on the upstroke that the original goal was. I think that's where we've diverged in our thinking on this concept.

If you "feather" the solenoid with PWM or current-based solution to adjust the duty cycle you need to leave some work to the finger (minimum finger force before release + max solenoid force < spring force needed to bottom out) in order to sense when the user is releasing the key by detecting the position moving away from bottom out.

My original idea was more of a brute force thing (solenoid on/off corresponding to key on/off to provide a strong tactile feedback at the point of actuation and release). Simple to implement in firmware and no particularly special controller electronics needed. Your solution is more "elegant", but requires a lot more work on the firmware and controller electronics side. I think this kind of keyboard would be fine to use an external supply for, so you can still add LED's etc to run from USB power if desired.

I have to say, thank you for explaining your version of the concept, I see more and more the benefits to your version.

I believe your solution will be easier to implement from a hardware perspective and therefore more amenable to commercial production. Another interesting "feature" of this kind of keyboard is that it could provide some very interesting and accurate "force feedback" response. For instance, in a driving game (or more appropriately, in a game like Battlefield), the "forward" key could provide different return pressure depending on the suspension compression of the car, so you can feel the bumps. This could also be used as a prime marketing feature for the keyboard Also the fact that you can set the force profile to be linear or tactile so you can have practically any switch "type" emulated.

Which gives me an idea for mouse force feedback for FPS games... you know that there are lots of shooting games and that a gun provides recoil when fired? Perhaps a heavy linear solenoid mounted front to back in the mouse could give varying amounts of "recoil" for shooting games. Probably wouldn't be popular with competetive players, but may be nice for the casual player to add another layer of realism to the game.

[vvp]

If you "feather" the solenoid with PWM or current-based solution to adjust the duty cycle you need to leave some work to the finger (minimum finger force before release + max solenoid force < spring force needed to bottom out) in order to sense when the user is releasing the key by detecting the position moving away from bottom out.

Correct that inequality must be obeyed in average. We can disobey it for a predefined (short) time and predefined x travel. Not sure how useful effects that can provide. But we must obey it in general so that a key does not get struck at some x position.

Interesting idea about providing SW interface of force/travel diagram to applications and marketing this as a "force feedback" keyboard.

Which gives me an idea for mouse force feedback for FPS games... you know that there are lots of shooting games and that a gun provides recoil when fired? Perhaps a heavy linear solenoid mounted front to back in the mouse could give varying amounts of "recoil" for shooting games.

Or require electrically conductive mouse pad and put a set of coils in the mouse. Make the mouse a linear motor. Imagine driving mouse in a funny patterns over the pad even when user does not touch it 

[Oobly]

...

Which gives me an idea for mouse force feedback for FPS games... you know that there are lots of shooting games and that a gun provides recoil when fired? Perhaps a heavy linear solenoid mounted front to back in the mouse could give varying amounts of "recoil" for shooting games.

Or require electrically conductive mouse pad and put a set of coils in the mouse. Make the mouse a linear motor. Imagine driving mouse in a funny patterns over the pad even when user does not touch it 

MWAHAHAHA! That would be awesome. Brings this music video to mind:

Sorry for the off-topic...

hoggy, if a protocol (base protocol like SPI and packet contents order or something) and connector (RJ11 for instance) are specified, it could be implemented by any company (or individual). The thing is, though, which half will have the controller in? Or would it be like my idea with a controller both sides and the one actually hooked to the PC becomes the master automatically and the other goes into slave mode, only sending packets out to the main controller. That may need to be declared in the specification document for a "Hoggy modular ergo" compatible keyboard half.

[islisis]

Which gives me an idea for mouse force feedback for FPS games...

it's worth a shot marketing old as new, but this and ensuing ifeel line of force/tactile feedback logitech mice never caught on. tactile feedback was better for the desktop than games even imho

oobly: i didn't pay attention to your keyboard's thumbwell! great to hear it's more comfortable for you. makes me wish they came out even more now :/
and great vid 

[PieterGen]

I am thinking about better trackpoints. The present (IBM/ Lenovo) trackpoint is a good idea: don't move your hands from the keyboard, yet be able to "mouse".

However, in reality I don't find it nice to use, even after practice and adapting the speed & sensitivity. I think the main reasons are:

1. the trackpoint does not actually move, it stays put. This in contast to real mice (mouse fysically moves), or trackballs (ball really rolls) or trackpads (your finger really moves over the trackpad). So, with a trackpoint there is no mental relation between the motion of (finger, rolling ball, mouse) and the pointer. The relation is between pressure on the trackpoint and motion of the pointer, this is harder to grasp.

2. The trackpoint has to be low in order to be in the way of the fingers. This means: a short lever. Meaning: precision is harder to achieve.

3. The trackpoint is operated with one finger only. Precision is hard to achieve with 1 finger. For that reason, people who do precision work like sewing, calligraphy, tattooing, surgeries, hold their tools with two fingers  (usually thumb and index).

On a split keyboard, there IS room for a longer lever. If you put it on the side of the keyboard. In fact, you can even put two trackpoints in it. Drawback #1 of the trackpoint is not changed: a trackpoint will stay put. But the longer lever gives it some motion, which is good. Also, a longer lever means more precision, and can be grabbed with thumb & index.

One idea is to use one trackpoint (set say, the left one) for "rough" movements. This means a high sensitivity and high speed. The right one can be set up for precision movements, so lower sensitivity and lower speed. If you need to move the pointer to the other side of the screen and hit a specific point there, you use the left hand to move the pointer "quick & dirty" to roughly to right spot on th escreen, and then use the right trackpoint to place it precisely on spot. An added bonus is that now the mouse work is distributed over two hands.

Thoughts?

[hoggy]

[little snip]
hoggy, if a protocol (base protocol like SPI and packet contents order or something) and connector (RJ11 for instance) are specified, it could be implemented by any company (or individual). The thing is, though, which half will have the controller in? Or would it be like my idea with a controller both sides and the one actually hooked to the PC becomes the master automatically and the other goes into slave mode, only sending packets out to the main controller. That may need to be declared in the specification document for a "Hoggy modular ergo" compatible keyboard half.

Good thought...  I wonder if having a separate controller in it's own box would be a way to keep the overall costs down.  That way, neither half will have it and if you wanted a gaming specific half, then it's just that and the controller to buy/build and there's option of getting the other half at a later date.  I like the "Hoggy modular ergo" name, but I'm too modest, "Modular Ergo" has a nice ring to it.

[qihqi]

Qihqi, have you seen the access akc090?

Oh wow, thanks!

[hoggy]

I was thinking today about the palm switches Input Nirvana, Sordna and I think Lanx added to their Kinesis's.  More keyboards should have them.

[Tiramisuu]

learn to stenotype

[yasuo]

learn to stenotype

interest with this though, steno board actually easy to make with handwired