[lug] An alternative keyboard and its issues

Jeffrey Haemer jeffrey.haemer at gmail.com
Tue Sep 23 05:24:04 MDT 2008


In addition to asking guys like us, why not go over to CU and ask the OT and
PT schools?  If they don't know, then maybe someone there would turn it into
a research project.

(You might also ask the piano performance guys at the music school -- they
spend a lot of time thinking about hand mechanics and movement.)

On Mon, Sep 22, 2008 at 7:14 PM, Chris Riddoch <riddochc at gmail.com> wrote:

> Hi, everyone.
> I've got a little problem I'm trying to solve, and could use some help.
> I recently got myself a new and very bizarre device[1] which will help
> me type, and is great for my wrists, but lacks a certain something.
> I'll get to that.  First, how it's used.  There are two joystick-like
> things which slide in eight possible directions, like old arcade
> joysticks.  When you slide both to the left, it sends the keyboard
> scancode for 'a' to the computer.  It can be used as both a mouse and
> a keyboard.  Their documentation calls the eight possible directions
> "north," "northeast," etc.
> Here's the design problem I'm trying to work around: They simply
> arranged the key positions sequentially.  "a" is west on both the left
> and right "orbs." "b" is northwest on the left, and west on the right.
>  "c" is north on the left, and west on the right.  It's not an ideal
> layout.  But layouts are easily fixed with xmodmap... if only I knew
> what to move them *to*.
> This keyboard seems to be able to function just fine with me not
> actually re-centering after moving to a key's position.  As a result,
> I could hold one orb in place while moving the other to a different
> position - this would be less physical effort than moving both orbs on
> every "keystroke."  Optimizing for that alone would be an improvement,
> but I can think of at least one more reasonable consideration: sliding
> to either the left or right from the current position is easier than
> having to aim for a position not quite across the orb -- or worse, a
> quarter turn away.
> So, given a set of 47 remappable key positions (some just aren't for
> reasons too complicated to go into) I'm trying to find a mechanism to
> decide on where each key *should* go.  I have statistics on which
> letters follow which others with what frequency.  I can get statistics
> on the timing between different orb movements.  Which brings me to the
> last part: by what means would I use this information to find
> (reasonably) optimal positioning for the keys?  This is just a bit
> beyond me.
> Some of you may remember a guy who wrote an evolutionary algorithm for
> trying to optimize his keyboard layout.[2]  You'll notice that I'm
> trying to use a similar approach, but I'm having trouble getting from
> here to there.  This is clearly similar, but the differences are
> enough that I'm getting stuck.
> If anybody's interested in trying out one of these keyboards, I'll
> bring it to the HS meeting at Cafe Sole this Thursday.
> [1] The Orbitouch: http://www.keybowl.com/
> [2] http://klausler.com/evolved.html
> --
> epistemological humility
>  Chris Riddoch
> _______________________________________________
> Web Page:  http://lug.boulder.co.us
> Mailing List: http://lists.lug.boulder.co.us/mailman/listinfo/lug
> Join us on IRC: lug.boulder.co.us port=6667 channel=#colug

Jeffrey Haemer <jeffrey.haemer at gmail.com>
720-837-8908 [cell]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lug.boulder.co.us/pipermail/lug/attachments/20080923/635c911d/attachment.html>

More information about the LUG mailing list