Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - iandoug

Pages: [1] 2 3 4 ... 17
1
Keyboards and Other Interfaces / Re: Balanced Keyboard Layout
« on: June 13, 2018, 10:29:29 AM »
Depends on how you define the keycode on the Shift layer. If the Shift layer uses a Shift modifier (and there are many types of shift key actions -- conventional, one shot, down position of a key that otherwise outputs a character, etc.) then yes, if pressed without a modifier enabled. But you could define the key position with a macro definition "S(KC_G)" to output shift "G" without need of the Shift modifier.

Bit off topic but there are some experts here. I'm a bit involved in designing a keyboard for an African language. They have an unusual letter which is Ʋ U+01B2 LATIN CAPITAL LETTER V WITH HOOK and lower case, ʋ U+028B
LATIN SMALL LETTER V WITH HOOK. However they also have a version with an umlaut/diaeresis on it, which does not exist in Unicode. So you need to do it with the letter plus combining diaeresis :  ̈  U+0308 COMBINING DIAERESIS.

Now my question is, can standard keyboards/drivers/OS eg plain generic 105 ISO keyboard on Windows, be made to send U+01B2 plus U+0308 on one keypress?

Or will they require custom firmware / OS tweaks? Or something like AutoHotKey / Keyman ?

Thanks, Ian

2
Keyboards and Other Interfaces / Re: Balanced Keyboard Layout
« on: May 10, 2018, 01:45:26 PM »
The model 01 has arrived, so I'm finally able to give some early feedback on these questions.

Thanks, interesting ....

Any comment on using the index finger to hit Enter?
As opposed to, for example, a thumb?

Thanks, Ian

3
Keyboards and Other Interfaces / Re: Balanced Keyboard Layout
« on: May 06, 2018, 01:05:47 PM »
According to their site, default usage is something like this:
If that's the case then it's irrelevant to the tests in KLA. Unless you have other plans for it :-)

Whoops. You need it to access {} and [] ....  so will have to include it.

The code for plotting buttons on a curve may be a little tricky. Program then needs to be able to calculate the centre of each key, because that's where things get measured from. Suppose can borrow from the Kinensis layout there.

FWIW, after staring at the default layout, I think it would be better to have space next to shift, since you are likely to use Shift more than Alt.
The whole no-AltGr design shows the American heritage ... unless I am missing something. :-)

4
Keyboards and Other Interfaces / Re: Balanced Keyboard Layout
« on: May 06, 2018, 12:54:38 PM »
Thanks for looking into this. I have it on order, so don't know yet how useful that extra key under the base of the thumb will or how to best push it. My current thinking is that I will use it for a navigation layer where one can afford to be slow in pressing it down as this should definitely be more effort than a key under the thumb. Even if it turns out to be a gimmick the thumb keys appear better positioned than in my Ergodox, which is a big plus for me.

In any case I need to be able to still type on a laptop keyboard, so can't be too drastic in what I use those palm keys for. (I'm using a Japanese keyboard in a Lenovo T430 to have more thumb keys)

According to their site, default usage is something like this:
Quote
Underneath the thumb arcs, you'll see one of the Model 01's most unique features: a palm key. You can think of it as a Function key or a special sort of Shift. Dropping the base of your thumb onto it turns the H, J, K, and L keys into your arrow keys, turns the number keys into F-keys and even turns the WASD keys into a high-precision mouse.

If that's the case then it's irrelevant to the tests in KLA. Unless you have other plans for it :-)
Wonder why they call it a palm key when it's actually a Mount of Venus key.... IMHO the palm is the area of the hand past the thumb....
Just call it the Venus key and then you can hit on Venus for your functions....
I'll shut up now.

5
Keyboards and Other Interfaces / Re: Balanced Keyboard Layout
« on: May 05, 2018, 11:46:47 PM »
Just thought I'd post my current layout. Only have to use my cheat sheet for some of the punctuation on the shift keys. My only common typo is swapping r and h, and that's because I had it the other way in my previous layout. I hope the pic and txt attaches correctly.

Mmm I somehow missed the one you posted here
https://geekhack.org/index.php?topic=74546.0

but I got Lydell's layout. Will add to the next round of tests. Must still do Den3 on all. Maybe must just restart with KLA original and Den with all the new layouts, and then do Den3 on them all... probably better use of time. Have 18 new layouts to add at the moment.

6
Keyboards and Other Interfaces / Re: Balanced Keyboard Layout
« on: May 05, 2018, 12:19:02 PM »
I found the physical layout for the model 01 in the KLE format here: http://www.keyboard-layout-editor.com/#/gists/9b917e6bfbd6f76962cb3ee9d81e24dc

How hard would it be to get it added to KLA starting from that?

Have to figure out how to handle the palm keys ... there's no provision for that in KLA ... it only know about fingers and thumbs. Let me think. Sure Den will think too :-)
There are several issues with an extra modifier:
1. current keys (GUI view) only provide for 4 slots - normal, shifted, altgr, shift-altgr. So may have to code to allow centre spot as well.
2. need to update keymap handling to handle that
3. a more challenging problem is how to assign "weight" to use of palm key, compared to weights assigned to fingers. Do we assume using palm is even better than using thumb? Can you use right palm and right finger at same time? Etc....

