If the layout has two space bars, the analyzer only uses one. This results in incorrect loading on one thumb.

Hi Patrick

A question about your pixels per cm for the different layouts:

KB.keyMap.standard.s683_225.pixelsPerCm = 26.315789;
KB.keyMap.european.s683_225.pixelsPerCm = 26.315789;
KB.keyMap.ergodox.s683_225.pixelsPerCm = 25.7894732;//26.315789;

Why is the ergodox one different?

While I have your attention, what does s683_225 mean? It's been puzzling us :-)

Thanks, Ian

Hi Patrick

When above layout is in mix, then tables on analysis pages don't show.

Guess there is something confusing in the layout.

Thanks, Ian

Hi, I am examining the scoring system in the analyzer, and noticed this part where it calculates scores based on finger usage:

    fScoring[KB.finger.LEFT_PINKY] =    0.5;
    fScoring[KB.finger.LEFT_RING] =     1.0;
    fScoring[KB.finger.LEFT_MIDDLE] =   4.0;
    fScoring[KB.finger.LEFT_INDEX] =    2.0;
    fScoring[KB.finger.LEFT_THUMB] =    0.5;
    fScoring[KB.finger.RIGHT_THUMB] =   0.5;
    fScoring[KB.finger.RIGHT_INDEX] =   2.0;
    fScoring[KB.finger.RIGHT_MIDDLE] =  4.0;
    fScoring[KB.finger.RIGHT_RING] =    1.0;
    fScoring[KB.finger.RIGHT_PINKY] =   0.5;

The total score for this element is then: (fScoring) x (finger-frequency¹)

(¹ subject to a max frequency of 20%)

I interpret this as a theoretical ideal keyboard would have 20% on each on each middle finger, 10% on each index finger, 5% on each ring finger, 2.5% on each pinky and thumb. Obviously that only adds up to 80%, making an ideal layout impossible, and I guess forcing the layout designer to make compromises.

So, my queries:

• I would have expected the index-finger scoring to be much higher, is it a bug, or is there some reasoning that it is scored at only half that of the middle finger?

• I'm also a bit puzzled by the scoring for the thumbs (although I guess it's not that relevant on typical layouts), as the thumbs are obviously easier to type with than pinkies.

Any clarification you could give would be great!

Hi

in main.js and analyzer.js you have
KLA.results.fingerScores[ii] = total / 260; // 220 is max possible score
results.fingerScores[ii] = total / 260; // 220 is max possible score

Is there a typo there or are both 260 and 220 correct?

On a related note, if for example I get a final score of 70, does that mean the layout is 70% of optimal?

thanks, Ian

Hi Patrick

I've got a ton of other layouts in KLA format if you're interested.

Also other form factors (Matrix and ErgoLinear).

Cheers, Ian

Hi

The user-submitted Ina layout on your site has two N keys, and no -_ key. Not sure if the letters next to first N should shift left to add the missing key to the end of the row ...

Thanks.

Hi Patrick

A question about AltGr.
See http://patorjk.com/keyboard-layout-analyzer/#/load/dxSJmR0v

The only difference between the two QWERTY layouts is that I moved the "e" from its normal position to the AltGr slot on the same key, and put the right thumb on AltGr.

That kicked the score up 6 points.

Is that how your scoring algorithm is supposed to work?

Thanks, Ian

Hi

Are you able to see the high scores for the three tests?

Thanks, Ian

Hi Patrick

If you're going to be spending time on this again, there is something you should look at.

Your scoring model favours layouts which use the AltGr combinations. This is because the right thumb typically sits on the AltGr key, thus does not move sideways much, but does go up and down a lot. However your scoring only counts lateral movement, not vertical.

In Den's first fork, he added counting vertical distance moved. We picked 4mm vertical distance since that is more or less typical for mechanical keyboards. So each key press adds 8mm to the horizontal distance travelled.

This same issue applies to the various Ergo layouts which put a shift key on the left thumb. This doesn't make as drastic a difference as the AltGr but still boosts the score over conventional shift.

Cheers, Ian
Cheers, Ian

Hi Patrick

Trying to understand something ... for your Ergodox layouts, you have

KB.keyMap.ergodox.s683_225.pixelsPerCm = 25.7894732;//26.315789;
(function() {
var ii,
km = KB.keyMap.ergodox.s683_225,
normKeySize = 50,

All the other formats use 26.315789, so that 50 pixels = 1.9cm, the standard spacing between keys.

I'm not aware that Ergodox use a different size key.

Can you maybe remember why you changed it?

I'm trying to debug some issues with KLA, if for example on Colemak thumbshift on Ergodox, your input is the single letter "h", then the distance moved is coming back as 3.7, when it should actually be more than 3.8 (1.9 * 2) because the finger has to move vertically as well ...

This might be one aspect to Ergodox layouts scoring better ...

I tried using 26.315789 plus results to 2 decimals, it still says 3.66 which I suppose is rounded to 3.7. But this undercount will directly affect the scores.

I can't see anything that looks wrong in how the keyboard is set up, but clearly there must be ...

Thanks, Ian

Hi Patrick

The Balance Twelve layout is missing the right brace, presumably on the 8 key.

The underscore currently on the 8 should probably replace the Unicode character on the =.

Thanks, Ian

hi Patrick

The Anglian layout is missing colon and semicolon. Looks like the layout wants to be a variant of ISO British, but needs an extra key to do that. It's got £ and "Not" as chars instead.

I suppose the solution would be to migrate it to the European section onto an ISO layout. Let me try that.

bower install

bower invalid-meta for:/var/www/html/site/kb/bower.json
bower invalid-meta The "name" is recommended to be lowercase, can contain digits, dots, dashes
bower bootstrap#* not-cached http://twitter.github.com/bootstrap/assets/bootstrap.zip#*
bower bootstrap#* resolve http://twitter.github.com/bootstrap/assets/bootstrap.zip#*
bower bootstrap#* download http://twitter.github.com/bootstrap/assets/bootstrap.zip
bower jquery#* cached https://github.com/jquery/jquery-dist.git#3.6.0
bower jquery#* validate 3.6.0 against https://github.com/jquery/jquery-dist.git#*
bower bootstrap#* EHTTP Status code of 404

Any ideas?

Hi

Just wondering how your program handles characters not on the keyboard ... for example I tested a layout with perl and PHP code, but the keyboard layout I set up didn't have any brackets (or even < and > ) and it got the high score. Was this because you simply assigned a zero to the missing keys?

FWIW my layout only managed to beat AZERTY on your inputs, but not the rest....

(Can't load the brackets because keyboard physical layout is non-standard).

Thanks, Ian

@patorjk I was looking at your code to try and see how you were computing distance for the distance one's fingers travel when they type a text. You display distance when you provide analysis results in your Keyboard Layout Analysis javascript app like here: http://patorjk.com/keyboard-layout-analyzer/#/results

I found some distance computation here

function distanceBetweenKeys(keyMap, keyIndex1, keyIndex2) {
        var xDiff = keyMap[keyIndex1].cx - keyMap[keyIndex2].cx,
            yDiff = keyMap[keyIndex1].cy - keyMap[keyIndex2].cy;
        return Math.sqrt(xDiff*xDiff + yDiff*yDiff);

However, it seems to me that real numbers are needed somehow. Where are the real numbers? do you have an x,y coordinate table somewhere?

I looked in the layouts folder at a layout and it does not seem to have an x,y coordinate in the syntax. Can you point me to what I am missing?

Hi Patrick

I see you're checking things... I think the heat map is broken due to upstream .js file missing.

Cheers, Ian