Re-Create the DataHand - Thumb cluster under development. Project 75% done.

[wolfv]

OldDataHands,

I got C++11 running on Arduino for Teensy 2, and PROGMEM is working on an array of polymorphic objects.
Sorry for the false alarm.
DodoHand firmware should be ready in a few weeks.

Method for adding C++11 to Arduino for Teensy 2 is posted on https://forum.pjrc.com/threads/30474-User-Name?p=84425&viewfull=1#post84425

[Interface]

Haven't checked and measured all the mechanical pieces in detail but are there any that's too small to be printed on an FDM-machine like the Makerbot? If it is I would like to fork it and make one that'll be accessible to more people.

Also I was thinking of bringing out my Chavant clay and make my own hand supports and then use the clay model as basis for image based modeling.

Thumbs up for your work guys!

[OldDataHands]

Haven't checked and measured all the mechanical pieces in detail but are there any that's too small to be printed on an FDM-machine like the Makerbot? If it is I would like to fork it and make one that'll be accessible to more people.

Was not designed for FDM, but see what happens when you try to print and let us know!

[Interface]

Okay OldDataHands I will check the smallest pieces and try slicing them and we'll see, If it seems possible I could probably have a test print by Sunday.

[Interface]

OldDataHands I made a test slice on the carrier and I think it's possible. Will have a test print done soon.

[OldDataHands]

Very Cool! I just made some minor tweaks onto the thumb_work branch.
They're untested, but should be an improvement if you're going to
print the thumb switches.

Looking forward to your results.

[OldDataHands]

Oh, and just in case you haven't noted it,
the parameter "gfn" in dimensions.scad
ought to be set up above 50ish (I have printed
at a setting of 87 using shapeways) depending
on how smooth you want to make the final model
vs. how large a model you can tolerate.

[sinusoid]

Changed the paradigm a little.

Fast, dirty, cheap, beautiful.

Low actuation force, small travel, wonderfully clicky. No mid button yet, but that's easy.
Gonna use ribbon or small thin pcbs to get the switch pins out to the bottom. 

Diameter of these is 30mm, exactly the same as originals with hand guard. Much more comfy too.

[OldDataHands]

Wow!

What is the travel distance of the tips of the keys?

The leads from those switches all come nearly to the same point.
What do you have in mind regarding a center switch? How're you
going to fit it in there?

[sinusoid]

Wow!

What is the travel distance of the tips of the keys?

2mm on the tips, actuation towards the end, after 1.5mm.

A tensioning screw can be added on the outside-bottom that would press the key's lever end against the leaf spring of switch.
I was trying to get similar effect with the 3d print directly, but result is non-uniform (though tolerable).

The leads from those switches all come nearly to the same point.
What do you have in mind regarding a center switch? How're you
going to fit it in there?

The leads are 2.5mm long, I'm gonna trim them and solder in a ribbon or small thin PCBs. I was thinking PCBs, because you would be able to etch contact pads on one end, and slide them into a pre-made socket in the main PCB, so the whole assembly would actually be removable without soldering. There would be enough space for a screw in the middle to hold it in place, too.

For the middle key - a lever that presses a switch located above the top finger actuator. Working on it, should be ready wednesday-ish.

[sinusoid]

Kinda like so:




Do you guys think it would be a good idea to settle on a common keycap mounting standard for the Dodohand project?

I know the original uses a single actuator assembly, but separating it into an actuator and a keycap feels like a natural thing to do

[OldDataHands]

Ahah! That looks promising. Looking forward to a report
about the feel!

Even my Pro-II datahands have separate "keycap" parts...
though I'm uncertain of the benefit if you're doing your
own FDM 3D-printing. In my models I did a crude connection
between the thumb switches and the "keycaps" because it
allows the print to fit into a smaller bounding volume.

Do you have an idea which would work ?

It seemed to me that for the finger switches the tolerances
were too coarse to allow for a nice, reliable fit within the
rather thin parts that I was imagining.

[sinusoid]

Ahah! That looks promising. Looking forward to a report
about the feel!

It works well, but when I put back all the buttons back in with it, it has just a tad too little space to plunge down reliably. I'll have to give it an angled mount, to raise it by 1mm on the fingerpress spot, and it's gonna be good.
Also gonna change the angle, it's not sloping enough for my taste.