BTW... these keys are under the palm rather than heel of hand, right? So do you need to straighten fingers to allow palm to sink down to press key?

Thanks, Ian

7
Keyboards and Other Interfaces / Re: Balanced Keyboard Layout
« on: May 05, 2018, 12:13:39 PM »
Just thought I'd post my current layout. Only have to use my cheat sheet for some of the punctuation on the shift keys. My only common typo is swapping r and h, and that's because I had it the other way in my previous layout. I hope the pic and txt attaches correctly.

Interesting ideas (E and O on same thumb ... who'da thunk?) and shift-shift for backspace .... Mmm... :-)

8
Keyboards and Other Interfaces / Re: Balanced Keyboard Layout
« on: April 30, 2018, 02:24:31 PM »
The main question was: Is there any recommendation/advice how to use the beakl layout on the keyboardio model 01?

I think that will require adding that physical layout to KLA to test possibilities. (Or maybe even KLE) But KLA can at present only handle normal, shifted, alt-gr'd, and shift-alt-gr'd combos.
Is there an Alt-Gr on model 1? or is that done by some other combo, or all on a different layer?

It seems to have enough keys judging by the layouts used in KLA, maybe those are missing some keys like Function keys etc....

Hence my suggestion to add it to KLA and let's play around after that.

9
Keyboards and Other Interfaces / Re: Balanced Keyboard Layout
« on: April 29, 2018, 12:28:12 PM »
That wasn't the main question

The answer to your main question in is, "it depends" :-)

When I was playing against KLA I used the various programming, digit and punctuation input files to try to optimise. Often there is a clash between what gets good scores on these files and what gets good scores on English. Particularly with things like comma, period, and (). Also depends a lot on your English input text, and in this regard Alice is a poor choice, it uses way too many ! and ? and () compared to most texts. Even British vs American inputs throw out different results because of the different use of single vs double quotes in dialogue.

I can't speak for Den and why he changes things, I guess it's partly a result of real-world (where what the programs say is just awkward in practice) as well as what results he gets from running Opt on the layout, as opposed to KLA.

I'm fully expecting my own keyboard that I'm busy with to annoy me intensely with some key placements... which means back to the drawing board... (again).

At the end of the day you must use what works for you... there is no silver bullet... (as much as I would like there to be. Maybe a bronze bullet is good enough for most people. Will certainly be better than QWERTY.)

10
Keyboards and Other Interfaces / Re: Balanced Keyboard Layout
« on: April 29, 2018, 03:53:17 AM »
btw) Looking at the AltGR layers of both triggers a question that doesn't seem to be covered in this topic. How do you optimize the placement of coding symbols as they are radically different between the versions I see on the layouts page. Hitting the for elisp pretty common '( looks pretty painful on p_rn with all keys to hit on same hand and same applies for things like (" which is also common yet hard to hit, yet this is better for the opted4/beakl9 version.

The problem with the punctuation is that is is rather language-dependent (computer programming language).

Eg Ada cares nothing for {} or even [], but JS and the whole bloody C family can't live without them,
or Python and Ruby are not pedantic about ; at end of statement (unless on same line) but the whole bloody C family (and Ada, for that matter) can't live without them.

So I suspect the answer to your question is "it depends" ... what languages do you use? Then you need to balance those needs with your needs in English or whatever you type most in.

(yes, I am not a fan of C family... :-) ... they've caused a global shortage of curly braces!)


11
Keyboards and Other Interfaces / Re: Balanced Keyboard Layout
« on: April 16, 2018, 02:37:38 PM »
To map a different key to a "shifted" key or other modifier (or any other designated key for that matter), you can use layers, effectively defining a layer that is raised by the designated "shift" key. The manner in which the layer is raised -- held down, toggled, one shot, multiple taps, etc. -- is up to you. Thus, any key can issue any specific keycode on a particular layer.

A single key can be responsible for many layers. And layers can require multiple keys. Layers can beget layers. It sounds crazy but there are use cases.

I can see for example how to send KC_CIRCUMFLEX, but for example KC_G sends both g and G .... or is it actually sending the scancode from an ANSI keyboard for G? ie
<AC05> = 43  (lifted from //usr/share/X11/xkb/keycode/ibm  scancodes file)
 or somesuch?

Like I said, I was expecting QMK to specify that the key in row 3 column 6 sends AC05, and then in
/usr/share/X11/xkb/symbols/us

I would have something like
 key <AC05> { [         g,          G,     copyright, dead_doubleacute ] };

Trying to wrap my head around this, bearing in mind Windows works differently to Linux, I'm guessing Mac works similarly to Linux here, but has their own keyboard layout description files.

But I suppose XKB is only set up for Shift, AltGr and ShiftAltGr, and QMK allows for other fancy tricks.

So when I define the layers, if I want a separate Shift layer, will it effectively be a duplicate in most cases? eg if g and G happen to be on the same key, then we say that base layer and shift layer both send KC_G ?

Which seems somewhat counter-intuitive :-)

Confused, Ian



12
Keyboards and Other Interfaces / Re: Balanced Keyboard Layout
« on: April 16, 2018, 12:52:50 AM »
To illustrate http://thedarnedestthing.com/split%20redux. Unrelated to this topic but I have since migrated to this BEAKL mashup for the better finger rolls and the least same finger usage http://www.keyboard-layout-editor.com/#/gists/e0c628a2707117813c46611d37dee43e for anyone scrutinizing the layout in the link.

Thanks, will study.

Cheers, Ian

13
Keyboards and Other Interfaces / Re: not good
« on: April 15, 2018, 08:27:44 AM »
How is your wrist doing these days brother?

:-) Thanks for asking. It's improved, not back to how it was before though. Some bends are tight (flexion position), one causes pain (tension position), and the supination position (ie palm up) is still not horizontal ... can get it almost horizontal if I twist it with right hand. My age also means things heal slower than when I was a kid. But getting there. :-)

I can type etc okay, just some stretches a little sore.
Got a bit distracted with Forex stuff, but getting back into keyboard issues again too.


14
Keyboards and Other Interfaces / Re: Balanced Keyboard Layout
« on: April 15, 2018, 08:18:57 AM »
Oooops, just realized I never created a new Readme to go along the new version of my program, not very useful without it !

I guess one of the difficulties converting from KLA to XKB is to figure out the corresponding scancodes for each key id, which will depend on the kbd type

I'm trying to modify one of the examples from QMK firmware for my keyboard, and the bit that confuses me is that (AFAICS) in QMK I need to define what letter each key sends, and there is a large assumption that "a" and "A" (or 4 and $) will be on the same key, which is not the case these days.
https://github.com/qmk/qmk_firmware

I was expecting (based on what I've seen of XKB config files) that QMK would send "Scancode A1" being first key in top row, and then rely on the PC operating system to decide what to do with it. That would seem the obvious way to do it to me. But no. Possibly this is also related to all the layers/one-shot modifiers/etc/etc/ that QMK supports.

So now it looks like I have to define that a key is sending "/", but no, it's not sending "?" as well. It's a different key that's sending that.

I've done a bare-bones modification, now need to summon up the courage to compile and install it on Teensy board, and then see what Linux says it is getting.

I think QMK takes the approach it does to fake an standard ANSI board for Windows, so that you don't need to worry about custom MKL files on the OS side.

But in solving one issue they create others....

Any QMK experts welcome to jump in at this point :-)

15
Keyboards and Other Interfaces / Re: Balanced Keyboard Layout
« on: April 04, 2018, 12:12:36 PM »
After trying these CLPs out, going back to BEAKL15 (same thing when trying out X7-1H), I noticed right away how the reach to middle columns bothered me.

What hardware are you on?

Thanks, Ian

16
Keyboards and Other Interfaces / Re: Balanced Keyboard Layout
« on: April 04, 2018, 12:11:01 PM »
Ian, you had asked about scripts / programs that could help in creating / converting KLA json files,
you might want to have a look at a small go program I wrote : https://github.com/phques/txtkbd2kla
It's pretty basic, but it helps

thanks, interesting.

I did find this on github as well, for converting mac layouts to windows.

https://github.com/adobe-type-tools/keyboard-layouts

I've finished soldering my keyboard and the Teensy board seems to have survived the ordeal, now trying to find a gap and the courage to try to load a driver on it and get it to work... (fear of unknown procedures meets fear of failure -> procrastination.) for which I will eventually need an xkb file as well... so maybe should first do some code to do KLA.json -> xkb, for defined keyboard layouts. Should probably start with ANSI ones first since that's easiest to debug.

Cheers, Ian

17
Keyboards and Other Interfaces / Re: Balanced Keyboard Layout
« on: April 04, 2018, 11:58:18 AM »
I have it brought it up in the design of my phonetic script. (http://shenafu.com/smf/index.php?topic=117.msg1661#msg1661.) Such that 'TH' and 'NG' should be their own new single letters. Where TH is common in European languages, and NG is common in Europe, Asia, and Africa.

As for how to implement it on a keyboard. What are some ideas without inventing a new letter? Macros? Autocorrect? Replacement? (e.g. typing z becomes th).

Oddly enough I was thinking along these lines the other day, thinking that we really don't need existing 26 letters in English, eg Q or X sounds can be made with other letters.
On the other hand we could do with more vowels, so we can get away from that silly "magic e" that turns rat into rate and not into note etc.

FWIW if you're gonna substitute th with something for phonetic reasons you'll need two characters... for hard and soft th.

But don't get me started on redesigning English spelling... whole different ball game, where smarter people than me have tried and failed (so far).

18
Keyboards and Other Interfaces / Re: Balanced Keyboard Layout
« on: April 02, 2018, 01:07:29 AM »
I ordered an X-Bows keyboard plus numpad which is due in May. Here's an idea for the key mappings based on BEAKL 15.

Oh very nice mockup indeed .... :-)

19
Keyboards and Other Interfaces / Re: Balanced Keyboard Layout
« on: March 31, 2018, 01:52:45 AM »
the analyzer is problematic for code and puncs test when it comes to repeating symbols. for instance, something like long string of ********** would account for a lot of same finger and hand penalties. but in reality, you just hold down the button, so it should be effortless really. however, if that finger was a weaker finger, it could accumulate substantial penalties.

Not to mention copy-and-paste... :-)