Even my Pro-II datahands have separate "keycap" parts...
though I'm uncertain of the benefit if you're doing your
own FDM 3D-printing. In my models I did a crude connection
between the thumb switches and the "keycaps" because it
allows the print to fit into a smaller bounding volume.

I glue them from 2 parts anyway, because it's much easier to print them out, and they are overall nicer in quality from the printer. Using ABS, so it glues together seamlessly with acetone.
Printing holes in the keycaps would be easy, and the rods to mount them could be glued into the actuator lever without problems, just like I do it now.

I was thinking keycaps, because I ended up making the keys longer and more profiled than the original... and my wife would prefer them to be even different. Besides, this is an ergo device, so... no custom keycaps?

Making them removable would also allow for easier dismantling of the switch, I'll show in photos in a sec... basically, I'd be able to pop in the microswitches, pop in the levers with axles, close them up with a lid that holds it all together, and then put on the keycaps, whatever form and diameters they have.

Do you have an idea which would work ?

I think I'd go for something lego-style. The standard cross-section rod maybe? but I'd definitely go for keycaps of some sort.

It seemed to me that for the finger switches the tolerances
were too coarse to allow for a nice, reliable fit within the
rather thin parts that I was imagining.

Mine are more massive. While they fit in same diameter as the guard hole, they are considerably more voluminous. Made them like that on purpose, didn't like the original feel, it felt too... delicate. Small. Easy to break.

Anyway, here it is, added the middle button (sorry for the quality of these):



and here is the blow-up view. I used 2mm nails for the switch axles. No plate to hold them from the top yet, i goofed up on some booleans when preparing it, and couldn't match reliably.



I want to get this stuff running ASAP so I can start practicing WPMs and experiment with layers and key layouts.

[sinusoid]

Redesigned and fixed dimensions, sideways wobble is now eliminated. Got it printed, but it looks more or less like the other ones

As you can see in the images, I'm using a plastic plate to press down the switch rods. It's very hard to assemble when the keycaps are a part of the switches, so now looking for the best way to keep the two separated.

[OldDataHands]

I'm keen to see how you manage to attach the
keycaps to the plates. Please do share as soon
as you've got something!

Looks promising!

[Interface]

Thought I replied already, anyhow.

OldDataHands I've made a test print on the cbutton, it got too warm for the thin parts so it just melted to a glob there. But I see Sinusoid has a solution in the works!

I also thought I'd make my own hand rest for the Dodohand so I've sculpted a model in Chavant clay that I will digitize, ran out of clay though but got more at home so I'll continue working on it in a few days.

Sinusoid, I'm looking forward to printing your solution!

[sinusoid]

Quick update.

Switches work OK. Travel a little too big. That's going to be easy to fix, I'll leave that for later though. Right now I want to have a working prototype ASAP.

Here's a shot of 4 switches in various stages of assembly.
I couldn't make up my mind regarding keycap attachment, so I thought: screw it. Screw it all.

As you can see, some elements require sanding to get them working.

Then I assembled the switches, and made a mockup handrest. I'll probably put resin over it.
Worked with it a little, turns out this keyboard needs a really good hand support to be comfortable to use. Side movements felt awkward at first, but got used to it pretty quickly.
Has plenty of place for electronics.
Will have to design a thumb cluster for it, but want to make my own version, experiment a little. Will prototype something in with oil based clay later.

[Viz]

Great work guys! I'm so excited to see the end product!

[Phenix]

awesome project. but im worried about the price. Guess/Hope ~500

[test321]

Bump. Any news?

[sinusoid]

I have updates

First of all, I made a thumb cluster.


8 switches, 7 used at present. In a comfortable arrangement. Planning something nice for the 8th, but need to design a proper 3d printed hand rest first.

Second of all, I made a temporary hand rest. It was nice and shiny, made from ABS juice with reinforcement fabric, formed over oil based clay.
But then I decided to add some thermosetting clay spots onto it, to find minimum hand support areas. It had to be baked in the oven... see where this is heading?

So the ABS had a lot of acetone trapped within, even though I dried it for a very long time. When I stuffed it into the oven at 120°C it foamed and got runny! Got me some burns trying to save it and knead it back to shape while still hot, but it paid off... ergonomy-wise, at least.
Now it's functional and comfortable, but dead fugly. Sooo... here it goes 





This was shaped directly over the clay from the previous photo.

I'll be optimizing the handrest for points of support. Want to make them all movable, so they can be custom positioned in all axes, so it can fit different hand shapes and sizes.
Also will increase side support, so it'll hold the hand in a natural, vertical position for those who would like to write that way. Tested it, it works nice.
The switches will have a variable positions as well. Turns out this is really important, otherwise the keyboard gets a bit straining to type on after a while. I'm trying out different hinges and designing a general mechanical layout for the hand support, but no definitive results yet.

I managed to get a setup I can dry-test on.


I severely underestimated the design and the potential of this. When I started doing this, I had a parallel Kinesis -style keyboard layout in the works, with early 3d prints ready... From the time perspective, I regret not going at this full steam from the beginning. It's mentally aching, knowing I could have been 1 month further with the development of this right now...


Gonna be soldering this next.



@Viz
Me too 

@Phenix
Re:price/making it a product/selling it - No idea. Didn't really think about it yet. I don't even know if there's gonna be demand for this, or will people like the new switches. I have it in the back of my head, and would love to do it, but it's still too early. Needs to be tested, needs not to break, needs to be easily fixable, needs to fit most hand types... and I need to research best practices regarding selling stuff on GH.
I'll get down to it after I have a working, programmable prototype running. At this stage this would be a distraction. I did some research after your post, and ErgoDox price range seems like something acceptable to a lot of people. I would also like to release the files for this at some point, so anyone can print those out and assemble/modify on their own.

@test321
There you go

[regack]

So the ABS had a lot of acetone trapped within, even though I dried it for a very long time. When I stuffed it into the oven at 120°C it foamed and got runny! Got me some burns trying to save it and knead it back to shape while still hot, but it paid off... ergonomy-wise, at least. Now it's functional and comfortable, but dead fugly.

It looks like some kind of alien organic control system in a sci-fi movie... it's fantastic!

[Phenix]

Thanks for the update.
The wrist Rest looks .. functional. But if its ergonomic why not
to set up the angle is a good idea!

[alexjd99]

@Phenix
Re:price/making it a product/selling it - No idea. Didn't really think about it yet. I don't even know if there's gonna be demand for this, or will people like the new switches. I have it in the back of my head, and would love to do it, but it's still too early. Needs to be tested, needs not to break, needs to be easily fixable, needs to fit most hand types... and I need to research best practices regarding selling stuff on GH.
I'll get down to it after I have a working, programmable prototype running. At this stage this would be a distraction. I did some research after your post, and ErgoDox price range seems like something acceptable to a lot of people. I would also like to release the files for this at some point, so anyone can print those out and assemble/modify on their own.

I'm super glad you're going to be releasing the files, it's always a good thing to have it open source  ) Hope this doesn't end up facing any major problems, since I've been wanting a DataHand since I first saw one.

Good luck with finishing up the prototype 

[test321]

Great post man! Don't cheap out on switches they should have different actuation force for different fingers. Considering this is pretty much best keyboard to top all the keyboards, price doesn't matter at all, it should be all about quality. Does 3d printed plastic feel good or are there other more comfortable materials? Looks kinda tall, but that's probably because of your unique switch/part positioning.

[Zekromtor]

pick function over form every time.

I want some vids of excessively ergonomic WPMs

[sinusoid]

I made myself a promise I won't post here without delivering content... so sorry for slow reps. Anyway!

It looks like some kind of alien organic control system in a sci-fi movie... it's fantastic!

OK, now I had to do it. For the Overmind.




kekekekekeke

This is actually silly, because I already started redesigning this for 3d printing, and the element won't be used in the prototype. I could have spent this time in a more constructive manner. But it looks nice I guess

As you can see, the wires are connected to a proto board, and I did some wire management as well. On the last two I realized I can solder this without separating the ribbon. Now got to order shift registers and figure out how to handle debouncing.

Thanks for the update.
The wrist Rest looks .. functional. But if its ergonomic why not
to set up the angle is a good idea!

Designing the handrest now. It's gonna be VERY adjustable. Not just the tilt. When I say ergo, I mean it.