On the other hand, all layouts are penalised in same way.

Back in my youth it was common (especially in that abomination COBOL) for programmers to make pretty blocks around section headings, comments, etc

###########################################
# Main Section - Program Control          #
###########################################


But Linus threw a hissy fit about that once...

https://lkml.org/lkml/2016/7/8/625


20
Keyboards and Other Interfaces / Re: Balanced Keyboard Layout
« on: March 22, 2018, 04:36:47 AM »
Study says more like left/right hand = 0.8887, or about 47/53. Compare finger usage of BEAKL9 is 38.7/43 = 0.9.

Index is slightly stronger and agile than middle. So we give both a high share of keys pressed. But index is also shorter, so needs more effort to reach distant keys. So distant penalty for index is higher.

ETA for Den4 ? :-)

If imminent then no point in me testing everything with Den3 ....

Thanks, Ian

21
Keyboards and Other Interfaces / Re: Balanced Keyboard Layout
« on: March 22, 2018, 02:01:40 AM »
I managed to put together a basic ISO Beakl 15 version with MS Keyboard Layout Creator 1.4 (attached if anyone is interested). Unfortunately there doesn't seem to be a way to create a numlock layer with it,

Thanks for the sample, noted the issue re numlock.
I think the advanced things keyboard hackers do are not going to be supported by MS anytime soon (please correct me if I'm wrong :-) )

Regret my current setup re new layouts is still very messy ... If I add it to the database and "everything else" (ie all the tests etc) are not done then things may break.
And doing the KLA tests takes a while, basically at the moment I test all layouts on each preset, which generates a file (copied from browser console), and then have loader program which reads in each file and processes it.

I suppose I need a "one layout, all tests" process (as opposed to "one test, all layouts") but at the moment the console log won't tell them apart, especially in KLA original and Den1. I think Den3 writes some sample text from preset which could enable auto processing of the log file.

So typing training inputs for Beakl15 will be there eventually, just not now. Sorry.

Cheers, Ian

22
Keyboards and Other Interfaces / KLE renders
« on: March 21, 2018, 02:40:11 PM »
BTW http://kle-render.herokuapp.com/ has been updated, should be able to handle full width of your matrix layouts now. Also other changes.

I'll need to modify my program that generates KLE from KLA to make matrix full width. At present I skip a bunch of keys in the middle.

Sample render attached.

23
Keyboards and Other Interfaces / Re: Balanced Keyboard Layout
« on: March 21, 2018, 02:20:53 PM »
Study says more like left/right hand = 0.8887, or about 47/53. Compare finger usage of BEAKL9 is 38.7/43 = 0.9.

Index is slightly stronger and agile than middle. So we give both a high share of keys pressed. But index is also shorter, so needs more effort to reach distant keys. So distant penalty for index is higher.

Curious how extra line appeared as I quoted. :-)

We've actually got a lot of layouts that are in the 45/55 percentage balance range.

Re index and reach, it's one of the reasons why I think key to "inside" of index should be part of Home Block/whatever ... it is easy to reach . I think H from J is easier than M from J, on ANSI QWERTY. Going to M requires an awkward hand shift.

I saw some research the other night that concluded that the left hand index is stronger for gripping than right hand index. (IIRC... was something like that.) Found that rather odd.
Really struggling to find research that measures relative finger strength for pushing buttons ... they're all focused on "pinch" and different hand grips etc.
Would also like relative flexibility, and endurance... I basically search these things on my phone when I go to bed... tires me out :-)

24
Keyboards and Other Interfaces / Re: Balanced Keyboard Layout
« on: March 21, 2018, 03:38:57 AM »
Left is weaker and slower. Wants to stay in place. So more penalty for distance. Can't handle too many letters. Finger usage should be less, and higher penalty for same finger.

so that puts us back with vowels and punc on left .... been there, done that :-)

or do you want to overload right with etanoisrh ? :-)... put zxkqj etc on left?

Feels like you are saying hand balance should not be 50/50 ...

25
Keyboards and Other Interfaces / Re: Balanced Keyboard Layout
« on: March 20, 2018, 03:52:40 AM »
Uploaded BEAKL 11 to 15 on KLA test and 3, under BEAKL section when selecting layout.

Thanks. Still need to run Den3 with previous collection, will add these and BEAKL MU to next batch.

Staring at .klc and PKL ... will see if can get at least ANSI layouts to work. Will need to find samples of other form factors.

Cheers, Ian

26
Keyboards and Other Interfaces / Re: Balanced Keyboard Layout
« on: March 20, 2018, 02:12:39 AM »
Hi there. I want to try and learn Beakl. Do you have any quick pointers on how to use it in Windows?

Windows uses some sort of keymap file, yes? Mmm .klc files?

I should generate those for the layouts... will see what I can do. Also xkb files....

Cheers, Ian

27
Keyboards and Other Interfaces / Re: Balanced Keyboard Layout
« on: March 20, 2018, 02:08:28 AM »
The downside of concave wells is not as effective for less-fingers typing (e.g. 6-finger style), versus flat keyboards. Thus concave keyboards fitted for 10-finger typing limit freedom of motions. ( and limits even creative optimizations of bigrams.

Yeah, on the one hand I see the design rationale for concave well, on the other I know they ain't gonna work for my non-standard hands.
Also I'm sure there are issues between big hands and smaller hands.

You got KLA json for latest version please?

Thanks, Ian

28
Keyboards and Other Interfaces / Re: Balanced Keyboard Layout
« on: March 18, 2018, 07:40:08 AM »
Browsing around the book.

Attached.

29
Keyboards and Other Interfaces / Re: Balanced Keyboard Layout
« on: March 18, 2018, 06:27:41 AM »
Attached page from Barnes' book.

Browsing around the book.

Has a guideline (these things are aimed at efficiency on production line etc, but some things still relevant somewhat to keyboard analysis):

"Smooth continuous motions of the hands are preferable to zigzag motions or straight-line motions involving sudden and sharp changes in direction" ...

which kinda sums up the problem with typing ... we're continuously changing direction.

So how do we arrange keys to be in circular motion rather than zig-zag....

Suppose this ties in with inward and outward rolls to a degree.

Modelling typing can get very tricky :-) ... suppose that's why Patrick took a simplified model.


30
Keyboards and Other Interfaces / Re: Finger strengths
« on: March 18, 2018, 04:57:04 AM »
4. time to fatigue. Perhaps some fingers can work longer without tiring than others?

A few months back I was thinking about this in relation to same-finger usage... and wondering about modelling it.

A finger (well, the muscles in the hand and forearm that work it) will eventually get tired after repetitive action.

And will recover after some rest.

Question is, is this actually a factor in real-world typing? Probably most people don't type continuously these days, unlike secretaries/data-capture people in times gone by.

We could pick some number (x) and say that for every keystroke typed continuously by same finger, finger loses 'x %' energy. And for every keystroke where finger is resting, it gains 'y %' energy.
x may or may not be equal to y. I suspect y < x.

My thinking was along the lines of say we use pinky twice in a row (ie loses 2x %), then it rests for 1 key (recovers y%), then gets used again twice in a row, etc.
Do this for all fingers, probably with different x and y for each finger.

These numbers then directly impact "effort" calculations... tired fingers need more effort to do same job.

Yes I know this is probably overkill :-)

Just putting it out there in case it gets someone else thinking...


31
Keyboards and Other Interfaces / Re: Balanced Keyboard Layout
« on: March 17, 2018, 04:59:55 AM »
Finger typing and arm typing certainly employ different dynamics. Yet there could be similarities for the sake of measurement. So we must reason which metrics are important for either typing style, and how these metrics are same or different.

Attached page from Barnes' book. I found it very interesting that operator A2 was able to move the object 8 and 16 inches in effectively the same time... and even faster for the longer distance.
Comparing those numbers to his 24 inch time, and to both operators' "loaded" time, I'm guessing two things:

1. difference in body type, A2 was more slightly built and used forearm+wrist for 8 and 16 inches, but had to use shoulder as well for 24 inches. A1 was heavier-built, less flexibility, and had to use shoulder for 16 and 24 inches.

2. adding weight involved the shoulder and thus slowed the times down.

But given that a typical keyboard alpha area width is less than 16 inches, in theory there is hardly any time difference between moving 2 keys or 4 keys, for some people at least. Think the issue is not so much the "moving" as stopping in the right place.

32
Keyboards and Other Interfaces / Re: Finger strengths
« on: March 17, 2018, 12:52:43 AM »
On the other hand, and the reason why I want to touch type, I keep doing the bobbing head thing from kbd to screen .. not good for neck and shoulders,not good at all.

I think we need to introduce some new terminology... as I understand it, "Touch Type" has two components:

1. each key is assigned to a particular finger. Thou Shalt Use No Other Finger.

2. the keyboard map is integrated into your head-hand continuum. So you should not need to look at the keyboard because you "know" where the key is.

Now I'm reasonably good at (2), even when I hit the wrong key, I hit backspace and try again (sometimes 2 or 3 times) but rarely need to look at the keyboard, I just know I was a key or so off to the left or right, and try again...)

But there is no way I comply with (1). So am I "touch typing" or not?  (*)

At this point I don't really have better terms. Perhaps (2) could be "blind typing" or somesuch, and (1) could be something referencing "correct fingers".

Cheers, Ian

(*) The other day my therapist asked if I was "touch typing" (ie yet/again) and how my speed was (after the whole smash-my-left-arm incident). I didn't know how to answer because I don't consider my typing to be "touch typing"....

33
Keyboards and Other Interfaces / Re: Finger strengths
« on: March 16, 2018, 02:20:10 PM »

marked degree. Barnes (/) reviews evidence


Available at archive.org. 173MB PDF.

https://archive.org/details/in.ernet.dli.2015.275373

It's a textbook on Time and Motion studies... 3rd edition. Scanned so text not searchable :-((