I'm super glad you're going to be releasing the files, it's always a good thing to have it open source  ) Hope this doesn't end up facing any major problems, since I've been wanting a DataHand since I first saw one.
Good luck with finishing up the prototype 

I can't see no major problems. Mechanical part is completed and operational. Even if I fall ill or get killed in a car crash, OldDataHands has backup of the switches. The only thing left to work out is the electronics, and that's a well documented process that doesn't need exotic parts.

Great post man! Don't cheap out on switches they should have different actuation force for different fingers. Considering this is pretty much best keyboard to top all the keyboards, price doesn't matter at all, it should be all about quality. Does 3d printed plastic feel good or are there other more comfortable materials? Looks kinda tall, but that's probably because of your unique switch/part positioning.

I disagree. Datahand is about a layout and a principle of operation. This thing has been AFK for too long, and far too many people were not able to get it due to the price range when it was still available. And, in my personal opinion, it was badly overengineered and unmaintained for a large part of its lifetime.

Time for refinement will come later. Now it hast to start living again.

The plastic feels good, the switch feeling is light and clicky. I'm trying to counter the drawbacks of FFF printing by designing this in an appropriate way. Works out well so far, and the results are even on a well calibrated machine.

pick function over form every time.

I want some vids of excessively ergonomic WPMs

This exactly. (oh wait... did I just pretty-paint a throwaway part...  )
Seriously now, there is no place for form at this stage.

As for the vids... me too 

[wolfv]

Nice work sinusoid .  Seems like mechanical switches have improved since the original DataHand.

The only thing left to work out is the electronics, and that's a well documented process that doesn't need exotic parts.

Here are some suggestions based on my experience with DodoHand:

Use Teensy LC, it has 3 times more RAM than Teensy 2.0.  I ran out of memory writing DodoHand firmware on Teensy 2.0.
https://www.pjrc.com/teensy/teensyLC.html

Create separate designs for left and right hand PCBs.  Its easier to design that way, and much easier for electronic neophytes to trouble shoot.  DodoHand (and ErgoDox) uses the same PCB design for both left and right matrices.  The DodoHand PCB is hard to trace, and I still don't have the right thumb working.

[wolfv]

sinusoid,

Consider testing the hardware and firmware on breadboards before designing the PCBs:

[vvp]

Wiring breadboard is a pain. Just design a PCB (you will need it at the end anyway) and etch it at home. Its only something like 2 hours of work to etch it. It is cheap and the result is much easier to work with. And if it turns out well then you can put your prototype PCB into your first prototype keyboard.

[sinusoid]

@wolfv,

I have all the switches connected to a proto board with a ribbon cable, and pins soldered in for each output. Gnds are bundled together into one... the switch density left no choice on this one.

I'll be connecting this to an arduino mega temporarily, using a 74HC165 shift register as suggested here, by senso (though I realized ErgoDox uses I2c port expander successfully... whatever).
I would like to debounce the input before the shift register, so I researched a bit, and found this:

source: http://www.eng.utah.edu/~cs5780/debouncing.pdf

Applying it right now would mean I'm using something I don't understand well. Which is bad.
Right now I'm split between asking for help, and taking my time to bite into it, wanting to understand how it works exactly... and the first just won.

If anyone could help me out with getting the right caps, diodes and resistors, I could order them ASAP, and research it in my own pace then before soldering it together over the weekend.
Case described in the article seems to fit the Arduino Mega - calculated for 5V, C=1uF, R2=18K, R1=82K. Can someone confirm if these are correct? What diode should I use?
If no reply, I'll just sit to it over the weekend to gobble up necessary knowledge, and order parts monday-ish.

Or just skip the debouncer for the time being, hardwire to shift registers, and try to get some software on the mega... that's a good plan.

edit: reading the diagram, looking at where the cap connects... does it mean I make a single debouncer for all of the switches, where all the switches are in parallel? Or is it not possible with my lax treatment of the gnd pins?

edit2: or should I debounce in software? I will have to solve the case of key-pressed-constantly, this falls under debouncing.
For the final build, I should use both signal pins on the switch to determine its state, as suggested in the article. This is the perfect solution without the need for any debouncing whatsoever - switch is always in a known state then.

This is the current wireup, checked with multimeter, and ready for testing:


New hand rest, 3d printed. White residue is paint, I was verifying the exact contact areas with the hand.

Also, the size of this thing is like a big computer mouse. Kinda begs for a sensor on the bottom... Should I resist that urge, or succumb to it? 

Wiring breadboard is a pain. Just design a PCB (you will need it at the end anyway) and etch it at home. Its only something like 2 hours of work to etch it. It is cheap and the result is much easier to work with. And if it turns out well then you can put your prototype PCB into your first prototype keyboard.

I won't do that now. I etched PCBs in the past using toner transfer, and it's no problem, but this is not the right moment to do that. Would add increased overhead. Also, the PCB is not yet designed, which isn't 2 hours
Working device first, refinement later.
edit: I'm gonna use shift registers for this, so there won't be a need to wire up a matrix right now.

[vvp]

Also, the PCB is not yet designed, which isn't 2 hours

Yes, but you will need a PCB at the end anyway so designing it is not a loss of time. It would be lost time only when you think it is highly probable that your schematic is so bad or the case/PCB contours so unstable that you would need to modify it in a substantial way (which would completely break the original PCB layout).

I would not bother with hardware debouncing. Software debouncing in the micro-controller is easy and more flexible. Actually if I would have a chance to pick a keyaobard with a hardware debouncing or a software debouncing in an open firmware then I would go for the software option since it is easier to tweak later on.

[sinusoid]

@vvp,
There is no case yet. It's gonna be a bunch of elements with variable positions, think R.A.T.7 on steroids after a FEV vat dip. Switches won't have a traditional PCB due to size constraints and need for height alignment, they'll use flex interconnects to the mainboard a bit like they do now... it's all pretty complex crazy.

re:debouncing, got it, ordering registers only then! If someone has different opinion or exeriences, please chime in, I will research.

[Zekromtor]

vvp is correct. debouncing is a rather simple and tweakable task in software. plus, if you start getting double/triple presses out of nowhere someday (like I did with my green alps) then you'll want to be able to debug it with mods to the software and not have to worry if it's the switch or your hardware debouncer acting up.

In my case, it was the switches, which proved very vulnerable to dust/foreign matter interrupting the contacts enough to cause multiple clicks. Changing the debounce to crazy values like 100ms didn't even work, but compressed air in the switch did

[test321]

Holy crap you just topped size and ergonomic factor of datahand. i take my hat off to you sir.
how do switches feel? could they be used for gaming, especially for quick fps games which are normally played on cherry mx reds? Are clicks audible? Input lag? rollover?
Mouse sensor under the right kb + teflon mousefeet could be useful for casual browsing, typing, 3d modelling and programming - all of which don't require great precision, but rather steady speed and-not-moving-your-hand-to-mouse-constantly, however there should be easily accessible switch to turn the mouse function on or off.

Edit: you could also use left kb mouse sensor for vertical/horizontal scrolling, effectively replacing scrollwheel - which would also work for both left and right handed people since sensor functions are dictated software-wise.

Hypothetically speaking you could place 2-3 tactile switches for 1 button under a horizontal band on one of 3 hand rest parts on both kb which would result in 2 additional buttons - left and right mouse click.

[Zekromtor]

Although the idea to use it as a mouse is a cool one, I don't think it would work well. The problem isn't in using only your palm for mouse motion, but rather actuating the buttons while keeping the whole device stationary with your palm. Not having used one, I can only imagine that you want to rely on it being heavy enough or firmly fixed to the surface so that you don't have to counter every finger motion with palm pressure.

Edit: by all means, however, I still think it should be tried! It would be extremely cool if it did end up working well enough to double as a mouse for mundane tasks or even gaming.

[test321]

Need more pics!

[nclu]

Now that it's starting to get down to that mouse-size. What about turning it more vertical, almost more like a joystick? Great work, I've been watching this thing from the sideline quietly for a couple of years now and patiently await the a do-it-yourself instruction set.

[Turbinia]

Some awesome work with the micro-switches! Makes things allot easier than optical switching. I would say with the size it is now an optical mouse is feasible. Otherwise you are back to the odd reaches for trackpoints or trackballs. A very high DPI would be best so that not much movement would be required, to go with the rest of the minimal movement idea of the Datahand.