Found attached, possibly text changed between 1st and 3rd editions.

FWIW, the other day I was thinking back to my days playing arcade video games, in particular Asteroids Deluxe, which had five buttons. You steered with your left hand (2 buttons)(ob reminder: yes, you can use the mouse with your left hand...), left thumb button for shields, and right hand controlled thrust (forefinger) and fire (middle finger).  The way to fire off a rapid volley was to freeze your right hand and arm then move the whole thing up and down rapidly, rather than trying to just move your middle finger.

34
Keyboards and Other Interfaces / Re: Finger strengths
« on: March 16, 2018, 01:20:13 PM »
Been looking for some research/book/whatever that actually looks at how strong each finger is.

Came across this in attached PDF, freely available on web.


Ballistic movements are rapid motions,
usually repetitive, in which active muscular
contractions begin the movement, giving mo-
mentum to the member, but cease or diminish
their activity throughout the latter part of the
motion. It is unlikely that, of themselves, the
fingers utilize this type of motion to any
marked degree. Barnes (/) reviews evidence
that in repetitive work finger motions are
more fatiguing, less accurate, and slower than
are motions of the forearm. Consequently, in
repetitive finger activities in which there is a
ballistic element, such as piano-playing, typing,
and operating a telegraph key, wrist and elbow
motions predominate while the fingers merely
position themselves to strike the proper key.


Which I suppose ties in with previous observations that people who type with 2 or 4 or 6 fingers can be just as fast as touch typists... because in this case they're relying on the strong muscles of the arms to do the heavy lifting rather than stretching and contracting their fingers to get to all the required keys...

All of which has major implications for the modelling we are doing in KLA.....

Nevertheless, regarding 'strength of fingers' .... was thinking that there are maybe three or four factors to consider...

1. actual strength, in particular, for pressing, while keeping rest of fingers reasonable still, as well as whether pressing almost vertically or at assorted different angles.

2. flexibility of each finger to move in different directions

3. speed of finger in doing such movements... we can not assume all fingers are equally fast, can we?

4. time to fatigue. Perhaps some fingers can work longer without tiring than others?

Also related to the "average finger strength" table I posted above... I think these were measured by measuring "pinching" force, which would mean that the thumb was pressing with the "pad" / finger-print part, rather than the edge as is common in typing. Which could invalidate my calculations, unless we can determine that the thumb is more or less equally strong pressing with edge as with pad.

I have actually modified my programs that used relative strength of fingers in evaluating layouts based on bigrams, trigrams, quadgrams and common words typeable on the home keys, just want to double check them again before uploading the results. On the one hand the results look better than what I got with previous rather arbitrary linear assignment of finger strengths ... now, layouts that can type all the required letters on home keys score higher, whereas previously layouts missing some letters came first. I hope this is a consequence of the weighting and not a logic bug. :)
As expected the split-case layouts come out on top, and the QWERTY/alphabeticals at the bottom.

The new results affect the Best Layout Overall results as well.

Cheers, Ian

35
Keyboards and Other Interfaces / Re: Balanced Keyboard Layout
« on: March 14, 2018, 07:11:03 AM »
I was using Alice (1st in the last hehe) on Den v2, followed the link on your site's Tools page.
Is the 1st entry in the list, "Den's fork", den3?
http://shenafu.com/code/keyboard/Keyboard%20Layout%20Analyzer.html#/main  is Den1

Den 3 is here:
http://shenafu.com/code/keyboard/klatest/#/main

Will update my site to be more accurate.
"My fork" is mirror of Den1 with some cosmetic changes.



36
Keyboards and Other Interfaces / Re: Balanced Keyboard Layout
« on: March 13, 2018, 11:07:55 PM »
BEAKL5 seems to do better than 9 in both Ian's and Den's kla?

either I made a mistake entering 9, I am using the wrong kla versions .. or am just plain confused haha

I'm just mirroring Den1 ... presume you were comparing this to Den3.

Results depend a lot on your input text.... what were you using?

Cheers, Ian

37
Keyboards and Other Interfaces / Re: Balanced Keyboard Layout
« on: March 13, 2018, 11:06:07 PM »
is the beakl9 kla json file available somewhere ?

https://www.keyboard-design.com/letterlayout.html?layout=beakl-9.en.matrix

You can find others here  (use the "Search" to filter the list)

https://www.keyboard-design.com/letterlayout.html

Cheers, Ian

38
Keyboards and Other Interfaces / finger strengths
« on: March 11, 2018, 07:27:03 AM »
Revised numbers, from the original paper.

Interesting that middle finger comes out half as weak as thumb... maybe giving someone the finger is only half as good as a thumbs up... :-)

Guess I need to redo some of my non-KLA tests/calculations using these numbers instead of my previous "simplified" ratios of 1 - 5, thumb = 5, pinky = 1.

Cheers, Ian

39
Keyboards and Other Interfaces / Finger strengths
« on: March 11, 2018, 06:47:41 AM »
Been looking for some research/book/whatever that actually looks at how strong each finger is.

Finally found attached table which is from attached PDF, available to freely download on web.