[arisian]

A very high DPI would be best so that not much movement would be required, to go with the rest of the minimal movement idea of the Datahand.

The trouble with "high DPI" is that it also means twitchy and hard to control precisely; this would exacerbate the issues people were already concerned about of having to actively counter the "mouse" movement when trying to type.  One of the big "advantages" of the original datahand design was that it required only finger movement; no wrist/arm movement is needed for use.  That's why the trackball/trackpoint ideas seemed like a more natural extension of the original design.  Of course, there's no reason why we can't ultimately have several different models/variants 

[matt2]

A high DPI mode can be turned down.  I have a CST2545.  Holding the center button and then clicking the right button changes the default 800CPI to 1600CPI and clicking again will switch it to 400CPI.  1600CPI is essential for moving the pointer between two 30" monitors in a non-stress inducing movement, while 400CPI is good for accessibility or precision movement (such as photo editing or CAD).  So all of these DPI modes have a reason for existing and need to be present on a complete product.  I wish that it stored the CPI somehow, because I have to change it every time I reboot (about twice per year...I love Linux).  But at least I never have to worry about special drivers.

I am not sure how many trackballs are like this, but usually gunk builds up and you have to take the ball out and scrape it off of the roller.  With this one, I have never had to do that.  I have owned it for 3 years now, and all I have to do is spin the ball and the gunk flys off.  It is one of the more expensive trackballs out there, but it would be a good match for anyone with this kind of budget for input devices.

I use the focus follows mouse policy for window activation, which means that the keyboard focus changes based on what window the pointer moves under.  This does not raise the window to the front, so windows do not pop forward when this happens.  So as great as this idea is, I think something would have to disable the trackball movement when no movement is intended.  Maybe using a prototype would prove this out, but I would hope that there is some kind of hand posture detection that can be used to active trackball movement.  Or maybe the ball can be located in a position (such as recessed) where it is easy to avoid when using the keyboard.  If all else fails, you could use the other hand to activate a switch.

I switch between the keyboard and trackball quite a lot, so reducing that travel would be a huge benefit.

[test321]

A very high DPI would be best so that not much movement would be required, to go with the rest of the minimal movement idea of the Datahand.

The trouble with "high DPI" is that it also means twitchy and hard to control precisely; this would exacerbate the issues people were already concerned about of having to actively counter the "mouse" movement when trying to type.  One of the big "advantages" of the original datahand design was that it required only finger movement; no wrist/arm movement is needed for use.  That's why the trackball/trackpoint ideas seemed like a more natural extension of the original design.  Of course, there's no reason why we can't ultimately have several different models/variants 

maybe software based positive mouse accel would help with that?

Edit: wrist/hand support part could maybe also be more like U shape (the left part on the pic is already tall enough) so you can nicely lock & control the KB with wrist/hand, while easily removing your hand from the KB if you want to.

[Zekromtor]

I think it should extend to cover the entire wrist and only unlock with a verbal password

But in all seriousness, I'm starting to come around to this possibility. If your palm really has a nice recess to sit inside to provide 360 degree lateral resistance, this could work. Without the need to constantly move between mouse and keyboard, you really could consider a way to semi-permanently lock your hand in (test with velcro) with your offhand.

Also good to note: even though the ideal sensor position is somewhere under the palm, there's no reason why you couldn't just attach a standard mouse (I heard tape and skewers work  ) to the side of the existing rig to test the concept.

[Ashmon]

It seems to me that the inclusion of a mouse element to this can be solved pretty simply by following the functionality of the original datahand. Use one of the thumb switches to force the device into a mouse mode. This would mean that all potential drift from the laser element could be avoided while you are actively typing. Then you only read from the sensor and have it act like a mouse when the toggle is held. To make that even more simple you could transition that down to a foot pedal such as was done in the later models of the datahand.

Does that make any sense?

[sinusoid]

A little crappy update: got shift regs, got caps and resistors, etching breakout boards during the weekend, and ready to program this FINALLY. I'm having some hardcore deadlines at work, so focusing on the electronics is haaaaard. Grinding docs and tutorials in the free time mostly so I can hit the ground running this Saturday. Keep your fingers crossed