Can't find anything that measures finger strength pushing a key, but even that is tricky to measure if you want the isolated finger action while rest of hand is held relatively still.

I guess these numbers are heavily based on "pinch strength" which I suppose is a reasonable proxy for "pushing a key" ... the relative strengths between fingers should be similar for the two tests.

So now .... do we use these ratios to recalibrate the scoring algorithms?....

Something like

fingerleftrightaverageeffort
thumb109108108.51.00
index605758.51.85
middle545554.51.99
ring373837.52.89
pinky283129.53.68

Discuss :-)

40
Keyboards and Other Interfaces / Give me independence or give me death
« on: March 10, 2018, 01:31:31 PM »
Looks like our fingers are not really capable of moving independently of the others.

http://www.jneurosci.org/content/20/22/8542   (can export to PDF as well, if you like)

I have no opinion yet as to whether this is relevant to our modelling efforts or not.
Yes, the math(s) is a bit above Pythagoras.

41
Keyboards and Other Interfaces / Assorted thoughts
« on: March 10, 2018, 10:21:43 AM »
Hi all

Various things running around in my head, thought I should write them down for future reference... mainly to do with KLA and the modelling process.

In no particular order...

1. At the moment AFAICT we calculate the effort or work required to type as a function of distance moved and finger used. If I remember correctly we have
  a. Patrick: linear distance between keys, calculated by Pythagoras
  b. Den1 : as for Patrick, plus 4mm down and 4mm up for each key press
  c. Den3: Distance between keys doubles x-distance, also 4mm up and down, and different weightings for the fingers, where pinky is punished. Can't remember if distance is sqrroot( (2x)^2 + y^2) or sqrroot( 2(x^2) + y^2).

Den3 calcs have bothered me for a long time, and in recent days think I have come to realise why. I understand it wants to punish horizontal movement, but I really think that it is actually easier for Index finger to move one key to left or right, than to go up one row. Going down may be easiest of all.
The situation with the pinky may be the same. Regret due to personal bad pinkies I am not qualified to offer opinion on this, but both index and pinky are blessed with sideways movement facility, and I'm not sure if it's fair to punish them for that.

Contrawise, the two middle fingers are not designed to move sideways when curled over the keyboard, and thus I agree sideways movement, as in ANSI layout, should be punished.

2. Fingers have a limited range of movement. For some keys, you need to move your hands as well. This 'extra effort' is not included in calculations.

3. Related to (2), how accurate are our finger maps? Do people really use pinky to hit backspace or \| or ~ on QWERTY? Or do they make like me and use ring finger? If so, then we need to redo the finger maps to match reality and not some ivory tower touch typing ideal scenario. All of which is going to invalidate all the current scores.

4. Since people have different size hands (eg http://www.smallpianokeyboards.org/hand-span-data.html ) and we can't pick some magical 'average' (well maybe we can)), I was wondering if we could "allow" for the issue in (2) by changing the distance calculation somewhat, by loading the distance.
eg instead of say sqrroot( x^2 + y^2) we just use  x^2 + y^2 so that larger distances (implying having to move hand as well) are punished. The downside of this is that vertical motion is not adjusted accordingly... maybe we need to do 2(z^2) instead of just 2z.

5. At the moment (as in (1)) we assume the effort required to press a key is always the same. However I contend that pressing basically straight down on the home row requires less effort than in a situation that I use a lot, which is ctrl-insert on ANSI. In this scenario my hand is flat, thumb on Ctrl and middle finger extended straight out to Insert, and then press down. The muscle motions (and stresses on the joints) are very different to pressing K on QWERTY home row. I don't think the current "distance and which finger" models take this sort of action into account.

Okay enough for now :)

42
Keyboards and Other Interfaces / Re: Balanced Keyboard Layout
« on: March 06, 2018, 10:58:40 AM »
For the MS Natural, I guess the one I have, the MS Sculpt Ergo is kind of the replacement for it.

Everything after version one was a step downhill, in my humble opinion... I've owned most of them (not the Sculpt, but have examined it in store). Still have 2 model 4000s, one in use.

I'm still using mine (MS Natural original). Smashing my wrist got in the way of many projects, but I have put the new keyboard on the dining room table, along with the tools and soldering iron. Still busy adding the wires to the Teensy, then need to connect Teensy to keyboard and see if any thing actually works... then it's the whole Program The Teensy step that's looming like a monster over me....

43
Keyboards and Other Interfaces / Re: Balanced Keyboard Layout
« on: March 06, 2018, 10:41:34 AM »
I have been looking again at the reviews at xahlee.info and thought maybe the SmartYao could be an interesting compromise.
(sold as Koolertron on Amazon)
Physical keys (Cherry Mx or Gateron), split kbd, not staggered, some thumb keys, programmable and not as expensive as other better known alternatives.

Odd.. the pic on Xah's site has non-staggered keys, but the one on Amazon is staggered ...

Was going to suggest you look at MS Natural original but can't find it online now (only 2nd hand), I thought they were still being manufactured. Will be cheaper than more modern designs.

Else build your own ... do it slowly and spread the costs over months. It will work out more expensive, but then you get exactly what you want.. :-)



44
Keyboards and Other Interfaces / Re: not good
« on: February 22, 2018, 01:15:12 AM »
smashed my left wrist. back on ansi keyboard and mouse on right hand and mostly one handed typing for now. At least it has mech switches (gateron red I think)

We are the Borg. You will be assimilated. Resistance is futile.

Had another quick op to remove the wire. Surgeon was not very encouraging about regaining full use of left wrist, physiotherapist was more hopeful. Will have to see how it goes. Still on ANSI keyboard and mouse on right hand, can type a little bit with left hand.

45
Keyboards and Other Interfaces / Re: Balanced Keyboard Layout
« on: February 02, 2018, 09:49:10 PM »
On a final note, I found it very intriguing that BEAKL 9 seemed to score comparatively poorly against other popular layouts in distance using the Keyboard Layout Analyzer. At first it put me off, but then I considered that if the fingers were moving up and down more then they might actually be less prone to fatigue (and indeed the same finger scores for BEAKL 9 were very good, especially for pinky), so what are your thoughts on distance as a metric of layout quality?

Which version of KLA? Patrick's original?

Cheers, Ian

46
Arts, Literature, and Crafts / Re: [lang] Flownetic: The Phonetic Script
« on: February 01, 2018, 10:53:42 PM »
is left column supposed to be empty as this stage?

47
Keyboards and Other Interfaces / different approach to one-hand keyboard
« on: January 22, 2018, 11:56:57 AM »
was doing some research on one-handedness, found stats:

http://www.aboutonehandtyping.com/statistics.html

But wait! there's more!

Their 'solution' is to use kiddie-size keyboards:
http://www.aboutonehandtyping.com/multimediaminikeyboard.html

which seem seriously overpriced, compared to, for example
https://www.amazon.com/Keyboard-Portable-Professional-Industrial-Computer/dp/B071ZZ5G5Q/

or from China for half that....
https://www.aliexpress.com/item/MCSAITE-8017-78-Key-Portable-Mute-Ultra-thin-USB-Wired-Computer-Keyboard-for-Office-Desktop-Notebook/32846014011.html

I shall refrain from further comment :-)

48
Keyboards and Other Interfaces / Re: Thoughts on Gigabyte K83 keyboard
« on: January 22, 2018, 11:44:42 AM »

3. Spacing... the numpad is too close to the nav keys, my fingers can't fit in the gap, and I end up typing numbers  (given (1) above) when I don't mean to. For this issue alone, I'd suggest you look at other options.


after staring at a few other keyboards lying around, realised the problem is actually a combination of narrow gap PLUS their island-style design.... other boards have a raised surface which is high enough to rest your fingers on without triggering keys.

49
Keyboards and Other Interfaces / Thoughts on Gigabyte K83 keyboard
« on: January 21, 2018, 03:28:42 PM »
When I got involved with layout design I thought it would be good to have a spare keyboard to test new layouts on, so I bought a low-end Microsoft keyboard.

Then discovered two problems with swapping keycaps around:

1. Profile... different row, different shape... (in truth I should have seen that one coming...)

2. F and J have different stem alignment... don't fit nicely in other places.  Or other keys in their spots. Guess this is an assembly aid.

So I was annoyed and splashed out on a low-end mech keyboard instead... Gigabyte K83, with Cherry Red switches (wanted to see how reds were, since I had bought browns for the keyboard I'm building, and not going to use blues....)

Observations:

1. Reds are quite sensitive. See (3) below.

2. Switches bottom out quite hard.... maybe this is a function of me banging my MS Natural for 20 years and I need to develop a lighter tough. I have now installed black rubber ring bumpers (from Massdrop) on Ins and Del, since using them for copy-paste was hurting my middle finger a lot. The bumpers seem to help quite a bit.

3. Spacing... the numpad is too close to the nav keys, my fingers can't fit in the gap, and I end up typing numbers  (given (1) above) when I don't mean to. For this issue alone, I'd suggest you look at other options.

Cheers, Ian

50
Keyboards and Other Interfaces / Re: I only use one hand...
« on: January 19, 2018, 02:39:06 PM »
Try the CLP model.

Yeah, came to same conclusion, but with a twist.. no upper case slots needed.

Just another toggle on thumb for CAPS.

So that helps reduce the key count considerably.

Get a mouse with many buttons. Assign them meta and editing actions that replaces any ctrl- stuff. copy, paste, select all, save, back, etc.

Am considering it. Problem is my usual online stores take a week or two to deliver (no next-day Amazon-style here AFAIK)
This cast is supposed to come off on 30th and be replaced with modern design and at that point they'll probably want me using my fingers as much as possible (to ensure tendons etc don't get too attached to the steel plates). So may end up NEEDING fancy mouse for only few days. Am going back to my trackball :-)

Speaking of mouse, using one on my right hand again is damaging indicated spot on attached, Years ago when I used mouse I put blanket on table then covered it with sheet, and that was my desk/mousepad. Suppose that protected my hand. Sheet gave nice solid colour for mouse laser to measure on, blanket provided padding.


Pages: [1] 2 3 4 ... 17