reps in FIFO order, LONGPOST IS LOOOOOOOOONG:

@Zekromtor, re: software debouncing
Gonna do it this software way, at least attempt so if results allow.


@test321, re: switch feel, audibility
They're nice. I enjoy them. They're clicky, not too loud, the cases resonates nicely. They are a little springy, but very lightly so. I'll be optimizing them in the later phases, got few ideas.
I peer reviewed this, people said it was satisfying, I observed they went on clicking this for a while, sensing it, enjoying themselves.
re:gaming, lag
Don't know yet, electronics not complete. Will test it on gamer friends when ready and report on it.
re: mouse
see below
re: scrolling
I have a few ideas, but it largely depends on whether it's gonna have a trackpoint somewhere, or a mouse built in. I think that scrolling in modern devices is terribly lacking. 3d software solves this nicely, and I would like to replicate this effect.
re:additional buttons
I can't visualize this... could you please draw that, or illustrate in some way?


@Zekromtor, re: mouse not good, need to counter button press force with palm
I haven't noticed this, the buttons are very light, and weight of the hand is enough to keep it stationary. It's much more comfortable than my RAT5 too. Though you can't use wrist to navigate, you need to use the whole arm.
Major con for this is that you need a desk or other surface to use it.
Trackball is possible, but you lose a piece of the hand rest, need to take fingers off homerow too.
Trackpoint is possible, but you have to take the hand off the homerow, it's also not very precise.
I'll make this modular and test.


@test321, re:pics
later, it's dev time now


@nclu, re: turning it vertical
Yes, this is supported. Look at the long 'leaf' on the left side of the hand - it's used to rest it when in vertical position. I tested it a bit like that, and it works very well. Much more comfortable. You can tilt it about 80 degrees max, 45-60 is most comfortable for me.


@Turbinia, re:mouse
I used my RAT5 with high DPI for quite a while for graphic design, the biggest issue was breaking through inertia from a  full stop position. This really messes up precision on small start-stop movements. Would be awesome if not for that. But I have a few ideas, see below.


@arisian, re:navigating with keys
I've researched into that, many people said that this feature didn't work very well, that it was implemented poorly. More below. About twitchiness, see above rep to Turbinia.


@matt2, re: trackball
Ahh, the L-trac! They seem awesome, wish I could lay a hand on one some day.
Look at the Conchi build thread for some switch overhaul on a Kensington. It's nice. https://geekhack.org/index.php?topic=70144.0
Keys on this datahand-derivative are separate, so trackball can be placed instead of the hand rest.
Also thumb cluster can be thrown out on one of the hands to include a trackball.
I've got some stuff brewing trackball-wise, see the ball transfer unit trackball thread. Waiting for some time to finish it. Have a few surprises, but don't want to spoil until ready/checked
re: focus follows mouse, Linux, cursor-lock
YES. Focus follows cursor FTW. Linux default at that, too, afair. I use dwm, Firefox with Vimperator, and Spacemacs. Excludes the need for mouse in most situations.


@test321, re: positive mouse accel
Yes, this sounds like a good idea. Or fluent DPI switching. Idk, will have to test.
re:u-shaped wrist/hand support
It is u-shaped. There is a bone moving in the circled area, so you don't want the support to go all the way up. It supports the muscle that's below it comfortably. It almost 'grabs' your hand when you put it on the device, aligning it into position. Feels awesome imvho.


@Zekromtor, re: tape and skewers
ROFL! I've seen your setup on your blog, but not in that much detail, and not in this iteration, this is totally awesome!
I'm probably gonna core out a cheap mouse to test it, without modifying electronics.
I have to cut down the amount of awesome things that can be done to this design to actually FINISH IT. And soon.


@Ashmon, re: mouse as a layer/mode
Yes, it makes a lot of sense, especially if we can make the DPI/speed variable.


My thoughs on the pointing device:

Mouse:
PRO: getting a sensor into the device lets you do mouse nav without leaving 'home rows'.
PRO: you get a lot of precision and dynamics
CON: you need a desk and a surface.
Thought: Ever heard of those double-nipple IBM laptop prototypes? They used one for fast nav, and the other for precise nav, and you could combine them to be used at the same time... See where this is heading?

Trackball:
PRO: You can navigate without any surface. Compact. Arm movements not necessary.
PRO: Good precision
CON: need to get the hand out of the 'home rows'.
CON: you lose a piece of your hand rest, needs to rest on the ball.
Thought: I don't like the thumb-trackballs, but you could swap the side cluster for a trackball.
Thought: Looking at the Conchi build thread, maybe the paradigm of the navigating half should be different at all?

Trackpoint:
PRO: You can navigate on any surface
PRO: Hands on the home row if solved well. You can use two at the same time.
CON: Precision
Thought: Make the whole thing a one huge trackpoint in a mode/layer, so you can just tilt/change weight of your whole hand. Can easily be done with tensometers in the base. Better precision, but still far from mouse/trackball.

Keynav:
(http://www.semicomplete.com/projects/keynav)
PRO: hands on the home row
PRO: lots of large screens, here I come... no need to drag the cursor, you just tell it where to go with your keys.
PRO: Moves are REALLY fast.
PRO: Can be implemented in hardware, work cross-platform.
CON: latency increases with precision
CON: 3d software, graphics software - out of question?
Thought: lifesaver when using a lot of screens to quickly switch focus. Replaces the need for high speed movements, so the pointing device can focus on precision.
Thought: varying performance when used in games/software. Good for Starcraft, bad for Counterstrike?


Other thoughts:
Using the cursor rarely implies typing in the same time. Shortcuts are used mostly. So maybe a better way would be to add one of the single-handed typing functions (like chordability, or the Matias half keyboard function)?
Most of 'casual' mouse moves are already covered in software (tiling WMs, Keynav, Vim/Emacs, Vimperator addon for Firefox, etc), so the case we're dealing with here is heavy, constant mouse use in software where it's really necessary. So maybe the device should be designed in a way that takes into consideration this exact scenario, to minimize the need to remove the hand from the mouse, and facilitate shortcut accessibility with a single hand?

[Zekromtor]

Thought: Ever heard of those double-nipple IBM laptop prototypes? They used one for fast nav, and the other for precise nav, and you could combine them to be used at the same time... See where this is heading?

I do, and I support that kind of crazy. There'd probably be a hell of a learning curve, to the extent that only 1% of people might even want to bother, but the potential is there for incredible results after mastering two mice at once. Also, the double-nipple design is found commonly in nature, providing both form and function.

[matt2]

I had assumed that everyone knows about this, because it is how I found this site, but just in case, here it is; the TrackHand:

https://github.com/Henry/TrackHand

On the L-trac, I use the pip joint areas of my index and middle fingers to move the ball.  I have no idea how I would translate that into a TrackHand like setup.  Turbinia's mockup (reply #350 in this thread) seems to move it to the middle and ring fingers, which are less dominant for me.  I assume that the position was chosen due to the space that the DataHand's thumb cluster takes up, but I suspect that it would be better if it were under the index and middle fingers instead.  Maybe removing the thumb cluster (to make room) on the dominant hand side would be better for a frequent mouse user, but it would be nice to have both (thumb cluster & trackball) in their ideal positions.

Anyway, regardless of which path is chosen, it would be an improvement.

By the way, Cherry MX Blue keys are nice, but I still prefer my Model M's buckling spring.  Unfortunately, I need the ergonomics of the CK Comfort Keyboard, so I have to use https://github.com/zevv/bucklespring for a little nostalgia :-)

[test321]

re:additional buttons
I can't visualize this... could you please draw that, or illustrate in some way?

but now i'm not sure if it would affect KB movement in a bad way.

also, thumb trackball and keynav would require additional key bindings and thus more layers (like original datahand) so you wouldnt be able to reduce key layers from 5 to about 4 or even 3.

[berserkfan]

Looking at this excites and worries me. The eventual product could become a procrustean bed that fits the hand of the designer, and excludes a significant number of other people. In particular the ergodox thumb keys are way too far for my hands. I had to give away my ergodox two years ago at a fat loss for that reason.

[wolfv]

Looking at this excites and worries me. The eventual product could become a procrustean bed that fits the hand of the designer, and excludes a significant number of other people.

Most of these keyboards are experimental prototypes.
If one is successful, someone can make an adjustable version, or a 3-D printed version.