shenafu.com

Creativity => Hacks => Keyboards and Other Interfaces => Topic started by: Den on 2011-Mar-08 18:26

Title: Balanced Keyboard Layout
Post by: Den on 2011-Mar-08 18:26
Goals and Philosophy for Keyboard Layout Design:

My goals and philosophy in key arrangements and layout are hereby defined:

(The above image is hereby put into public domain.)

Newer thoughts

Learn about my highly recommended layouts (http://shenafu.com/smf/index.php?topic=89.msg850#msg850) based on new effort theory (http://shenafu.com/smf/index.php?topic=89.msg785#msg785)

Read my older stuff (http://www.shenafu.com/layout.php)

1st layout Comparison Results and Analysis (http://shenafu.com/smf/index.php?topic=89.msg312#msg312)
2nd layout Comparison Results and Analysis (http://shenafu.com/smf/index.php?topic=89.msg314#msg314)
3rd layout Comparison Results and Analysis (http://shenafu.com/smf/index.php?topic=89.msg497#msg497)

Old effort chart similar to Workman:
(http://www.shenafu.com/code/keyboard/keyboard_effort_grid OLD.png)
Title: 1st Balanced Layout
Post by: Den on 2011-Mar-09 13:26
After several dozen iterative attempts and tweaking, my initial layout--which I proclaim the Balanced layout--is shown below.

(http://www.shenafu.com/code/keyboard/balanced.png)

The main 30 keys are arranged like so:

Code: [Select]
UNSHIFTED
jfubz xwlcq
saenp mtoir
v,yh' kdg."

SHIFTED
JFUBZ XWLCQ
SAENP MTOIR
V(YH; KDG):

Try it out and compare it to other popular layouts at this Keyboard Comparison Tool (http://andong.azurewebsites.net/dvorak/)

Code: [Select]
`1234567890[]
#jfubzxwlcq/=\
#saenpmtoir-*N
*Lv,yh'kdg."*R
##*S#
*L
#######&**<>{}
######XWLCQ?+|
######MTOIR_
######KDG):
#
*R
~!@*#$%^
#JFUBZ
#SAENP
#V(YH;
#

Results and Analysis:

Here we analyze the results from the comparison tool. My layout is the bottom one called Balanced. First compare prose text and then source code.

PROSE

The selected text is from the first three chapters of The Old Curiosity Shop by Charles Dickens.

Overall Effort and Balance
(http://www.shenafu.com/code/keyboard/balanced1.png)

Overall effort is right behind Colemak and Workman. On the other hand, effort imbalance score surpasses even Workman by a few percentages. Notice Colemak is very unbalanced, while Dvorak is the least balanced.

Effort for each finger
(http://www.shenafu.com/code/keyboard/balanced2.png)

The goal for this test is to see whether the load is shared amongst each finger and each hand. As the title in the chart says, these should be around 11-12% for each finger. Dvorak and Colemak has only around 5-7% for the strong left middle finger; while right ring and pinky is used a hefty 10-20% of the time. Also, these two layout heavily rely on the right hand: 50% right hand and 40% left hand. Workman does a lot better by shifting the weight of the right ring finger onto the left middle finger; however, right pinky is still overused. Fortunately, both hands do about equal amounts of work. With the Balanced layout, some load from the right ring and pinky finger is distributed to the left ring and middle fingers. Thus, the difference between left and right hand is only about 4%, compared to the 9% to 13% in Colemak and Dvorak layouts, respectively.

Keys for each finger
(http://www.shenafu.com/code/keyboard/balanced3.png)

Results from this chart is similar to the last. Dvorak and Colemak has very uneven distribution for the strong versus the weak fingers. On the other hand, Workman and Balanced is closer to the ideal curve for each finger. That is, the index and middle fingers do most of the work, while the ring and pinky fingers do much less. Moreover, the balance between both hands for these two layouts are more reasonable compared to Dvorak and Colemak.

One oddity in the bottom table is that Balanced layout actually has higher percentage in the bottom row compared to the top row. As I explained at the beginning, and by looking at the difficulty diagram, not all top keys are equal in effort and value. Not only that, some bottom keys are much easier to access than some top keys.

Finger travel
(http://www.shenafu.com/code/keyboard/balanced4.png)

The results in this chart is different from the previous ones. Colemak and Workman have the least distance, Balanced is somewhat higher, and Dvorak even higher. However, if you compare the left and right hands, Balanced lives up to its name. The distance for each hand is very close in value, thus both hands are balanced and do equal amounts of work. Colemak has a difference of about 5%, Workman 10%, and Dvorak almost 30%.

Metrics
(http://www.shenafu.com/code/keyboard/balanced5.png)

Here are several metrics and penalties--some of which I don't necessarily agree with or worry too much about. Nonetheless, Balanced values are comparable to Colemak and Workman.

One thing worth mentioning is row jumping. It is almost mantra among keyboard enthusiasts that the top row is preferable to the bottom row, and that placing less frequent keys on the bottom row will avoid row jumping. Yet the chart shown here clearly busts this myth. On the Balanced layout, two of the most common letters H and D are intentionally placed on the bottom row. One would expect that row jumping would thus be a big problem for Balanced. However, this is not the case. Row jumping on the Balanced layout happens a mere 0.3% more often than Dvorak and Colemak. If you type 1000 characters, row jumping happens 12 times instead of 9.

Pairs of consecutive keys typed with the same finger
(http://www.shenafu.com/code/keyboard/balanced6.png)

A slight mark against Balanced is that it has three such pairs of letter-letter combinations typed with the same finger above 0.20%. Dvorak has one (GH), Colemak has none (its worst offender is E, that is E-comma), Workman has LY (and also E-comma, not surprising since it's based on Colemak). On the bright side, Balanced worst offender OL / LO is typed by the strong middle finger. Then again, 0.51% is really minuscule statistic.


CODE

Source code was in C++ from Firaxis' Civilization 4 SDK.

Overall Effort and Balance
(http://www.shenafu.com/code/keyboard/balanced_code1.png)

Balanced layout ranked first and second in either chart. This is by no means definitive since programming languages vary wildly. Nonetheless, Balanced has the advantage of unshifted double quotes and the parentheses are brought down to the bottom row.

Effort for each finger
(http://www.shenafu.com/code/keyboard/balanced_code2.png)

By exchanging the parentheses and angled brackets in Balanced, the consequence is that the efforts for each finger are relatively even compared to the other layouts and the total effort is reduced considerably.

The high pinky usage is most likely due to the extreme reliance on the numerals 1 and 0 and programming symbols such as !, =, etc..

Keys for each finger
(http://www.shenafu.com/code/keyboard/balanced_code3.png)

Once again, the Balanced layout distributes the keys more evenly. Whereas other layouts over-work the index finger, Balanced moves some of that workload to the middle and ring fingers. For balance between each hand, Qwerty scores the best, with Colemak closely behind.

One glaring difference you can see is that number row usage dropped considerably when the parentheses are moved to the bottom row. The opposite would happen when writing XML and HTML where angled brackets are common.

Another peculiarity is that Balanced puts the moderate letters P and M instead of the more common H and D on the home row. Yet, it still has the highest percent of usage on the home row. One guess is that variable names tend to use those letters. Not surprisingly, Qwerty scores way behind in terms of utilizing the home row.

Finger travel
(http://www.shenafu.com/code/keyboard/balanced_code4.png)

In finger travel distance, Balanced placed first by a decent margin; most likely due the movement of the parentheses to the bottom row. Again, each finger has relatively even workload compared to other layouts.

All layouts were quite unbalanced, with the right hand working about 10% harder than the left. This can be attributed to the fact that the opening and closing punctuations--parentheses, square and curly brackets--are placed on the right side of the keyboard. Thus, the right hand will be doing more work when writing source code.

Metrics
(http://www.shenafu.com/code/keyboard/balanced_code5.png)

Not much to say here. There is not much difference between these layouts when it comes to writing source code.

Qwerty also pops up in same hand row jumping--about two to three times as often as the other layouts.

CONCLUSION

Every popular layout has their advantages and drawbacks. Popular layouts such as Dvorak, Colemak, Workman, Maltron, and others--yes even Qwerty--are great layouts based on their design philosophy and constraints, technological era, and user testimonies. However, a few of us fanatics and idealists, such as myself, seek to find a layout that is closer to the ideal (or our own ideal) based on our experiences, goals, philosophy, and metrics. This layout that I propose--the Balanced layout--performs very similarly to the up-and-coming Colemak. However, we cannot rely on algorithms alone to compare layouts--they may measure the incorrect or unnecessary properties and neglect other relevant properties. Human nature and other niceties must also be taken into account. Thus, the Balanced layout strives to implement ergonomic features that some layouts forgo or sacrifice for whatever reasons. These missing features include balancing the workload across each finger and both hands, being visually intuitive by emphasizing vowels, and optimizing the placement of commonly used punctuations.
Title: Re: Balanced Keyboard Layout
Post by: Den on 2011-Mar-09 18:06
Other considerations and tips

Space often follows E and spacebar is hit with the right hand. Thus, E should be on the left hand for quickness.

Trigrams are best typed as 1-2 or 2-1 as alternating hands. i.e. T-HE or TH-E; A-ND or AN-D; I-NG or IN-G

Use a mouse that comes with extra buttons. Assign them to editing functions including cut, paste, space, and backspace. Rather than reaching for the keyboard, editing with the mouse is generally more efficient.

Use Autohotkey to reassign obsolete keys. Turn Insert into Ctrl-V (paste), Delete into Ctrl-C (copy), Shift-Delete into Ctrl-X (cut).

Use Autohotkey to swap keyboard layouts. For instance, run this .ahk file (http://shenafu.com/code/keyboard/dv2balanced.ahk) to turn Dvorak into Balanced. Pause or exit the script at will.

Title: 2nd Balanced Layout
Post by: Den on 2011-Mar-11 03:36
2nd Layout

The main 30 keys are arranged like so:

Code: [Select]
UNSHIFTED
jgupk qflcx
haenr dtois
"byw' vm,.z

SHIFTED
JGUPK QFLCX
HAENR DTOIS
:BYW; VM()Z


AutoHotkey script to convert Qwerty to Balanced (http://shenafu.com/code/keyboard/qw2balanced2.ahk) & AutoHotkey stand-alone executable (http://shenafu.com/code/keyboard/qw2balanced2.ahk.exe)

AutoHotkey script to convert Dvorak to Balanced (http://shenafu.com/code/keyboard/dv2balanced2.ahk) & AutoHotkey stand-alone executable (http://shenafu.com/code/keyboard/dv2balanced2.ahk.exe)


Try it out and compare it to other popular layouts at this Keyboard Comparison Tool (http://www.andong.co.uk/dvorak/Default.aspx)

Code: [Select]
`1234567890[]
#jgupkqflcx/=\
#haenrdtois-*N
*L"byw'vm,.z*R
##*S#
*L
#######&**<>{}
######QFLCX?+|
######DTOIS_
######VM()Z
#
*R
~!@*#$%^
#JGUPK
#HAENR
#:BYW;
#


Results and Analysis:

Here we analyze the results from the comparison tool. My layouts are the bottom ones called Balanced1 and Balanced2. Balanced1 is same as 1st layout, except for three swaps: S-H, V-Z, and Q-X. First compare prose text and then source code.

PROSE

The selected text is from the first three chapters of The Old Curiosity Shop by Charles Dickens.

Overall Effort and Balance
(http://www.shenafu.com/code/keyboard/balanced2_1.png)

Balanced2 has the best overall effort score by a decent amount, and only behind Balanced1 in effort balance.

Effort for each finger
(http://www.shenafu.com/code/keyboard/balanced2_2.png)

The Balanced layouts have a good curve for the three stronger fingers while keeping pinky usage reasonably low. Workman has better curve in the strong fingers, but pinky usage is higher as a result.

Workman and Qwerty has balanced load for both hands; Balanced is slightly worse, but still much better than Dvorak and Colemak in this regard.

Keys for each finger
(http://www.shenafu.com/code/keyboard/balanced2_3.png)

Looking at a glance, one can easily tell that the Balanced layouts have the best curve when distributing workload across each finger. Workman is also good except for the right pinky.

Once again when balancing load between hands, Balanced and Workman come out on top by a wide margin.

One major change from the Balanced1 to Balanced2 is that more common letters are put in the home and top rows and the bottom row is relegated to uncommon letters and punctuation.

Finger travel
(http://www.shenafu.com/code/keyboard/balanced2_4.png)

Balanced2 has the lowest finger travel distance, while Balanced1 has the best balance between hands.

Metrics
(http://www.shenafu.com/code/keyboard/balanced2_5.png)

You gain in some areas and lose in others. Balanced2 sacrifices same finger and same hand percentage, but limit row jumping and reverse order. Notice the amazingly low row jumping at 0.5%.

CODE

Source code was in C++ from Firaxis' Civilization 4 SDK.

Overall Effort and Balance
(http://www.shenafu.com/code/keyboard/balanced2code_1.png)

The Balanced layouts are among the least effort and most balanced.

Effort for each finger
(http://www.shenafu.com/code/keyboard/balanced2code_2.png)

Most effort are done by the pinkies. Nonetheless, Balanced1 requires the least effort and provides the best balance.

Keys for each finger
(http://www.shenafu.com/code/keyboard/balanced2code_3.png)

Both Balanced layouts spread the keys evenly to all fingers and hands. As a result of moving the parentheses to the bottom row, total keys pressed is reduced slightly, but access to numbers row has reduced significantly. Note that the reverse would be true for languages like XML and HTML that rely on angled brackets.

Finger travel
(http://www.shenafu.com/code/keyboard/balanced2code_4.png)

Finger travel distance for both Balanced layouts is lower by a decent amount. Balanced2 has the shortest distance and the best balance.

Metrics
(http://www.shenafu.com/code/keyboard/balanced2code_5.png)

Balanced2 didn't do as well as other layouts on these metrics, but not that much worse. However, when writing code, these types of metrics matter much less. You're not speed typing, and your pinkies are the main workforce who are accessing keys on the fringe of the keyboard. In fact, some same hand usage is by design, especially IF, DO and FOR.

CONCLUSION

As good as Balanced1 was, I was unsatisfied with the position G because typing ING was uncomfortable. Balanced2 tries to rectify that by placing G on the same hand as N. More to the point, Balanced2's goal was to improve the ease and comfort of typing common digram and trigrams and 2- and 3-letter words. That's why Balanced2 may have higher same hand and same finger percentages, but makes it up by reducing row jumping and reverse (outward) rolling.
Title: Re: Balanced Keyboard Layout
Post by: Den on 2013-Sep-21 14:46
3rd Layout

Another attempt at a more balanced layout. This time I moved the punctuation to the top row like Dvorak to facilitate typing numbers, like monetary values and IP addresses. Also, the previous results were skewed by the Enter key being hit by the right pinky. So I removed the Enter key on my layouts to find a truly balanced comparison between the left and right hands.

The main 30 keys for the 3rd Balanced layout are arranged like so:
Code: [Select]
UNSHIFTED
',.cq xyugj
roitf mneas
"wldv khpbz

SHIFTED
:()CQ XYUGJ
ROITF MNEAS
;WLDV KHPBZ

Try it out and compare it to other popular layouts at this Keyboard Comparison Tool (http://www.andong.co.uk/dvorak/Default.aspx)

Code: [Select]
`1234567890-=
#',.cqxyugj[]\
#roitfmneas/
*L"wldvkhpbz*R
##*S#
*L
#######&**<>_+
######XYUGJ{}|
######MNEAS?
######KHPBZ
#
*R
~!@*#$%^
#:()CQ
#ROITF
#;WLDV
#

Results and Analysis

Here we analyze the results from the comparison tool. My layouts are the bottom ones called Balanced 1, 2, & 3. In order to find a truly balanced layout focusing on the letters and punctuations, I removed the Enter key from my layouts, which relies on the right pinky finger. For the non-Balanced layouts, we can extrapolate similar results by reviewing the older experiments in previous posts. However, note that the algorithms for the comparison tool has been modified somewhat, but this doesn't really change the results that much.

PROSE

The selected text is from the first three chapters of The Old Curiosity Shop by Charles Dickens.

Overall Effort and Balance

(http://www.shenafu.com/code/keyboard/balanced3_1.png)

Balanced #3 uses a bit more effort than #1 & #2, but has the best balance overall, although not by much. However, this doesn't tell the whole story. We have to see the more detailed reports to determine the balance of the hands and each finger.

Effort for each finger

(http://www.shenafu.com/code/keyboard/balanced3_2.png)

First, we can see that the Enter key takes up a lot of effort by the right pinky: about 10% of all effort. That's in addition to the other keys assigned to the right pinky. Altogether, on a standard keyboard the right pinky exerts about 20% of all effort including stretching to hit the Enter and Shift keys.

Speaking of Shift keys, the left and right shift keys ask for significant effort by both pinkies. You can see by the charts that the pinkies exert more effort than the middle and ring fingers regardless of layout, except maybe Qwerty which doesn't have a frequent letter for the right pinky.

Anyway, back to the Balanced layouts, all three versions distribute the effort to each finger quite evenly. However, the same is not true for each hand. In Balanced #1 and #2, the left hand actually exerts a lot more effort than the right. As I said in the intro, this was partly due to the skew from the Enter key which #1 and #2 didn't take into account. Without the effect of the Enter key, #3 manages to achieve true balance between left and right hand.

Keys for each finger

(http://www.shenafu.com/code/keyboard/balanced3_3.png)

For the segment of prose used in this experiment, the Enter key accounts for almost 2% of all keys. So remove 2% from the right pinky on the non-Balanced layouts to get a closer comparison. Regardless, it's apparent that the Balanced layouts have a better bell distribution of keys based on the strength and length of the fingers. That is, the pinkies hit significantly fewer keys than the other fingers. This is not necessarily true for the other layouts, which all seem to under-utilize the ring finger.

The main difference between Balanced #3 and the previous versions is that more keys are hit with the right hand, rather than vice versa. This may actually be more desirable since most people are right-handed. This is a different case than effort, however, since effort takes into account other factors like distance. So while left hand may be hitting fewer keys, the overall effort may match or exceed the right hand.

Finger travel

(http://www.shenafu.com/code/keyboard/balanced3_4.png)

For other layouts, subtract 40m for the Enter key. After doing this, Colemak (-6.84% for right hand) actually looks very balanced, while Workman  (-6.88% for right hand) seems very biased toward the left hand. However, this seems too much a departure from previous experiments where Workman was heavily biased toward the right hand. I don't know the reason for this reversal other than that the algorithm has been modified since last time.

Anyway, the Balanced layouts live up to their names. #3 edges out the others ever so slightly in terms of balance between each hand, however that also takes a bit of toll in total distance.

Metrics

(http://www.shenafu.com/code/keyboard/balanced3_5.png)

Balanced #3 looks to have higher percentages in all these metrics. Some of it is by design, due to moving the punctuation to the top row and putting frequent letters on the bottom row. Nevertheless, the margins aren't significant. More important is the feel while typing. For instant, certain row jumping aren't really that bad and some are by design.

Title: Re: Balanced Keyboard Layout
Post by: Den on 2016-Mar-19 06:01
NEW LAYOUTS BASED ON NEW EFFORT THEORY


BEAKL stands for Balanced Effortless Advanced Keyboard Layout. Its goals are as follows:


Comparing other layouts

Despite not putting the most common letters on the home row, the BEAKL layout still beats the competition in tests that heavily favor and expect common letters on the home row. This is accomplished with smart placement of common letters in the home block as described above. Thus achieving great combination of hand alternation and rolls with low same finger and same hand penalties. Due to its balanced nature, it is best to test this layout against other layouts using ergonomic keyboards designed with straight columns if possible.

The distance scores may be skewed due to the unnatural slant of standard keyboards. Most importantly, distance is not as good indicator as the actual time to hit a key. As claimed above, keys hit by the non-pinky fingers outside the home row are hit faster than the home pinky; even though generally the home pinky is thought of having a better distance score, while other faster keys may be penalized.

Consquently, BEAKL not only takes into account distance, but also speed, rolls, and alternation.

BEAKL Layouts Showcase

Balanced Effortless Advanced Keyboard Layout (BEAKL) 4
Code: [Select]
UNSHIFTED
"scg. ,uof'
wnthm pieay
qvlrk xdbzj

SHIFTED
:SCG( )UOF;
WNTHM PIEAY
QVLRK XDBZJ

Pros:
Great metrics: distance, effort, balance, alternation, rolls, prose, code
Minimal work of pinky, inside index
Maximize middle, index
High number of words typed with home block keys (index, middle, ring on top, home, bottom rows)

Cons:
High same finger
Known metrics algorithms not take into account new philosophy and preferences, like minimize pinky and inside index usage

Details:
Pinky each under 4%, total under 8%
Inside index each under 5%, total under 9%
Index, middle each 13-21%

Balanced Effortless Advanced Keyboard Layout (BEAKL) 7
(http://www.shenafu.com/code/keyboard/beakl7-ergo.png)
(Creative Commons Attribution 4.0 License courtesy of http://patorjk.com/keyboard-layout-analyzer/#/about (http://patorjk.com/keyboard-layout-analyzer/#/config))
Code: [Select]
UNSHIFTED
"vrldb juoiq
wsthf ,naey
kcmgx "pz.'

SHIFTED
VRLDB JUOIQ
WSTHF ;NAEY
KCMGX (PZ):

Pros:
  • Superior metrics that beats even computer generated layouts that favor the home row: distance, effort, balance, alternation, rolls, prose, code, messaging
  • Minimal work of pinky, inside index
  • Maximize ring, middle, index
  • High number of words typed with home block keys (index, middle, ring on top, home, bottom rows)

Cons:
  • New, not yet known to public

Details:
  • Pinky each under 4%, total under 8%
  • Inside index each under 4%, total under 8%
  • Index, middle, ring each 13-21% key presses
  • Low same finger and same hand usage

Balanced Effortless Advanced Keyboard Layout (BEAKL) Opted

Optimal layouts from using AdNW's optimizer.

(http://www.shenafu.com/code/keyboard/beakl-opted.png)
(Creative Commons Attribution 4.0 License courtesy of http://patorjk.com/keyboard-layout-analyzer/#/about (http://patorjk.com/keyboard-layout-analyzer/#/config))

Code: [Select]
Letters may be put outside 10x3 block.
UNSHIFTED SHIFTED
znmcg /uoyj q ZNMCG ?UOYJ Q
prtsd .aeih PRTSD )AEIH
vlwfb -,'"k x VLWFB _(:;K X

196.847 total effort 118.770 positional effort left right
2.721 same finger rp 1.869 shift same finger top 11.8 10.3
63.913 hand alternat. 41.454 shift hand alter. mid 20.8 24.0
2.075 inward/outward 30.607 inward or outward bot 7.5 5.9
13.098 adjacent 13.472 shift adjacent sum 44.0 56.0
10.866 no hand altern. 42.637 two hand altern.
5.452 seesaw 5.361 indir same finger

LP LR LM LI LT RT RI RM RR RP LS RS
2.7 12.8 9.9 14.6 4.0 15.7 14.8 13.7 7.4 4.4 Sh 4.0 2.9

Code: [Select]
Letters restricted to inside 10x3 block.
UNSHIFTED SHIFTED
znmcg 'oiuj - ZNMCG :OIUJ _
prtsd ,aehk PRTSD (AEHK
vlwfb q."yx / VLWFB Q);YX ?

206.646 total effort 125.463 positional effort left right
2.811 same finger rp 1.869 shift same finger top 11.8 13.0
63.913 hand alternat. 41.454 shift hand alter. mid 20.8 19.8
1.952 inward/outward 30.518 inward or outward bot 7.5 7.4
14.128 adjacent 17.011 shift adjacent sum 44.0 56.0
10.866 no hand altern. 42.637 two hand altern.
5.648 seesaw 5.328 indir same finger

LP LR LM LI LT RT RI RM RR RP LS RS
2.7 12.8 9.9 14.6 4.0 15.7 16.3 13.9 6.5 3.5 Sh 4.0 2.9

Details:

Comparison to other layouts
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2016-Jul-04 04:13
hi
(http://www.shenafu.com/code/keyboard/keyboard_effort_grid OLD.png)[/spoiler]

Just wondering how you arrived at these weightings, they differ a bit from those used in developing the Workman layout.
http://www.workmanlayout.com/blog/

I still need to compare against Michael Dickens' values.
BTW these captchas are even worse than the ones on GeeekHack.
Thanks, Ian
Title: Re: Balanced Keyboard Layout
Post by: Den on 2016-Jul-05 23:16
hi
Just wondering how you arrived at these weightings, they differ a bit from those used in developing the Workman layout.
http://www.workmanlayout.com/blog/

I still need to compare against Michael Dickens' values.
BTW these captchas are even worse than the ones on GeeekHack.
Thanks, Ian

That is the old weightings. It was partly influenced from Workman and (my personal) effort to reach each key and their difficulty for rolls. This chart is obsolete.

The new weightings can be found in the first post. These weightings take into account the speed to press each key. In other words, the delay before key is pressed. With this factor, the home pinky is actually quite slow to press. Even though it has basically no distance penalty, the weak pinky is not as responsive as other fingers. So relying on pinky, even the home pinky, will slow down your typing and increases fatigue rate. Thus the pinky keys have high penalties to prevent the optimizer from putting a common letter at pinky keys.

Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2016-Jul-06 13:43
Sorry I thought I had quoted your new weighting diagram, not so used to this forum software.

Anyway, present for you. Hope I got it right. The starting layout I used had some keys marked on the front edge, I deleted those.
Not sure what to put on the extra keys etc ... I don't have a Kinesis board.

http://www.keyboard-layout-editor.com/#/gists/276c4f3518a83751206ae79ebc0bedd8

And please ask your admins to implement
https://nakedsecurity.sophos.com/2014/12/05/i-am-not-a-robot-google-swaps-text-captchas-for-quivery-mouse-clicks/
the captchas on this site are ridiculous.
Cheers, Ian
Title: Re: Balanced Keyboard Layout
Post by: Den on 2016-Jul-06 21:52

And please ask your admins to implement
https://nakedsecurity.sophos.com/2014/12/05/i-am-not-a-robot-google-swaps-text-captchas-for-quivery-mouse-clicks/
the captchas on this site are ridiculous.
Cheers, Ian

I'll check out about other captcha methods. Meanwhile we should start a new topic on captchas in the Tech Support boards (http://shenafu.com/smf/index.php?board=6.0) (at the top of forums list).
Title: Re: Balanced Keyboard Layout
Post by: Den on 2016-Jul-08 15:57
In my excitement to find the optimal layout, I blindly took the last result that has the shortest distance, without clearly considering the other factors, including finger balance and row usage.

For best alternation results, the layouts divide the keyboard into two districts: consonant district and vowel district. The optimizer converges to the point that the letters don't move across the districts. Hence, we can analyze and optimize the districts separately without affecting the other. The optimizer basically converges into two results for each half (or hand), for a total four possible layouts.

Consonant District
The two optimal consonant districts are these:

Code: [Select]
left
znmcg top 11.8
prtsd mid 22.2
vlwfb bot 8.4
sum 42.4
2.5 13.8 10.6 15.5
P R M I
Code: [Select]
left
znlcf top 13.2
prtsd mid 22.2
vbmgw bot 7.0
sum 42.4
2.5 11.8 12.4 15.8
P R M I

The main differences are 6 letters in the top and bottom rows. The 1st layout puts more work in the bottom row and the ring finger. On the other hand, the 2nd layout works the top row and evenly distributes work between the middle and ring fingers. The 2nd layout should thus feel overall better.

Vowel District
The two optimal vowel districts are these:

Code: [Select]
right
'oiuj top 14.2
,aehk mid 21.8
q."yx bot 3.2
sum 39.2
14.7 15.7 7.5 1.2
I M R P

Code: [Select]
right
'uohq top 12.3
.aeik mid 23.6
x,"yj bot 3.2
sum 39.2
11.1 15.8 11.2 1.1
I M R P

The main difference is the H and I letters swap rows. By doing this, the work is better distributed between the ring and index fingers, and some workload from the top row is shared to the home row. The 2nd layout should thus feel overall better.

Conclusive Layout

Code: [Select]
Opted 1 292.209 total effort 90.601 positional effort left right
2.324 same finger rp 1.059 shift same finger top 11.8 14.2
  znmcg'oiuj/ 66.771 hand alternat. 32.213 shift hand alter. mid 22.2 21.8
  prtsd,aehk 1.792 inward/outward 29.119 inward or outward bot 8.4 3.2
  vlwfbq."yx- 14.287 adjacent 23.203 shift adjacent sum 43.3 56.7
9.048 no hand altern. 43.311 two hand altern.
5.137 seesaw 5.387 indir same finger
2.5 13.8 10.6 15.5 0.9 17.5 14.7 15.7  7.5  1.2 Sh  0.9  1.5
Code: [Select]
Opted 2 294.290 total effort 89.338 positional effort left right
2.737 same finger rp 1.059 shift same finger top 13.2 12.3
  znlcf'uohq/ 66.771 hand alternat. 32.213 shift hand alter. mid 22.2 23.6
  prtsd.aeik 1.987 inward/outward 28.706 inward or outward bot 7.0 3.2
  vbmgwx,"yj- 13.596 adjacent 17.196 shift adjacent sum 43.3 56.7
9.048 no hand altern. 43.311 two hand altern.
4.936 seesaw 5.189 indir same finger
2.5 11.8 12.4 15.8 0.9 17.5 11.1 15.8 11.2  1.1 Sh  0.9  1.5   

The top layout is the 1st optimized layout from the previous post, and the 2nd layout is the conclusive layout by combining the two optimized districts as discussed in this post. The stats are not that different. The main difference is the work is distributed toward the home and top rows and more evenly among the 3 big fingers. The 2nd layout should thus feel overall better with similar performance.

Using this popular keyboard layout analyzer (http://patorjk.com/keyboard-layout-analyzer/), which should favor layouts that put the 5 best keys on the home row and is against our philosophy, yet both our old and new BEAKL layouts come in the top 3 consistently. See screenshots below:

(http://www.shenafu.com/images/kb-results1.png)(http://www.shenafu.com/images/kb-results2.png)(http://www.shenafu.com/images/kb-results3.png)

How can BEAKL perform so well in unfavorable tests against all odds? This particular keyboard analyzer divides the composite score into 3 equal parts. BEAKL arguably surrenders one of these parts, but it must beat the competition in the other two tests if it is to score higher than the rest in the overall score.

Only one part is the distance test. Sure BEAKL performs slightly worse based on the assumption that accessing keys other than home row incurs some penalty. However as we've explained before, distance alone is not a great measurement of ergonomics and speed. The greater distance and effort from the 3 big fingers more than compensates for not overusing the weak and slow pinky fingers. One because these keys are much stronger and durable, so they can withstand the extra workload without causing fatigue. Even a little effort from the pinky causes much fatigue. Two the bigger fingers are still faster at pressing keys farther away than the pinky at home. So what good is distance without considering the time and delay to press a key? Thus we suggest that these distance tests should be replaced to somehow incorporate elements of time regardless of where the key is located, in order to more accurately portray the physiological movements and strengths of each finger.

The second part of the test is finger and row usage. Here BEAKL really outdoes the competition, obviously, since balance and effort is part of its name. In short, this test punishes pinky usage and bottom row usage, so naturally BEAKL scores high in this part. When every other layout has ridiculous 10% to 20% workload on both pinkies, BEAKL prides itself in 5% or under of total effort for both pinkies. Other benefits to minimizing pinky usage are faster rolls done with other fingers (particularly inner-index column) and fewer awkward, long one-hand sequences involving pinkies. Even though BEAKL encourages bottom row usage and every other layout designer avoids it, ironically results show that BEAKL bottom row usage is comparable or better to other layouts.

The third and final part of the test is penalties for same hand and same finger key presses. With BEAKL heavily favoring hand alternation and rolls, this naturally leads to very low same hand and same finger penalties. As a matter of fact, BEAKL consistently score better than the competition in this part of the test.
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2016-Jul-10 13:22
Hi

Interesting.
Are you running the analyzer locally or on the official web site? Am asking because I'm not sure how to give it a layout to analyze, since new submissions are not accepted ... Do I just 'configure' a layout and it will use it?

The layout I'm playing with uses both thumbs, and not sure if his algorithm will handle that.

Something that I feel the keyboard analyzers I know about don't consider, is the position of your hand after you move it to stretch for a key. I actually use my pinky less than other people because both are missing the last joint, so I tend to use the ring finger more. Also I'm not a touch typist in the formal sense, and I suspect most people are not either... when I'm typing, my fingers are NOT touching the home keys and pressing, I acually seem to use my index finger and middle finger much more than the others (am noticing this now because I'm paying attention to it as I type...)

Anyway, let's say you need to type a } on a QWERTY layout .. isn't your hand going to move up to the top row, so that if you then need a letter from the top row, there is less of a penalty than if your had just typed a K for example? Futher, most keyboards are staggered, and the fingers can't just move up and down, they need to go sideways too, which again moves the hand, and affects the penalty or otherwise of the next letter. Am I being clear enough here? :-)

Comments?

BTW I don't see any captchas to fill in ... thanks :-)
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2016-Jul-10 13:25
Oh yes, so how does your layout look now? And it's Official Name? :-)

Thanks, Ian
Title: Re: Balanced Keyboard Layout
Post by: Den on 2016-Jul-10 15:29
Hi

Interesting.
Are you running the analyzer locally or on the official web site? Am asking because I'm not sure how to give it a layout to analyze, since new submissions are not accepted ... Do I just 'configure' a layout and it will use it?

The layout I'm playing with uses both thumbs, and not sure if his algorithm will handle that.

While that site no longer accepts new layouts, you can still configure custom layouts. You can compare up to 5 layouts, so up to 5 custom layouts will be saved for your session until you close the browser. Just drag the keys around with the mouse, or type in the characters for special keys.

You can also import and export layouts via codes. Export, copy, and save these codes on your computer, then copy and paste them back during import.

Below are the codes for my 2 latest layouts:

BEAKL Opted 1: http://pastebin.com/3xrNpukQ
BEAKL Opted 2: http://pastebin.com/baaXQt9z

Quote
Something that I feel the keyboard analyzers I know about don't consider, is the position of your hand after you move it to stretch for a key. I actually use my pinky less than other people because both are missing the last joint, so I tend to use the ring finger more. Also I'm not a touch typist in the formal sense, and I suspect most people are not either... when I'm typing, my fingers are NOT touching the home keys and pressing, I acually seem to use my index finger and middle finger much more than the others (am noticing this now because I'm paying attention to it as I type...)

Anyway, let's say you need to type a } on a QWERTY layout .. isn't your hand going to move up to the top row, so that if you then need a letter from the top row, there is less of a penalty than if your had just typed a K for example?

The keys on the outside are so rarely used, or for special purposes, that they have negligible effect on the statistics. I recommend you move your entire hand when reaching for distant keys. It's pretty fast to swipe your hand there and back. Never stretch your pinky; hit those keys with your stronger fingers.

For hunt-and-pecking (not touch-typing), then it makes more sense to concentrate the keys in columns. So you move your hands up and down, rather than sideways. Your fingers naturally move and bend up and down, not sideways.

The BEAKL layouts already enable this strategy. By taking the pinky keys out of the picture, the common letters naturally form into the remaining columns for better access by the stronger fingers. Your fingers then neatly find the letters simply by bending naturally, while less need to swipe your hand frantically all over the keyboard. You can also use the ring finger to hit keys on the pinky column.

Quote
Futher, most keyboards are staggered, and the fingers can't just move up and down, they need to go sideways too, which again moves the hand, and affects the penalty or otherwise of the next letter. Am I being clear enough here? :-)

Staggered or not doesn't really affect the relative position of the letters, or which keys are pressed by which fingers (by strict touch-typing standards.) The biggest differences would be the corner keys, but then the placement of these letters wouldn't matter that much since they are rare letters anyway.

Quote
Oh yes, so how does your layout look now? And it's Official Name? :-)

Name it "BEAKL 2.0" for now. This layout feels better at a slight performance hit.

Code: [Select]
UNSHIFTED SHIFTED
znlcf 'uohq ZNLCF ;UOHQ
prtsd .aeik PRTSD :AEIK
vbmgw x,"yj VBMGW X()YJ

Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2016-Jul-12 12:40
So I applied my mind... and got some reasonable results.

I played with PatorJk's analyzer until I won. Although I need two layouts to win all three sections. The one that wins on Alice does not do so well on the SAT words... or the 'sample' text when you load the site. Or a long Perl program, for that matter.

Out of curiousity  I fed it the first three chapters of Dicken's Old Curiousity Shop, copied from Gutenberg site, leaving out the front matter.

Results are:

Rank Layout Score
#1 Ian v38-74.36 73.66
#2 Ian v23-73.36-wordwinner 72.66
#3 MTGAP Thumbshift 72.50
#4 BEAKL Opted1 72.49
#5 BEAKL Opted2 69.54

I call the second one WordWinner because it wins both the Common and SAT words tests (against MTGAP and your two, which was what was left after I tested all the layouts against Alice... BuTeck was also in the running but got knocked out.
The numbers refer to the score on Alice. Second one is actually an earlier version of current Alice winner.

However I feel this is pretty much Horses for Courses ... am trying to get a layout that does well in all the tests but so far been a battle.

Have you been able to test your layouts with Michael's "Typing" analyzer? I've got it here and am trying to get to grips with it...not sure how well it will handle ErgoDox layouts.

My layouts don't seem particularly strong on things Michael looks at, like bigrams and inward rolls etc .... on the other hand my layout beats MTGap so it must be doing something right, given that MTGap is probably one of the best of the well-known layouts around (AFAIK). (not including yours, which is clearly giving it a run for the money)

Comments?

(my layouts are not 'complete' hence am not posting publically yet.. I haven't filled in all the keys, but AFAIK I have all the ones used in the tests. Adding missing keys in tends to drop the score, as they are then taken into account, and ignored otherwise .. I asked Patrick.)
Title: Re: Balanced Keyboard Layout
Post by: Den on 2016-Jul-13 03:49
Are you making a new layout manually, or with the help of a program? It's indeed difficult and time-consuming (albeit addictive and satisfying) to do it by hand. It's even harder to try to beat layouts created and optimized by such programs, like BEAKL and MTGAP. These programs go through thousands of layouts in mere seconds.

I haven't the patience to play with Michael Dickens' analyzer. (Maybe one day...) I did find something interesting while reading his old site (http://mtgap.bilfo.com/completed_keyboard.html). He compared one of my very early layout, Amuseum's Layout (http://www.shenafu.com/layout.php), and it placed 6 out of 18. Not too bad for my primitive works, and proves that my older theories hold water. I just tested it in Keyboard Layout Analyzer and it surprisingly holds up quite well against Colemak.

I also think BuTeck is a dud. It underperforms for a layout created from a more recent optimizer program.

The concentration of bigrams will vary depending on the corpus used. Prose is very different than a list of vocabulary words. In prose, certain words and bigrams like TH, WH, HE, would be a lot more common than in a random list of words. That could be why you lose in SAT words or vice versa.

For best results, use an enormous corpus that incorporates different styles, including (English) prose, code, messages and communications, website text, lists (of random stuff), encyclopedia, etc. Save it all in one text file which you can then reuse.

I wouldn't worry too much about winning all the tests. You should decide which metrics are the most important. For me they are avoiding any pinky usage, high hand alternation, and excellent inward rolls. Bigrams and inward rolls seem to be important to touch typists and keyboard theorists, but may not necessarily apply to others (since I haven't seen much studies or discussion about what's best for hunt-and-pecking.)
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2016-Jul-13 07:09
Are you making a new layout manually, or with the help of a program?

By hand (as opposed to having a computer try all the possibilities)

For best results, use an enormous corpus that incorporates different styles, including (English) prose, code, messages and communications, website text, lists (of random stuff), encyclopedia, etc. Save it all in one text file which you can then reuse.

The JavasScript (well the browser) doesn't like large inputs to play with.. maybe I need to convert it to run in headless mode without a browser. I've tried various classics from Gutenberg and it does well. Does not do so well with Perl or PHP, think I need to pay attention to where the brackets etc are.
[/quote]

I wouldn't worry too much about winning all the tests. You should decide which metrics are the most important. For me they are avoiding any pinky usage, high hand alternation, and excellent inward rolls. Bigrams and inward rolls seem to be important to touch typists and keyboard theorists, but may not necessarily apply to others (since I haven't seen much studies or discussion about what's best for hunt-and-pecking.)

Currently doing well. The "Distance" measurement is one of the higher scores (on the panel, dunno compared to the likes of QWERTY), but other metrics are good.

These pics from Alice:

Finger Usage:
(http://i.imgur.com/m64Vjvg.png)

Left middle is a bit overworked but any changes produce worse score, so let it be....
I fiddled a bit and was able to get ZXCV in decent position on right side without damaging score, so I may 'mirror' the keyboard to put most work on right middle, and ZXCV back by left control ....V would then be where A on QWERTY is now, and W (close tab in Firefox) next to it. If anything, an improvement on traditional ZXCV. as the V is closer. This was not a design goal, but in later stages became possible, and a nice bonus.

Hand usage:
(http://i.imgur.com/PdvF9NM.png)

My starting point was a "balanced" layout determined by taking the letter frequency table for English, and the various 'position' weightings (yours, Workman) and assigning the letters, then studying the results, tweak, repeat ... When I started I was rather low down and despaired of ever getting up to your and MTGap's lofty heights... :-)
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2016-Jul-13 07:24
I haven't the patience to play with Michael Dickens' analyzer. (Maybe one day...) I did find something interesting while reading his old site (http://mtgap.bilfo.com/completed_keyboard.html). He compared one of my very early layout, Amuseum's Layout (http://www.shenafu.com/layout.php), and it placed 6 out of 18. Not too bad for my primitive works, and proves that my older theories hold water. I just tested it in Keyboard Layout Analyzer and it surprisingly holds up quite well against Colemak.

Well that explains the mystery of where Amuseum comes from... :-)

I had a look at Typing again last night, he has some samples for Kinesis, but the ErgoDox layouts have two extra columns. I'll probably have to modify the program to cater for that, he does have some brief instructions on how to do it. Never worked in C before, I've gone out of my way to avoid any languages that start off talking about Static Voids ... makes my head spin :-)
Title: Re: Balanced Keyboard Layout
Post by: Den on 2016-Jul-13 16:50
Without seeing your layout, I can only make assumptions and guesses based on your screenshots.

First, I see that pinky usage is relatively low, which of course I approve.

Second, your left thumb usage is unusually higher than other layouts. I'm guessing you put E in left thumb. But that doesn't explain the unusually high left middle finger. Thus I would be cautious of high same finger usage for middle left finger.

I thought of something to say about Workman's effort model now that others are also copying and modifying to their own whims. It is counterproductive to assign such nuanced grades for the first nine keys or so for each hand. I mean no need to be so specific, from 1.0 1.5 2.0 2.5 etc for the best nine keys on each hand. You just need to make about three grades 0, 1, and 2, and assign three keys to each grade.

One, the efforts between these keys aren't that far apart. Some people erroneously assume (as I once did) that individual finger flexibility has a big effect on typing speed and comfort. That is, people tend to short-sell how nimble the big fingers really are (and over-sell the pinky).

Two, these graph-makers tend to miss the forest for the trees. A layout is not just individual keys, so they neglect other important factors in typing holistically, such as rolls. For example the top ring finger is usually assigned a worse grade. But that ignores the fact that it is also one of the better keys to start inward rolls.

Three, they assume that all reaching should be done by the fingers alone. That's very unergonomic. The arms should move freely to bring the fingers closer to the keys without over-stretching or over-curling the fingers.
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2016-Jul-13 17:08
Second, your left thumb usage is unusually higher than other layouts. I'm guessing you put E in left thumb. But that doesn't explain the unusually high left middle finger. Thus I would be cautious of high same finger usage for middle left finger.

Reasonable guess :). I had T on left thumb. E was on left middle finger, but the actual problem was that O was above it. Moving O next to it solved the problem.
My score on Alice went down a bit, but still best layout. Secondly, it is now also best at Common Words, and second best at SAT words.
In the mean time I'm trying again to get a good layout with E on the thumb ... :-)
I've compiled a huge corpus with a bunch of text from different classic books on Gutenberg. My layout was best on each individually, except for Romeo and Juliet, where yours (think BEAKL 1) won. The text has a lot of periods and square brackets, which is unusual.
Title: Re: Balanced Keyboard Layout
Post by: Den on 2016-Jul-14 16:13
I'm playing with fixing the period (.) on the top index. This will improve "e." combo slightly, but most importantly put the dot closer to the number row to help type decimals. This one of the great innovation I learned from Dvorak.

This is the new layout:
Code: [Select]
QNLCF X.OHJ
PRTSD UAEIK
VBMGW ',"YZ

There are some minor changes as a result. U moves into period's old spot in the home inner-index. Z and Q swap hands. X and ' swap rows. For traditional analyzers, this actually scores a bit better than BEAKL 2.0 because those tests prefer the U on the home row. Meanwhile, it tends to outscore all the layouts for writing code. So overall I think this is a great change.
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2016-Jul-14 17:33
I'm playing with fixing the period (.) on the top index. This will improve "e." combo slightly, but most importantly put the dot closer to the number row to help type decimals. This one of the great innovation I learned from Dvorak.

My current best layouts (as per Patrick's analyzer) have period on ring bottom and comma on ring top (my vowels are on left hand at present). If I move them elsewhere the score drops. It's probably a function of the test data, but even on Alice it works the best.

There are some minor changes as a result. U moves into period's old spot in the home inner-index. Z and Q swap hands. X and ' swap rows. For traditional analyzers, this actually scores a bit better than BEAKL 2.0 because those tests prefer the U on the home row. Meanwhile, it tends to outscore all the layouts for writing code. So overall I think this is a great change.

My U is not on the home row ... (except for WordWinner which still wins the SAT words tests). Other higher-scoring layouts have U on bottom row under E ... I don't think EU/UE is a common bigraph in English, so it doesn't get punished much.

Will see if I can load your new layout to play with... .only using BEAKL 1 at the moment because I have three layouts scoring above BEAKL and MTGap.
Maybe I must run Patrick's analyzer locally and change the code to allow more layouts. It leaks memory badly... guess that's the Javascript's fault.

I tried to win with E on the thumb, but could not beat previous layout with T on thumb. In desperation I swapped E and A and immediately got a new high score on Alice. But even that hit a block, and so I tried putting H there instead...which worked better. Am now up to 75.54 on Alice. However the words tests are not so good, and my own large corpus also not so good. Haven't even tried testing code ... :-)

So still have not found Nirvana. Left side of keyboard is like something from Wales, and right side like a Czech dictionary ... so dunno how user  friendly such a layout would be...
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2016-Jul-14 17:41
Oh yeah. the 75.54 layout has a very low 'effort' ... much lower than MTGap which was optimised for low effort.
Scores from Alice:
(http://i.imgur.com/zwveE5f.png)
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2016-Jul-14 17:54
Have you been able to test your layouts here at all?

http://spwebgames.com/keyboard/

My layouts don't fit their patterns. I did manage to beat their Colemak Mod DH a little, which didn't impress the author.... :-)  The game is also on the Colemak site @ https://colemakmods.github.io/mod-dh/analyze.html but Firefox doesn't want to show it to me there at the moment ... probably some Java security issue.
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2016-Jul-14 18:02
Here:
http://patorjk.com/keyboard-layout-analyzer/#/load/vTNvRTR9

Layouts are visible under Configuration. All a work in Progress, WordWinner least complete. Possibly why it wins.... might be missing a few punctuation characters.
Title: Re: Balanced Keyboard Layout
Post by: Den on 2016-Jul-14 20:00
There are some errors in your layout. You don't have a capital "I", only "i". Your layouts are great in prose, unfortunately tend to lag behind in everything else (code, numbers, random stuff).

Putting a letter on a thumb may squeeze a bit more performance. Maybe I'll try "A" or "S" there, too. The common trigram " a " could be icebreaker. But according to my digram chart (http://www.shenafu.com/digrampop.html), "T" is the most common digram with SPACE.

Quick change to the Opt program produced this:
Code: [Select]
134              271.035 total effort   106.408 positional effort    left right
                   3.004 same finger rp   2.921 shift same finger top 12.4 10.9
  vncdfu.o/q      64.215 hand alternat.  45.894 shift hand alter. mid 16.1 20.4
  brshmyiaez       1.871 inward/outward  30.002 inward or outward bot  8.6  5.4
  wlgpkx,'"j-     14.586 adjacent        11.551 shift adjacent    sum 47.3 52.7
      t            9.549 no hand altern. 42.280 two hand altern.
                   4.575 seesaw           3.720 indir same finger
                  3.0 12.8  9.1 12.3 10.1 16.0 12.5 12.1 11.1  1.0 Sh  3.7  3.2

It doesn't seem the patorjk analyzer give the thumb any advantages, but the AdNW/Opt does. Opt gives about 17% - 21% better effort score to my new thumb layouts.

Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2016-Jul-14 21:37
There are some errors in your layout. You don't have a capital "I", only "i".

Wonderful, fixed, thanks... drops the scores a bit. Patrick's program should refuse to analyze if the layout can't type everything in the sample.

Your layouts are great in prose, unfortunately tend to lag behind in everything else (code, numbers, random stuff).

Yeah I know ... working on that. It's partly because it's a "programmer's" layout with the numbers shifted. I got into this optimizing thing because I am trying to design my own keyboard (see Programmer's Keyboard at www.keyboard-layout-editor.com... version has changed quite a bit since). Anyway that uses a slightly modified Workman-P, which when I originally designed it last year, was the best I had come across. A comment on my site proposed Dvorak but I don't like that ... anyway I looked into the whole topic and ended up too deeply involved ;-)
My keyboard design expects the user to do numbers on the numpad, not the top row of keys. I also will let the numlock switch the top row between punctuation and numerals... but analyzer programs can't handle use cases like that.

Putting a letter on a thumb may squeeze a bit more performance. Maybe I'll try "A" or "S" there, too. The common trigram " a " could be icebreaker. But according to my digram chart (http://www.shenafu.com/digrampop.html), "T" is the most common digram with SPACE.

If you see my keyboard I had two space keys, but the analyzers don't work so well with that .. they prefer one. Actually my recent versions wanted to put E and T on thumb keys (as well as space and return, and Alt, just for reachability reasons) but at the current results that may not be optimal.

Quick change to the Opt program produced this:
[cut]
It doesn't seem the patorjk analyzer give the thumb any advantages, but the AdNW/Opt does. Opt gives about 17% - 21% better effort score to my new thumb layouts.

Sorry, please advise re AdNW/Opt ... Google won't tell me.

Thanks, Ian
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2016-Jul-14 21:40
Sorry, please advise re AdNW/Opt ... Google won't tell me.

No matter, sorted, I had already downloaded their program but not looked at it. Will do so :-)

Cheers, Ian
Title: Re: Balanced Keyboard Layout
Post by: Den on 2016-Jul-15 02:04
What if more thumb buttons were added? Would that improve performance, and if so by how much?

Some keyboards with thumbwells have four big thumb keys that could be reassigned to letters. Including the space, three letters could fit there.

The top candidate is T from what we discovered earlier. I also saw the optimizer put R on the thumb. I guess the third could be one of HEAS, but I wonder that the optimizer will say.
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2016-Jul-15 06:09
What if more thumb buttons were added? Would that improve performance, and if so by how much?

Some keyboards with thumbwells have four big thumb keys that could be reassigned to letters. Including the space, three letters could fit there.

The top candidate is T from what we discovered earlier. I also saw the optimizer put R on the thumb. I guess the third could be one of HEAS, but I wonder that the optimizer will say.

I tried with E and T on the thumbs... but I don't think Patrick's program is smart enough to pick which thumb to use for space and just uses the same one. So the metrics on one thumb go through the roof. I asked him about it and he says it does 'pick the least effort key' when there are duplicates, but I'm guessing that only applies to things like Shift ... he didn't think of handling two space bars.

So I decided that Space is "just another letter" (and so too are comma and period...) which was annoying because it thoroughly breaks my keyboard design having to put comma and period in the middle of the keys.

I'll take a look at Patrick's code and see if my suspicions are correct. Must also try to get that German program to run.

Here's a layout where I had the A on the thumb. (which beat (on Alice) what I could get with E on the thumb))

http://patorjk.com/keyboard-layout-analyzer/#/load/3dB51J4D

What I find most curious about my high-scoring layouts is their almost complete lack of bigrams and trigrams ... there's a few on the right home row, but just about all the main ones (th, he, en, ed, in, ng, er, etc etc) are on different hands. So possibly Michael's program will rate my layouts very badly, since he thinks that bigrams/trigrams are important. Perhaps they are not? I tried deliberately putting th and he on inward rolls but Patrick's program gives it worse scores.

My layouts suck for coding because too many of the needed characters (+,=,<,>,{,}, $ in perl and php) are all shifted and in the wrong places. I'll see how I can fix.

Also, writing code usually involves a lot of ctrl-c and ctrl-v and edit result ( for me, in any case) rather than physically typing everything like you have to do with prose. Also things like

####################################################################
#                                                                                                                       #
#                This is a Section Header                                                                       #
#                                                                                                                       #
####################################################################

are going to confuse the hell out of the metrics. Yes I copied and pasted the last 2 lines. And used my middle finger on the hash.

Cheers, Ian
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2016-Jul-15 06:19
FWIW, this is where I was before I started looking into optimizing the letter layouts. Ignore all the math/greek/currency/punctuation stuff, probably overkill for 99% of the population. This version is supposed to support dozenal numbers. I thought these thumb clusters would be 'optimal' but perhaps I need to rethink. Also where to put . and , for the numpad (if best place otherwise is in the middle of the letters...)
It is apparently possible (in Linux, at any rate) to have a key send a stream of letters instead of just one ... hence And/The/ing/ion etc.

(http://i.imgur.com/S0pelxL.jpg)

I hope posting this publicly does not come back to bite me.
Title: Re: Balanced Keyboard Layout
Post by: Den on 2016-Jul-15 07:01
I managed to recompile opt to accept 34 keys to fit the extra 4 thumb keys. (I added "\|" to fit the required amount of characters.) The suprising 4 characters it put on the thumb well are "_INR" where _ is the space.

Here's the optimal layout it spit out:
Code: [Select]
BEAKL Thumb 1             224.068 total effort    78.409 positional effort    left right
                   3.496 same finger rp   7.918 shift same finger top  9.3 10.3
  \"ou-bdclq      64.288 hand alternat.  45.701 shift hand alter. mid 18.2 16.1
  zea.yfhstw       1.548 inward/outward  29.437 inward or outward bot  4.7  7.4
  j/',xkpgmv      12.842 adjacent         8.308 shift adjacent    sum 52.7 47.3
     i_rn          9.429 no hand altern. 42.298 two hand altern.
                   4.061 seesaw           4.904 indir same finger
                  0.4 11.1 12.1  8.7 20.4 13.4 11.1  9.1 11.9  1.9 Sh  3.2  3.7

This an improvement of 31.6% over no thumb letters and 17.0% over one thumb letter. The pinkies are reduced to only 2.5% of total usage. The period is now right under the home index. Otherwise looks pretty nice and efficient.
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2016-Jul-15 07:10
I managed to recompile opt to accept 34 keys to fit the extra 4 thumb keys. (I added "\|" to fit the required amount of characters.) The suprising 4 characters it put on the thumb well are "_INR" where _ is the space.

Here's the optimal layout it spit out:

So this will fit on the ErgoDox template?

I'll play with it later ... need to do some actual work now :)

Well done.

Cheers, Ian
Title: Re: Balanced Keyboard Layout
Post by: Den on 2016-Jul-15 07:24
I'm trying to include ENTER key as part of the layout. But I need to figure out the correct character to represent it in the code.

How do you remember where all the keys are? And the keycaps?

It also likes the mirror, which appeared as the dominant layout after some minor changes:
Code: [Select]
BEAKL Thumb 1.1             224.133 total effort    78.048 positional effort    left right
                   3.497 same finger rp   7.957 shift same finger top 10.3  9.3
  qlcdb-uo"\      64.292 hand alternat.  45.646 shift hand alter. mid 16.2 18.2
  wtshfy.aez       1.546 inward/outward  29.432 inward or outward bot  7.5  4.7
  vmgpkx,'/j      12.848 adjacent         8.346 shift adjacent    sum 47.3 52.7
     nr_i          9.430 no hand altern. 42.292 two hand altern.
                   4.062 seesaw           4.906 indir same finger
                  1.9 11.9  9.1 11.1 13.4 20.4  8.7 12.1 11.1  0.4 Sh  3.7  3.2

Dvorak typists may prefer the other layout with all the vowels on the left hand.
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2016-Jul-15 07:58
I'm trying to include ENTER key as part of the layout. But I need to figure out the correct character to represent it in the code.

Hex 13  / D
In Patrick's he uses U:D
so probably something like \x0d or somesuch ... not sure how C++ handles these things.

How do you remember where all the keys are? And the keycaps?

Well I haven't built it yet... :-)
The layout is supposed to be logical, as far as possible. Eg greek letters on similar looking or English equivalents, currency symbols were allocated along the top based on their relative GDP, leaving the known ones (eg $) where it was, otherwise on keys with some similarity to shape.

Still trying to figure out how to have the keys printed ... will probably need to be dye-subbed, and will need to find someone here who can do it. I did speak to someone about it last year.
Keycaps are PBT so dyesub will be best option.

Dvorak typists may prefer the other layout with all the vowels on the left hand.

I read somewhere that E should be on the right hand but that was just an opinion based on most people being right handed (and having ambidextrous spacebar). Also saw some people complaining about a new commercial Ergo board that only provided Space on right thumb ... the lefties were upset. My keyboard tries to be ambidextrous in that regard... you could also remap the arrows keys. I think a lot of complaints (and the whole "make keyboard as small as possible to bring the mouse closer" arguments) would go away if people realised that yes, you can actually use the mouse with your left hand, and yes, it does work better. You just need to be aware that there are right-hand versions of ctrl c/v/x that were defined by IBM   :-)
https://en.wikipedia.org/wiki/IBM_Common_User_Access

I've been using the mouse on my left hand since the 1990s. It still confuses people. The idea originated from some techie in a corporate I was in at the time.

Cheers, Ian
Title: Re: Balanced Keyboard Layout
Post by: Den on 2016-Jul-15 08:15
Hex 13  / D
In Patrick's he uses U:D
so probably something like \x0d or somesuch ... not sure how C++ handles these things.
The config file doesn't seem to accept escape codes.
Quote
I read somewhere that E should be on the right hand but that was just an opinion based on most people being right handed (and having ambidextrous spacebar). Also saw some people complaining about a new commercial Ergo board that only provided Space on right thumb ... the lefties were upset. My keyboard tries to be ambidextrous in that regard... you could also remap the arrows keys. I think a lot of complaints (and the whole "make keyboard as small as possible to bring the mouse closer" arguments) would go away if people realised that yes, you can actually use the mouse with your left hand, and yes, it does work better. You just need to be aware that there are right-hand versions of ctrl c/v/x that were defined by IBM   :-)
https://en.wikipedia.org/wiki/IBM_Common_User_Access

I've been using the mouse on my left hand since the 1990s. It still confuses people. The idea originated from some techie in a corporate I was in at the time.

Well, many ergo mice only come in right hand versions. Anyway if you mouse with the right hand, then making the left hand the dominant hand for typing can balance out the stress for both hands. I also like "A" on left hand for simple renaming of files and variables by adding "a" at the end. Move the mouse with the right hand, then type "a" with the left hand.
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2016-Jul-15 08:39
The config file doesn't seem to accept escape codes.

I had a quick look at their docs and sample layouts. They use the same ideas as Michael and the Colemak site analyzer ... seems to assume ANSI/ISO layouts to start with, and we're beyond that.

At a guess, I think you're going to have to use a placeholder, eg $ or some character not in the normal 30, and then modify the code to convert it to \x0d.
But given that it's not included in the configs, their code probably doesn't even use it (again, assumes an ANSI/ISO layout and Enter is not up for optimizing...)

Their code (based on config options) seems very complex yet at the same time incomplete ... ie does not worry about numbers or other punctuation.

I think I'm going to have to write my own analyzer, downside is that it will require precise definitions of the layout (even more than Patrick's) but upside is that it will then handle all use cases and work properly ... :-)

Cheers, Ian
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2016-Jul-15 08:56
Perhaps you can define Ǝ as the definitive symbol for Enter.... :-)
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2016-Jul-15 10:29
The standard.cfg file mentions

Taste RTRN  15  2   13.50  1.5  5   -   7   # Return

but it's commented out ... maybe you just need to add it to your custom defs?
Title: Corpus
Post by: iandoug on 2016-Jul-15 11:59
I've installed LogKeys, will let it run a day or three to get a better idea of what I actually type, and use that for optimising. However I don't think the optimiser programs pay attention to Backspace and delete, do they?....

Was thinking before that you should be able to set an error percentage figure for the optimiser... eg every 10 letters you make a mistake and need to backspace, or somesuch ...

Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2016-Jul-15 18:43
Well, many ergo mice only come in right hand versions.

One of the reasons I've never gone back to a mouse. :-)

If you weren't a gamer I'd suggest Kensington Expert Mouse with the wrist pad...
Newer version (Slimblade) has laser but apparently has other issues ...the Expert is the classic.
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2016-Jul-15 20:17
I managed to recompile opt to accept 34 keys to fit the extra 4 thumb keys. (I added "\|" to fit the required amount of characters.) The suprising 4 characters it put on the thumb well are "_INR" where _ is the space.

Here's the optimal layout it spit out:

I loaded it in Patrick's analyzer... score was not to my liking (on Alice) so tried to improve it ...

Best I've got to at the moment is http://patorjk.com/keyboard-layout-analyzer/#/load/KGLSJrrN
but still way behind your other layouts ... .what do the Germans say about my version?

I'm not happy with the pinky load at the moment ;-)
Title: Re: Balanced Keyboard Layout
Post by: Den on 2016-Jul-15 21:34
I loaded it in Patrick's analyzer... score was not to my liking (on Alice) so tried to improve it ...

Best I've got to at the moment is http://patorjk.com/keyboard-layout-analyzer/#/load/KGLSJrrN
but still way behind your other layouts ... .what do the Germans say about my version?

I'm not happy with the pinky load at the moment ;-)

the problem is Patrick's analyzer (PA) is bugged for thumb layouts. you can see that the other fingers distance doesn't drop, maybe even rises, when letters are put at thumb. there may be some penalty for digrams with thumb keys.

pinky is the case in point. how can "\ZJ" be 1086.0 pts. when "ZPV" is 318.8 pts.? the points should be half as much, not three times higher.
Title: Re: Balanced Keyboard Layout
Post by: Den on 2016-Jul-15 21:41
I give up on ENTER key. there is no easy way to code it in. anyway, it's not a big deal.

The standard.cfg file mentions

Taste RTRN  15  2   13.50  1.5  5   -   7   # Return

but it's commented out ... maybe you just need to add it to your custom defs?

that's just label for the key. nothing to do with the character code.
Title: Re: Corpus
Post by: Den on 2016-Jul-15 21:51
I've installed LogKeys, will let it run a day or three to get a better idea of what I actually type, and use that for optimising. However I don't think the optimiser programs pay attention to Backspace and delete, do they?....

Was thinking before that you should be able to set an error percentage figure for the optimiser... eg every 10 letters you make a mistake and need to backspace, or somesuch ...

you can merge old files and code into the corpus.

good typists make very few mistakes. so we should measure the ideal metrics.

every 10 letters seem very high.
Title: Re: Balanced Keyboard Layout
Post by: Den on 2016-Jul-15 22:19
I removed the shifted punctuation and got different results. Now the "L" replaces the "I" on the thumb row.

Code: [Select]
BEAKL Thumb 4    224.331 total effort    81.877 positional effort    left right
                   3.056 same finger rp   9.094 shift same finger top  8.9 10.9
  \/o.xbdclq      65.022 hand alternat.  39.478 shift hand alter. mid 21.5 17.0
  zeaiyfhstw       1.351 inward/outward  29.075 inward or outward bot  3.2  7.8
  j"',-kpgmv      12.677 adjacent        11.136 shift adjacent    sum 52.8 47.2
      unr          8.927 no hand altern. 42.224 two hand altern.
                   4.066 seesaw           3.986 indir same finger
                  0.4 10.9 12.1 10.2 19.2 11.5 11.7  9.6 12.5  2.0 Sh  3.4  1.2

Title: Re: Balanced Keyboard Layout
Post by: Den on 2016-Jul-15 22:45
BTW I recommend BEAKL 3.0 as the best overall layout for now (where the period is fixed to the top right index):

Autohotkey (Dvorak-to-BEAKL) script (http://shenafu.com/code/keyboard/dv2beakl-s.ahk)

BEAKL Opted3: http://pastebin.com/PYTAdFev

Code: [Select]
UNSHIFTED SHIFTED
qnlcf x.ohj QNLCF X:OHJ
prtsd uaeik PRTSD UAEIK
vbmgw ',"yz VBMGW ;()YZ

(http://www.shenafu.com/code/keyboard/beakl-opted-3.png)

Alright, I think I should stop here and stop tinkering because there's no end to changing this and that. Unless some major new idea comes up, this will be the official BEAKL Standard, or BEAKL-S. And the official layout with thumb keys will be BEAKL-T (to be determined), which we should spend more time developing since that's a newer thing.
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2016-Jul-16 03:41
the problem is Patrick's analyzer (PA) is bugged for thumb layouts. you can see that the other fingers distance doesn't drop, maybe even rises, when letters are put at thumb. there may be some penalty for digrams with thumb keys.

pinky is the case in point. how can "\ZJ" be 1086.0 pts. when "ZPV" is 318.8 pts.? the points should be half as much, not three times higher.

It's not the three letters .... it's the shift key. That's why I had left shift on the thumb ... it makes a major difference to the score. I stole the idea from the MTGap Thumbshift layout ... even though I thought it was a dumb idea until I saw the numbers.
Title: Re: Balanced Keyboard Layout
Post by: Den on 2016-Jul-16 04:04
Reiterate that vowel district including space should be put on the left hand. Because the right hand is more agile, the right hand will execute the tricky rolls and same finger combos better, which are more often on the consonant district. Also the consonant district utilizes bottom row more, and here the right hand is also faster.

Just when you thought I'd stop making new layouts, here's another based on what I just said: space and vowels on the left, and the letters spill to the right of the pinky.
Code: [Select]
Opted4           307.727 total effort   120.514 positional effort    left right
                   2.969 same finger rp   2.638 shift same finger top  9.1 12.9
  joy.xfclnz      64.717 hand alternat.  37.242 shift hand alter. mid 25.1 22.7
  haeiudstrpk      1.834 inward/outward  29.468 inward or outward bot  4.5  7.6
  '"/,-wgmbvq     12.288 adjacent        13.971 shift adjacent    sum 55.5 44.5
     _             9.863 no hand altern. 42.253 two hand altern.
                   4.559 seesaw           4.538 indir same finger
                  3.5 12.8 11.5 11.0 16.7  1.4 15.3 12.5 11.6  3.8 Sh  3.2  1.4
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2016-Jul-16 06:38
Just so I'm clear, we want these numbers to be as low as possible?

Opted4           307.727 total effort   120.514 positional effort   

Will try and start playing with the German evaluator later today. I know neither German nor C++... German I can sometimes figure out because of the similarities to English and Afrikaans. Need to read up on C/C++ variable syntax.

Thanks, Ian
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2016-Jul-16 07:38
I played some more with your thumbkey layout.

This works for Alice, because it has a lot of single-quoted text.

http://patorjk.com/keyboard-layout-analyzer/#/load/n7Mf64N6

However I see it is also top (for the layouts used) for Words and SAT words ... so it must be doing something right.

You can see what the Germans think :-)
Personally I am not happy with some of the other metrics (total distance is too high.)
Although left-right hand balance under Finger Usage can hardly be improved... see the SAT words comparison.

Here's a comparison against the other top layouts (that I know of) on Patrick:
http://patorjk.com/keyboard-layout-analyzer/#/load/3RZl7Bqf

Cheers, Ian
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2016-Jul-16 09:56
We have a new champion on the SAT word list :

#1 Den BEAKL Thumb 1 Mod-Ian 73.99

Even beats my previous "WordWinner" layout ...
There's a problem on the server and I can't save the results to share.
Currently it's also second on the Common Words list. (by 0.30 points)
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2016-Jul-16 10:22
ignore previous, just beaten it...
Scores on the three tests on Patrick are:

74.30 (3rd)  |  76.02 (1st) |  75.08 (1st)

It beats Beakl1 and MTGap Thumbshift. Haven't loaded BEAKL3 yet.
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2016-Jul-16 10:42
http://patorjk.com/keyboard-layout-analyzer/#/load/tTdS5D94
Title: Re: Balanced Keyboard Layout
Post by: Den on 2016-Jul-16 14:25
Just so I'm clear, we want these numbers to be as low as possible?

Opted4           307.727 total effort   120.514 positional effort   

Will try and start playing with the German evaluator later today. I know neither German nor C++... German I can sometimes figure out because of the similarities to English and Afrikaans. Need to read up on C/C++ variable syntax.

Thanks, Ian

Opt will select the best layout with the lowest total effort. However that might affect other metrics, like same finger and seesaw, which might be better or worse than other layouts with higher total effort.

Obviously I have heavily modified the configuration such that my fitness evaluation is wildly different than the standard configuration that came with the download. The score also depends on the corpus, its length, and its contents.

You don't have to touch the C files to alter the configuration. Pretty much everything is done with text files and command line options. It comes with a PDF, the English instructions are in the bottom half of that document.

There are two reasons to recompile, though. First is whether you want to support multithreading. Second is when you change the number of keys in the keyboard. Default supports 35 keys (minus 2 shifts = 33 usable). To increase the thumb well for the 4 thumb keys, I had to recompile to 36 keys (30 basic + 6 thumbs - 2 shifts = 34 usable). (The keys on the side of the right pinky I then commented out in the config files, and added some into the thumb row.) So now I have two commnands for different keyboard types.
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2016-Jul-16 15:22
One layout to rule them all....

http://patorjk.com/keyboard-layout-analyzer/#/load/0pbGQ89P

You can actually get 75.44 on Alice with a small change... but it messes up the others. I did also hit 76.05 on Common Words while refining the above. But above result is what gets to the top of all three....

On the downside, the Effort metric sucks. On the other plus side, the finger-use hand balance is 47/53, best in the panel.

On an aesthetic note I'm not wild about the layout ... but the numbers speak for themselves. Wonder what the Colemak fanboys would say.... :-)
Cheers, Ian
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2016-Jul-16 15:33
above layout sucks on Perl test program. Also PHP/HTML/Javascript. Presumably because brackets are not optimised.
Does not do so well when fed opt.cc either.... even Colemak Thumbshift beats it. I'll see why later.
Title: Re: Balanced Keyboard Layout
Post by: Den on 2016-Jul-16 16:07
One layout to rule them all....

http://patorjk.com/keyboard-layout-analyzer/#/load/0pbGQ89P

You can actually get 75.44 on Alice with a small change... but it messes up the others. I did also hit 76.05 on Common Words while refining the above. But above result is what gets to the top of all three....

On the downside, the Effort metric sucks. On the other plus side, the finger-use hand balance is 47/53, best in the panel.

On an aesthetic note I'm not wild about the layout ... but the numbers speak for themselves. Wonder what the Colemak fanboys would say.... :-)
Cheers, Ian

to beat Pats Analyzer we need an optimizer program for it, like we have for AdNW and MTGAP, to run through 1000s layouts fast. it would also be nice to see how their program score certain areas. like what are effort scores for all thumb keys.


Title: Re: Balanced Keyboard Layout
Post by: Den on 2016-Jul-17 20:50
I might order the Ergodox (if it's still available) in order to customize and test the keyboard with new layouts.
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2016-Jul-18 02:39
I might order the Ergodox (if it's still available) in order to customize and test the keyboard with new layouts.

Oh my, great minds think alike. I investigated that myself, but they go for around $300... not too cheap if it turns out to be a bad design. :-)

Been playing Patrick with standard ANSI layouts ..... managed to get top scores on Alice and  Common Words but still can't beat your Balance 12 on the SAT words ....
My effort scores are not good.. really need a thumb key on the left hand :-)

Cheers, Ian
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2016-Jul-19 10:05
I might order the Ergodox (if it's still available) in order to customize and test the keyboard with new layouts.

The one I saw on Massdrop was around 300 $ I think
https://www.massdrop.com/buy/infinity-ergodox
you need to register before they let you see.

Apparently the place to buy is here
http://falbatech.pl/prestashop/index.php?id_category=12&controller=category&id_lang=2
Fully assembled for 200 €
Oh wait, that one's sold out.

Wood one is 330 € ....
Not sure I want MX Clear switches. The keycaps appear blank, unless it's just the angle of the photo.
Title: Re: Balanced Keyboard Layout
Post by: Den on 2016-Jul-19 20:32
The one I saw on Massdrop was around 300 $ I think
https://www.massdrop.com/buy/infinity-ergodox
you need to register before they let you see.

Apparently the place to buy is here
http://falbatech.pl/prestashop/index.php?id_category=12&controller=category&id_lang=2
Fully assembled for 200 €
Oh wait, that one's sold out.

Wood one is 330 € ....
Not sure I want MX Clear switches. The keycaps appear blank, unless it's just the angle of the photo.

I'm not sure I want them at those prices. I'd rather wait for the new Kinesis (Advantage) coming out later this year. I already use old Kinesis Classic, but don't want to reprogram it for every test layout. If I have another Kinesis then I can play around with it.
Title: Re: Balanced Keyboard Layout
Post by: Den on 2016-Aug-05 01:17
I'm not sure I want them at those prices. I'd rather wait for the new Kinesis (Advantage) coming out later this year. I already use old Kinesis Classic, but don't want to reprogram it for every test layout. If I have another Kinesis then I can play around with it.

I pre-ordered the new Kinesis Advantage2 since I trust in their quality. Supposedly they have a program that allows you to customize the layouts of the keys. We'll see how well it works for our purposes.
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2016-Aug-05 03:04
That's not exactly cheap either :-)

I actually went to a gaming show over the weekend to look at the keyboards, but they didn't have much ... Asus, Corsair and Logitech. I also looked at some online, they're in the same price range as above.

I've been playing with layouts on ANSI104 boards on Patrick's site... so far have top scores in the three input tests, but with three different boards ... two my own and one a modified version of HIEAMTSRN, which was a actually a good layout to start with ... it beat all others (in ANSI104) on Common Words and SAT, just didn't do so well on Alice. So I made a few tweaks that improved it and it got to the top of all the layouts in the menu. ... :-). Your Balance 12 and MTGAP were the other two top layouts.

So I was considering getting a mech keyboard that I can swap caps around on to test the layouts... HIEAMTSRN 'relabelled' a few caps, I've tried to avoid doing that in my tests, but moving the left shift to where CapsLock is does make a definite difference. I've also tried swapping Alt-Grey and R-Shift, which helps a little.

Been a bit quiet lately, things got hectic work-wise. I see the Advantage2 address some of the criticisms of the original, especially those mushy rubber keys. I must look at 'tenting' my own design. Not sure how well keywells work, it makes strong assumptions about people's relative finger length.
Eg....
http://www.livescience.com/49883-finger-length-in-men.html

Cheers, Ian
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2016-Aug-05 14:48
Was it your vote here, or do you have a fan? :-)

http://www.strawpoll.me/10920081
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2016-Aug-05 16:31
Have come to the conclusion that the legacy assignment of assorted punctuation etc to random numbers is standing in the way of a sane layout. Also some numbers are more common than others (eg 0 and 1, presumably because they are used in dialling codes, IP addresses and multiples of 10, and so should NOT be on the pinkies ....

New high score (for ANSI104) for Alice: 71.14. But numrow is destroyed (still no key relabelling though, but hence my rant above).
Title: Re: Balanced Keyboard Layout
Post by: Den on 2016-Aug-05 16:32
Was it your vote here, or do you have a fan? :-)

http://www.strawpoll.me/10920081

Lol i dont remember that poll. When was it made? I mean i thought BEAKL is too new, unknown and untested. As far as I know, I'm the only user. But apparently someone thought it was worthy enough to be put on a poll about keyboard layouts. Like I can't add options to that poll. And I definitely didnt make that poll. MTGAP not on there?

Disclaimer: i did vote just now so there are 2 users for BEAKL ;p
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2016-Aug-05 16:37
AFAIK it popped up today on /r/linux
Judging by the few votes it is new.
And most people are stuck on qwerty.
I guess some manufacturer is testing the water to see if there is a market for an alternative layout off the shelf.
Title: Re: Balanced Keyboard Layout
Post by: Den on 2016-Aug-05 16:52
AFAIK it popped up today on /r/linux
Judging by the few votes it is new.
And most people are stuck on querty.
I guess some manufacturer is testing the water to see if there is a market for an alternative layout off the shelf.

Interesting since i didnt even make the files necessary to install BEAKL on linux. But i guess linux users would be more open-minded to alternative layouts.

I did make autohotkey scripts to convert dvorak to beakl for windows. But thats only found in this thread, not publicised.

Actually yesterday i did tweet to @kinesisergo, makers of kinesis keyboards, about how my BEAKL layout reduces workload by the pinkies. And they seemed to agree with that feature. Also i did go around some months ago to various keyboard related forums to proclaim my new theories on typing efforts. Including geekhack, deskthority, and colemak forums. Perhaps most importantly, i added an entry to the deskthority wiki to make BEAKL seem more official and authoritative.
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2016-Aug-05 17:10
Mmm I wonder if it is Kinesis that is running the poll then ... the timing and list of options is curious.

ADNW is not listed on Wikipedia page on keyboard layouts. And the list is missing Norman and, as you say, MTGAP, which is actually a *bloody good* general purpose layout .. it may not be 'best' in a given test but is generally One of the Best in any given test I've thrown at it... while others are not that consistent. More so because it does weird things like mixing the n in with the vowels... although it does relabel some keys, the numrow is as per qwerty.
Title: Re: Balanced Keyboard Layout
Post by: Den on 2016-Aug-05 17:39
The deskthority wiki is not affiliated with wikipedia. Here is the link to my BEAKL entry:
https://deskthority.net/wiki/Keyboard_layouts#BEAKL_.282016.29

AdNW section is right above this.

it may be Kinesis' doing. maybe they will upload preprogrammed layouts ready to be downloaded on their site? to coincide with the new feature for their new keyboard. :shrug

MTGAP is definitely awesome, but it's not hyped up enough. everyone's all aboard colemak and adnw hype trains.
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2016-Aug-06 17:15
So at lunch I'm staring at my latest efforts, and have what I thought was a brain wave ... do a layout based on

T H E ... D N A

since The and And are the two most common words in English, and typical home-row letters (except the D).

So I tried it out .. and was soon swapping the letters ... don't get a good score with that as starting point.

Anyway after much effort I have a new top layout (well, 'top' as in "beats the others on Patrick's site").

http://patorjk.com/keyboard-layout-analyzer/#/load/glSPVfcC

That wins all three competitions. However I have other layouts/variants that get better scores individually.

What I 'like' about this one is that there are no funny tricks ... no keys got new shift symbols, numrow is standard (except for - and = which I had to move, the - helps on Alice).

I could boost the Alice score substantially by moving Left Shift up one key, moving the () to better location on top row, and bringing the ! down into 30-keys block.

But for now it's the best all-rounder on Patrick's site. If I run it against my "corpus" it doesn't do so well (4th behind HIEAMSTRN improved, MTGAP and HIEAMSTRN) but in fairness HIEAMSTRN remaps some keys. MTGAP is just bloody good (and does remap some keys but don't know if that is what makes the difference).

Must make an effort to get the German analyzer working. I wanted to test this layour on the Colmak site but that only seems to handle the 30 keys, leaving out the '/".

Cheers, Ian
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2016-Aug-06 17:27
Finally.

http://patorjk.com/keyboard-layout-analyzer/#/load/lhHjZ86l

Right index working too hard, distance is bad but still gets high scores, including on my corpus.

Will probably suck for any brackety programming languages though :-)
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2016-Aug-07 07:30
Came to realise last night that humans are strange creatures. We are happy to accept a keyboard with letters in 'random' (ie non-alphabetical) layout, but our heads expect the digits to be in order ... even if that is not optimal.

Bought a cheap MS 200 keyboard today, seemed to be the only one they had that had poppable semi-decent keycaps without any non-standard shapes so I can rearrange them easily. I did look at a Razor gaming keyboard.... but price for need didn't make sense :-)

Cheers, Ian
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2016-Aug-07 11:25
(@#&(@#&$( Microsoft.

Their keys pop off and on okay, but some genius decided to make the F and J keys have different shafts to all the rest.... possibly I can scrape the offending bit of plastic off of those two keys, and the two new ones going where they were, but this is not going to support "frequent rearranging" ....

Should have plonked down the money on the Razor ... as least I think it has Cherry-compatible keycaps, and I've got lots of spare of those.
Title: Re: Balanced Keyboard Layout
Post by: Den on 2016-Aug-07 19:34
Came to realise last night that humans are strange creatures. We are happy to accept a keyboard with letters in 'random' (ie non-alphabetical) layout, but our heads expect the digits to be in order ... even if that is not optimal.

we're used to seeing and using numbers in order. finger 'order' according to typing effort on a keyboard is a unique case. cf numpad and phones have their own ordering.

i'm testing a number order which i think is optimal. but yet to conclude if it's really better and worth the side effects. eg gaming hotkeys. (thankfully most well designed games let you customize hotkeys.)
Title: Re: Balanced Keyboard Layout
Post by: Den on 2016-Aug-07 19:40
(@#&(@#&$( Microsoft.

Their keys pop off and on okay, but some genius decided to make the F and J keys have different shafts to all the rest.... possibly I can scrape the offending bit of plastic off of those two keys, and the two new ones going where they were, but this is not going to support "frequent rearranging" ....

Should have plonked down the money on the Razor ... as least I think it has Cherry-compatible keycaps, and I've got lots of spare of those.

not really into testing out physical keyboards. the only alternative i've tried is Kinesis based on positive testimonies on the keyboard and the manufacturer. most other keyboards are same lame cheap designs. there are some interesting ones, like teck and ergodox, but reviews have been mixed.

the most important isnt physical rearrangement of characters; it's logical layout. physically changing keys seem tedious when you're testing out so many new layouts. until you've settled on a layout and want to publish it to the world.
Title: Re: Balanced Keyboard Layout
Post by: Den on 2016-Aug-07 19:46
for constant rearrangement, perhaps a tablet that allows reconfiguring the keys. something like AnySoftKeyboard for android. which as you may know i'm very familiar with from my other topic on optimal tablet/phone layouts (http://shenafu.com/smf/index.php?topic=88.0). given a big enough tablet to fit ten fingers, might be easier to test logical layouts with automatic visuals.
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2016-Aug-09 11:29
the most important isnt physical rearrangement of characters; it's logical layout. physically changing keys seem tedious when you're testing out so many new layouts. until you've settled on a layout and want to publish it to the world.

For me the proof of the pudding is in the typing .... have managed to get the MS set up on this box but typing is a challenge... seeing as I'm going from something widely regarded as decent (original MS Natural) to this MS 200 ... different  physical and logical layout and mushy keys....

Have splashed out on a low end mech keyboard ---- maybe that will feel better. For some reason typing on this layout seems easier.....

The zxcv keys are now mostly on the right hand, but still within reach. Ctrl-R and Ctrl-T are a bit  more problematic. As is muscle memory....
Title: Re: Balanced Keyboard Layout
Post by: Den on 2016-Aug-11 01:40
I practiced some more with BEAKL 3.0, but for some reason it just doesn't jive for me. The vowel district seems the main issue. So I significantly altered the configuration in Opt to punish awkward rolls in the left hand. And it spit out something like this:

Code: [Select]
BEAKL 4.0
jyo.k gcmnz
hieau dstrp
q"',x wflbv

So far I like this a lot more with just a little practice. The H is back on the home pinky, which I can live with. Y moved from the bottom row to the top, which feels much better. The consonant district has some minor changes, swapping G/F & M/L.

It resembles more like BEAKL 1.0 but outperforms it by a bit.
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2016-Aug-11 02:16
Pretty good :

http://patorjk.com/keyboard-layout-analyzer/#/load/x6NV84bH

You can win on Alice like this:
http://patorjk.com/keyboard-layout-analyzer/#/load/1HJ0RWMN

And if you do this, you win all three...
http://patorjk.com/keyboard-layout-analyzer/#/load/FGbTQBGk

But don't know what opt will say about that ... :-)
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2016-Aug-11 02:23
Now Ian is upset. This new layout beats my previous best 2 out of 3 (the Words tests):

http://patorjk.com/keyboard-layout-analyzer/#/load/Mc6v9bpr

These scores are getting seriously high (compared to, for example, dear old QWERTY..)

http://patorjk.com/keyboard-layout-analyzer/#/load/j54DMs6c

Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2016-Aug-11 03:43
Silly me. I think I got your ' and " the wrong way around.

Here you go... let's see what Opt thinks of this:

http://patorjk.com/keyboard-layout-analyzer/#/load/kL7W45zf
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2016-Aug-11 04:30
I fixed the '   " on your original layout and it immediately wins Alice (against other layouts on Patrick's site)

http://patorjk.com/keyboard-layout-analyzer/#/load/Rqql9vjZ
Title: Re: Balanced Keyboard Layout
Post by: Den on 2016-Aug-11 11:47
Silly me. I think I got your ' and " the wrong way around.

Here you go... let's see what Opt thinks of this:

http://patorjk.com/keyboard-layout-analyzer/#/load/kL7W45zf

" ring finger
' middle finger

I'm sure you can score better on patorjk by putting N on home row. But putting R or other frequent letter on right pinky will overwork that finger, and worse for rolls. I think Opt puts R on home and N on top because R has more digrams with other consonants. So rolls with R will be faster and more convenient even if other consonants are on top or bottom row.
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2016-Aug-11 12:59
If you look at the numbers here:

http://patorjk.com/keyboard-layout-analyzer/#/load/Rqql9vjZ

then the new layout has the second lowest right pinky travel and usage, against other leading layouts. The only one that's lower is my other OAEH layout.

So I don't think your worries are justified...

Perhaps on other tests the results will be different. I tried loading the layout on the Colemak evaluator and it didn't do so well, but that thing is focused almost entirely on minimizing same-finger usage, and I'm not sure that using just about only that is a good metric.

I discovered that the Adesso keyboards that I have here are good for keytop rearranging... so I've loaded the new layout onto one. Don't really like them as keyboards because they're MS Natural wanna-bes but the key action is not that good. But at least the 'ergo' layout will be less frustrating than ANSI slab.
Need to print some stickers for the relabelled keys. And make an xkb file :)
Title: Re: Balanced Keyboard Layout
Post by: Den on 2016-Aug-12 01:57
If you look at the numbers here:

http://patorjk.com/keyboard-layout-analyzer/#/load/Rqql9vjZ

then the new layout has the second lowest right pinky travel and usage, against other leading layouts. The only one that's lower is my other OAEH layout.

So I don't think your worries are justified...

I look at the pinky usage percentages and make sure each pinky falls under 5% in many typical conditions. With the R on right pinky, there's a high risk of it going way above 5%, even approaching 8%.

Quote
Need to print some stickers for the relabelled keys. And make an xkb file :)

How do you create and distribute xkb files?
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2016-Aug-12 02:48
XKB: I use Kate (text editor) to modify a file and then paste it into a suitable spot in
/usr/share/X11/xkb/symbols/us   (since it's a variant of the US layout).

Then I add appropriate entries to
/usr/share/X11/xkb/rules/base.lst
/usr/share/X11/xkb/rules/base.xml
/usr/share/X11/xkb/rules/evdev.lst
/usr/share/X11/xkb/rules/evdev.xml

The docs on the web are a little vague on that, apparently not all 4 are necessary but I haven't had time to fiddle, and thought it better to keep them all in synch. I use KDE so the changes are auto-detected in System Settings, apparently the people on Gnome and cousins need to restart their desktop.

Sample xkb file below.

Was testing the new layout against my 9428-line perl program, and your Balanced12 comes up best. Then I noticed that the version on Patrick's site is not correct ... it's missing the } and it has a dash, underscore plus another similar looking character loaded with Unicode code. I modified it to put the } on the 8. You should ask Patrick to fix it (via github), he fixed the INA layout for me which had a similar issue.

Still trying to figure out exactly how Balanced12 comes out on top, must be something to do with the punctuation. It gets 49.97 while the best I've got BEAKL4--modified to is 48.79, and everything else lower (HIEAMTSRN-improved gets 46.96, MTGAP 44-something), so you can see it's doing something right that the others are not.

Here's the current version that I'm playing with, the numbers and punctuation are still a mess. Moved some other minor keys around as they got better scores on the other three tests. Looks neater in fixed-pitch font :-)

// HIEAU Keyboard Layout symbols for xkb on X.Org Server 7.x
// 2016-08-12 Den + Ian Douglas. http://www.iandoug.com

partial alphanumeric_keys
xkb_symbols "hieau" {

    name[Group1]= "English (HIEAU - 1)";

    include "us(basic)"

    // Alphanumeric section
    key <TLDE> {  [        grave,  asciitilde, dead_grave, dead_tilde  ] };
    key <AE01> {  [            1,  equal                               ] };
    key <AE02> {  [            2,  plus                                ] };
    key <AE03> {  [            3,  parenleft                           ] };
    key <AE04> {  [            4,  dollar                              ] };
    key <AE05> {  [            5,  percent                             ] };
    key <AE06> {  [            6,  asciicircum                         ] };
    key <AE07> {  [            7,  ampersand                           ] };
    key <AE08> {  [            8,  parenright                          ] };
    key <AE09> {  [            9,  numbersign                          ] };
    key <AE10> {  [            0,  asterisk                            ] };
    key <AE11> {  [  bracketleft,  braceleft                           ] };
    key <AE12> {  [ bracketright,  braceright                          ] };

    key <AD01> {  [ k,          K         ] };
    key <AD02> {  [ y,          Y         ] };
    key <AD03> {  [ o,          O         ] };
    key <AD04> {  [ comma,      caretleft ] };
    key <AD05> {  [ z,          Z         ] };
    key <AD06> {  [ f,          F         ] };
    key <AD07> {  [ c,          C         ] };
    key <AD08> {  [ l,          L         ] };
    key <AD09> {  [ p,          P         ] };
    key <AD10> {  [ q,          Q         ] };
    key <AD11> {  [ minus,      underscore] };
    key <AD12> {  [ semicolon,  colon     ] };

    key <AC01> {  [   h,  H   ] };
    key <AC02> {  [   i,  I   ] };
    key <AC03> {  [   e,  E   ] };
    key <AC04> {  [   a,  A   ] };
    key <AC05> {  [   u,  U   ] };
    key <AC06> {  [   d,  D   ] };
    key <AC07> {  [   s,  S   ] };
    key <AC08> {  [   t,  T   ] };
    key <AC09> {  [   n,  N   ] };
    key <AC10> {  [   r,  R   ] };
    key <AC11> {  [   v,  V   ] };
   
    key <AB01> {  [   j,          J          ] };
    key <AB02> {  [   quotedbl  , question   ] };
    key <AB03> {  [   apostrophe, slash      ] };
    key <AB04> {  [   period    , rightcaret ] };
    key <AB05> {  [   exclam    , at         ] };
    key <AB06> {  [   w         , W          ] };
    key <AB07> {  [   g         , G          ] };
    key <AB08> {  [   m         , M          ] };
    key <AB09> {  [   b         , B          ] };
    key <AB10> {  [   x         , X          ] };
    // End alphanumeric section

//    key <CAPS> { [    BackSpace,       Escape,       BackSpace,        BackSpace ] };
   
    include "level3(ralt_switch)"
};

additions to the .lst files:
hieau           us: English (HAEIU - 1)

additions to the .xml files:
   <variant>
          <configItem>
            <name>hieau</name>
            <description>English (HIEAU - 1)</description>
          </configItem>
    </variant>

paste, for example, just before the closing </variantList> before the Afghani section starts.
       </variantList>
    </layout>
    <layout>
      <configItem>
        <name>af</name>
        <shortDescription>fa</shortDescription>
        <description>Afghani</description>
 

Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2016-Aug-12 02:52
I think it will be worthwhile to write some Perl to convert between various config files, eg from Keyboard Layout Editor to Keyboard Layout Analyser, xkb, and the two config files that Win and Mac use. Generating the '30-keys' map should be possible but these things REALLY need to be 31-keys at least, and preferably 'entire keyboard' .... :-)
Title: Re: Balanced Keyboard Layout
Post by: Den on 2016-Aug-12 04:15
Can you add new layouts to xkb without modifying existing files? In other words, create only new files and zip them into a single .tar.gz file for easy distribution. Then the user just has to unzip the files and choose the new layout in the system settings.

Balanced 12 was not created by me, although the vowel district does resemble BEAKL 1. It does very well under my AdNW tests. Right in between MTGAP (1st) and BEAKL 4 (3rd) in default settings, but they were all very close. Under my modified settings, Balanced 12 scored better than MTGAP, but not as good as Bu. Naturally all the BEAKL layouts scored the best by a mile under my settings.

Some programs may not properly read non-ASCII characters, so presence of these characters in the layout may mess up the scores.
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2016-Aug-12 04:32
Whoops.... all this time I've assumed Balanced 12 was yours ... sorry :-) . It does do pretty well in the scoring.
I'll ask Patrick to fix it.

Re the xkb files, I don't know.... it would be nice, but there are the config files that need to be edited, and you can't just 'replace' whatever the user happened to have on his system, because it could have been modified.

The 'clean' way is to get your layouts added upstream by the xkb maintainers, and then it will be automagically added when people update their systems. Eg Norman, Workman, etc, have followed that route. I don't think you need to beg them to add the layouts, or pay them money, but I guess they have some criteria to stop every 'new' layout getting added, when no one uses it. I suppose getting some community support for the layout would help. Build a 'vibe' etc.

I'm actually busy building a new site which will, amongst other things, deal with new layouts and attempt to track and report on the good/better/best ones.

Cheers, Ian
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2016-Aug-12 07:15
Finally beat Balance 12 at Perl:
#1 Prog BEAKL 4 Mod Ian 71.71 74.63 74.10 c70.01 s48.97 : 50.16
#2 Balance Twelve : 49.97
#3 HIEAMTSRN Improved 3 : 46.96

But only by swapping your ' and " around, because the program makes heavy use of ".

So those scores in the layout name become
1 Prog BEAKL 4 Mod Ian 71.40 74.61 74.10 c70.05 s50.16

c == my large text corpus
s == s.pl, the program
Alice drops the most because it uses the ' for all the dialogue.

Layout is here: http://patorjk.com/keyboard-layout-analyzer/#/load/gR5B6vzV

Will probably suck for people use Emacs because I switched the ~ and ` around. Perl uses ~ a lot.

Cheers, Ian
Title: Re: Balanced Keyboard Layout
Post by: Den on 2016-Aug-12 14:01
I did name earlier ones Balanced layout, but apparently someone else also came up with a similar name (Balance without 'd') much later.

Looking back at my earlier Balanced layouts (http://www.shenafu.com/layout.php), one of them has the home row OAEID RHTNS. of which the vowels kind of resembles your OAEH. totally forgot why I arranged them like that, but apparently it was copied directly from Klausler, which at that time I was very impressed and learned a lot from.

Title: Re: Balanced Keyboard Layout
Post by: Den on 2016-Aug-12 14:15
Re the xkb files, I don't know.... it would be nice, but there are the config files that need to be edited, and you can't just 'replace' whatever the user happened to have on his system, because it could have been modified.

The 'clean' way is to get your layouts added upstream by the xkb maintainers, and then it will be automagically added when people update their systems. Eg Norman, Workman, etc, have followed that route. I don't think you need to beg them to add the layouts, or pay them money, but I guess they have some criteria to stop every 'new' layout getting added, when no one uses it. I suppose getting some community support for the layout would help. Build a 'vibe' etc.

I'm actually busy building a new site which will, amongst other things, deal with new layouts and attempt to track and report on the good/better/best ones.

Cheers, Ian

It kind of catch 22. If it's cumbersome to install new layouts, people won't try and use them. And if nobody uses them, they won't add new ones.

Obviously I would like to submit a layout to the official patches eventually. However we still need to settle and decide on a final version that we all feel satisfied on. And then hopefully be accepted by the public. I wonder if I can sell to them the claim to reduce pinky usage and fatigue. And of course test scores  :P

Title: First new idea in keyboard layout since, um, ergo and thumbkeys
Post by: iandoug on 2016-Aug-12 17:27
It's not every day a new idea comes along, but today is your lucky day... :-)
You can look if you promise not to laugh...

http://patorjk.com/keyboard-layout-analyzer/#/load/FH8z8sHL
(its for the SAT words but you can then see the layout. Regret I can't share the input source.)

Actually had the idea a few days ago and finally got around to trying it out.

Here's the scores when run against my perl program as input. The program is not just perl, it outputs HTML/Javascript/PHP, and contains data arrays with address, geo co-ordinates,  and phone number data.

(http://i.imgur.com/CJuR0td.png)

Finger travel:

(http://i.imgur.com/j8Lrq28.png)

(http://i.imgur.com/4OoFRAO.png)

Consecutive finger use, excluding doubles.

(http://i.imgur.com/TJVU9L4.png)

In all cases you need to compare it against its peers, not just absolute. The input file is not your typical Alice file :-)

I must still doublecheck I didn't miss any characters when rearranging.

As an experiment I ran it against the first 1000 digits of pi, where it did very badly, second worst, but still beat Balance 12. I reality, if you are entering something like that, you'll use the numpad not the numrow.

Cheers, Ian
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2016-Aug-12 17:34
The number and punctuation layouts are based off of Michael's frequency lists, and then guided by heatmaps.
Layout is rather bizarre at first glance, but then so too is QWERTY.

Cheers, Ian
Title: Re: Balanced Keyboard Layout
Post by: Den on 2016-Aug-12 21:40
It's pretty novel idea. Have you actually tried typing this way, and how does it feel? However the brackets seem all over the place, hard to find and memorize.

Speaking of numpad, you could try secondary layer like Kinesis. But the num-lock key to switch between modes should be more accessible, like at the thumb.

It has been argued that optimizing punctuation (and maybe numbers) may be fruitless because they're not used often. So if one would rearrange them, it would be very personal, based on one's personal habits and whatever programming language one uses the most.

Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2016-Aug-13 10:16
It's pretty novel idea. Have you actually tried typing this way, and how does it feel? However the brackets seem all over the place, hard to find and memorize.

No, only did the tests last night. Was impressed with the scores and just shared. I ran another test with a longish PHP/Mysql program and it is a clear winner (ie 60 vs 50 for MTGAP. Some other layouts score higher than MTGAP, including Balance 12, even ADNW and that BePov-whatever one. Didn't check them all, but know from experience which are likely to score high).

Yes the brackets etc are all over the place. It bothers me too. But it's hard to argue with the numbers... after all, we all learned how to type QWERTY and that's also all over the place.

Speaking of numpad, you could try secondary layer like Kinesis. But the num-lock key to switch between modes should be more accessible, like at the thumb.

I have a 'problem' with 'layers' in that I have enough trouble hitting + instead of = (or vice versa) without having to remember what's the third or 4th level character on a key... when I'm coding I have enough other things to worry about than needing all that extra processing in my head. But I accept that some people say it works for them... they like smaller and smaller keyboards, I prefer dedicated keys for as much as possible. Hence my rather large keyboard layout.

I'm just trying to optimise ANSI because it's a challenge and I figured I could beat MTGAP, Balance 12 and HIEMNSTRA...

ANSI is not the best layout to start with, and while a better logical (as in 'move the keys around') layout is a step in the right direction, we need to start with form factor first, eg ergo style.

Which creates another problem... how do you take an arguably good layout and move it from ANSI to Ergo... without losing the goodness, and still gaining from the thumbkeys?...


It has been argued that optimizing punctuation (and maybe numbers) may be fruitless because they're not used often. So if one would rearrange them, it would be very personal, based on one's personal habits and whatever programming language one uses the most.

Agreed.... but if I'm building a keyboard for 'programmers', or even just for myself, then why not? :-)
I realise not every language uses {} or </> but if they are not interfering with anything else, then might as well optimise...

I need to find white-on-black tape for my Brother p-touch label printer to make some stickers. Then I can try typing on that weird layout and see how it goes ...

Also need to stop trying to optimise... wish there was a way to measure/know when Max Optimum has been reached... :-)

Cheers, Ian
Title: xkb
Post by: iandoug on 2016-Aug-13 10:41
Re xkb, came across these rather old instructions for installing Carpalx:



INSTALLATION INSTRUCTIONS
=========================

 
1. Copy carpalx.xkb to your XKB symbols directory (path my differ slightly)

    $ cp carpalx.xkb /usr/share/X11/xkb/symbols/carpalx

2. Add the following lines to /usr/share/X11/xkb/symbols.dir

    -dp----- a------- carpalx(qgmlwb)
    --p----- a------- carpalx(qgmlwy)
    --p----- a------- carpalx(qfmlwy)
    --p----- a------- carpalx(qwkrfy)
    --p----- a------- carpalx(qwyrfm)
    --p----- a------- carpalx(tnwmlc)

3. Now it should be possible to load the layouts with, e.g.

    $ setxkbmap carpalx                            # defaults to QGMLWB
    $ setxkbmap -layout carpalx -variant qwkrfy    # to select other variants


4. The following files should also be updated:

    /usr/share/X11/xkb/rules/xorg.lst
    /usr/share/X11/xkb/rules/xorg.xml


NOTE: You can find examples of such files being modified in folder

    usr-share-X11-xkb-rules

under the current folder. You can diff between the old and new versions
in order to see what the differences are. Changing these files, you will
be able to change keyboard layouts using configuration applets offered
in Gnome and KDE.


Useful documentation:
    http://www.khjk.org/log/2011/jan/carpalx.html
    http://hektor.umcs.lublin.pl/~mikosmul/computing/articles/custom-keyboard-layouts-xkb.html
    http://people.uleth.ca/~daniel.odonnell/Blog/custom-keyboard-in-linuxx11

Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2016-Aug-16 16:05
So I went back to the drawing board after the last radical double-decker numerals makeover, and continued with the layout we had before.

I have successfully tweaked it to the top scores against other notable layouts with different inputs, including Perl and PHP. Results against Alice are here, so you can see the layout. It's basically the "Programmers" variant of the other layout.

http://patorjk.com/keyboard-layout-analyzer/#/load/RSDqvq5L

The "distance" scores are not the lowest, but the "same finger in succession" scores are good. So it can't be all bad.  I suppose if we compare them to QWERTY instead of other top layouts then the scores are not that bad.

On the Plus side, Ctrl- X, V, Z, M, B, R and T (last two for browsers) are convenient (on right hand), while Ctrl- S, A and C are not so convenient.
The numbers in the titles of slot 1 and 2 refer to the scores on Alice, Common Words, SAT words, my large Corpus, s.pl (large Perl program with HTML and PHP generated), and a largish PHP/MySQL program.

I did spend some time trying to achieve lowest "distance" scores and came to the conclusion that it would need to be based off the 11 most common letters going on the home row... but could not get a sane layout for that. The BvoFRak EN V0.5 seems to excel in getting low 'distance' scores, and it's "almost" based off those letters. I tweaked it a bit and was able to get lower 'distance' scores, but at the same time the overall score went down.

I'm wondering if getting a High Score as well as a Low Distance score are mutually exclusive goals.

I also tried an experiment (after seeing what BvoFRak EN V0.5 did) of moving the Left Hand Home position one key to the right to open up a column on the left pinky but that didn't work so well. Also not possible on an MS Natural or Adesso split keyboard. (if you still want a column to the right of the left index)

After painstakingly moving the keys, and relabelling others, on my Adesso, I realised that it has profiled keys and you can't just move a row 1 to row 3 .... so will have to revert it to QWERTY and then relabel all those that change rows. Will move what I can if in same row. Will try the layout in slot 1 on URL above. Note that it contains a manually fixed Balanced 12 layout.

I also note that were we are now has a lot in common with BvoFRak EN V0.5 and HIEAMTSRN Improved 3 .... which I suppose is to be expected, there are a finite number of sane layouts, particularly on the home row :-)

Cheers, Ian

Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2016-Aug-16 16:07
Re the last layout, you can boost the score on Alice by moving the single quote under the E, and putting the parentheses on the middle fingers.
Title: Re: Balanced Keyboard Layout
Post by: Den on 2016-Aug-17 20:09
I just got my new Kinesis. Just in time because some keys on my old one is getting sticky. So I'm gonna spend some time to play with it.
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2016-Aug-18 01:57
Enjoy :-)

Did you see that new 40% board coming to Massdrop?
Title: Re: Balanced Keyboard Layout
Post by: Den on 2016-Aug-18 21:21
The keys are more clicky, less soft than my old keyboard. probably need time to adjust.

There are no application to modify the layouts. You do it using the keyboard one key at a time, or create and edit text files. A special key combination opens the onboard drive to the OS, then you can open it in a file manager and read and write to the files. You can switch between layouts using special hotkeys, based on special file naming convention.

This has some consequences.
1. You can't use the OS to change layouts. Must keep it at locale default, such as QWERTY. Otherwise the mappings get mangled.
2. The unshifted and shifted characters move together. That means punctuation stick together in their default pairs. e.g. dot and greater-than sign always found on the same key. So we can't mix and match the punctuations to our preferences. e.g. I like to move parentheses () down with the letters and <> up to with the numbers. But I can't do that unless I move the numbers down.

I might make a HTML form to facilitate creating layout code that will be accepted by the keyboard. My BEAKL file looks something like this:

Code: [Select]
b_qwerty.txt

[T]>[K]
[R]>[.]
[E]>[O]
[W]>[Y]
[Q]>[J]
[G]>[U]
[F]>[A]
[D]>[E]
[S]>[I]
[A]>[H]
[B]>[X]
[V]>[,]
[C]>[']
[X]>[;]
[Z]>[Q]
[Y]>[G]
[U]>[C]
[I]>[M]
[O]>[N]
[P]>[Z]
[H]>[D]
[J]>[S]
[K]>[T]
[L]>[R]
[;]>[P]
[N]>[W]b
[M]>[F]
[,]>[L]
[.]>[B]
[/]>[V]

[escape]>[caps]
[caps]>[lctrl]
[lshift]>[escape]
[lctrl]>[lshift]
[rctrl]>[rshift]
[']>[rctrl]
[rshift]>[']
[delete]>[bspace]
[bspace]>[space]
[enter]>[delete]
[space]>[enter]
[rshift]>[hyphen]
[=]>[intl-\]
[obrack]>[/]
[cbrack]>[kpplus]
[intl-\]>[=]
[hyphen]>[obrack]
[\]>[cbrack]


[1]>[9]
[2]>[3]
[3]>[1]
[4]>[5]
[5]>[7]
[6]>[6]
[7]>[4]
[8]>[0]
[9]>[2]
[0]>[8]

Square brackets [] mean single key replacement, as opposed to macros in curly brackets {}. Left of the greater-than > sign means the location of the key (in QWERTY). Right side means the new output of the key. e.g. [T]>[K] means the T key should output the letter K.

You can also modify the keypad (secondary) layer, but I have no need for that. I did bring the plus + sign from the keypad layer to the top (main) layer because I want to quickly access it unshifted (as seen by the code [cbrack]>[kpplus]).
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2016-Aug-19 02:18
You sound a bit disappointed (and frustrated).

Which OS are you using?

According to Kinesis site, both old and new use Cherry MX brown switches, but I've think I've heard rumblings on the net about them switching production to China and/or doing something that lowers quality. There's plenty of competition now that their patents have expired. Possibly they just need a few thousand presses to get a nice feel. :-)

There are guys in Korea who disassemble, lube, and add 'stickers' inside the switches to improve the action. A bit too otaku for me :-)
Eg
http://www.gonskeyboardworks.com/manuals/137-parts-needed-for-a-kbd.html

I find it odd that you can't use the OS to remap the keyboard, the board should send standard "scan codes" to the OS, what the OS does with that does not concern the board....

Cheers, Ian
Title: Cheating?
Post by: iandoug on 2016-Aug-20 16:59
I suppose this may be considered 'cheating'.

http://patorjk.com/keyboard-layout-analyzer/#/load/28ZD4Fps

Basically I got fed up because I couldn't tweak BEAKL Mod to beat BvoFRak EN V0.5 and Colmak and HIEAMTSRN Improved 3 on Distance and Same Finger usage... one or more always had a better score on one or the other.

So I thunk outside the box.

Never actually tried to type like that, it may not be very practical :-)

I see on the 'words' tests it STILL flipping does not win. At least it does give MTGAP Thumbshift (not included above) a run for the money.

Will have to think some more ....
Title: Re: Balanced Keyboard Layout
Post by: Den on 2016-Aug-21 18:44
i don't get hung up on these arbitrary distance scores. their opinion on how to measure distance and effort wildly differs from mine. other tests are less arbitrary, like number of times a key is pressed and same hand/finger.

that H is way out there, though. really bad for HE digram, too.
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2016-Aug-22 01:29
that H is way out there, though. really bad for HE digram, too.

I trust you noticed I put it on the left thumb? :-)

Cheers, Ian
Title: Re: Balanced Keyboard Layout
Post by: Den on 2016-Aug-23 17:59
I trust you noticed I put it on the left thumb? :-)

Cheers, Ian

I did miss that. I've tried using thumb on the bottom row, but it feels really uncomfortable to curl the thumb like that.
Title: Re: Balanced Keyboard Layout
Post by: Den on 2016-Sep-04 04:34
Any modern keyboard layout should take into consideration the entire desk and other devices on the desk used by the user. i.e. the ubiquitous mouse and its relation to the keyboard. With most users being right-handed, thus the mouse operated by the right hand by vast majority of users, we may assume the user has the left hand perched on the left half of the keyboard. Thus we can assign common utility keys on the left of the keyboard within easy reach. Including space, enter, escape, etc.

The most essential key here is space. (...) Thus we want to place it on the left hand. Naturally the vowel district follows the space to the left hand during optimization.

Furthermore the most common numeral digits should also go on the left hand so that they may be typed without lifting the right hand off the mouse. I propose the order of the number row as such:

Code: [Select]
40123 87659
per the frequency of each digit. The five most common numbers fall on the left hand. The sequence and symmetry gives a sense of order and ease of use. Coincidentally and fortunately the dot/period falls in line with the vowel cluster on the left hand, so fractional values can also be typed mainly with the left hand.

Likewise the numpad could do some optimization as well. Something like this:

Code: [Select]
546
021
378
. 9

where the dot/period is hit by the thumb. With the numpad operated by the right hand, this order allows better rolls.
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2016-Sep-07 17:35
Mmm I don't think I got an email when you posted your message on the 4th. Odd.

Anyway I have applied my mind to the "distance" problem (like a mountaineer, because it is there.. :-) )... and have succeeded in getting low scores on all three tests on Patrick's site. Except for Alice, where I could not beat Arensite, but then I had a look at what he did ... and decided to beat him at his own game. It may be considered a bit of a cheat .... basically you need to put the right shift on the AltGr key ... which takes a lot of work off the right pinky. It's also arguably 'better' to do shift with the thumb, your hand can reach other keys better.

I've also build a spreadsheet which analysed the layouts and three main scores: the overall score, the distance (well, Patrick's version), and same finger use (excluding duplicate letters). Further to that I'm building a site about keyboards, I'll post the data there .... it's easily sortable so it's quick to see how any given layout scores. It will hopefully be up and running tomorrow (but not for public consumption, still very much 'in development').

Needless to say BEAKL mod Ian gets the best overall scores, while my new LoDi (low distance) range basically dominates the distance scores. Have not cracked the same finger metric very well yet ... but the ones that get good marks there tend to not do so well in Distance or overall score. Then I need to find a way to marry the best with the best.... :-)

Cheers, Ian
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2016-Sep-08 09:35
Still mostly broken site and a lot to do.
Table is here.
http://www.keyboard-design.com/best-ansi-layouts-as-determined-by-keyboard-layout-analyzer.html

Think it's kinda working ... out of practice at launching new sites :-)
Using Semantic UI as well for the first time, which brings its own issues..

Cheers, Ian
Title: Re: Balanced Keyboard Layout
Post by: Den on 2016-Sep-08 17:45
Thats a huge chart. Don't tell me you typed them all manually? 😃

You should promote that chart to other higher traffic sites (when it's ready). Will generate more discussion (and quarreling between fandoms of popular layouts 😃.)

I notice it's missing BEAKL layouts without your mods. Could add them? Mainly versions 1, 3, and 4 bare bones.
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2016-Sep-08 18:12
Yes, manually typed, but not all at once... :-)

Actually came here to get your BEAKL 4... will have to construct them from scratch as I don't have them.

I have (finally) managed to get something with low same-finger usage on Alice, but beating STDC on the words tests is going to be a challenge... those words are not natural. I took a look at the SAT words... lots and lots of "ious" and "ous"... so my comment re American spelling not really valid there :-)
But people don't type those words so frequently in real life.
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2016-Sep-08 18:35
Went through this entire thread, think I found the json for your BEAKL layouts. Will sort out tomorrow ... still building movie pages.

Cheers, Ian
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2016-Sep-08 19:02
Have added BEAKL Opted 4 to the table, the others are Ergodox layouts which are not done yet.... will be in separate table.

Just check I had the right layout please... :-)
http://patorjk.com/keyboard-layout-analyzer/#/load/CMLP7qQz

Cheers, Ian

Title: Re: Balanced Keyboard Layout
Post by: Den on 2016-Sep-08 19:44
Have added BEAKL Opted 4 to the table, the others are Ergodox layouts which are not done yet.... will be in separate table.

Just check I had the right layout please... :-)
http://patorjk.com/keyboard-layout-analyzer/#/load/CMLP7qQz

Cheers, Ian

Yea it looks correct.

BEAKL Opted 1 is still impressive when you allow letters to go outside the 30 main keys. Have you explored that area and how far? Extend two keys to outside each hands, so optimize 34 keys. The extra characters worth adding are -/()
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2016-Sep-08 19:53
Yea it looks correct.

BEAKL Opted 1 is still impressive when you allow letters to go outside the 30 main keys. Have you explored that area and how far? Extend two keys to outside each hands, so optimize 34 keys. The extra characters worth adding are -/()

You mean on Ergodox? I went all over on that layout... didn't check with the original to see how it was supposed to look, just saw keys in weird places and tried things... :-)

I've actually been thinking about why we are limited to 3 main rows (instead of 4 ... ) ... I suppose the touch typists think their fingers have to rest on some keys, instead of, for example, being between two rows ....

I looked at the Arensito page, very old, but his initial design uses the top 3 rows rather than the bottom 3 ... in truth he requires a non-standard keyboard for his layout. I may revisit some of his ideas when I get around to my own design (once I get a logical layout that I'm happy with).

Arensito: http://www.pvv.org/~hakonhal/main.cgi/keyboard

Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2016-Sep-09 05:51
Until such time as I put the layouts up, here's a link showing the current top scorers (score only).(IHEAUDS 73.31 and BEAKL 4 Mod Ian 73.08 74.70 74.19)

I've included your BEAKL4 as well, so you can see how my mod differs from it.

http://patorjk.com/keyboard-layout-analyzer/#/load/jnZtFvL6

Managed to tweak my HIEAMTSRN mod to get the lowest same-finger score (36) on Common Words... just the SAT words left to conquer. :-)

Cheers, Ian
Title: Re: Balanced Keyboard Layout
Post by: Den on 2016-Sep-09 06:25
If we also include 4 thumb keys, that would total up to 38 keys to optimize.

Actually it seems stretching fingers is easier, so it makes sense to start at a lower row. On Kinesis it's quite easy to reach number row. The curvature could benefit that more than the bottom row, even if the latter is closer.

Arensito is just moving one row up, which I don't see much benefit, whether on standard or Kinesis. As explained above, I would accept the number row, but the home and top rows stay in place. Remember stretching fingers is good, so the fingers have to remain low in order for them to stretch.

For example I'll swap the bottom and number rows for quick illustration:

Code: [Select]
BEAKL 4 Stretch

q"',x wflbv
jyo.k gcmnz
hieau dstrp
40123 87659

You can see the home row and top row letters did not move to new rows. They stay the same place on the keyboard.

Of course this is most likely not optimized. We'd have to reassign the effort scores, etc. The main difference off-hand is the distance is farther between home and number row. Nevertheless, that may still be better for row jumping. e.g. jumping from home to old-number row may be better than jumping from bottom row to top row.

Actually the bottom row on the Kinesis feels kind of nice as the home row. It's curved up to meet the fingers which could tap inwards instead of downward.
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2016-Sep-09 06:47
Um, if home row is in same place then I don't think it is necessary to reassign effort scores .... keys are still the same distance away. ?
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2016-Sep-09 06:52

Patrick's analyzer really doesn't like the idea... :-) distance scores go way up.
Title: Re: Balanced Keyboard Layout
Post by: Den on 2016-Sep-09 08:22
Kinesis bottom row as home row feels really nice, and so is stretching to the top row. Quick results gave this:

Code: [Select]
BEAKL Stretched

j"'.xwfmbz
qyoukgclrv
hiea,dstnp

Pretty reasonable, not far departure from BEAKL 4.
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2016-Sep-09 08:33
Interesting idea. The 'curling' fingers in always feels awkward to me. I suppose the staggered layouts make it worse.

On another note entirely, I ran some layouts using Google's home page (which is mostly very messy Javascript, disguised by the plain interface).

Results were 'interesting'.
                                   score     distance      samefinger
Colemak                   31.69   764412   16684
MTGAP                   34.15   803772   14322
HIEAMTSRN-Mod Ian 7       46.13   650171   10913
IHEAUDS-73.31                46.67   674424   10377
BEAKL-4-Mod-Ian-73.08    46.71   675512   10375
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2016-Sep-09 08:38
Clearly we are doing something right ;-)
Title: Re: Balanced Keyboard Layout
Post by: Den on 2016-Sep-09 09:00
I really like it. It's really intuitive. You should try it.

The N moves back to the "home" row, and the R up, which makes PR bigram feel quite good. The U moves next to the O, which is another great move.
Title: Re: Balanced Keyboard Layout
Post by: Den on 2016-Sep-09 09:16
yea it seems like HIEA is a breakthrough. and some form of STRN on the opposite side.
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2016-Sep-09 10:26
Can you maybe load your new layout on Patrick's site and post the link?

thanks, Ian
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2016-Sep-09 10:29
And Ian is seriously annoyed with Arensito for getting these numbers on Google's home page;

61.27   402296   5490

At the moment all I can think is that somehow his layout is tripping up Patrick's analyzer. The Arensito variant does not do nearly so well:
31.58   804118   14919

Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2016-Sep-09 17:00
His layout as loaded on Patrick's site seems to be missing the ":" character, unless I am overtired or going blind .... and since Google's home page is dense css and javascript, there are lots of ":"s ....

Neo 2.0 also got a high score on Google, this layout is missing brackets...

I think Patrick just ignores letters not on the keyboard, which leads to misleading results.

Have mostly finished capturing the Google scores, just all my umpteen variants I need to load ... I need to start removing the weaker ones.
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2016-Sep-09 19:00
Have updated the table, removed my weaker variants, added analysis of Google home page, and got a new high score (and low Same Finger at the same time) on Alice ...

So not a bad day... :-)

Title: Re: Balanced Keyboard Layout
Post by: Den on 2016-Sep-09 19:19
Here (http://patorjk.com/keyboard-layout-analyzer/#/load/xkhksTsj) are conglomerate of BEAKL 1, 3, 4, 4 Ergo, and Stretch. Once you set home fingers to the bottom row, it scores very well. Almost as good as BEAKL 3.

Code: [Select]
BEAKL Opted4 Ergo
73.55

BEAKL Opted4
70.17

BEAKL Opted1
69.98

BEAKL Opted3
67.92

BEAKL Stretch
67.33
Title: Re: Balanced Keyboard Layout
Post by: Den on 2016-Sep-09 20:03
Just for fun, I tried to optimize a layout that kept ZXCV at bottom left while applying BEAKL philosophy. It came out like this:

Code: [Select]
ZXCV Opted

qnlfg  .iodj
prstlm  uaehb
zxcvw  ',"yk


It scores between MTGAP and Colemak.
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2016-Sep-10 14:17
Have updated the scores page, now running from a database. Can select what you want to see.
Added some scores from Putin's speech to the UN. (as an example of modern prose).
Page is still a mess of normal HTML styling and Semantic UI styling ... I find Semantic very difficult to work with since everything is in its own div... could not get checkboxes to behave like checkboxes (they looked fine but wouldn't click) so just gave up and went back to plain HTML.

BEAKL 4 Mod Ian 73.08 74.70 74.19 is still a tough cookie to beat on score.

Curiously that it is HI while my leading layouts are IH. I've tried swapping the columns but the scores go down ... think it's related to using the left shift key. The right-hand sides are also different (RN vs NR). My problem is if I go NR then where do I put the P to get nice PR... Mmm maybe R must go on forefinger ....
Title: Low Distance
Post by: iandoug on 2016-Sep-10 14:27
Here's my leading Low Distance layouts ... the one wins Alice, while the 59.8x win Common Words and SAT, as regards low distance.

http://patorjk.com/keyboard-layout-analyzer/#/load/t5rcgP5L

Only way to get low distance is to put O on home row. Which creates other problems.

Cheers, Ian
Title: Re: Balanced Keyboard Layout
Post by: Den on 2016-Sep-10 19:21
They should be default sorted by best average score across all chosen tests.
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2016-Sep-11 05:33
I did consider that ... I actually wanted to have a selection for "sort results by" but in my imagination that user interface got messy doing that, so I just return results alphabetically and the user can then play with the columns.

At the moment I'm just doing a select and printing the rows as I pull them, after massaging the numbers pretty and adding links (well, 1 at the moment) to the layouts. To pre-sort I would need to populate a table with results and then determine some 'average' (see below) for each row, and then sort the table based on that average.

The question is, how is the average calculated?

For simple cases, eg Test1, Test2, Test3, returning Patrick's "Score" only, yes, that is reasonably straightforward... we want the high score. But different tests have different 'ranges' of scores... eg a good score on Alice is over 70, while a good score on Putin is only over 45 or so. So a straight 'average' won't work.

I actually have already built a spreadsheet (attached, if I can figure out how) which attempted this exercise for a few leading layouts and selected tests and results.

The idea was basically this (column headings)

layoutname    [test score  Rank] (have multiple sets of these [ ])
I looked at : Score, Distance, SameFinger, HandBalance (in finger usage).

So I would have a rank in each category, as well as a winner and loser.

If you add up all the Ranks, the lowest overall Rank is the winner, worst is loser.

The overall best in that exercise was BEAKL 4 Mod Ian 71.34 74.65 74.19, with IHEAUDS 71.48 74.47 73.37 second.

But at the same time, IHEAUDS had 11 Bests and 1 Worst, and BEAKL had 10 Bests and 1 Worst. So by that measure, the results should be flipped.

Which is why your suggestion is not so trivial... :-)

Then I got to thinking about "standardizing" each set of scores. The problem is that for example we have scores like this:
75 74 73 65 62 58 55
The difference between the top two is 1, while between the bottom two is 3, but in Ranking, they will only be 1 rank apart, and give a misleading idea of their relative strength.

However if for example, we put the top score at 100%, and then converted each score to a percentage of that, then we would have a consistent way of comparing things.

However, how do we handle the cases where LOW SCORE is desired? I suppose one way would be to do the same exercise, and then subtract everything from 100.... but then "best" does not come out at 100 but at something below it

Eg doing the exercise above for the numbers

75 74 73 65 62 58 55

for Want High, we get 100 98.67 97.33 86.67 82.67 77.33 73.33
for Want Low, we get 0 1.33 2.67 (etc)
and taking averages will just get you 50 each.

I suppose what MIGHT work is if we do this, to standardise LOW score as desired on a percentage scale.

Take max score.
Find next multiple of 10 (eg 100, 1000, 10000, etc).
Subtract each score from this.
Now take resulting high score as 100%, and calculate the rest as a percentage.

so for above we would have
75 74 73 65 62 58 55, giving
25 26 27 35 38 42 45, and taking 45 as 100 (we want LOW SCORE to win), we get
55.55 57.78 60 77.78 84.44 93.33 100

and then I think we can work out an overall average....

I'll have to think about how to do this.... at the moment the program printing the table is doing it 'blind', it does not know nor get which score is good or bad, it's just data to be printed. I'll have to

1. store in table.
2. add bunch of columns to table for the standardised %
3. do the sums, which will need to know which way around to calculate the %
4. sort on total column.

Issues:
1. layouts require score for every test.
2. results of doing this are RELATIVE to other layouts compared ... if I add a new layout tomorrow then all the scores may change if it is good, since all scores are relative to 'best' in any given test.

Going for brunch, will ponder this some more.

Typing helps me think (because it forces both sides of your brain to work together :-) ).

Spreadsheet attached, .ods in .zip. Done with LibreOffice. Not a spreadsheet guru.







Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2016-Sep-11 05:36
"Default" score in spreadsheet is the score for the default text that populates the text box on Patrick's site.

Also regarding "stretched", I think you will need to tweak the analysis because I'm pretty sure all the distances are based on Home row being where it should be ... regardless of where you say your fingers will live. I've tried running his program locally, it loads and runs but the results are a mess.. the 'tabbing' layout does not work. Not sure why.
Title: Re: Balanced Keyboard Layout
Post by: Den on 2016-Sep-11 05:59
"Default" score in spreadsheet is the score for the default text that populates the text box on Patrick's site.

Also regarding "stretched", I think you will need to tweak the analysis because I'm pretty sure all the distances are based on Home row being where it should be ... regardless of where you say your fingers will live. I've tried running his program locally, it loads and runs but the results are a mess.. the 'tabbing' layout does not work. Not sure why.

Reassigning home fingers definitely affects scores. Without doing it, Stretch only scored about 60. After changes, it jumped to 67. Could there still be some other bias? Maybe. Like maybe the number row is too far from home. So maybe we could my original idea by swapping number and bottom rows. And see if that scores better on Patorjk.
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2016-Sep-11 07:38
Have already tried your suggestion I think, scores were not so good. I think we maybe need to do something like
numrow
qwerty
asdf
zxcv

to
qwerty
asdf
zxcv
numrow

but then KLA needs to know that homerow is now shifted up by one.... it affects the distance scores as well as other keys on home row (apart from home keys).

Anyway realised over lunch that my formula for standardizing to LOW score should be

100/(score/minimum)

Example, 50 and 150, 50 is best:
50: -> 100/(50/50) == 100%
150: -> 100/(150/50) = 100/3 == 33.33%

Which looks about right.

Also decided that it will be much easier to let LibreOffice do all these messy calcs, I can them load them in the database, which will the site more responsive.
More later.
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2016-Sep-11 10:14
Have the results on my spreadsheet, all tests. Top 30. Several different variants of IHEAUD|CS. Am surprised IAEHDCS does so well, only stumbled onto it yesterday .... I don't like the fact that left pinky works a bit hard, but the numbers speak for themselves....

Link to top 5: http://patorjk.com/keyboard-layout-analyzer/#/load/bjW0bFrb

Arensito                       85.5453865086
IAEHDCS                     84.9611410774
IHEAQCS                     82.4472692076
IHEAUDS                     81.6353200338
IHEAUCS                     81.630233298
IHEAUDS                     81.5693450842
IHEAUDS                     81.1444153607
HIEAMTSRN                   80.1132358376
HIEAMTSRN                   79.9814712378
STNDC                       79.2283658384
IHEAUDS                     79.1437295271
BEAKL 4 Mod Ian             78.2078933097
BEAKL 4 Mod Ian             75.0225753607
Colemak                     74.4453369389
Aus der Neo-Welt            73.6976925801
HIEAMTSRN                   72.0745854358
NRSTM                       71.3330104301
Balance Twelve              71.2838682852
Colemak                     70.9977722175
Arensito                    70.9919299888
Colemak                     70.7519334525
MTGAP                       70.7486709207
Colemak                     70.7464793632
LoDi                        70.6361898754
Ian OAEH                    70.53085519
LoDi                        69.2987388188
Colemak                     67.8736509498
Vu Keys                     67.5566278433

So I'm very annoyed with Arensito (see how low down the other variant is), but I can't help thinking that it's somehow showing up bugs in Patrick's program. I mean, look how difficult it looks to type "the". I can't believe that it gets such high scores.
I "fixed" it by adding the two missing characters (: and \) and I could see where missing, which only changed the scores slightly.

If you have any ideas as to how it is scoring so well, please advise :-)

Now need to modify my loaded program, and then the code that gets the results for display.

Note: we're actually double-counting here, since Patrick's overall score includes distance, same finger, plus other metrics.
Note 2: BEAKL 4 mod Ian still wins lots on score alone. Other metrics not so good.
Note 3: first Colemak variant above is my right-shift mod.

cheers, Ian
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2016-Sep-11 13:10
Okay new version is up.

http://www.keyboard-design.com/best-ansi-layouts-as-determined-by-keyboard-layout-analyzer.html

Title: Re: Balanced Keyboard Layout
Post by: Den on 2016-Sep-11 16:09
Right, the final score is already the aggregate to determine "winner" on KLA. So the average or sum of scores for all corpuses checked should be default. Name this "Overall Score".

You may also consider additional fields to sum the distances and same fingers besides the overall score. Name these Overall Distance and Overall Same Finger.

This way no additional math is needed. No percent or division. There could be default sort direction for each field, and user can reverse order if they want.
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2016-Sep-11 16:38
Let me think about that. In truth it is tedious keeping my spreadsheet up to date with all the calculations going on.

At present the site does do more or less what you want, in a slightly different way.. eg if you only select to see Scores, then you get what you asked for above, the right hand column is the average of the standardised scores (ie  each score as a percentage of the winner's score). The order will still be the same doing it your way.

Likewise if you select Distance or SameFingers.

I decided to investigate the problem with Arensito and Google ... Google's code is Not Exactly English. They use weird constructs, in particular things like a.b or _. or a, .... and since we have both comma and period on the A finger, the Same Finger scores go through the roof. But A is not a common letter to end a word on in English.

So I think I need to separate that test out (perhaps in a group of other Computer tests), because it is messing up the evaluation of a layout for English.

I know I would never use variables like they have ... nightmare to debug. I assume it is the result of a minimization step where proper variable names are reduced to single letters for distribution.
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2016-Sep-11 18:51
Well the same-finger metrics continue to drop.... :-)

Have decided to split the table into two sections:
1. unremapped keys (ie you can move keys around, but no relabelling)
2. remapped keys

That way we can compare apples to apples better.

Might have an "all comers" the same as current as well.

I should probably go to bed now...
Title: Re: Balanced Keyboard Layout
Post by: Den on 2016-Sep-12 01:20
The key to Arensito seems to be activating the special characters with Alt-Gr rather than reaching to a distant row. This works in its favor when inputting code.

edit: or maybe this layer forgot to calculate the actual keys. you can see the heat map that Arensito is extremely light when testing with code. whereas other layouts have heavy usage on many keys.

QED the Alt-Gr layer is miscalculated. It subtracts distance and finger usage.
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2016-Sep-12 09:41
Here (http://patorjk.com/keyboard-layout-analyzer/#/load/xkhksTsj) are conglomerate of BEAKL 1, 3, 4, 4 Ergo, and Stretch. Once you set home fingers to the bottom row, it scores very well. Almost as good as BEAKL 3.

I have added these (except ergo) and implemented some of your suggestion. I think for distance and samefinger I need to use the methodology I was using previously, but done by PHP not me fiddling in spreadsheets.

Also added another test.

BTW the v4 linked above must be slightly different to the one I had, some scores were better.

Arensito also has () and - on Alt-Gr, so that's probably boosting the score in other places too.
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2016-Sep-13 03:50
I see VU Keys layout does very well, and was surprised to see why ... it's largely a mirror of what we're doing.

Curious that I arrived at something similar starting from a completely different place. I suppose it validates the design ideas to a large extent.
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2016-Sep-13 10:00
So I added a new test (KLE) and my poor 'best-at-English' gets clobbered down the rankings.

I suspect it's because the text makes heavy use of < and > which need the right shift as opposed to the left, and the difference to that key from Home is higher on the right hand side than on the left hand side ... amazing how a few millimetres adds up... :-)
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2016-Sep-14 14:51
Mmmm...

https://geekhack.org/index.php?topic=73978.0
Title: Re: Balanced Keyboard Layout
Post by: Den on 2016-Sep-14 16:14
Mmmm...

https://geekhack.org/index.php?topic=73978.0

seems overboard and doesn't look that comfortable. thumbs shouldn't fan out that much. better to move whole arm and hand to hit farther keys.

the pinky is way too low, causing too much bend. it's not the natural at-rest position, and would be a pain to hit the lower pinky key. remember how we said we like stretches, not bends.
Title: Re: Balanced Keyboard Layout
Post by: Den on 2016-Sep-14 16:42
I've actually been thinking about why we are limited to 3 main rows (instead of 4 ... ) ... I suppose the touch typists think their fingers have to rest on some keys, instead of, for example, being between two rows ....

4 rows can be great if your typing style is moving around a lot, like Sean Wrona. Moving the whole arm is usually faster and less straining than stretching and bending only the fingers. But for traditional typists, extra rows doesn't seem conducive for the nice rolling action we are accustomed to.

Quote
I looked at the Arensito page, very old, but his initial design uses the top 3 rows rather than the bottom 3 ... in truth he requires a non-standard keyboard for his layout. I may revisit some of his ideas when I get around to my own design (once I get a logical layout that I'm happy with).
Arensito: http://www.pvv.org/~hakonhal/main.cgi/keyboard

His reason to move the letters up is so he can put all the special keys on the bottom row, which would be hit with the thumbs. Essentially mimicking the Kinesis and other keyboards that have a thumb cluster.
Title: Re: Balanced Keyboard Layout
Post by: Den on 2016-Sep-14 19:09
Have you tried altering "our" layouts to have Alt-Gr layer like Arensito? and compare stats.
Title: Re: Balanced Keyboard Layout
Post by: Den on 2016-Sep-15 00:48
To improve Stretch, consider if we remove the far top index and pinky finger and replace with the awesome under-index bend and side-pinky.

Code: [Select]
BEAKL Stretch Numdown

  "'x   wmb   
 qyouk gdlnv     
jhiea, cstrpz   
    .   f   


BEAKL Stretch Numup

  "'.   wmb   
 jyoux gdlnv   
qhiea, cstrpz
    k   f     

where the dot/K and F are now under the home index, and J/Q and Z are outside the home pinkies. The top index and pinkies are unassigned.

The effort has been improved by 15.% from the previous Stretch layout.

The most bottom row for Numdown contains the numerals. And naturally the dot/period is right beside them. In Numup, the number row stays at the top. This means this layout would require five rows, but the standard keyboard only has four. So Numup can only be used on keyboards like Kinesis, Ergodox, etc.
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2016-Sep-15 02:37
Have you tried altering "our" layouts to have Alt-Gr layer like Arensito? and compare stats.

I tried with < > and wasn't sure of the effect... will try a better test later. Busy capturing the Ergo layout results now, up to around MTGAP Thumbshift which is so far the best. Tried comparing some of my Ergo layouts from earlier and they failed to beat it, but I have so many I'll have to do a systematic test and see which are good... and also try mapping something like current champ on ANSI onto Ergo layout... and the try tricks like putting H on thumb....
Title: Re: Balanced Keyboard Layout
Post by: Den on 2016-Sep-15 03:42
Comparing Arensito on standard layout and BEAKL on Ergo layouts, they have really close scores for code. Observations on why Arensito scores so highly on code.

1. The shift and alt-gr keys break up the same-finger and same-hand. So using more thumb-pressed shift and alt-gr give better scores.

2. Arensito has really low distance scores that are comparative to ergo layouts. This can be attributed to its mimicking of the thumb cluster as we noted earlier. Thereby lessening penalties from other fingers, particularly the pinkies.

3. Arensito has good locations for all the different types of brackets. Hitting them with alt-gr is still better than putting them on outside the pinkies, where they incur high penalties. Hence why it can get a good score on distance.

4. Arensito doesn't score so well on prose, as we are aware, but excellent on code. So we should try to steal its alt-gr trick for punctuation on a great prose layout, such as BEAKL and your alterations.
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2016-Sep-15 04:06
3. Arensito has good locations for all the different types of brackets. Hitting them with alt-gr is still better than putting them on outside the pinkies, where they incur high penalties. Hence why it can get a good score on distance.

4. Arensito doesn't score so well on prose, as we are aware, but excellent on code. So we should try to steal its alt-gr trick for punctuation on a great prose layout, such as BEAKL and your alterations.

Mmm. Interesting idea. On the one hand it disrupts my plans for AltGr on my own keyboard design ... I must investigate the difference between "all brackets unshifted" vs "put them in easy-to-reach on AltGr". Also I currently have swapped AltGr with RShift, which may need a rethink.

Don't like things outside on the pinkies. But the keys are there and have to be used for something. On my "brackets" mod of current best layout, I've moved += (in that order) to where I have <> on top left. Don't like that they're both on same finger, but putting them that way is arguably easier to type than current Shift-+ = to get the common += in programs. I don't use my pinkies for those keys anyway as it's too short, I use ring finger. I should post a pic of my hands :-)

Gonna be busy till the weekend, so will see about those experiments then.
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2016-Sep-15 10:46
Wonder how the community would feel about me adding this layout to the mix.... cry foul? But consider Arensito then....

http://patorjk.com/keyboard-layout-analyzer/#/load/xl5VRFRt

Does best with English not coding.


Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2016-Sep-16 14:17
Okay have uploaded the Ergo layouts, as well as new tests and interface updates.

Known issue: if you take too many results, it scrolls off the right of your screen, and no horizontal scrollbar. Not sure if browser bug or 'feature' of Semantic UI.
Will have to find a workaround.

BEAKL4 Ergo does quite well.

MTGap does well at prose, but not so well at other things.

Have not tested all the possibly permutations of inputs, so some combos might break or get MySQL errors/whatever ...please advise any problems :-)

I think I am finished adding tests now. Have other aspects to do/update/etc.

Cheers, Ian
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2016-Sep-16 15:36
Here (http://patorjk.com/keyboard-layout-analyzer/#/load/xkhksTsj) are conglomerate of BEAKL 1, 3, 4, 4 Ergo, and Stretch. Once you set home fingers to the bottom row, it scores very well. Almost as good as BEAKL 3.

Code: [Select]
BEAKL Opted4 Ergo
73.55

Would you prefer 74.74 on Alice? :)

Just a quick re-arrange based on current top ANSI layout.
http://patorjk.com/keyboard-layout-analyzer/#/load/W3X4Cswn

All three metrics on all three tests on Patrick dramatically better. Will check other inputs later.
Title: Re: Balanced Keyboard Layout
Post by: Den on 2016-Sep-16 16:11
Quote
Don't like things outside on the pinkies. But the keys are there and have to be used for something.

They're much better spots for Ctrl, Alt, etc. than at the bottom. Your pinkies don't have to stretch as much when doing one-handed combinations.
Title: Re: Balanced Keyboard Layout
Post by: Den on 2016-Sep-17 02:43
Beat Arensito at code at its own game:
http://patorjk.com/keyboard-layout-analyzer/#/load/qr7jx9Dm

Check out BEAKL Opted4 Ergo Alt, scoring upper 60's for all sorts of code (including javascript, html, java, json).
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2016-Sep-17 03:21
Beat Arensito at code at its own game:
http://patorjk.com/keyboard-layout-analyzer/#/load/qr7jx9Dm

Check out BEAKL Opted4 Ergo Alt, scoring upper 60's for all sorts of code (including javascript, html, java, json).

Way cool :-)
I checked the heat map page, it does look like KLA is indeed counting the keys on AltGr.... I see you've even put the digits on AltGr.... interesting idea... means it frees up the awkward locations for REALLY UNUSED characters.

I'll have to ponder your ideas a bit later... promised a client a job would be done by Monday so that's got to take priority... :-)

BTW while compiling all my stats, I noticed another layout which also had double-decker digits ... so what I thought was a totally new idea is not actually...  nothing new under the sun... :-)
Title: Re: Balanced Keyboard Layout
Post by: Den on 2016-Sep-17 05:17
Using Alt-Gr to game the scores is not necessarily more ergonomic, though.  there's a lot of value to hit special characters without modifiers. shortcuts in apps, especially games that need quick, simple key presses, especially the numbers. I like to use keys at the edge of the keyboard to control playback in VLC.
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2016-Sep-17 06:36
Yeah, I guess we'll have to try using a keyboard configured that way. I also prefer frequently used things to be unshifted and easy to hit. Which is one of the reasons why my keyboard has so many keys... :-)

Anyway I knocked together a quick and dirty frequency counter, here's the results for the programming inputs. Set below it includes my PHP and Perl programs, which I can't post publicly.

Also = is used almost as much (which I nearly typed as almuch now...) as the quotes ... this means my current location up left is way unoptimal.... (yes spellchecker I know it's not a word...)
Includes some high-ASCII characters, I looked them up, mostly European plus dagger and degree and per-mil.

  : &#x20; : 49922
. : &#x2e; : 10111
, : &#x2c; : 7283
= : &#x3d; : 7150
" : &#x22; : 7093
) : &#x29; : 6754
( : &#x28; : 6747

 : &#x0a; : 5907
; : &#x3b; : 5370
- : &#x2d; : 5090
: : &#x3a; : 4184
0 : &#x30; : 3642
_ : &#x5f; : 3621
{ : &#x7b; : 3339
} : &#x7d; : 3335
1 : &#x31; : 3063
< : &#x3c; : 3004
> : &#x3e; : 2970
/ : &#x2f; : 2085
2 : &#x32; : 1635
& : &#x26; : 1547
[ : &#x5b; : 1380
* : &#x2a; : 1377
] : &#x5d; : 1368
+ : &#x2b; : 1323
3 : &#x33; : 1203
4 : &#x34; : 1077
| : &#x7c; : 1021
         : &#x09; : 986
# : &#x23; : 956
' : &#x27; : 955
! : &#x21; : 954
5 : &#x35; : 932
8 : &#x38; : 753
6 : &#x36; : 740
9 : &#x39; : 638
7 : &#x37; : 636
? : &#x3f; : 532
$ : &#x24; : 523
% : &#x25; : 296
\ : &#x5c; : 286
� : &#xe2; : 208
~ : &#x7e; : 187
� : &#x94; : 153
� : &#x80; : 148
@ : &#x40; : 147
^ : &#x5e; : 64
� : &#x86; : 44
� : &#x92; : 33
` : &#x60; : 22
� : &#x89; : 9
� : &#x91; : 5
� : &#xa4; : 5
� : &#xa0; : 4
� : &#xc2; : 4
� : &#xb7; : 3
� : &#x93; : 3
� : &#x90; : 3
� : &#x9c; : 2
� : &#xef; : 2
� : &#xb0; : 1
� : &#xab; : 1
� : &#x96; : 1
� : &#xba; : 1


-----------------------------------
Include php and pl program with above. pl program generates html/css/php/javascript.
As expected $ and # frequency go up.

  : &#x20; : 133436
" : &#x22; : 23622

 : &#x0a; : 16514
, : &#x2c; : 15643
# : &#x23; : 15466
. : &#x2e; : 12317
= : &#x3d; : 10967
) : &#x29; : 10624
( : &#x28; : 10618
; : &#x3b; : 10488
$ : &#x24; : 8742
0 : &#x30; : 6467
- : &#x2d; : 6434
         : &#x09; : 6406
/ : &#x2f; : 5603
1 : &#x31; : 5569
} : &#x7d; : 5146
{ : &#x7b; : 5144
> : &#x3e; : 5103
: : &#x3a; : 5031
< : &#x3c; : 4984
_ : &#x5f; : 4587
2 : &#x32; : 3496
3 : &#x33; : 2615
' : &#x27; : 2323
4 : &#x34; : 2248
~ : &#x7e; : 2146
& : &#x26; : 2145
6 : &#x36; : 2103
8 : &#x38; : 1883
5 : &#x35; : 1866
\ : &#x5c; : 1673
* : &#x2a; : 1636
+ : &#x2b; : 1609
7 : &#x37; : 1599
[ : &#x5b; : 1567
] : &#x5d; : 1536
! : &#x21; : 1281
9 : &#x39; : 1173
| : &#x7c; : 1164
? : &#x3f; : 658
@ : &#x40; : 602
% : &#x25; : 541
� : &#xe2; : 210
^ : &#x5e; : 163
� : &#x94; : 153
� : &#x80; : 150
� : &#x86; : 44
� : &#x92; : 33
` : &#x60; : 22
� : &#x89; : 9
� : &#x91; : 5
� : &#xa4; : 5
� : &#xc2; : 4
� : &#xa0; : 4
� : &#x90; : 3
� : &#x93; : 3
� : &#xb7; : 3
� : &#x99; : 2
� : &#xef; : 2
� : &#x9c; : 2
� : &#x96; : 1
� : &#xb0; : 1
� : &#xab; : 1
� : &#xba; : 1
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2016-Sep-17 12:12
Input: 500 ISO dates. I was impressed with how well Beakl4 mod Ian did against the usual contenders (MTGAP, Colemak Programmer, etc), until I added Arensito ... then adding your latest alt ergo made me feel a little better... :-)

Rank         Layout         Score
#1 BEAKL Opted4 Ergo Alt 57.94
#2 Arensito fixed 57.11
#3 BEAKL 4 Mod Ian (best one) 47.20
#4 MTGAP 16.36
#5 Personalized 16.36
#6 Programmer Colemak 15.53

It's kinda weird that scores can differ so vastly for what is basically numeric input ....

Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2016-Sep-17 15:19
Mmm. 500 ISO DateTimes with random timezone offsets. Arensito tricks not always helpful...
eg: 1994-09-19T23:02:50+20:00.   Dates from 1970 to 31 Dec 2030.

Rank      Layout                Score
#1       BEAKL Opted4 Ergo 47.71
#2      BEAKL 4 Mod Ian    45.08
#3      BEAKL Opted4 Ergo Alt 44.01
#4      Arensito fixed 42.19
#5      Simplified Dvorak 30.70
#6      Personalized        21.38
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2016-Sep-19 05:22
Started playing around with AltGr ... starting from Beakl 4 Mod Ian best.

http://patorjk.com/keyboard-layout-analyzer/#/load/wmLflcsd

Need to work on the digits more... tried moving K and V to the blank spot but scores went down on KLE.
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2016-Sep-19 07:22
Well that was depressing ... had a nice variant catching up to yours and Konqueror goes and crashes on me ... and no recent saved version. :-(

Sigh. :-)

Now need to try and remember what I did ...
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2016-Sep-19 10:11
Wins most programming but not all.

http://patorjk.com/keyboard-layout-analyzer/#/load/ntLmFD3r

SameFinger metrics good, Distance not so good. First had to overcome the +/- 3 point loss from swapping Shift and AltGr. So in the end, pretty good.
73,78 on Alice...

Not sure how practical this whole AltGr move is ... might work better on a non-ANSI layout. For example I often have to add a comma to the end of a bunch of lines in a text editor. So my right hand is tied up with the arrow-down and End keys, it can't also be pressing AltGr so the left can hit the comma on AltGr whatever. Think I did try with comma and period as Primary, but think I got better scores putting them as alt on home row ... will fiddle more later.

Also you hand is unnaturally contorted keeping the thumb on AltGr... which is why a different layout will be better. Suppose keyboards need a shorter space bar ...
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2016-Sep-19 18:03
Ignore message layout about ... missing the colon.
Title: Arensito is annoying...
Post by: iandoug on 2016-Sep-20 13:18
So after getting a layout that wipes the floor with Arensito I add another test:

500 dates in German format
dd.mm.yyyy

and it promptly beats me again.

Good going for a layout developed so long ago....

Sigh :-)
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2016-Sep-20 14:44
Part of Arensito's "secret" is that AltGr is on the spacebar, and the only shift key directly above it. So the distance that the left thumb has to move is one key.
By comparison I have AltGr and RShift on right thumb next to each other , but the distance from centre of AltGr to RShift is 1.5 keys, because AltGr is wider.

All those extra 0.5 keyshifts add up, leading to a higher distance, and lower score, I imagine. I am loathe to copy that idea... at the moment I'm sitting with a layout that has only 4 rows instead of 5 ... numrow is completely blank and free for esoteric uses.... :-)
Title: Arensito
Post by: iandoug on 2016-Sep-23 10:18
Hi

http://patorjk.com/keyboard-layout-analyzer/#/load/j0VSsQLk

What's so special about his number layout? Or is it just that ours sucks in comparison?
1000 digits of π
Title: Numpads
Post by: iandoug on 2016-Sep-23 17:00
Mmmm.

So does this mean that numpads, while looking like a good idea, are not actually?

http://patorjk.com/keyboard-layout-analyzer/#/load/Hlmsrmrm

I really don't like the direction this research is sending me ... more and more towards keyboard.io ... I realised that I could fit the entire keyboard onto 4 rows (including bottom modifiers) by using AltGr+shift (or another dedicated modifier).

Which is of course completely the opposite direction I was going in when I started designing my keyboard ... but how must I argue with the numbers? :-)
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2016-Sep-23 17:03
I suppose numpads are good when you're keeping your place on a page with the left hand and entering lots of numbers with the right ... else you might need three hands....

Read a joke today that if aliens landed here in  10000 years time and tried to figure out how we looked from the keyboards lying around, they'd conclude we had ten tentacles coming out of our chests....
Title: backspace/delete
Post by: iandoug on 2016-Sep-24 08:39
Thoughts on putting Backspace on AltGr-space?

And maybe delete on AltGr-shift-space?

https://autohotkey.com/board/topic/109966-ergonomic-coding-script-for-me-atleast/

Thanks, Ian
Title: Re: Arensito
Post by: Den on 2016-Sep-24 16:38
Hi

http://patorjk.com/keyboard-layout-analyzer/#/load/j0VSsQLk

What's so special about his number layout? Or is it just that ours sucks in comparison?
1000 digits of π

My Ergo Alt got 49.47, compared to Arensito 46.77. On standard keyboard, 4 points behind Arensito. If I put 2 on the index home, they both gain 3 points.
http://patorjk.com/keyboard-layout-analyzer/#/load/k7l8Zl51
Code: [Select]
BEAKL Opted4 Ergo Alt
49.47 (52.17)

Arensito fixed
46.77

BEAKL Opted4 Alt
45.48

Personalized
40.22

BEAKL 4 Mod Ian AltGr KLE68.79! check
38.65

BEAKL Opted4 Ergo Mod Ian 1
38.56

Title: Re: Balanced Keyboard Layout
Post by: Den on 2016-Sep-24 17:09
What we can learn from numpads:

1. Numpad are 1-handed only. This is very stressful on that hand, not always good rolls, and high same-finger.

2. It uses only the 3 strong fingers (and 0 on the thumb) for the digits, but no pinky. This is the exact same thing I've been advocating in BEAKL: No common letter/number on the pinky.

3. Another familiar concept is the stretching. Since 123 are the most common numbers, that is our home row. That means we stretch to reach the other numbers.

That said, I can envision a different (better?) design for 1-hand numpad based on BEAKL philosophy and effort grid.
Title: Re: backspace/delete
Post by: Den on 2016-Sep-24 17:14
Thoughts on putting Backspace on AltGr-space?

And maybe delete on AltGr-shift-space?

https://autohotkey.com/board/topic/109966-ergonomic-coding-script-for-me-atleast/

Thanks, Ian

I much prefer Backspace on its own thumb key, and the Kinesis makes it possible. It doesn't affect these test scores, anyway. (I've heard of some programs that simulate typing mistakes, and thus include random backspace into their tests.)

Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2016-Sep-24 17:29
2. It uses only the 3 strong fingers (and 0 on the thumb) for the digits, but no pinky. This is the exact same thing I've been advocating in BEAKL: No common letter/number on the pinky.

Enter/return is on pinky.

Curiously, if I remove the need for the enter key, and paste pi all as one string, the numpad scores goes DOWN (which is not what I was expecting :-) )
http://patorjk.com/keyboard-layout-analyzer/#/load/8crzN68C

And you do better...

http://patorjk.com/keyboard-layout-analyzer/#/load/VJz26H4f

I'm supposed to be working ...  I need to redo my AltGr, spent most of the day fixing my site. Yeah, that meant fighting with Javascript to get the results into nicely scrollable tables that also sort properly. Then had to deal with the site management software having mangled a few things as well ;)

So AltGr will have to wait for another day....
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2016-Sep-24 17:33
and so we stumble onto another of Arensito's secrets .... the Enter key way up there... but REALLY close to the pinky .... so any tests with lots of Enters gives it an advantage over ANY other layout that leaves Enter in default position.

I've moved it in my AltGr, but not as short a distance as he has... I suppose I need to put it on a single key that the distance calculations become more favourable....
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2016-Sep-24 17:40
mmm something like this makes rather a radical difference

http://patorjk.com/keyboard-layout-analyzer/#/load/23xmLtmc

see BEAKL 4 Mod Ian AltGr KLE68.79! check layout. Almost as good as an Ergo layout...
Title: Re: backspace/delete
Post by: iandoug on 2016-Sep-24 17:43
I much prefer Backspace on its own thumb key,

If your thumb homes are Space and AltGr, then backspace becomes a no-mover...

I'll try it sometime... in reality my thumbs hover over the board (like all the other fingers not actually pressing anything...) so it might turn out to be more effort... ;-)
Title: Re: Balanced Keyboard Layout
Post by: Den on 2016-Sep-24 19:54
Quote
Enter/return is on pinky.

Enter usage varies wildly depending on type of entry.

Ideally Enter would be accessed by the thumb.

Preliminary optimized layout looks like this:

Code: [Select]
BEAKL OptedN Nums

 543 
70216
 8 9
.

There are 3 rows and 5 columns, and 2 more thumb keys. That is exactly the same number of keys on a standard numpad. I haven't included the math signs or Enter yet.

Visually:
(http://www.shenafu.com/images/kb-beakl-numpad-nums.png)

With signs:
Code: [Select]
BEAKL OptedN Full

754=* 
31/2+
908-6
.     

Visually:
(http://www.shenafu.com/images/kb-beakl-numpad-all.png)

This works great with dates, too, both with slashes or dashes.

What if we needed more signs?

Code: [Select]
BEAKL OptedN Ext

^+-=*
%62.#
9315:
784$/
0

Visually:
(http://www.shenafu.com/images/kb-beakl-numpad-ext.png)
Title: Re: Balanced Keyboard Layout
Post by: Den on 2016-Sep-26 15:22
My next breakthrough is to expand the pinkies in both directions. This not only improves the scores on prose, but can almost match Arensito on code without resorting to cumbersome AltGr.

This next evolution I dub BEAKL Opted36 because it 6 columns x 3 rows x 2 hands, for total 36 keys.
Code: [Select]
BEAKL Opted36

{jyou( wdmn)z
xhiea. gstrpk
}'"/,; fclbvq

see image
(http://www.shenafu.com/images/kb-beakl-opted36.png)

in KLA :http://patorjk.com/keyboard-layout-analyzer/#/load/bnKXn59Z (http://patorjk.com/keyboard-layout-analyzer/#/load/bnKXn59Z)

Code: [Select]
Results

Alice
72.74

PPTT
31.

Google source
53.00
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2016-Sep-26 15:36
Mmm interesting.... I'm actually going in the other direction and moving towards the centre, but that requires considerable use of AltGr, which as Arensito pointed out way back when, in not very comforable on ANSI layout... need custom design.

I found scores improve if you move Enter to where ''/" is, but that's only doable if you can shuffle keys around via AltGr.

Got very upset this morning, had a new layout that got new high scores on English prose and then I lost it ... thought I had it saved but didn't, it seems. So I tried again and got one that was actually better at English but worse on the technicals.
It's layout 1 here (the others are the variants I was fiddling with).
http://patorjk.com/keyboard-layout-analyzer/#/load/GrGK0QRX

Good scores, low distances, samefinger not the best but not too bad either.
The / is certainly a problem, it needs to move.

Wasn't going to share it until I had sorted out the technicals but then you popped along... :-)

I will contemplate your ideas above. I can see one issue, is that you are using WIDE keys which means Patrick's calculations for distance will hit you....
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2016-Sep-26 15:39
The copyright sign and "not" sign are just to force KLA to put the legend at the bottom of the keycap instead of the top when there is not shifted character.
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2016-Sep-26 19:20
 I wonder if 75 on Alice is doable on ANSI?.... getting close.

http://patorjk.com/keyboard-layout-analyzer/#/load/PVLp2rKm
Title: Re: Balanced Keyboard Layout
Post by: Den on 2016-Sep-26 20:28
Even better when you bring 1 and 0 down.

Code: [Select]
qjyou( wdmn0{
xhiea. gstrpv
}1"),: fclbk

(http://www.shenafu.com/images/kb-beakl-opted36.png)

http://patorjk.com/keyboard-layout-analyzer/#/load/wXXP350C
Title: Re: Balanced Keyboard Layout
Post by: Den on 2016-Sep-27 06:06
Center keys do seem to be effective. BEAKL 4 Ergo already uses them and does very well on code. The problem is Kinesis doesn't have those keys, so I can't try such a layout.

Title: Re: Balanced Keyboard Layout
Post by: Den on 2016-Sep-27 06:17
and so we stumble onto another of Arensito's secrets .... the Enter key way up there... but REALLY close to the pinky .... so any tests with lots of Enters gives it an advantage over ANY other layout that leaves Enter in default position.

I've moved it in my AltGr, but not as short a distance as he has... I suppose I need to put it on a single key that the distance calculations become more favourable....

the fact Arensito use pinky for Enter is huge faux-pas. that could be up to 20% for each pinky. ouch! maybe try AltGr + middle finger.
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2016-Sep-27 06:44
the fact Arensito use pinky for Enter is huge faux-pas. that could be up to 20% for each pinky. ouch! maybe try AltGr + middle finger.

According to Michael's frequency tables, Enter is between w and b ... Mmm that's an idea.
What I was trying to say was that it's right down there in QXZ territory, not up in "should be on a thumb" territory. I think if entering data (numbers etc) then we use enter a lot, but if writing text we don't. If coding, then a lot more. I think Michael used formal text, informal text and code to get his frequencies, so given that code would have pushed the frequency higher, in normal text it will be very low... certainly in modern word processors, only for paragraphs not end of line.

YMMV :-)
Title: Re: Balanced Keyboard Layout
Post by: Den on 2016-Sep-27 08:19
According to Michael's frequency tables, Enter is between w and b ... Mmm that's an idea.
What I was trying to say was that it's right down there in QXZ territory, not up in "should be on a thumb" territory. I think if entering data (numbers etc) then we use enter a lot, but if writing text we don't. If coding, then a lot more. I think Michael used formal text, informal text and code to get his frequencies, so given that code would have pushed the frequency higher, in normal text it will be very low... certainly in modern word processors, only for paragraphs not end of line.

YMMV :-)

there's also a high chance of multiple Enters hit consecutively, and that's even worse for the pinky. that's how i probably hurt my right pinky on keyboard at work.
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2016-Sep-27 09:06
FWIW my own design put the enter on the thumbs... I think we've subconsciously associated 'big key' == important, even if that's not true (and a hangover from typewriters).

http://www.keyboard-layout-editor.com/#/samples/pkb.json

Said design has now largely been chucked out the window, based on last few month's learning.. :-)
Title: 75 today...
Post by: iandoug on 2016-Sep-27 13:44
Well almost ... short with 1c. Maybe you can find the missing cent.

Alice, 74.99  on ANSI. Also a layout I did back in July that got top score on Alice.

ANSI layout is optimised for Alice ... punctuation in Alice is placed to get good score. Other punctuation not attended to. So probably not much good for other stuff, though should be reasonable for other English prose, depending if single or doublequoted.

http://patorjk.com/keyboard-layout-analyzer/#/load/KGdP8Zlj

Just tried it to see if it was possible to hit 75 (based on the assumption that 75 is 3/4 of the way to 100, meaning the keyboard is only 3/4 optimised.... which is depressing :-)  )
Title: shift and alts
Post by: iandoug on 2016-Sep-27 13:56
People are used to using shift to access things on a key ... AltGr is just another shift with a silly name from the 70s.

The biggest problem we have at the moment is that the bureaucrats have declared ANSI and ISO as The Standards and everything else, no matter how much better, is treated with suspicion.

Based on current top-scoring layouts, we can make a much better keyboard with appropriately sized and spaced keys, free of legacy influences.

As I said before, it possible to put the rest of the ANSI 104/105 keys onto 4 rows (no numpad though, that's a duplication). However then there is no space for certain things already mapped to AltGr like Euro symbol, Euro letters ë ç ø etc on some National layouts. See AltGr page on Wikipedia  https://en.wikipedia.org/wiki/AltGr_key
Title: Re: shift and alts
Post by: Den on 2016-Sep-27 14:18
People are used to using shift to access things on a key ... AltGr is just another shift with a silly name from the 70s.

The biggest problem we have at the moment is that the bureaucrats have declared ANSI and ISO as The Standards and everything else, no matter how much better, is treated with suspicion.

Based on current top-scoring layouts, we can make a much better keyboard with appropriately sized and spaced keys, free of legacy influences.

As I said before, it possible to put the rest of the ANSI 104/105 keys onto 4 rows (no numpad though, that's a duplication). However then there is no space for certain things already mapped to AltGr like Euro symbol, Euro letters ë ç ø etc on some National layouts. See AltGr page on Wikipedia  https://en.wikipedia.org/wiki/AltGr_key
Simply propose a new modifier, the Punc key, that accesses a new layer. Actually that sounds like Func / Fn which is found on laptops and other keyboards for media functions. Could make that standard on all new keyboards henceforth.
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2016-Sep-27 14:36
:-)

And we label it with an interrobang? Or two? :-)

9‽
‽‽
Or maybe Pilcrow for Punctuation ¶ but I suppose that could be confusing as some northern Euro layouts have that sign on already (to actually use it).

Or ⁂ would be most elegant..... and possibly confusing :-)
Stolen from http://mentalfloss.com/article/12710/13-little-known-punctuation-marks-we-should-be-using

Maybe just call it the NumPunc key .... :-)


Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2016-Sep-27 14:40
Center keys do seem to be effective. BEAKL 4 Ergo already uses them and does very well on code. The problem is Kinesis doesn't have those keys, so I can't try such a layout.

I didn't know what to do with those keys when I was fiddling with the ergo layouts ... their shape implies they're not for letters, but for modifiers/whatever, and it felt odd putting letters etc there. I did eventually dig up some 'official' key mappings for those layouts but haven't had time to play with them yet.
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2016-Sep-27 15:05
Xah Lee has tried things on centre keys and didn't like it.

See his long and detailed comment here @ xah lee on 2015-12-29 at 21:14 said:
here: http://iandoug.com/?p=152

I trust you are familiar with him?
http://xahlee.info/kbd/keyboard_blog.html
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2016-Sep-27 17:54
This current layout is remarkable at English.

Decided to see how it would do with some medical terms (because they are frequently tricky to spell and have unusual letter combos) and again it wins without much effort. And there's hardly any punctuation at all... just some capital letters mainly.

http://patorjk.com/keyboard-layout-analyzer/#/load/3l83VH4w

Score, distance, samefinger, hand use balance, low pinky, no problem ...
Title: Re: Balanced Keyboard Layout
Post by: Den on 2016-Sep-28 04:09
Making great progress on puncs without AltGr. But still working on improvements.

It seems very important to keep numbers on the same row.

PPTT:
http://patorjk.com/keyboard-layout-analyzer/#/load/bBrJ5sS5
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2016-Sep-28 16:46
Making great progress on puncs without AltGr. But still working on improvements.

It seems very important to keep numbers on the same row.

PPTT:
http://patorjk.com/keyboard-layout-analyzer/#/load/bBrJ5sS5

Impressive scores... the first non-AltGrs on my lists are Aus der Neo-Welt 39.04 (ANSI) and QWERTY Thumbshift 38.18 (ergo) so that's quite a jump.

I've also gone into Deep Thought mode about numbers and punctuation, and realised (for AltGr/NumPunc style) that I need a better understanding of how keys are weighted. I know you have your own version of the weightings here http://www.workmanlayout.com/blog/ but I think Patrick's are slightly different as well ... I get the feeling he does not punish bottom row the same why Workman does. So bottom middle is a good slot, better than ring top, for example. It's something I started to notice as I swapped punctuation around in pairs.

In truth, sometimes I got a better score with a character on AltGr slot than in main slot, on same key. I suppose it depends on what was before and after it in the text.

Are you still happy with your weightings on page one, or has experience led to a different opinion now? :-)

Must try and dig into Patrick's code, those weightings are probably in an array there somewhere.

My other problem is the digits... should not have more than 1 on each pinky, but don't want to overload the index finger either ... probably I am missing something here again.. .maybe doubledecker numbers are the solution, given shift on the right thumb rather than pinky. I'll play around with that idea... might free up slots for higher-use punctuation.
thanks, Ian
Title: numpad
Post by: iandoug on 2016-Sep-28 17:24
AltGr or no AltGr, still think a numpad is a good idea. I would not be able to work without one.

So a suggestion...

http://www.keyboard-layout-editor.com/#/gists/e3f904204dca35cfa33d142ddedd6d1d
Title: Re: Balanced Keyboard Layout
Post by: Den on 2016-Sep-28 20:22
In truth, sometimes I got a better score with a character on AltGr slot than in main slot, on same key. I suppose it depends on what was before and after it in the text.

May be a flaw in the PPTT test is that it expects adjacent characters to be on the same layer. So constantly switching between shift and unshift could affect the scores. OTOH in real code for most languages, such long strings of puncs would be unlikely. You can tell because Arensito doesn't do that well against my new layouts (with and without AltGr) when it comes to actual code from my projects in Java and Javascript. Now it could be that those languages are quite verbose, so letters play a big part. Nevertheless, the PPTT has sequences of puncs that aren't likely to occur in real everyday code.

Quote
Are you still happy with your weightings on page one, or has experience led to a different opinion now? :-)

I still very much believe in it. It has helped spawn several of the best layouts for prose, and my latest is very poised to excel in code as well.

One thing to realize is that the values on the graph are relative. Certain groups of keys have similar values, and another block of keys have their own values. (One minor change is to put the bottom index key as the same value as the top keys.) By placing them in groups, it leaves room for the optimizer to rearrange for best rolls, bigrams, trigrams, and other hidden factors.

I have extended the same philosophy for 36 and 44 keys. The result can be witnessed in exceptional BEAKL Opted36. By extending keyboard for the fringes of the pinky, it surpassed Opted4 in prose, and still leaves room for puncs to be optimized for code.
Title: Re: numpad
Post by: Den on 2016-Sep-29 02:41
AltGr or no AltGr, still think a numpad is a good idea. I would not be able to work without one.

So a suggestion...

http://www.keyboard-layout-editor.com/#/gists/e3f904204dca35cfa33d142ddedd6d1d

I've posted my numpad layouts created by the optimizer in previous posts. The trickiest part is making a good representative corpus that one would type with numpad only. Actually one thing people seem to neglect is the tab key to advance to the next input field.
Title: Re: numpad
Post by: iandoug on 2016-Sep-29 03:06
I've posted my numpad layouts created by the optimizer in previous posts. The trickiest part is making a good representative corpus that one would type with numpad only. Actually one thing people seem to neglect is the tab key to advance to the next input field.

MMm... I normally use the arrows when working in spreadsheets.

Capturing all the numbers from the tests has helped me realise some deficiencies in standard numpad layout.
Didn't think of the tab. Also some cultures use the ' as a thousands separator (and I've seen it on calculators too, in general I think it is a Good Idea as then there is no source for confusion as to what the decimal separator is).

I tried to put all the chars used in numbers, dates and times on the pad. Will have to see about Tab and ' . I did actually consider have an Enter and Plus on both sides, based on the idea that the numpad would be in centre of keyboard, and thus make the Enter and Plus left-and-right-hand friendly. So if I do that then it would have an extra column, allowing for Tab and ' as well...

Re the PPTT, I know it's not a realistic test, but I was looking for something to test punctuation layout across languages without influence from the Alphas. My comments about Patrick scoring AltGr higher than normal come from experiments with the KLE home page, not the PPTT.

I need to update my site with new test and UI improvement, but currently have way too many 'experiments' in the database, which all score highly and knock the conventional layouts way down in the list.
Title: Re: Balanced Keyboard Layout
Post by: Den on 2016-Sep-29 03:07
All right, I'm tired of messing with BEAKL Opted36. I'm freezing it, so I can remap my keyboard and test it out.

You can find the standard and ergo versions, which I propose both be added to your keyboard design site for comparison.
http://patorjk.com/keyboard-layout-analyzer/#/load/r7T1MdwZ (http://patorjk.com/keyboard-layout-analyzer/#/load/r7T1MdwZ)
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2016-Sep-29 03:13
All right, I'm tired of messing with BEAKL Opted36. I'm freezing it, so I can remap my keyboard and test it out.

You can find the standard and ergo versions, which I propose both be added to your keyboard design site for comparison.
http://patorjk.com/keyboard-layout-analyzer/#/load/r7T1MdwZ (http://patorjk.com/keyboard-layout-analyzer/#/load/r7T1MdwZ)

Okay ... was waiting for that :-)

Takes a while to add new layouts because I have to run each test on them.

I think I must see if I can get Patrick's thing to work properly locally, and disable the "Personalised" section, because I think that's the slow part.
Title: Re: Balanced Keyboard Layout
Post by: Den on 2016-Sep-29 03:15
To test just puncs, you could simply remove all letters and numbers from the layout. The corpus of real code stays intact, including letters and numbers. The analyzer should ignore the characters that don't appear on the layout. Things like space and enter should remain on the layout.
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2016-Sep-29 03:25
To test just puncs, you could simply remove all letters and numbers from the layout. The corpus of real code stays intact, including letters and numbers. The analyzer should ignore the characters that don't appear on the layout. Things like space and enter should remain on the layout.

Yeah was thinking I must write a quick proggie to strip out alphas and/or digits from for example KLE ... this would be more 'natural' as a test, but would be language-specific. I'll see what the Hanoi pages look like after such an exercise.
Title: Re: numpad
Post by: iandoug on 2016-Sep-29 03:54
I've posted my numpad layouts created by the optimizer in previous posts. The trickiest part is making a good representative corpus that one would type with numpad only. Actually one thing people seem to neglect is the tab key to advance to the next input field.

http://www.keyboard-layout-editor.com/#/gists/e3f904204dca35cfa33d142ddedd6d1d
Title: ??????
Post by: iandoug on 2016-Sep-29 12:18
I went looking for your effort grid, not on page one any more so google ... which leads to the attached when loading this:

http://www.shenafu.com/code/keyboard/keyboard_effort_grid.png

Please advise... :-)

Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2016-Sep-29 12:28
Google says your effort grid is also here, but it's not (in Firefox).... just a link to it.

http://www.taylorpeterson.co/blog/keyboardlayouts

Looks like he was a bit ahead of me....

Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2016-Sep-29 12:46
He requires ZXCV and S unmoved....

http://nikolay.rocks/2016-04-02-meet-halmak

Will add it to my comparisons.

His second version dumps that requirement....
Title: Re: ??????
Post by: Den on 2016-Sep-29 16:31
I went looking for your effort grid, not on page one any more so google ... which leads to the attached when loading this:

http://www.shenafu.com/code/keyboard/keyboard_effort_grid.png

Please advise... :-)

Might be something wrong with (your) Firefox. I can see it (in Habit browser), it's pretty big so hard to miss. That is the correct URL. Shown here again:

(http://www.shenafu.com/code/keyboard/keyboard_effort_grid.png)

FYI that graph was created in HTML/JS, so I may publish it as such if interested. Of course it's pretty easy to roll your own. The most interesting part is the color scheme that automatically adjusts to the value of each box. This is much easier than using paint program to refill the boxes every time a value is altered. Paint programs are also unergonomic when it comes to modifying lots of text like this.
Title: Re: ??????
Post by: iandoug on 2016-Sep-29 16:41
Might be something wrong with (your) Firefox. I can see it (in Habit browser), it's pretty big so hard to miss. That is the correct URL. Shown here again:

(http://www.shenafu.com/code/keyboard/keyboard_effort_grid.png)

Image does not appear in Firefox.
If I paste the URL into Konqueror, it loads.

If I try Chromium, it gets more dramatic than firefox... so clearly they think there is something funny with your png.
For example, https://securelist.com/blog/virus-watch/74297/png-embedded-malicious-payload-hidden-in-a-png-file/

Is shenafu yours entirely, or shared?

Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2016-Sep-29 16:47
ignore that grey block, I accidentally moused over a javascript bookmark in firefox, open next to chromium.
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2016-Sep-29 16:48
Google more useful than firefox:

https://www.google.com/transparencyreport/safebrowsing/diagnostic/index.html?hl=en-US#url=http://www.shenafu.com/code/keyboard/keyboard_effort_grid.png
Title: Re: Balanced Keyboard Layout
Post by: Den on 2016-Sep-29 17:19
Google more useful than firefox:

https://www.google.com/transparencyreport/safebrowsing/diagnostic/index.html?hl=en-US#url=http://www.shenafu.com/code/keyboard/keyboard_effort_grid.png

Something similar happened a few years back. I'll have to cleanse the site again.
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2016-Sep-29 17:27
I wget (wgot?) the png and scanned it but nothing found. But that may not mean anything.

Regret last time I pulled viruses apart was in the 90s on DOS.... so somewhat out of practice there... :-)
Title: Re: Balanced Keyboard Layout
Post by: Den on 2016-Sep-29 17:39
He requires ZXCV and S unmoved....

http://nikolay.rocks/2016-04-02-meet-halmak

Will add it to my comparisons.

His second version dumps that requirement....

His screenshot shows only 65 pts.? A mere 0.36 pts. over the other popular layouts. But we already have scores easily approaching 73-75 pts., whopping 8-10. pts. beyond them. But we still have to try our own tests with his layout for fairness.

Preliminary overview based on experience tells me it has some fatal flaws. First, "I" on right pinky. Second, some same fingers combos, such as "sl", "do", "nc", "be", "ay", etc.
Title: Re: Balanced Keyboard Layout
Post by: Den on 2016-Sep-29 17:41
I wget (wgot?) the png and scanned it but nothing found. But that may not mean anything.

Regret last time I pulled viruses apart was in the 90s on DOS.... so somewhat out of practice there... :-)

There are bad dummy files in the directory, so Google reports the whole directory as bad.
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2016-Sep-29 17:46
His screenshot shows only 65 pts.? A mere 0.36 pts. over the other popular layouts. But we already have scores easily approaching 73-75 pts., whopping 8-10. pts. beyond them. But we still have to try our own tests with his layout for fairness.

I have asked him on his github repo for the KLA .json file.
I think his screenshot was not done with Alice or KLA words because the Colemak score did not match with what it gets on those tests. So was some other corpus that he used.
My original message here about it was a bit demeaning so I edited it ... tend to forget this is public.
But I agree current layouts are far superior... in particular I didn't like where he put the H, typing TH or HE is going to be a pain.
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2016-Sep-29 18:18
His layout doesn't do anything fancy, just moves keys around so I set it up quickly ... his layout is not really a challenger.

This run against ClassicCollection.
http://patorjk.com/keyboard-layout-analyzer/#/load/vMBWW8wc

and this against KLE.htm, where he does beat my "shuffle keys only" layout.
http://patorjk.com/keyboard-layout-analyzer/#/load/6kkglfc5

I suppose I should try to optimise that layout for tech tests instead of just English.
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2016-Sep-29 18:31
I suppose I should try to optimise that layout for tech tests instead of just English.

Mm that wasn't too hard ....

http://patorjk.com/keyboard-layout-analyzer/#/load/CKKz3dT4
Title: Re: Balanced Keyboard Layout
Post by: Den on 2016-Sep-29 18:40
I have asked him on his github repo for the KLA .json file.
I think his screenshot was not done with Alice or KLA words because the Colemak score did not match with what it gets on those tests. So was some other corpus that he used.
My original message here about it was a bit demeaning so I edited it ... tend to forget this is public.
But I agree current layouts are far superior... in particular I didn't like where he put the H, typing TH or HE is going to be a pain.

Yea, TH and SH look like pain to type, and they're very common.

It seems his basic premise is symmetry. I've been down that road, but, as I said in an earlier post, one hand (right hand) is stronger and more agile than the other. I even adjusted parameters to punish weird sequences by the weaker (left) hand. So there is no longer any symmetry between hands in my configuration files.

In another post, he mentioned something about no need to preserve the Ctrl shortcuts. I already realised that when using Autohotkey to remap the layout. Since I only remap basic and shift layers, but not the Ctrl layers, the shortcuts stay in the same place regardless of layout. This seems to me another oversight, hysteria by those who claim that certain letters must remain in place due to shortcuts (coughcolemakcough). When there are technical solutions to keep shortcuts as is, without hindering the adoption of a superior layout. (To be fair, Colemak is a respectable layout despite its constraints.)

Although it's odd he chose to keep Ctrl-s, when to me, Ctrl-a (select all) is really the most important shortcut. Copy and paste I can assign to the mouse. Saving files, there are toolbar buttons for that. But most programs neglect select-all, even text editing software.
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2016-Sep-29 19:06
In another post, he mentioned something about no need to preserve the Ctrl shortcuts.

Although it's odd he chose to keep Ctrl-s, when to me, Ctrl-a (select all) is really the most important shortcut. Copy and paste I can assign to the mouse. Saving files, there are toolbar buttons for that. But most programs neglect select-all, even text editing software.

When I set up his layout I noticed that ZXCV was not there, which I thought odd since he mentions it as a requirement on his blog.

He's a programmer, and probably constantly saving his work, hence ctrl-S.

In truth, many years ago the editor I was using (think it was some HTML editor on Win3.1) assigned ctrl-S to "save as" rather than "save" which brought up the file dialogue.... So I got into the habit of alt-f -> s and now it's muscle memory ...

FWIW my fancy programmer's keyboard had a hotkey for "select all" aka ctrl-A. :-)

KDE on Linux has an annoying bug/feature re hotkeys.. if you have multiple layouts configured, you can switch between them on the fly, but the hotkey locations stay where they were as per layout 1. So if you rely on muscle memory then it's okay, but if you actually WANT to press ctrl-X when X is somewhere else, it doesn't work ...
Title: Re: ??????
Post by: ADMIN on 2016-Sep-29 19:43
These were the most recent updates to my site. I uploaded some .AHK (autohotkey) scripts that remaps keyboard into BEAKL into the same directory as the effort grid image. I also uploaded some images into a different directory. Some APK files for my Android games (the same files you can find on Google play store).

The google dashboard doesn't provide any URLs for me to check or verify which are bad files.
Title: Re: Balanced Keyboard Layout
Post by: ADMIN on 2016-Sep-29 19:47
When I set up his layout I noticed that ZXCV was not there, which I thought odd since he mentions it as a requirement on his blog.

His earlier layout "Rockstar" has this requirement. It's gone with Halmak.
Title: Re: ??????
Post by: iandoug on 2016-Sep-29 20:03
Some APK files for my Android games (the same files you can find on Google play store).

Do you have, um, 'unusual' ad suppliers in there?

There have been reports of some ad networks being used to spread junk.
Title: Re: ??????
Post by: Den on 2016-Sep-29 20:22
Do you have, um, 'unusual' ad suppliers in there?

There have been reports of some ad networks being used to spread junk.

those don't have ads, and they're in different directory.
Title: Re: ??????
Post by: Den on 2016-Sep-29 20:46
Might be something wrong with (your) Firefox. I can see it (in Habit browser), it's pretty big so hard to miss. That is the correct URL. Shown here again:

(http://www.shenafu.com/code/keyboard/keyboard_effort_grid.png)

FYI that graph was created in HTML/JS, so I may publish it as such if interested. Of course it's pretty easy to roll your own. The most interesting part is the color scheme that automatically adjusts to the value of each box. This is much easier than using paint program to refill the boxes every time a value is altered. Paint programs are also unergonomic when it comes to modifying lots of text like this.

The page was already there:
http://shenafu.com/code/keyboard/keyboard effort grid.html (http://shenafu.com/code/keyboard/keyboard effort grid.html)

inline scripting
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2016-Sep-29 20:56
firefox...

Reported Unwanted Software Page!

This web page at shenafu.com has been reported to contain unwanted software and has been blocked based on your security preferences.

Unwanted software pages try to install software that can be deceptive and affect your system in unexpected ways.
Title: Re: Balanced Keyboard Layout
Post by: ADMIN on 2016-Sep-29 21:06
firefox...

Reported Unwanted Software Page!

This web page at shenafu.com has been reported to contain unwanted software and has been blocked based on your security preferences.

Unwanted software pages try to install software that can be deceptive and affect your system in unexpected ways.

I tried to contact Google. Waiting to see how they respond.
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2016-Sep-30 07:41
Well your effort grid is now showing up on page 1 again...

Quick test, Game of Life code stripped of Alphas.

http://patorjk.com/keyboard-layout-analyzer/#/load/PpRnTn2N

Huge difference between AltGr and non-AltGr layouts. Haven't tried with your ergo layouts yet.

Title: Re: Balanced Keyboard Layout
Post by: Den on 2016-Sep-30 17:32
I tried to contact Google. Waiting to see how they respond.

I didnt do anything but they removed the danger status.

Seems a false flag, or some troll. (Not sure, but a coincidence that I was in a spat over at a specific keyboard forums: starts wth "C". They voted down my post because they felt like i crapped on their pet layout. Probably looked through my posting history, i only posted a few times. I likely posted about the effort grid there and they thought it worthy of sabotage. Just my keyboard directory where the image is found is flagged, the rest of site is fine. Hmm.)
Title: Re: Balanced Keyboard Layout
Post by: Den on 2016-Sep-30 22:48
This is the layout I'm going to try for Kinesis:

(http://shenafu.com/code/keyboard/beakl-opted34-kinesis.png) (http://shenafu.com/code/keyboard/beakl-opted34-kinesis.png)

It's different than the Ergo layout used for aiming for high scores. Kinesis lacks center keys, so I had to move the arrows where the brackets would be. Also I like shift on the left thumb--I'm used to it by now and it's essential for gaming.

Title: Re: Balanced Keyboard Layout
Post by: Den on 2016-Sep-30 23:11
Tweaked the effort grid's values and color scheme.
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2016-Oct-01 03:34
Tweaked the effort grid's values and color scheme.

Those pinky values are rather harsh :-)

I went searchabout on Google to find other people's grids the other day, the most comprehensive I found was I think from the Carpalx guy (Martin, eventually found his name) because it includes the "whole" keyboard (ie numrow and up to |\ key, but not modifiers...).
I suspect Patrick's weightings are based off of this, because he assigned 0 to all four home finger positions, and Patrick's weightings seem similar.

http://mkweb.bcgsc.ca/carpalx/?typing_effort
His discussion on this page reminds me of your way of thinking... :-)

On another note I'm going to try to sort out the mess of alternate layouts I have (and hopefully drop the weaker ones), and in the process rename them more sanely than BEAKL 4 Mod Ian 73.08 74.7. xxxx , I think I will keep BEAKL just for yours or where I've done very minor mods like moving a key or two, and rename the others based on home row (or somesuch).

Cheers, Ian

P.S. Yeah, Those C guys are a bit "dedicated" to their layout, that's why I refer to them as fanbois on my site.... :-)
Justice will come. :-)


Title: Re: numpad
Post by: Den on 2016-Oct-01 03:41
This numpad has big tab key. it seems built for spreadsheets.

(https://trulyergonomic.com/store/image/data/1-Truly-Ergonomic-Mechanical-Numeric-Keypad.jpg) (https://trulyergonomic.com/store/truly-ergonomic-mechanical-numeric-keypad)

Upon closer inspection, the special keys are activated with Shift + digits. including math, movement, and copypasta. They even have the thousands 000, which you might like. Shift is the wide, hollow up arrow.
Title: Re: numpad
Post by: iandoug on 2016-Oct-01 03:52
This numpad has big tab key. it seems built for spreadsheets.

(https://trulyergonomic.com/store/image/data/1-Truly-Ergonomic-Mechanical-Numeric-Keypad.jpg) (https://trulyergonomic.com/store/truly-ergonomic-mechanical-numeric-keypad)

Some interesting ideas. What's bothering me is how to access the front-printed functions... I'm guessing the Fn key is involved, but are you supposed to hold that with your pinky and use another finger to get the function at the same time? Truly NOT Ergonomic? :-)
Maybe make a single centre-zero and put Fn bottom left under the thumb?

I like the idea of putting things on a "shift/modifier" instead of lots of extra keys... so I shall borrow that .... :-)

Thanks. :-)
Title: Re: numpad
Post by: Den on 2016-Oct-01 03:57
Some interesting ideas. What's bothering me is how to access the front-printed functions... I'm guessing the Fn key is involved, but are you supposed to hold that with your pinky and use another finger to get the function at the same time? Truly NOT Ergonomic? :-)
Maybe make a single centre-zero and put Fn bottom left under the thumb?

I like the idea of putting things on a "shift/modifier" instead of lots of extra keys... so I shall borrow that .... :-)

Thanks. :-)

I hope the shift is single-press so you don't have to hold it down. I suspect the Fn key opens the Excel functions dialog.

Another missed opportunity to incorporate the thumb. It can be used to activate the shift. Much more ergonomic and faster than reaching way up there. Also I would extend it to 5 columns and move the far top keys to the new column accessed by the index.
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2016-Oct-01 04:08
  • Consider untraditional typing techniques, such as using ring finger instead of pinky to type corner keys

I do that by default due to the way my hands were issued to me. I use pinky for control and shift and ring for anything higher.
It's actually a rare inherited genetic 'experiment' by nature (Type B brachydactyly, but only on pinkies/5th toe), to see if humans really need long pinkies. Guitar players and typists probably do. Labourers probably not.

It means I need to swing my hand to hit Enter or Backspace. And I use backspace a lot :-)


Title: Re: numpad
Post by: iandoug on 2016-Oct-01 04:13
I hope the shift is single-press so you don't have to hold it down.

I was wondering the same thing and thought the same as above, but using arrow key will then be a pain... arrow Fn arrow Fn arrow Fn.... unless it operates in both modes.

I would just call it Shift and put the alternates in traditional spot on key, I think they called it Fn so that they can claim you can use the arrows WITHOUT shift ... marketing doublespeak because the +*/ etc is now shifted instead.

IMHO Truly need to think more deeply about their designs (and that includes their Ergo keyboard).
Title: Re: Balanced Keyboard Layout
Post by: Den on 2016-Oct-01 04:14
I do that by default due to the way my hands were issued to me. I use pinky for control and shift and ring for anything higher.
It's actually a rare inherited genetic 'experiment' by nature (Type B brachydactyly, but only on pinkies/5th toe), to see if humans really need long pinkies. Guitar players and typists probably do. Labourers probably not.

It means I need to swing my hand to hit Enter or Backspace. And I use backspace a lot :-)

To hit the Enter and Backspace, I would move the entire arm and hit them with the middle finger or sometimes two or more fingers.

On KLA, I suggest that far keys be reassigned to non-pinky fingers. Not sure how that would affect the scores.
Title: Re: numpad
Post by: Den on 2016-Oct-01 04:37
I was wondering the same thing and thought the same as above, but using arrow key will then be a pain... arrow Fn arrow Fn arrow Fn.... unless it operates in both modes.

I would just call it Shift and put the alternates in traditional spot on key, I think they called it Fn so that they can claim you can use the arrows WITHOUT shift ... marketing doublespeak because the +*/ etc is now shifted instead.

IMHO Truly need to think more deeply about their designs (and that includes their Ergo keyboard).

apparently their design is patented, too.

couldn't find much help on their site, so i looked for videos reviews. i.e. https://www.youtube.com/watch?v=Z_i3xuJc_lc

But he doesn't describe how the shortcuts are activated.

Title: effort grid
Post by: iandoug on 2016-Oct-01 04:50
Started poking in Patrick's code. I should fix the Arensito and Balanced layouts in my repo and push to him. Bit out of practice with Github.

Anyway this seems to be his 'effort' grid, to be used in conjuction with "distance between keys", have not figured out how he weights top row as better than bottom row yet, unless that's possibly a consequence of "distance between keys".

        // FINGER USAGE
        results.fingerScores = [];
        var percent;
        var fScoring = {};
        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;
       
But more importantly, his calculation is a little more subtle than explained in the visible text on the results page:
        var consecHandWeight = 17, consecFingerWeight = 17, fingerUsageWeight = 33, distWeight = 33;

So he measures "consecutive hand use + consecutive finger use" as one third of score.
Which seems a bit double-counting to me, as same finger requires same hand.

Will ponder his code over brunch :-)
Title: Re: Balanced Keyboard Layout
Post by: Den on 2016-Oct-01 05:41
So thumbs have same weight as pinky. Is that why our thumb layouts don't score that well?
Title: Re: Balanced Keyboard Layout
Post by: Den on 2016-Oct-01 06:52
Those pinky values are rather harsh :-)

actually I reduced the top pinky to match the bottom pinky.

think of the values to help the optimizer prioritize the keys. the pinkies should have the lowest priority by far.

Quote
I went searchabout on Google to find other people's grids the other day, the most comprehensive I found was I think from the Carpalx guy (Martin, eventually found his name) because it includes the "whole" keyboard (ie numrow and up to |\ key, but not modifiers...).
I suspect Patrick's weightings are based off of this, because he assigned 0 to all four home finger positions, and Patrick's weightings seem similar.

http://mkweb.bcgsc.ca/carpalx/?typing_effort
His discussion on this page reminds me of your way of thinking... :-)

His research came out first, so I might have picked up the same talking points. While we may intuit these things, however, putting it all into values and algorithms, and finally into an ideal layout is far from trivial. So to his credit, he was able to make the seminal Carpalx. But ironic that his best optimized layout doesn't do that well on KLA.

Quote
On another note I'm going to try to sort out the mess of alternate layouts I have (and hopefully drop the weaker ones), and in the process rename them more sanely than BEAKL 4 Mod Ian 73.08 74.7. xxxx , I think I will keep BEAKL just for yours or where I've done very minor mods like moving a key or two, and rename the others based on home row (or somesuch).

For that matter, is it time to reveal our layouts and findings to the public? We should choose the most acceptable ones.

The base BEAKL have extremely low pinky usage, so they have their appeal. BEAKL 36 (actually 34) seem more friendly for coding, but may not be easily adapted for most keyboards. While BEAKL 4 seems safe and can be great at code if packaged with AltGr layer for punctuations.

Actually I might have to make one BEAKL 32 that would be acceptable on standard keyboard, and which would be nice compromise between BEAKL 4 and 36.

As for your layouts that score the highest on KLA, we could come up a clever name. Like "KLA-BEST".
Title: Re: Balanced Keyboard Layout
Post by: Den on 2016-Oct-01 09:00
According to my current Opt configuration, these are the order of best layouts amongst mine and other well-known layouts :
Code: [Select]
BEAKL Opted32
BEAKL Opted4
BEAKL Opted3
BEAKL zx-cv
BEAKL z-xcv
BEAKL zxcv-
BEAKL Opted1

HIEAMTSRN
Balanced12
Bu Teck
Balanced_V
Carpalx

BvoFRak
Klausler
MTGAP
Vu Keys
Dvorak
Neo 2

BLOU
Colemak
Amuseum
Norman

Workman
Arensito

Capewell
Qwerty

ABCDEF

TNWMLC

Consider that my settings prefer low pinky usage, high hand alternation, inward rolls (over outward rolls), and the most recent effort model.

Due to limitations of Opt, this list counts only main 32 keys. so alternative layouts like 34/36 keys, altgr, and ergo are not counted.
Title: Re: Balanced Keyboard Layout
Post by: Den on 2016-Oct-02 02:46
Just tested BEAKL 34 and it feels very awesome. So intuitive and smooth. Some mistakes from similarity to previous BEAKL familiarity, which I hope doesn't take too long to overcome. Most important is for some reason I don't feel as anxious as typing with previous BEAKL layouts, less locking up.
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2016-Oct-02 10:29
Dunno if you are on MassDrop, this from a year ago has popped up, looking for interest in having made....

https://deskthority.net/workshop-f7/diy-35-keyboard-t10319.html
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2016-Oct-02 14:34
After a whole weekend of tedious data capture, have new tests and your layouts on site.

Added a link to a page about the current champ (all tests, ANSI) layout too.

I think if I move the Enter key it will do slightly better.

Have not renamed all my experiments or layouts yet, so the ANSI results are flooded with my stuff at the top of the lists... just disable if required. Have decided to label the weaker ones as 'experiments' and have a toggle to hide them. I also have a whole stack NOT in the database (including a lot of Ergo thumb-style experiments) but those will have to wait a bit.

Need to add links to the corpus files. Should probably not diss the professor like that, but IMHO "quotes" are effectively under MIT licence and so should any collection of them be... :-)

cheers, Ian
Title: Re: Balanced Keyboard Layout
Post by: Den on 2016-Oct-02 15:26
Dunno if you are on MassDrop, this from a year ago has popped up, looking for interest in having made....

https://deskthority.net/workshop-f7/diy-35-keyboard-t10319.html

Never want to go back to staggered keyboard. This has too few keys, loses functionality.

TEK is more like something I'd want. They recently came out wth new models. I need to research reviews on their build quality.

ErgoDox also supports many layers, so that could be the right direction to push for the Punc modifier. But very difficult to acquire one.
Title: Roundup of assorted points
Post by: iandoug on 2016-Oct-02 16:07
"For that matter, is it time to reveal our layouts and findings to the public? We should choose the most acceptable ones."

I need to fix some things on the site first... housekeeping stuff, and there's an Under Construction page as well.

"As for your layouts that score the highest on KLA, we could come up a clever name. Like "KLA-BEST"."
:-)
In truth those AltGr layouts have upset the apple cart ... and now completely dominate the top 10. So "Best" is currently a moving target. I need to reduce the ones visible, and yeah, get better names...
My problem is that many were originally based off of BEAKL or HIEMSTRA, but at what point does it cease being a mod and become something else? Every layout had to start somewhere, even if ABCDEF...
So on the one hand I want to give credit where due, but also don't want to dilute other's work, or trade on their name...

I actually have 4 ranges: High Score, Low distance, Low samefinger, and Just-Rearrange (to compete directly with Colemak etc... no fancy tricks that you can't achieve just by swapping keycaps on a standard board).
Make that 6 ranges if we include Ergo and Thumbkey Ergo.

"Those pinky values are rather harsh :-)"
I meant you really punish pinky use with those numbers .... but I don't think home pinky should be hit so hard. You either put some things on pinky, or index has to work overtime ...
So few fingers, so many keys... :-)

Title: Re: Roundup of assorted points
Post by: Den on 2016-Oct-02 17:29
"For that matter, is it time to reveal our layouts and findings to the public? We should choose the most acceptable ones."

I need to fix some things on the site first... housekeeping stuff, and there's an Under Construction page as well.

Besides that, it behooves to test these layouts. Testing by ourselves is important to have first-hand experience. But beta-testing with the public would get more feedback and attention.

Quote
"As for your layouts that score the highest on KLA, we could come up a clever name. Like "KLA-BEST"."
:-)

or how about Klamax?

Quote
In truth those AltGr layouts have upset the apple cart ... and now completely dominate the top 10. So "Best" is currently a moving target. I need to reduce the ones visible, and yeah, get better names...
My problem is that many were originally based off of BEAKL or HIEMSTRA, but at what point does it cease being a mod and become something else? Every layout had to start somewhere, even if ABCDEF...
So on the one hand I want to give credit where due, but also don't want to dilute other's work, or trade on their name...

Once we sort out the ones we want, we can determine their sources and final names.

Quote
I actually have 4 ranges: High Score, Low distance, Low samefinger, and Just-Rearrange (to compete directly with Colemak etc... no fancy tricks that you can't achieve just by swapping keycaps on a standard board).
Make that 6 ranges if we include Ergo and Thumbkey Ergo.

BEAKL Opted4 is pretty much Just-Rearrange. I prefer quick access to parentheses (), and number row rearranged, but those parameters can be ignored with no effect.

BEAKL 32 extends just two keys which would be occupied by punctuation on standard keyboards, which tops the list I posted just a few posts above. And "BEAKL zx-cv" even tries to maintain those letters at the bottom left. They don't look that different than other BEAKL layouts.

In fact, 32 keys is the default number in Opt.

Yet it is easy to regenerate layouts to fit these exact parameters. Then make sure we don't tamper with extraneous keys.

Quote
"Those pinky values are rather harsh :-)"
I meant you really punish pinky use with those numbers .... but I don't think home pinky should be hit so hard. You either put some things on pinky, or index has to work overtime ...
So few fingers, so many keys... :-)

You're missing the forest for the trees. What's most important are the results, and you need these proper measures to achieve the desired results. Which is low overall pinky percentage and low same-pinky. The latter is the most vulnerable for the weak finger.

The other problem is pinky is just not as agile, so overusing them will slow you down.

I have some theories on why people can type so fast on Qwerty, but that deserves its own post. I conjecture one factor may be the relatively low pinky usage. Such that pinkies would not hinder the other fingers as they move up and down the keyboard.
Title: Re: Balanced Keyboard Layout
Post by: Den on 2016-Oct-02 18:13
Your concern about overuse of index is unfounded. First, index is quite flexible and nimble, and can take a lot more stress than pinky.

Second, the total index finger usage doesn't rise as a result. The overall effort is distributed among the bigger fingers. One major reason is how my effort grid prioritize the keys evenly away from the pinky and center (inner-index) columns. Also I tell Opt the target percentage for each finger. For the index, this includes the center column. So it will punish if it overshoots the target.

Third, our inner-index usage is still lower than some other popular layouts. Including Colemak and Dvorak. With some tweaks, it may drop a bit more. For example, put U and D at the top indexes rather than inside.
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2016-Oct-03 02:59
Third, our inner-index usage is still lower than some other popular layouts. Including Colemak and Dvorak. With some tweaks, it may drop a bit more. For example, put U and D at the top indexes rather than inside.

When playing around I came to the conclusion that KLA prefers home-row to up/down for the index to move. Possibly the physical distance on a staggered keyboard is a millimetre or so less. Which adds up.

My "problem" when trying to optimise is that the index is frequently flying around a lot, but again, so few fingers, so many keys .... the alternatives are worse.

I must write a rant page about ZXCV .... :-) people are obsessed with them, forgetting all the other shortcuts they use. And there are convenient alternatives to XCV, just most people don't know them.

Cheers, Ian
Title: Re: Roundup of assorted points
Post by: iandoug on 2016-Oct-03 03:00
or how about Klamax?

I can see the ads now ... "Have you had your Klamax today?" .... :-)
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2016-Oct-03 03:09
Get going with your Klamax.

Bill Gates: "One Klamax should be more than enough for anybody."

Or for the techies: First thing in the morning, last thing at night: Klamax!

I should shut up now. :-)
Title: Re: Balanced Keyboard Layout
Post by: Den on 2016-Oct-03 03:23
Trying to find a pattern in the list of best layouts among BEAKL's Opt and KLA tests.

Code: [Select]
hiea-str
aeoh
oaei
inea
ieoa
uiae
neio
soen
nioh
aren
tnio

The most consistently top scores (so far) are in the family HIEA-STR. The vowels and punctuations reside in one half of the keyboard and the other half are all consonants. This family includes most BEAKL Opted layouts, HIEAMTSRN, Balance 12, and Bu-Teck. It is common to see YOU right above IEA.

The HOEAI is discovered by the Carpalx program. The vowel and consonant districts are very similar to HIEA, except O is brought down and I is moved to the center. One quirk about this layout is the restriction of ZXCV to the bottom left. My own layouts that have this same restriction all have YHEAU instead, with DOI above HEA.

The next contenders are OAEI and IEOA. These tend to be improvements over the influential Dvorak layout, including Klausler, Balanced V (my layout that was derived from Klausler), and BvoFRak. Like Dvorak and the other better layouts mentioned, all vowels fall on one side of the keyboard that encourages hand alternation when typing. These three all have RHTNS in some form on the opposite home row.

A slight departure is MTGAP, which has INEA as its home left hand. It was also developed with a optimizing algorithm, so it's a strong contender in its own right.

Followed by Dvorak and its followers. These have 5 of the 6 vowels AEIOUY on the home row of one hand. Dvorak (AOEUI), Vu Keys (AOEIY), and Neo 2 (UIAEO).

Then comes the Colemak family, which tries to keep as much of Qwerty as possible. Including keeping ZXCV at its default Qwerty location. Workman and Norman tries to improve on Colemak's ergonomic issues, but not without a cost to performance.

Finally there are the outliers. They include Arensito, Capewell, and Qwerty. The latter is of course the grand-daddy of all layouts created over 140 years ago, and is still the standard found on all keyboards, despite its well-known shortcomings. Arensito and Capewell were developed quite early in the 21st century compared to other layouts, so did not have the advantage of being refined by the later, more sophisticated optimizing software.
Title: Re: Balanced Keyboard Layout
Post by: Den on 2016-Oct-03 03:44
When playing around I came to the conclusion that KLA prefers home-row to up/down for the index to move. Possibly the physical distance on a staggered keyboard is a millimetre or so less. Which adds up.
Which is odd because OU is such a common bigram and would benefit greatly being placed closer together and on the same row.

Quote
My "problem" when trying to optimise is that the index is frequently flying around a lot, but again, so few fingers, so many keys .... the alternatives are worse.

It's not that bad as long as total keys pressed by indexes are not high and you have high hand alternation to let them rest. But be glad that BEAKL effort grid doesn't place high value on home inside index, or it'll be really hurting, as Workman attested.

Quote
I must write a rant page about ZXCV .... :-) people are obsessed with them, forgetting all the other shortcuts they use. And there are convenient alternatives to XCV, just most people don't know them.

Cheers, Ian

The reliance and abuse of XCV shortcuts is terrible to ergonomics and is known to be a cause of carpal tunnel syndrome. Nevertheless, I whipped up this layout for those people:

Code: [Select]
BEAKL ZX-CV

wnlpg (iod- j
brtsf uaehy k
 zxmcv ),."q

I've tried ZXCV*, Z*XCV, and ZX*CV, with the latter winning out overall.

Not only does it surpass Colemak in prose and code for the most part, it is much more ergonomic. Alas, that's all it's good for as it doesn't score well on KLA.
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2016-Oct-03 04:01
The most consistently top scores (so far) are in the family HIEA-STR. The vowels and punctuations reside in one half of the keyboard and the other half are all consonants. This family includes most BEAKL Opted layouts, HIEAMTSRN, Balance 12, and Bu-Teck. It is common to see YOU right above IEA.

My experience playing with KLA revealed this:

O on home row gives best "low distance" scores. But not Best Scores overall.
For that, you need O above E, because the OE/EO combo in English is very rare (but quite common in a language like Afrikaans (and presumably Dutch and German too).

See here:
http://patorjk.com/keyboard-layout-analyzer/#/load/gN7jFV2Q

I have lower distance scores on other 'experimental' layouts but that low distance of 14,835 must be compared to the 'mainstream' one (Arensito, if that counts, at 15,967) or Workman Programmers at 16,433. Huge difference. Others are worse.

Downside is some extra work for middle finger.
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2016-Oct-03 04:03
I have come to the conclusion that English has 7 vowels ... AEIOU and H and Y.

The idea that O should not be on the home row surfaced here:

https://mathematicalmulticore.wordpress.com/2010/06/24/new-keyboard-layout-project-have-we-been-mistaken-all-along/
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2016-Oct-03 04:05
I will add "BLOU" (Afrikaans for blue) layout above to my tests to see if the claims stand up :-)
Title: Re: Balanced Keyboard Layout
Post by: Den on 2016-Oct-03 04:22
My experience playing with KLA revealed this:

O on home row gives best "low distance" scores. But not Best Scores overall.
For that, you need O above E, because the OE/EO combo in English is very rare (but quite common in a language like Afrikaans (and presumably Dutch and German too).

See here:
http://patorjk.com/keyboard-layout-analyzer/#/load/gN7jFV2Q

I have lower distance scores on other 'experimental' layouts but that low distance of 14,835 must be compared to the 'mainstream' one (Arensito, if that counts, at 15,967) or Workman Programmers at 16,433. Huge difference. Others are worse.

Downside is some extra work for middle finger.

Distance is not constant among keyboard form-factors and especially between algorithms and parameters used to calculate it. Moreover there are other factors to speedy and comfortable typing, including ease of bigrams and trigrams, rolls, even distribution of finger usage, hand alternation, and minimizing consecutive same-finger. So relying on distance as the main factor to determine the best layout can be misleading and red herring.

Hence, overall score are usually called effort scores, since it covers more than just distance.
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2016-Oct-03 04:41
Moreover there are other factors to speedy and comfortable typing, including ease of bigrams and trigrams, rolls, even distribution of finger usage, hand alternation, and minimizing consecutive same-finger.

I was thinking I must add bigrams and trigrams as tests... Dunno if Patrick looks at that or not or if it is 'automagically' included invisibly by just being in the text.
Title: Re: Balanced Keyboard Layout
Post by: Den on 2016-Oct-03 04:56
I have come to the conclusion that English has 7 vowels ... AEIOU and H and Y.

The idea that O should not be on the home row surfaced here:

https://mathematicalmulticore.wordpress.com/2010/06/24/new-keyboard-layout-project-have-we-been-mistaken-all-along/

I've read that before. When you reduce the effective number of columns to 4 or even 3, then the top and bottom rows have to take up the slack.

You revealed earlier the weights of each finger for KLA. If it means what I think it means, then putting more common letters on the middle and index fingers will give higher scores. In other words, putting a very common letter on the home pinky will not score as high versus if it was on the middle finger.
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2016-Oct-03 05:06
You revealed earlier the weights of each finger for KLA. If it means what I think it means,

I'm not so sure about that... those are only "finger" weightings, he must have an array somewhere with the weightings for each key, just haven't found it yet in all his .js bits and pieces. Will search again.
Those numbers seemed too little for all the sums he does.

Isn't it a bit late there now? :-)
Title: Re: Balanced Keyboard Layout
Post by: Den on 2016-Oct-03 05:17
I've read that before. When you reduce the effective number of columns to 4 or even 3, then the top and bottom rows have to take up the slack.

You revealed earlier the weights of each finger for KLA. If it means what I think it means, then putting more common letters on the middle and index fingers will give higher scores. In other words, putting a very common letter on the home pinky will not score as high versus if it was on the middle finger.

By the same token, BEAKL layouts with N at the top and STR at home can be seen as more efficient than STNR. The ring finger is faster than pinky, and you get faster rolls from ring to middle and to index.
Title: Re: Balanced Keyboard Layout
Post by: Den on 2016-Oct-03 05:19
I'm not so sure about that... those are only "finger" weightings, he must have an array somewhere with the weightings for each key, just haven't found it yet in all his .js bits and pieces. Will search again.
Those numbers seemed too little for all the sums he does.

Isn't it a bit late there now? :-)

Finger usage is 1/3 of the overall score. That's why the weights of each finger regardless of row is important, if that is in fact how it counts this part of the score. This is not related in any way to the distance score.
Title: BLOU
Post by: iandoug on 2016-Oct-03 05:27
Gets good same-finger score (better than any other mainstream), other metrics not so good.

http://patorjk.com/keyboard-layout-analyzer/#/load/q9p3b6L6
Title: bigrams
Post by: iandoug on 2016-Oct-03 09:35
Cleaning up my keyboard folder, found a bigrams file.
Here's the bottom. Find it hard to believe so many occurrences of these combos ... don't think I've ever seen them. Maybe I need to read more scientific literature ;-)

xz   23383121
vk   21599286
xq   20714339
qq   16554628
zx   16061325
qv   15697108
vj   15424672
qg   15295164
jy   10880910
vq   8637649
qk   8123073
jz   8070227
qx   7684606
vz   7573361
qj   6944827
qy   6901470
zq   6170496
jx   5682177
qz   4293975
jq   2858953

Now need to figure out how to build a file with relative frequency of these into something that KLA can handle. Numbers are huge, PHP will probably throw weird errors (like converting to float instead of integer) if I add them all up ...
Title: Re: Balanced Keyboard Layout
Post by: Den on 2016-Oct-04 04:19
If you're into layers, check this out. This has 7 layers, but uses only the 3x4 keys on each hand, and both thumbs. Heavy mix of modifiers and dead keys.

https://web.archive.org/web/20130512083048/http://www.andong.co.uk/dvorak/DDvorak.aspx?page=Advanced+DDvorak

He uses comma as dead key. On Dvorak that's at top ring. On most of our layouts, comma is at bottom index. Which I think is better because that's a faster and easier key to hit. This really entices me to try this method. Only problem is how to set up. Most likely with Autohotkey, but still need to research the API and see how others have done it.

Also how would dead keys affect games?
Title: Re: Balanced Keyboard Layout
Post by: Den on 2016-Oct-04 07:10
I'm thinking make numpad left-handed and train this way, so i can enter all numbers without leaving right hand off mouse. Turn Caps Lock into Num Lock, which toggles the numpad. Autohotkey will recognize the key press based on the state of Num Lock. Kinesis has Keypad button, which I can use as another layer for numbers and others.

Code: [Select]
BEAKL Left Numpad

 2976
5103.
-48/

Top pinky is not used. Dot and slash stay on the same key as on the letter layer (of BEAKL 34).

Title: Assorted...
Post by: iandoug on 2016-Oct-04 17:46
Hi

Not wild about layers which is why I am so annoyed with the AltGr things doing so well... as I said before, I sometimes get += mixed up and can't think of more than 2 layers on a key... :-) ... my mind is not that capable... :-)

Re left hand numpad, it's much easier to switch your mouse to your left hand... :-) Or get an ambidextrous trackball. Suggest you try on a cheapie ambidextrous mouse first, when you realise the world hasn't ended you can get a proper left-hand gaming mouse. Just a suggestion :-). I know we've discussed it before, but think like a permaculture farmer, they have a dictum that "the problem is a solution". In your case the problem is the mouse is too far away and interferes with your numpad. (Which I guess is standalone). So you can either invent a left-handed numpad, or just move the mouse.... :-)
 
I'm getting very annoyed with this MS natural numpad, the keys are feeling squishy and difficult to press. Really need to migrate up to proper mech switches. It's not like it's overused, I hardly used the numpad until all this data capture started.

Anyway I've loaded all the the test results for the bigrams, trigrams and quadgrams, leading to some assorted comments:

1. results were most varied of all the tests I've done, particularly same-finger on the quadgrams... varied from 0 (yes, quite a few, could not believe the first one) to in the thousands. Some of your layouts also got 0.

2. was quite chuffed that my designed-from-first-principles-just-rearrange-no-fancy-tricks layout does the best against its peers... especially since it was done by hand and without any algorithms checking bi,tri and quadgram performance.

3. In the same vein, those Halmak layouts don't do too badly at English, when compared against their peers (just rearrange, no tricks).  BLOU also quite good at English.

4. That thumbhack layout with H on thumb continues to impress too :-)

Got a bit of flu so need to get some rest. Been a hectic day.

Cheers, Ian

Title: Re: Balanced Keyboard Layout
Post by: Den on 2016-Oct-04 18:41
I don't have AltGr and have all the puncs are in relatively good positions on the Kinesis (due to its compact boxed-in design). So the only layer I really want is to use the same hand for typing numbers, which are way more important than puncs.

It would take a new lifetime to retrain my left hand to be as strong and accurate as my right hand to control the mouse. Kinesis doesn't have a numpad, so the distance argument is moot. OTOH it takes one session to learn a new numpad.

Turning Caps Lock into Num Lock, I can quickly toggle on and off the numbers layer.
Title: Re: Balanced Keyboard Layout
Post by: Den on 2016-Oct-04 20:28

KLE image of my Kinesis layout (BEAKL 34 and left numpad):
(http://www.shenafu.com/code/keyboard/KLE-BEAKL-34-Kinesis.png) (http://www.keyboard-layout-editor.com/##@@_c=%23fbbbc9&f:1&f2:2&w:0.675&h:0.85%3B&=%0APaste&_x:0.07499999999999996&c=%23cccccc&w:0.675&h:0.85%3B&=%0AF1&_x:0.07499999999999996&w:0.675&h:0.85%3B&=%0AF2&_x:0.07500000000000018&w:0.675&h:0.85%3B&=%0AF3&_x:0.07500000000000018&w:0.675&h:0.85%3B&=%0AF4&_x:0.07500000000000018&w:0.675&h:0.85%3B&=%0AF5&_x:0.07500000000000018&w:0.675&h:0.85%3B&=%0AF6&_x:0.07500000000000018&w:0.675&h:0.85%3B&=%0AF7&_x:0.07500000000000018&w:0.675&h:0.85%3B&=%0AF8&_x:4.825&w:0.675&h:0.85%3B&=Repeat%20Rate%0AF9&_x:0.07499999999999929&w:0.675&h:0.85%3B&=Disable%20Macro%0AF10&_x:0.07499999999999929&w:0.675&h:0.85%3B&=Macro%0AF11&_x:0.07499999999999929&w:0.675&h:0.85%3B&=Remap%0AF12&_x:0.07499999999999929&w:0.675&h:0.85%3B&=PrintScr%20SysReq&_x:0.07499999999999929&c=%23ac97d8&w:0.675&h:0.85%3B&=Scroll%3Cbr%3Elock&_x:0.07499999999999929&c=%23cccccc&w:0.675&h:0.85%3B&=Pause%20Break&_x:0.07499999999999929&c=%23ac97d8&w:0.675&h:0.85%3B&=Keypad&_x:0.07499999999999929&c=%23cccccc&w:0.675&h:0.85%3B&=Progrm%3B&@_x:2.25&f:3%3B&=0%0A%2F&&=1%0A%23&=2%0A$&=3%0A%3F&_x:5.5%3B&=8%0A%7C&=7%0A%2F@&=6%0A*&=5%0A%25%3B&@_y:-0.75&c=%23fbbbc9&a:6&w:1.25%3B&=Esc&_c=%23cccccc&a:4%3B&=4%0A%5C&_x:13.5%3B&=9%0A%5E&_c=%23fbbbc9&a:7&w:1.25%3B&=Delete%3B&@_y:-0.25&x:2.25&c=%23cccccc&a:4&f:6&fa@:0&:0&:0&:3%3B%3B&=Y%0A%0A%0A2&=O%0A%0A%0A9&=U%0A%0A%0A7&_f:3%3B&=%27%0A!%0A%0A6&_x:5.5&f:6%3B&=W&=D&=L&=N%3B&@_y:-0.75&f:3&w:1.25%3B&=-%0A%60&_f:6%3B&=X&_x:13.5%3B&=V&_w:1.25%3B&=Z%3B&@_y:-0.25&x:2.25&c=%235eb1e7&fa@:0&:0&:0&:3%3B%3B&=I%0A%0A%0A1&=E%0A%0A%0A0&=A%0A%0A%0A3&_c=%23cccccc&f:3&fa@:6&:0&:0&:6%3B%3B&=.%0A%2F_%0A%0A.&_x:5.5&f:6%3B&=G&_c=%235eb1e7%3B&=S&=T&=R%3B&@_y:-0.75&c=%23ac97d8&a:6&f:3&w:1.25%3B&=Num%3Cbr%3ELock&_c=%235eb1e7&a:4&f:6&fa@:0&:0&:0&:3%3B%3B&=H%0A%0A%0A5&_x:13.5%3B&=P&_c=%238ed7b0&a:7&f:3&w:1.25%3B&=Ctrl%3B&@_y:-0.25&x:2.25&c=%23cccccc&a:4%3B&=%22%0A%2F%3B%0A%0A4&=)%0A%3E%0A%0A8&=,%0A%2F%2F%0A%0A%2F%2F&=%2F:%0A~&_x:5.5&f:6%3B&=F&=C&=M&=B%3B&@_y:-0.75&w:1.25%3B&=J&_f:3%3B&=(%0A%3C%0A%0A-&_x:13.5&f:6%3B&=K&_w:1.25%3B&=Q%3B&@_y:-0.25&x:2.25&c=%23f8d615&a:7%3B&=%E2%87%A9&=%E2%87%A7&=%E2%87%A8&_x:7.5&c=%23cccccc&a:4&f:3%3B&=%5B%0A%7B&=%2F=%0A+&=%5D%0A%7D%0A%0A%0A.%3B&@_y:-0.75&x:1.25&c=%23f8d615&a:7&f:6%3B&=%E2%87%A6&_x:13.5&c=%23cccccc&a:4%3B&=+%3B&@_r:15&rx:5.25&ry:4&x:1.5&c=%238ed7b0&a:7&f:3%3B&=Shift&=Ctrl%3B&@_x:0.5&c=%235eb1e7&h:2%3B&=Space&_c=%23fbbbc9&h:2%3B&=Back%3Cbr%3ESpace&_c=%23f8d615%3B&=Home%3B&@_x:2.5%3B&=End%3B&@_r:-15&rx:12.75&x:-3.5&c=%238ed7b0&a:4%3B&=Cmd%0A%0A%0A%0A%0A%0AWin&_a:7%3B&=Alt%3B&@_x:-3.5&c=%23f8d615&a:6%3B&=Page%3Cbr%3EUp&_c=%23fbbbc9&a:7&h:2%3B&=Tab&_c=%235eb1e7&h:2%3B&=Enter%3B&@_x:-3.5&c=%23f8d615&a:6%3B&=Page%3Cbr%3EDown)
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2016-Oct-05 02:22
I was actually wondering how Kinesis would handle the right-hand shortcuts that replace Ctrl XCV... seems like they won't work on Kinesis layout, and you need them if you use the mouse on the left hand (which, by the way, I also thought was a dumb idea until I tried it.)

Anyway your design is interesting, I'll ponder it more later. First thing I noticed was that you have 1 0 3 on home rather than 1 0 2 .... why is that? 2 is more common than 3 and it looks like you've put 2 on ring, not even middle? Just find that a bit puzzling :-)

Can't you make AltGr layouts work with Kinesis? Is this a physical button issue or software/controller issue?

thanks, Ian
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2016-Oct-05 02:25
Just realised the ortholinear nature of Kineses/Ergodox is one of the reasons it gets better scores ... diagonal distance for index and pinky to move is shorter than on staggered. Even up-down will be fractionally shorter.
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2016-Oct-05 03:23
Can I add your layout above to my site? Am building a gallery with KLE layouts, since the KLE site only has a few presets and there's lots of interesting ideas on the web.

Thanks, Ian
Title: Re: Balanced Keyboard Layout
Post by: Den on 2016-Oct-05 06:41
I was actually wondering how Kinesis would handle the right-hand shortcuts that replace Ctrl XCV... seems like they won't work on Kinesis layout, and you need them if you use the mouse on the left hand (which, by the way, I also thought was a dumb idea until I tried it.)

There are many alternative ways to execute copypasta.
1. Put them on the mouse. Highly recommended.
2. Autohotkey and similar software to remap shortcuts.
3. Kinesis macros. Will be retained on keyboard between computers without need for OS software. There are a few redundant and useless keys that can be reused for this purpose.
4. If you use Dvorak-like layouts with consonants on right hand, then those combos can be executed by the right hand.

Quote
Anyway your design is interesting, I'll ponder it more later. First thing I noticed was that you have 1 0 3 on home rather than 1 0 2 .... why is that? 2 is more common than 3 and it looks like you've put 2 on ring, not even middle? Just find that a bit puzzling :-)

That's what the optimizer came up with. Maybe my imperfect corpus has way more 3 than 2. Should be okay to switch them if you like. But that's pretty close to optimal. I restricted dot and slash to be at the same spot as the letter layer. 10 of course at the home keys. 598 and dash pretty much stay in those spots. Either 67 in the far top corner.

Quote
Can't you make AltGr layouts work with Kinesis? Is this a physical button issue or software/controller issue?

Kinesis Advantage2 doesn't have the AltGr key. The manual and website don't mention it at all. I've never used or seen AltGr before, so I don't know what one needs to add it.

Can I add your layout above to my site? Am building a gallery with KLE layouts, since the KLE site only has a few presets and there's lots of interesting ideas on the web.

Sure. Actually the layout was quite different before I switched to BEAKL 34. Escape was brought all the way down to outside bottom left pinky. Caps Lock was Control. etc.

GeekHack has lots of Interesting Layouts (https://geekhack.org/index.php?topic=83799.0)
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2016-Oct-05 07:10
There are many alternative ways to execute copypasta.

:-) I was referring to the other standard shortcuts using Ctrl, shift, and Insert + Delete, with the right hand.

Kinesis Advantage2 doesn't have the AltGr key. The manual and website don't mention it at all. I've never used or seen AltGr before, so I don't know what one needs to add it.

Probably a consequence of aiming at the American market.

from Wikipedia:
==============
Originally, US PC keyboards (specifically, the US 101-key PC/AT keyboards) did not have an AltGr key because that was relevant to only non-US markets; they simply had "left" and "right" Alt keys.

The right Alt key is usually an equivalent of the AltGr key because both the right Alt key and the AltGr key share the same scancode and are indistinguishable by software. However, on some keyboards it may not be the case, i.e. the keyboard has two Alt keys, each of which acts as the left Alt key. On compact keyboards like those of netbooks, the right Alt key may be missing altogether. To allow the specific functionality of AltGr when typing non-English text on such keyboards, Windows allows it to be emulated by pressing the Alt key together with the Control key:
==================

Thanks for the geekhack link :-)

Cheers, Ian
Title: Re: Balanced Keyboard Layout
Post by: schizoID on 2016-Oct-05 07:29
Hello!

Story.

Some remarks:
1. sorry for my English, it is really bad, but I hope that you can understend what I mean
2. all text examples shown in [  and ]

The story begins that I wanted to learn some better layout for programming than QWERTY. I found Dvorak for programmers and start to learn it. But accidently I started to search other alternatives and came to this site.

When I start to try layouts from this topic, I initially want to check the most effective layout for regular not ergonomic keyboards, and at the moment this was BEAKL AltGr 1 or, as I remember, which have best scores.

Problem 1.

At least for me the problem with this layout is that KLA in analysis don't take into account (as I may conclude) "overall" hand state at home position, which in this layout for the right hand is terrible for me because of unnatural position of the right thumb which is very curved so it can be placed at home position in Alt_R. KLA thinks that it is Ok, but in real life this is not. For example, try to type [ "]  or [ &]  on AltGr version 2 with right thumb and index.

I thought, what if I just remove home position from Alt? Results drastically goes down (Alt 2 from top position go to last on Alice): http://patorjk.com/keyboard-layout-analyzer/#/load/JSGvJ4Vq

So, the first thought that came into my mind was that I need to "uncurve" my right thumb, and the solution as I saw then, was to shift hand by one key to right.

Then I created my custom layout, optimize symbols' positions with KLA, and create custom layout in linux for real tests. And it looks good, but the problem with curved thumb still exists, may be not so greatly as in Ian AltGr 2 version. And this version was unacceptable for me too.

Problem 2.

When I do real tests while typing some text in my shifted version I accidentally typed [  I'll ] . This was another BIGGER problem: movement of right thumb when you type something mixed with Alt_R and Shift_R. Consider quoted text, dialogs, constants in the programming languages. For example, in the BEAKL 4 Mod Ian AltGr 2 for typing a start of the dialog [ "I've]  you need to do this (assuming that your thumb at AltGr in home position, but it difficult because finger is not relaxed completely at ordinal keyboard at this position): hit AltGr, hit [ "]  with the SAME hand (try it), move thumb to Shift_R, hit it hold it, hit [ I] , move thumb to AltGr, hit it, hold it, hit [ '] . Try to do all of these quickly as you can =) Yes, I can try to move such key combinations (for example move [ ']  and [ "]  to another keys without AltGr and Shift_R), but who knows how much of such sequences can occur in different types of texts and with which symbols? And even if I need to type just one such sequence in the middle of something long, it would be very annoying.

SpaceBar - as a MOD Key (AltGr).


I start to thinking how to fix this problem. I thought: "SpaceBar is very good to be a modifier. But how then will type space itself, which is most frequent character in text, especially in code where names of variables as short as we can and so many one-tow length signs sequences". I decided try to map AltGr to SpaceBar and space symbol to AltGr + [ A]  and unshift right hand , and see what results I can achieve in KLA. And results were even better than with existed AltGr versions. It was a good sign for me =) I start to experiment again with the positions of symbols, map Return on AltGr + [ S]  (In Linux at shell I found that Ctrl+m is more convenient for me instead to reposition right hand to hit Enter, and KLA agreed with me =) ), which give even more scores. Then I create xkb layout and begin real tests. Situation was much better than with previous tests.

Problem 3.

When you type space symbol in some text in such way it costs you much "brain energy" =) : you need take into account short timings and coordinate accurately your index and thumbs to not to type some other AltGr symbol instead of space, or [ a]  instead of space. For example on right middle in BEAKL we have T, which is very frequent character, I want to place here on Alt state [ ,] . And [ Try to type this text without commas as fast as you can]  :D. When I type space in a such way I see at the screen that when I hold SpaceBar and hit [ a]  it printed IMMEDIATLY. And I just want to type [ t]  IMMEDEATLY, because pressed down space generates NO symbol by itself, and I just hit [ t]  whith holded space and got commas. I must always recall to myself to release SpaceBar before I press [ t] .

Hack in Linux with xcape.

Very long time I tried to change the position of the space or AltGr, but results go down. I thought that I'm stucked. I didn't sleep for 24+ hours (Never think that design and optimize your own layout may be so fun ;) ). But suddenly into my head came the HACK how to fix it. Long ago in one article I read that in Linux there's utility called xcape. How I remember it I don't know, because I read that article very briefly and didn't try to remember anything, and it was very long in the past =)
xcape allows you to assign to modifiers ANY other key, that would be hitted if modifier just PRESSED and RELEASED ALONE without other keys. And here's a hack: I allready modified SpaceBar into ModKey, so I need to assign to <ANY_KEY> to be an actuall [ space]  AND assign via xcape that if I press and release SpaceBar ALONE that <ANY_KEY> will be called. Just what I wanted. The good thing about this is that <ANY_KEY> can even иу physically unpresented in your keyboard! So I don't loose even one key!

Problem with the hack.

I checked hack, and it works well. And it seems that it solved all above problems. Howerer, there's one small negative visual effect. When you normally type character it typed as you press. With hack space is  printed after you completely release SpaceBar. I thought that SOMETIMES I will hit Alt symbol instead of space. But when I start to test it I was disappointed when I type at high speed. I start look with xev what happens. At high speeds you actually press TWO or even THREE keys at the same time. For example for [ ea]  events are: KeyPress_E + KeyPress_A + KeyRelease_E + KeyRelease_A. And these often occurs with SpaceBar - instead of space+symbol I got AltGr+Symbol, because SpaceBar dont't press-released alone. And it did this hack totally useless for such keys as SpaceBar, and Shifts. But you can apply it for example for Control or Alt...

Another hack.


I thought that I'll choose shifted version of AltGr. I start to do more tests with it. Accidently I remember about one xkb feature - Latches. What it does: when you press Shift normally - you need to HOLD it and hit other keys. Yes, this is convenient if you need to type something in a SEQUENCE in uppercase, but when you need to type One character, I think that it is more conveniently to just press-release Shift and then other char. And printing shifted just one character is far more frequent event. Good thing about latches is that when when you hold the key you type as with normal SHIFT, so I got 2 benefits at the same time.

Final layout.

I think that idea about latches can improve any layout. Developing it further I have concluded that curvature of right thumb in shifted layout became acceptable for me, because [ "]  and [ &]  now can be typed with hit of AltGr, release it and hit other key. I decided to shift last layout, as it had highest scores, and assign both Shifts to SpaceBar, and space as AltGr state of SpaceBar or as Shift state of AltGr. I didn't test it yet and can't be sure that it good at practice, but it is seems to be so if the speed don't decrease because of two keypresses for space. I want to try this method in QWERTY first.

Actual layouts.

http://patorjk.com/keyboard-layout-analyzer/#/load/891VT257

SchizoKBD-AltGrSpc - is not shifted layout
SchizoKBD-shifted-AltGrSpc - is shifted.
schizoKBD-shifted - is one of the first layouts, with SpaceBar as space.

Test results:
All comparisons ware with these layouts: a74.29 kle70.07 WIP, BEAKL 4 Mod Ian 73.08 74.70 74.19, BEAKL Opted36).
(https://s13.postimg.org/fj5c84gav/layout_results.png)
Green - is my final layouts

"Overall" is the test for all texts connected together (not the average of scores of other tests).
"Average" is math average.

Texts of tests you can find in attachment.

For programming languages all code taken from git repository from various top projects that I found. I tried to find sources with about 1000 lines length. But perl is bigger, because I instantly found it.
TLDP - is the book of coding in shell in Linux from http://tldp.org/LDP/abs/html/ (for testing technical literature).
bash - is just a small lines of bash script from TLDP, because in tldp test I didn't get highest scores at the beginning and tldp test is a long test.
Some tests I found on this forum (signs, medical, trump).
tesla - is the article from wiki about Nikola Tesla.

For the purpose of tests, I did one modification in the KLA's layouts: space in tests is on alt-shift state of [ A] , I don't know why, but when I assign space to SpaceBar and/or AltGr on alt/shift state scores goes down, while I expected that it goes up.
In AltGr-shifted layout Control will be on where [ X]  on layout, hack with xcape (think, that for rarely used letter and Control it is acceptable).

Thanks if you read it =)
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2016-Oct-05 09:43
@schizoID

Hi, thanks for long and detailed post. Congratulations on high scores.

I also had the idea of putting shift (or AltGr) on spacebar, and then making space to be AltGr+spacebar but haven't had time to test it yet. Basically it was a follow-on to the idea of putting Backspace on AltrGr+space.

If you do that then the thumbs don't need to move at all.

In truth, we copied the AltGr approach from Arensito, because his layout got such good scores on the technical tests (but not so good on English).
But even he admitted that doing it on a conventional ANSI layout will not be comfortable. You need custom hardware. So the idea is to find something that works well on ANSI and remap it to Kinesis or ErgoDox, where the thumb keys are more convenient.
Arensito's page: http://www.pvv.org/~hakonhal/main.cgi/keyboard
See diagram at bottom, he puts AltGr on spacebar. Also shift is directly above, so for KLA is one key distant, while for normal AltGr - Space on right hand, it's 1.5 keys distant.


Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2016-Oct-05 09:48
80.
http://patorjk.com/keyboard-layout-analyzer/#/load/9vx9QB98
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2016-Oct-05 09:54
Well I guess that answers the question of whether it was possible to hit 80 on Alice ... highest I've got before was 74.99 ... which was rather frustrating as I was hoping for 75.
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2016-Oct-05 09:57
And it bothers me greatly that E is on index not middle ... scores go down dramatically if you swap A and E ... curious.
Title: Re: Balanced Keyboard Layout
Post by: Den on 2016-Oct-05 09:57
tl;dr
j/k

Seems absurd that pressing 3 keys simultaneously for the most common character that appears 1 in every 6 character, is the most efficient method. I think it should punish more for more keys hit. "Coordination Penalty"

I'm sure there are some keyboards that split the space bar in half. So you don't have to contort your thumb. Although widening the arms apart are a good idea anyway, to slightly ease the bending of the wrists.
Title: Re: Balanced Keyboard Layout
Post by: Den on 2016-Oct-05 10:06
the scores get higher when you put letters and puncs on Shift-AltGr. As I suspected, the program's scoring algorithm seem bugged for modifiers: you get bonus points for each modifier.

Try this. Take the letters and puncs off the Primary Key and put them on Shift, AltGr, or Shift+AltGr. The score will steadily rise.
Title: Re: Balanced Keyboard Layout
Post by: schizoID on 2016-Oct-05 10:17
Hi, thanks for long and detailed post. Congratulations on high scores. However I'm having trouble finding where you put the space key on this layout: schizoKBD-AltGrSpc. Can you please advise?
It is under A in Alt-Shift state.
It was a cheat for KLA highest scores =)

80.
http://patorjk.com/keyboard-layout-analyzer/#/load/9vx9QB98
U <=> O, right? =)

tl;dr
j/k

Seems absurd that pressing 3 keys simultaneously for the most common character that appears 1 in every 6 character, is the most efficient method. I think it should punish more for more keys hit. "Coordination Penalty"
Yes, I wrote about it, and I don't know why KLA decreases scores when space hitted as Alt-Space, instead of Alt-Space-A.

Now I think about to leave SpaceBar as a space, and for Shift state it will generate AltGr.
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2016-Oct-05 10:34
It is under A in Alt-Shift state.
Yes I went back to look again and found it.

U <=> O, right? =)

Yes, OE / EO is rare in English.

I will need to study your layout to see how it manages to get an extra 5 points. I bumped AltGr 2 layout to over 75 but that't still a long way from 80.
I checked that all the symbols are there, we've had issues in the past where layouts were missing characters and got higher scores.
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2016-Oct-05 10:37
Off topic but I was wondering who the .kz visitor to my site was.
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2016-Oct-05 11:02
Does this have an Enter key somewhere?
schizoKBD-shifted

The first layout drops 5 points if you move the space off the A to somewhere else, like the bottom row. So I guess that's its secret.
Title: Re: Balanced Keyboard Layout
Post by: schizoID on 2016-Oct-05 11:05
Space is the most used character alone.
What do you think about to put it in home row?
I try it with KLA, but scores down.
But if KLA doesn't give us objective numbers, I don't know how to check this idea.

And, what you think about two keys modifiers vs shifted one modifier?
For example, what is easiest, if <Shift> under right thumb at home position, and comma under right middle at home position:
1. <Shift> + <SpaceBar> = <AltGr>. In this case you don't need to move your hands from home position: <Shift> + <SpaceBar> + <right middle>
2. <AltGr> mapped to <LeftShift> and <RightShift> keys. In this case you need to move left pinky to get <AltGr>, but only two key presses: <AltGr> + <right middle>.
Title: Re: Balanced Keyboard Layout
Post by: schizoID on 2016-Oct-05 11:14
Does this have an Enter key somewhere?
schizoKBD-shifted
Yes, Enter is the AltGr+SpaceBar on schizoKBD-shifted.

The first layout drops 5 points if you move the space off the A to somewhere else, like the bottom row. So I guess that's its secret.
As Den wrote, there's a bug with modifiers in KLA algorithm. Now, I don't think, that resutls are credible at all =) We need to fix it or new analyzer.
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2016-Oct-05 12:18
Yes, Enter is the AltGr+SpaceBar on schizoKBD-shifted.

Sorry I must have fiddled with the layout and then thought it was missing.

Will ponder these ideas, and see if I can see anything wrong in KLA programs.
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2016-Oct-05 13:57
the scores get higher when you put letters and puncs on Shift-AltGr. As I suspected, the program's scoring algorithm seem bugged for modifiers: you get bonus points for each modifier.

Try this. Take the letters and puncs off the Primary Key and put them on Shift, AltGr, or Shift+AltGr. The score will steadily rise.

I did a simple test... moved the e in QWERTY.

Score went down.
http://patorjk.com/keyboard-layout-analyzer/#/load/Cwzd98hG
Title: Re: Balanced Keyboard Layout
Post by: schizoID on 2016-Oct-05 14:13
I did a simple test... moved the e in QWERTY.

Score went down.
http://patorjk.com/keyboard-layout-analyzer/#/load/Cwzd98hG
It is because your AltGr not in home position for right thumb.
See this: http://patorjk.com/keyboard-layout-analyzer/#/load/dfpj3jkR
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2016-Oct-05 14:29
It is because your AltGr not in home position for right thumb.
See this: http://patorjk.com/keyboard-layout-analyzer/#/load/dfpj3jkR

Yes just realised, but you beat me to it :-)
I agree with Den, this is bizarre, it should not jump 6 points in score like that.
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2016-Oct-05 15:15
Mmm.

Playing with QWERTY and AltGr.
Some changes increase the score.
Others decrease it.

Eg. the 'r' here:
http://patorjk.com/keyboard-layout-analyzer/#/load/QlrMw3Ps

Curious. Tried to pick up a pattern but don't see one...
Title: Re: Balanced Keyboard Layout
Post by: Den on 2016-Oct-05 15:28
As Den wrote, there's a bug with modifiers in KLA algorithm. Now, I don't think, that resutls are credible at all =) We need to fix it or new analyzer.

The first fundamental flaw that is easily observable is that home keys add zero to the distance score. An easy test is input only home letters as the corpus. That means no matter how much you type those letters, you will not expend effort. That is like saying you don't spend energy and would never get tired by walking in place. Of course that can't be true.

This will heavily throw off the distance scores. In theory, no matter how big the corpus, you can get a perfect 0 on distance score. That's why we see such great scores when we put puncs on the home keys, including home thumbs. Their distance scores can get unbelievably low.

So that will be the first flaw to fix.
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2016-Oct-05 15:34
The first fundamental flaw that is easily observable is that home keys add zero to the distance score.
 That means no matter how much you type those letters, you will not expend effort. That is like saying you don't spend energy and would never get tired by walking in place. Of course that can't be true.

Um, if you are measuring DISTANCE then I think 0 is the correct answer. If you are measuring EFFORT then 0 is the wrong answer.
I suppose we will have to dig into Patrick's code to see what's what. In the mean time I've raised the issue on Github..
Title: Re: Balanced Keyboard Layout
Post by: Den on 2016-Oct-05 15:56
Um, if you are measuring DISTANCE then I think 0 is the correct answer. If you are measuring EFFORT then 0 is the wrong answer.
I suppose we will have to dig into Patrick's code to see what's what. In the mean time I've raised the issue on Github..

Then distance is a poor quantity to be measured this way. You expend effort even if you move no distance on the keyboard. You still get tired, do you not? So if you got tired, then you have expended effort and done work.

The equation for work = force * distance. If distance = 0, then work = 0. But we know work is not 0, because we get tired even if it's just typing home keys. Therefore, distance can never be 0.

This also applies to speed. The equation for speed = distance / time. So if distance can be 0, is our typing speed 0 when we type only letters from home keys? That obviously can't be true.

Actually typing speed is dependent on the inverse of distance. Farther keys will slow us down. The inverse of 0 is infinity or undefined. How can we have typing speed of infinity or undefined?

In conclusion, the quantity we want is the effort due to the distance. Even home keys should exert and cost a minimal, positive amount of effort.
Title: Re: Balanced Keyboard Layout
Post by: schizoID on 2016-Oct-05 16:18
Then distance is a poor quantity to be measured this way. You expend effort even if you move no distance on the keyboard. You still get tired, do you not? So if you got tired, then you have expended effort and done work.

The equation for work = force * distance. If distance = 0, then work = 0. But we know work is not 0, because we get tired even if it's just typing home keys. Therefore, distance can never be 0.

This also applies to speed. The equation for speed = distance / time. So if distance can be 0, is our typing speed 0 when we type only letters from home keys? That obviously can't be true.

Actually typing speed is dependent on the inverse of distance. Farther keys will slow us down. The inverse of 0 is infinity or undefined. How can we have typing speed of infinity or undefined?

In conclusion, the quantity we want is the effort due to the distance. Even home keys should exert and cost a minimal amount of effort.

I think, that distance should not be just the length of the motion to move finger to the key, but the length of the motion to key PLUS the height*2 of the pressed key, which will more accurately represent real things that happen when typing. In this case distance never will be equal to 0.
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2016-Oct-05 16:25
I think, that distance should not be just the length of the motion to move finger to the key, but the length of the motion to key PLUS the height*2 of the pressed key, which will more accurately represent real things that happen when typing. In this case distance never will be equal to 0.

Yup, agree 100% .... but I don't think analyzers are doing it that way. I guess because regardless of layout, you still have to press the key, so that part will be the same across all layouts .... EXCEPT for what we are doing now, where we have put normal chars onto AltGr, adding an extra keypress.

I suppose if we take this to the logical conclusion, and do the sums properly, it might turn out that Arensito style is not so good...

Still bombed from flu and in no state to stare at other people's Javascript.... maybe tomorrow or Friday.
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2016-Oct-05 17:04
Mmm looks like QWPR designer was one step ahead of me (and us): (from Wikipedia) https://en.wikipedia.org/wiki/Keyboard_layout#Other_English_layouts

The Qwpr layout is also designed for programmers and multilingual users, as it uses Caps Lock as a "punctuation shift", offering quicker access to ASCII symbols and arrow keys, as well as to 15 dead keys for typing hundreds of different glyphs such as accented characters, mathematical symbols, or emoji.

There's your NumPunc key.... :-)

Was browsing Patrick's code to see how things work, still have not found his key grid defining distances between keys, but saw references to KB.keyMap.standard.s683_225 so I was trying to find what 683_225 is .... it's a bit too wide to the dimensions of a standard ANSI slab, though the 225 is about right for the other dimension (in millimetres). And Google doesn't know either.
Title: Re: Balanced Keyboard Layout
Post by: schizoID on 2016-Oct-05 17:28
EXCEPT for what we are doing now, where we have put normal chars onto AltGr, adding an extra keypress.

No, this is a fundamental issue, for shift too, not only for AltGr:
http://patorjk.com/keyboard-layout-analyzer/#/load/r7SBjsfp
the text is just 'f', and I change F<->f

So any analysis in KLA is not accurate enough just becuase it thinks that printing upper letters is more easy than regular =).
I think that it was created just for fun, not serious analysis, and as author wrote in readme, it wrote it while learning Angular...

I think I will try andw optimizer, because it seems that I can create physicall layouts and use dead keys for analysis as auther is from German.
And also it takes into account many other parameters that you can define by itself such as effort for the roll digram, etc...
Title: Re: Balanced Keyboard Layout
Post by: schizoID on 2016-Oct-05 17:46
Mmm looks like QWPR designer was one step ahead of me (and us): (from Wikipedia) https://en.wikipedia.org/wiki/Keyboard_layout#Other_English_layouts

The Qwpr layout is also designed for programmers and multilingual users, as it uses Caps Lock as a "punctuation shift", offering quicker access to ASCII symbols and arrow keys, as well as to 15 dead keys for typing hundreds of different glyphs such as accented characters, mathematical symbols, or emoji.

I saw it early, before BEAKL, and according to KLA it is not so great: https://sourceforge.net/p/qwpr/wiki/KeyboardLayoutAnalyzer/
That is how I came to this site ;)
Title: Re: Balanced Keyboard Layout
Post by: schizoID on 2016-Oct-05 17:51
Den, you used adnw to create BEAKL, right?
Can you share your config?
I want to add dead keys for puncs and symbols, and see what I'll get.
Thanks.
Title: Re: Balanced Keyboard Layout
Post by: Den on 2016-Oct-05 18:37

KLE image of my Kinesis layout (BEAKL 34 and left numpad):
(http://www.shenafu.com/code/keyboard/KLE-BEAKL-34-Kinesis.png) (http://www.keyboard-layout-editor.com/##@@_c=%23fbbbc9&f:1&f2:2&w:0.675&h:0.85%3B&=%0APaste&_x:0.07499999999999996&c=%23cccccc&w:0.675&h:0.85%3B&=%0AF1&_x:0.07499999999999996&w:0.675&h:0.85%3B&=%0AF2&_x:0.07500000000000018&w:0.675&h:0.85%3B&=%0AF3&_x:0.07500000000000018&w:0.675&h:0.85%3B&=%0AF4&_x:0.07500000000000018&w:0.675&h:0.85%3B&=%0AF5&_x:0.07500000000000018&w:0.675&h:0.85%3B&=%0AF6&_x:0.07500000000000018&w:0.675&h:0.85%3B&=%0AF7&_x:0.07500000000000018&w:0.675&h:0.85%3B&=%0AF8&_x:4.825&w:0.675&h:0.85%3B&=Repeat%20Rate%0AF9&_x:0.07499999999999929&w:0.675&h:0.85%3B&=Disable%20Macro%0AF10&_x:0.07499999999999929&w:0.675&h:0.85%3B&=Macro%0AF11&_x:0.07499999999999929&w:0.675&h:0.85%3B&=Remap%0AF12&_x:0.07499999999999929&w:0.675&h:0.85%3B&=PrintScr%20SysReq&_x:0.07499999999999929&c=%23ac97d8&w:0.675&h:0.85%3B&=Scroll%3Cbr%3Elock&_x:0.07499999999999929&c=%23cccccc&w:0.675&h:0.85%3B&=Pause%20Break&_x:0.07499999999999929&c=%23ac97d8&w:0.675&h:0.85%3B&=Keypad&_x:0.07499999999999929&c=%23cccccc&w:0.675&h:0.85%3B&=Progrm%3B&@_x:2.25&f:3%3B&=0%0A%2F&&=1%0A%23&=2%0A$&=3%0A%60&_x:5.5%3B&=8%0A%7C&=7%0A%2F@&=6%0A*&=5%0A%25%3B&@_y:-0.75&c=%23fbbbc9&a:6&w:1.25%3B&=Esc&_c=%23cccccc&a:4%3B&=4%0A~&_x:13.5%3B&=9%0A%5E&_c=%23fbbbc9&a:7&w:1.25%3B&=Delete%3B&@_y:-0.25&x:2.25&c=%23cccccc&a:4&f:6&fa@:0&:0&:0&:3%3B%3B&=Y%0A%0A%0A2&=O%0A%0A%0A9&=U%0A%0A%0A7&_f:3%3B&=%27%0A!%0A%0A6&_x:5.5&f:6%3B&=W&=D&=L&=N%3B&@_y:-0.75&f:3&w:1.25%3B&=-%0A%3F&_f:6%3B&=X&_x:13.5%3B&=V&_w:1.25%3B&=Z%3B&@_y:-0.25&x:2.25&c=%235eb1e7&fa@:0&:0&:0&:3%3B%3B&=I%0A%0A%0A1&=E%0A%0A%0A0&=A%0A%0A%0A3&_c=%23cccccc&f:3&fa@:6&:0&:0&:6%3B%3B&=.%0A%2F_%0A%0A.&_x:5.5&f:6%3B&=G&_c=%235eb1e7%3B&=S&=T&=R%3B&@_y:-0.75&c=%23ac97d8&a:6&f:3&w:1.25%3B&=Num%3Cbr%3ELock&_c=%235eb1e7&a:4&f:6&fa@:0&:0&:0&:3%3B%3B&=H%0A%0A%0A5&_x:13.5%3B&=P&_c=%238ed7b0&a:7&f:3&w:1.25%3B&=Ctrl%3B&@_y:-0.25&x:2.25&c=%23cccccc&a:4%3B&=%22%0A%5C%0A%0A4&=)%0A%3E%0A%0A8&=,%0A%2F%2F%0A%0A%2F%2F&=%2F:%0A%2F%3B&_x:5.5&f:6%3B&=F&=C&=M&=B%3B&@_y:-0.75&w:1.25%3B&=J&_f:3%3B&=(%0A%3C%0A%0A-&_x:13.5&f:6%3B&=K&_w:1.25%3B&=Q%3B&@_y:-0.25&x:2.25&c=%23f8d615&a:7%3B&=%E2%87%A9&=%E2%87%A7&=%E2%87%A8&_x:7.5&c=%23cccccc&a:4&f:3%3B&=%5B%0A%7B&=%2F=%0A+&=%5D%0A%7D%0A%0A%0A.%3B&@_y:-0.75&x:1.25&c=%23f8d615&a:7&f:6%3B&=%E2%87%A6&_x:13.5&c=%23cccccc&a:4%3B&=+%3B&@_r:15&rx:5.25&ry:4&x:1.5&c=%238ed7b0&a:7&f:3%3B&=Shift&=Ctrl%3B&@_x:0.5&c=%235eb1e7&h:2%3B&=Space&_c=%23fbbbc9&h:2%3B&=Back%3Cbr%3ESpace&_c=%23f8d615%3B&=Home%3B&@_x:2.5%3B&=End%3B&@_r:-15&rx:12.75&x:-3.5&c=%238ed7b0&a:4%3B&=Cmd%0A%0A%0A%0A%0A%0AWin&_a:7%3B&=Alt%3B&@_x:-3.5&c=%23f8d615&a:6%3B&=Page%3Cbr%3EUp&_c=%23fbbbc9&a:7&h:2%3B&=Tab&_c=%235eb1e7&h:2%3B&=Enter%3B&@_x:-3.5&c=%23f8d615&a:6%3B&=Page%3Cbr%3EDown)

Slightly modified a few corner keys.
Title: Re: Balanced Keyboard Layout
Post by: Den on 2016-Oct-05 23:25
Den, you used adnw to create BEAKL, right?
Can you share your config?
I want to add dead keys for puncs and symbols, and see what I'll get.
Thanks.

This is the latest cfg for BEAKL 34

http://shenafu.com/code/keyboard/std-beakl34.cfg

AdNW Opt doesn't do dead keys, so you'd have to find clever ways to simulate that.

Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2016-Oct-06 01:24
No, this is a fundamental issue, for shift too, not only for AltGr:
http://patorjk.com/keyboard-layout-analyzer/#/load/r7SBjsfp
the text is just 'f', and I change F<->f

I have also noticed strange changes in the score when flipping things between normal and shifted, but I was playing with the punctuation, not the letters.

Patrick does count the number of keypresses (which is a proxy for vertical "distance") but I don't think he includes it in his sums:

     // put it all together!
        var consecHandWeight = 17, consecFingerWeight = 17, fingerUsageWeight = 33, distWeight = 33;
        results.finalList = [];
        for (ii = 0; ii < len; ii++) {
            results.finalList[ii] = {};
            results.finalList[ii].layoutName = analysis[ii].layoutName;
            results.finalList[ii].score =
                (results.consecHandScores[ii] * consecHandWeight) +
                (results.consecFingerScores[ii] * consecFingerWeight) +
                (results.fingerScores[ii] * fingerUsageWeight) +
                (results.distScores[ii] * distWeight);
            if ( !isFinite( results.finalList[ii].score ) ) { results.finalList[ii].score=0;}
        }

So there's no "keypress" in there, unless that's a factor of finger usage. So if you use more fingers the score goes up?
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2016-Oct-06 03:48
        var consecHandWeight = 17, consecFingerWeight = 17, fingerUsageWeight = 33, distWeight = 33;

                (results.fingerScores[ii] * fingerUsageWeight) +

Let me think out loud, I think I have a "start" of a solution but not the entire thing.
I think the problem lies with the line above, which looks like it multiplies each finger used by it's weighting, which was defined elsewhere.
So higher finger use == higher score. Which is not correct.

Instead we need to punish excess finger use. So let us assume that every character in the test can be typed by pressing one key (yes I know you need shift for some. But layouts are compared against each other, and so all will need shift and will be punished the same way). This will be the "ideal" number of keypresses.

So my idea is to do something like "actual - ideal" keypresses, which should be positive, times some factor, and subtract that from the line above.

I want to say something like "you got \ by pressing 3 keys but you should only need 2 (or 1) so I need to punish you, because that AltGr and Shift you pressed with your xxxx finger and yyyy finger are unnecessary so that is 1 times the weight on xxxx finger + 1 times the weight on yyyy finger deducted from your score".... but we can not arbitrarily decide how many presses non-letter keys need. So doing it that way won't work, hence we use a "factor" as a proxy way of achieving something similar if not as accurate. And because the score will be compared to other layouts which were treated the same way, it should be okay.

Am I making sense here or have the flu meds scrambled my brain :-)

Cheers, Ian
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2016-Oct-06 04:03
It might be easier to just punish every modifier use, because we know when it is pressed, which finger pressed it. Which means we can keep a running total.
Title: Re: Balanced Keyboard Layout
Post by: schizoID on 2016-Oct-06 13:10
This is the latest cfg for BEAKL 34

http://shenafu.com/code/keyboard/std-beakl34.cfg

AdNW Opt doesn't do dead keys, so you'd have to find clever ways to simulate that.
Thank you.

It might be easier to just punish every modifier use, because we know when it is pressed, which finger pressed it. Which means we can keep a running total.

I checked my idea with distances.
I supposed that results are based as Den said on ratio between distance of fingers and their distance.
So I found in the KLA's source where distance counts and added for each key additional distance for finger
when it press and release the key. Extra distance ~= width of the key (I didn't measure exactly).

Tried on this text "f f f." Dot needed to release right thumb at the end and count distance.

Also, in KLA consecHandPress counts without thumbs. Added this too. Got such results (clickable)

Distance:
(https://s17.postimg.org/7rescdn0r/distance.png) (https://postimg.org/image/7rescdn0r/)

Score:
(https://s17.postimg.org/dtmf2vbgr/scores.png) (https://postimg.org/image/dtmf2vbgr/)
Title: Re: Balanced Keyboard Layout
Post by: schizoID on 2016-Oct-06 13:20
Checked our layouts on Alice and C-source with my modifications.

Alice:
Distance:
(https://s16.postimg.org/5o3rmyx5d/alice_distance.png) (https://postimg.org/image/5o3rmyx5d/)
Score:
(https://s16.postimg.org/4978vd2dt/alice_scores.png) (https://postimg.org/image/4978vd2dt/)
C-source:
Distance:
(https://s16.postimg.org/hre57nej5/c_distance.png) (https://postimg.org/image/hre57nej5/)
Score:
(https://s16.postimg.org/oj4kai3ip/c_score.png) (https://postimg.org/image/oj4kai3ip/)
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2016-Oct-06 13:23
You got KLA running locally?

I tried but the results screen is a mess, all on one long screen, no "tabs" function.
I see my repo is two commits behind Patrick's so I must figure out how to resync with his. Am a bit clueless with git/github.

Looks like your change made a huge difference to the score. It's so huge I'm worried that if you try a whole document, the scores will go way down.

Can you perhaps test Alice with MTGap, QWERTY and Arensito? I've attached a fixed version of Arensito, the one Patrick has is missing two characters.
Should be .json not .txt, but forum does not allow .json attachments.

Thanks.

Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2016-Oct-06 13:32
Sorry our messages overlapped.

Re Alice, so my score dropped from 73 to 51. I was not expecting that. Nor was I expecting the AltGr layouts to still be on top for the C code.

So I think your modification is doing *something* but I'm not sure it's doing the correct thing to fix the scoring.

Instead of using "half a keycap width" ie around 9mm, you should rather use say 4 mm?

Busy working but will let this run in the back of my head.... :-)
Title: Re: Balanced Keyboard Layout
Post by: schizoID on 2016-Oct-06 13:56
You got KLA running locally?

I just saved locally webpage. And firefox saved it for me with all javascripts. There're minor issues such as you can't change layout properly (don't know why), but for importing works fine.

Looks like your change made a huge difference to the score. It's so huge I'm worried that if you try a whole document, the scores will go way down.
Changes supposed to be huge, because the height of keys don't count at all. But results will go down for EACH layout and overall distribution of places among them will not change dramatically. May be I need to change the height to another value, because I think that pressing and releasing a key is more easy than moving finger to another key, and now it is treats as same effort action. Also I just wanted to check my idea, and better solution is to add another metric for key press/release for each finger. In fact we allready. have such metric for fingers in the Den's table, but in KLA the distance is more important than finger usage, as I may conclude. May be if we change scoring for 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;
we can get more credible results in KLA.

Can you perhaps test Alice with MTGap, QWERTY and Arensito? I've attached a fixed version of Arensito, the one Patrick has is missing two characters.
Should be .json not .txt, but forum does not allow .json attachments.

Thanks.
I think that it is better that you try to save whole web page as I wrote. In attach analyzer.js with my changes.
Title: Re: Balanced Keyboard Layout
Post by: schizoID on 2016-Oct-06 14:27
Another idea.
We need different kinds of distance: DistanceReal and DistanceScoring.
DistanceReal is the real distance of our fingers that they do.
DistanceScoring is the metric that reflects the effort to move SPECIFIC finger.
I think that moving index or middle is easy than pinky. Now we have just keyboard effort grid, that reflects this.
But the DISTANCE is treated equally for each finger.
I think that it is better to remove from scoring but leave them for info such metrics as finger usage and real distance, and add new DistanceScoring, that combines them.

For example, let assume that BaseMetricPressRelease = 0.5cm. And use these table from KLA:
        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;
RealDistance = DistanceToMoveToKey + DistanceToPress + DistanceToRelease.
ScoringDistance = RealDistance/FingerScore.
To hit Q on Qwerty we get: (1.5+0.5+0.5)/0.5=5
To hit E on Qwerty we get: (1.5 + 0.5 + 0.5)/4 = 0.625
To hit D on Qwerty we get: (0 + 0.5 + 0.5)/4 = 0.25
To hit A on Qwerty we get: (0 + 0.5 + 0.5)/0.5 = 2

I think that these figures are close to what Den said about BEAKL: "Bottom row ring and index fingers are extremely fast. Sometimes 2x or more faster than the home pinky."

Of course I need to play with figures, but this is just concept.
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2016-Oct-06 14:57
Up/down will vary by keyswitch but I propose we take Cherry MX brown as a viable benchmark to use.

Actuator travel: 4.0 -0.4 mm
http://cherry.de/cid/keymodules_MX1A-Gxxx.htm?

American site says .16 inch == 4.064 mm
http://cherryamericas.com/product/mx-series/
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2016-Oct-06 16:56
Where you add 50, is that equivalent of 5 mm?
Title: Re: Balanced Keyboard Layout
Post by: schizoID on 2016-Oct-06 17:45
Where you add 50, is that equivalent of 5 mm?
See lines with analysis.distance in typeKey function
as this
analysis.distance[analysis.tmp.prevFingerUsed] += 50;
Where you see 50 can remove or change it.

In kb.js there's a comment:
// 50 pixels = 1.9cm
So I added too much =)
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2016-Oct-06 18:12
I'll change it to 10, that's about 4mm on that scale.
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2016-Oct-06 18:53
Well that seems to deal with Arensito's advantage....

Test: 500 US dates.

First attachment is Patrick's site.
Second is local, after using schizoID analyzer, with 50 changed to 10 and 100 changed to 20.
Title: Re: Balanced Keyboard Layout
Post by: ADMIN on 2016-Oct-06 19:41
Can you perhaps test Alice with MTGap, QWERTY and Arensito? I've attached a fixed version of Arensito, the one Patrick has is missing two characters.
Should be .json not .txt, but forum does not allow .json attachments.

I added ability to attach .json files. See attachment.
Title: Re: Balanced Keyboard Layout
Post by: schizoID on 2016-Oct-06 20:54
It seems that I finally, after a week of headashes, found the solution, that will satisfy me =)
The problem was, that if I want to print fast "one two" with xcape I get "oneTwo" very OFTEN.
This is why I came into finding esoteric layouts where you need to press 2 or 3 mod keys in sequence to get just space, or comma. But due to it we have found bug in the algorithm of KLA ;)

There's another Linux solution: patched xf86-xorg-evdev input driver: https://gitlab.com/at-home-modifier/at-home-modifier-evdev/wikis/home
It is not ideal: sometimes such errors happens, but it is not more bottleneck for my typing speed, because now they occur very SELDOM.
Just measured my speed in Russian, and it is the same as before, and my own mistakes are much more frequent than driver's (7 to 1, I think).
With this utility I can remap Controls to home positions of the pinkies, and AltGr under Index, Shifts under space, all modifiers at home positions, this is why it's name: At Home Modifier by Evdev =)

May be for you it would be helpful too such as for me. =)
Title: Re: Balanced Keyboard Layout
Post by: Den on 2016-Oct-06 21:01
It might be easier to just punish every modifier use, because we know when it is pressed, which finger pressed it. Which means we can keep a running total.

you should only punish modifiers on the entry and exit, not for every character that relies on them. this is to account for consecutive characters that use the same modifiers.

if i type "Beakl", i used shift once. "BEAKL" also only once because i will hold down the shift until all the uppercase letters are finished. that is, i wouldn't press and release shift for each uppercase letter. (it may be prudent to explicitly add space to the shift layer for this purpose.)

in general, only switches between layers would cost additional effort. the layers being main, shift, altgr and shift+altgr. so if all my puncs are on the same layer, and all I have to do is hold down AltGr to type a sequence of them, then i shouldn't be penalized for each key. the penalty is accounted for only at the start and end of the sequence.
Title: Re: Balanced Keyboard Layout
Post by: Den on 2016-Oct-07 00:34
function distanceBetweenKeys() assumes that horizontal and vertical matter equally. But shouldn't we penalize horizontal movement? this will give higher (worse) distance scores for inner-index and outer-pinky columns.

Arensito and AltGr layer still has some merit. But it won't be the runaway strategy as we've assumed before.
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2016-Oct-07 01:58
function distanceBetweenKeys() assumes that horizontal and vertical matter equally. But shouldn't we penalize horizontal movement? this will give higher (worse) distance scores for inner-index and outer-pinky columns.

When I read this the first time I thought by "vertical" you meant the keypress action. On later reading I got your other meaning.

Maybe we should talk about x, y and z directions rather than horizontal and vertical, to avoid confusion?

Cheers, Ian
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2016-Oct-07 03:40
FWIW.

Comparison, using Alice, QWERTY, and Patrick vs schizoID mod Ian algo. (where I changed 50 to 10, and 100 to 20)

Normal:
KLA: 53.06,  schizoID : 46.79

move "e" to AltGr slot. Right thumb home to AltGr
KLA: 59.30,  schizoID: 51.92

So both go up? Shouldn't schizoID have come down?

Or am I doing something wrong?
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2016-Oct-07 03:55
you should only punish modifiers on the entry and exit, not for every character that relies on them. this is to account for consecutive characters that use the same modifiers.

Agreed, if I read Patrick's code correctly that's how he does it... has code for modifier down and modifier up.
Title: Re: Balanced Keyboard Layout
Post by: Den on 2016-Oct-07 07:13
It's hard to debug the scores when they don't show up on the tables screen. So I added some fields for each score category that displays the penalties respectively.

It makes sense to normalize the scores. If the ideal score is 100, and the weights of each category is 17, 17, 33, 33--which add up to 100--then the score for the layouts should approach those values in the respective category. Then we can refine the scoring equations to fit within the boundaries (between 0 and the weight).
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2016-Oct-07 07:40
It makes sense to normalize the scores. If the ideal score is 100,

I actually asked Patrick about that ... ( no answer yet).... if ideal score is 100 and the best we've got to on Alice is around 75, does that mean we're only 75% optimised?.....
Title: Re: Balanced Keyboard Layout
Post by: Den on 2016-Oct-07 07:53
I actually asked Patrick about that ... ( no answer yet).... if ideal score is 100 and the best we've got to on Alice is around 75, does that mean we're only 75% optimised?.....

score of 100 means all text appears instantly.
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2016-Oct-07 08:59
? :-)

I think I know what you mean but not sure I agree... there's no time in the calculations, only hands and distance. Maybe "text appears without moving any fingers"? :-)
Title: Re: Balanced Keyboard Layout
Post by: Den on 2016-Oct-07 09:35
actually lower scores should mean better layout since scores are based on penalties. so the winner is the layout with the least penalties. this will also make it easier to calculate a fair scoring system from the stats directly.

KLA final score is based on inverse percentages using cryptic coefficients and min-max boundaries. some parts of the scores can go into negative values.
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2016-Oct-07 11:38
actually lower scores should mean better layout since scores are based on penalties. so the winner is the layout with the least penalties. this will also make it easier to calculate a fair scoring system from the stats directly.

I was actually just resting and pondering that ... what was bothering me was that we want to measure "least effort" or "most effective", but we're doing it by counting finger use and distance, which seems wrong unless, as you say, it gets inverted.

Further, any non-ortholinear layout is going to force the fingers to move x and y, so should be punished.

Also I don't think weighting the thumbs the same as pinkies is correct... they should be at least as strong as middle and flexible as index?

Okay let me write my whole story, just hope it doesn't get a TL;DR... :-)

I have several issues with existing layout analysers:

1. most assume ANSI 104, some allow Ergodox/Kinesis as well. But nothing else (or not easily).
2. from my point of view, ANSI 104 sucks, which is why I use MS Natural (original), which is better but far from ideal.
3. the ideal layout starts at the physical level, before we get to the logical level, but we have no way to test different layout ideas to see if Ergodox is better than Kinesis is better than keyboard.io etc.
4. there are different evaluators, each using different algos, giving different results. That may be a good or bad thing, but when a layout scores "best" on Colemak fanbois site, and does not do so well on KLA, then how do we know if it is good or not?
That's part of the reason I built keyboard-design.com. to compare these things, but it looks like some of these analyzers are rather limited (eg only 30 or 32 keys, no relabelling, etc). So it's difficult to cross-reference results.

So ... part of what I intend(ed) with keyboard-design.com was something like this:

1. write a program to convert KLE and KLA .json to a new format that encaptures all that they do, plus what MS, Apple and Linux (not bothering with Sun) put in their keyboard def files. This will include which finger by default should press each key. Also exact xy co-ordinates of each key. I've kinda decided on using YAML for this instead of json or xml. Ideally there will be programs to convert this layout back to the other formats too.

2. Then write a new analyzer taking the good ideas from existing ones, and adding whatever I feel is missing in the analysis. This should be flexible enough to handle things like a layout having a button under the heel of your hand. This would probably be a back-end program running on a server rather than the browser. Probably better if a compiled language. Part of what I don't like evaluating with KLA is that it is slow/can't handle large inputs without browser offering to stop the script. I don't know if it is the "personalised" code that is taking long, would be nice to be able to switch that off. When I was testing layouts I didn't need to see 4 other layout as well, but no way to switch them off.

But when I'm comparing layouts, I have to do it in batches of 5, and type the answers into a spreadsheet. With a backend program I could give it a list of inputs, a list of layouts, and a .csv file to write the results to.... with no risk of typos.
At the moment there are over 130 layouts in my database so checking how they do on a new test takes ages... as does seeing how a new layout does on 40 (currently) different tests.

Which brings us to the million dollar question, how to evaluate a layout....

Possibilities:
1. distance (x, y, z)
2. hand alternation
3. rolls, in and out. Is out necessarily bad?
4. Home row? Same row? Next row? Jump row?
5. consecutive finger use
6. do strong fingers/thumbs do most work? (*)
7. are modifier-combos actually doable/comfortable without hand contortions?

(*) this probably ties up with how to "weight" each finger use. If we want to allow non-standard layouts, then the traditional "effort grid" approach won't work because we can't create a grid for every possible layout.

So instead we take an algorithmic approach along the lines of
"finger F at home scores 1. For each mm x it has to move, add 0.2. For each mm y it has to move, add 0.1" or something along those lines. Possibly you can have different scores for +y and -y, because middle likes to go up but index may prefer to go down.  This is probably the most difficult and contentious part of the exercise. But it gives us total flexibility to handle any layout created in KLE.

So that's where I am now ...

In unrelated news, Patrick came back to me on a question about his scoring, turns out the code is correct and the comment was wrong. Hopefully he will also take a look at the other issues I raised.


Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2016-Oct-07 16:58
Don't know if I like the Enter in that spot.

Would take some getting used to I think.

http://patorjk.com/keyboard-layout-analyzer/#/load/hVxsjkjk
Title: Re: Balanced Keyboard Layout
Post by: Den on 2016-Oct-07 19:52
Also I don't think weighting the thumbs the same as pinkies is correct... they should be at least as strong as middle and flexible as index?

Actually distance and finger usage measure different attributes of fingers, so their multiplier values should be separate. Distance measures reaching and bending. Finger usage measures strength, stamina, agility, and reflex.

Quote
Possibilities:
1. distance (x, y, z)
2. hand alternation
3. rolls, in and out. Is out necessarily bad?
4. Home row? Same row? Next row? Jump row?
5. consecutive finger use
6. do strong fingers/thumbs do most work? (*)
7. are modifier-combos actually doable/comfortable without hand contortions?

(*) this probably ties up with how to "weight" each finger use. If we want to allow non-standard layouts, then the traditional "effort grid" approach won't work because we can't create a grid for every possible layout.

So instead we take an algorithmic approach along the lines of
"finger F at home scores 1. For each mm x it has to move, add 0.2. For each mm y it has to move, add 0.1" or something along those lines. Possibly you can have different scores for +y and -y, because middle likes to go up but index may prefer to go down.  This is probably the most difficult and contentious part of the exercise. But it gives us total flexibility to handle any layout created in KLE.

If we want to calculate a composite score, then we should define a common base unit of measurement for effort. Let's call this "ef". Hitting a key costs Z efs. Reaching a distant key costs X efs. Same finger presses costs additional Y efs. Holding a modifier key costs some M efs. and so on.

A (physical or logical) layout with lower efs is the better, more effortless one.

Title: Re: Balanced Keyboard Layout
Post by: Den on 2016-Oct-07 22:55
I rewrote and simplified KLA scoring so that the target score is 100. Most layouts will go above 100, but in rare cases (depending on corpus) some layouts may go below 100. Lower scores are better.

Title: Re: Balanced Keyboard Layout
Post by: Den on 2016-Oct-08 00:41
With the new scoring system, Arensito still scores significantly better than the rest. The positive penalty value based on X-Y axes of distant keys still makes a great difference.

Ergo (+AltGr) keyboards can still beat Arensito on standard keyboard. But I don't have json for Arensito on Ergo to compare apples to apples.
Title: Re: Balanced Keyboard Layout
Post by: Den on 2016-Oct-08 01:55
I modified the interface to accept a variable amount of layouts to compare.

Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2016-Oct-08 03:10
Actually distance and finger usage measure different attributes of fingers, so their multiplier values should be separate. Distance measures reaching and bending. Finger usage measures strength, stamina, agility, and reflex.

Okay

If we want to calculate a composite score, then we should define a common base unit of measurement for effort. Let's call this "ef". Hitting a key costs Z efs. Reaching a distant key costs X efs. Same finger presses costs additional Y efs. Holding a modifier key costs some M efs. and so on.
A (physical or logical) layout with lower efs is the better, more effortless one.

Can I just rewrite some of your words a bit to ensure we're on the same wavelength?

Hitting a HOME key costs Z efs.
Reaching a distant key costs X efs.  ... where X is a factor of (x,y) distance and finger used. Question: Do we measure from CurrentPostition to NextPosition directly, or is there an implicit ReturnToHome in the middle?
Similarly, do we automatically return a finger to Home on release, or do we leave it where it is in case it is needed in the same spot again? Eg having Rshift + AltGr on right thumb, do we fly around or stand still until have to move?

BTW I am thrilled you have started working on the code... :-)
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2016-Oct-08 03:13
With the new scoring system, Arensito still scores significantly better than the rest. The positive penalty value based on X-Y axes of distant keys still makes a great difference.

I am happy with that, where it is logically fair. But I don't think hitting three keys to get a space is logically fair, so such a layout should not get highest score. (no offence to such layouts, I also tried to game KLA).
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2016-Oct-08 03:16
I modified the interface to accept a variable amount of layouts to compare.

Way cool :-)
Would be nice to disable the "personalised" option too... the only time I have found that useful was in the technical tests, where I would load a bunch of layouts and they all scored WORSE than the Personalised layout ... then I knew they all sucked at technical things... :-)
Actually I sometimes get annoyed with some of the layouts that get bad scores in everything (like those one-handed Dvorak layouts). But according to the Tao, we need the bad to appreciate the good... :-)
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2016-Oct-08 03:27
I modified the interface to accept a variable amount of layouts to compare.

Are you going to push your changes to Patrick?

I'll see if I can knock together (an initial version of) Arensito on Ergo sometime today... have a wedding later.
Title: Re: Balanced Keyboard Layout
Post by: Den on 2016-Oct-08 04:57
I am happy with that, where it is logically fair. But I don't think hitting three keys to get a space is logically fair, so such a layout should not get highest score. (no offence to such layouts, I also tried to game KLA).

actually it's not much different than chording, so this does have merit and may be yet another breakthrough to accept.

i tried some minor but reasonable penalties for holding down a mod key, but that barely made a dent to the score.
Title: Re: Balanced Keyboard Layout
Post by: Den on 2016-Oct-08 05:30
Are you going to push your changes to Patrick?

I'll see if I can knock together (an initial version of) Arensito on Ergo sometime today... have a wedding later.

you can do it for me. see attachment
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2016-Oct-08 13:28
Thanks.

Are these the only ones you changed?
main.css
app.js.download
services.js.download
templates.js.download
analyzer.js.download
kb.js.download

Haven't looked at your changes yet, but if you replaced the scoring calcs then I'm not sure how that will be received... we might have to tweak it to offer both scoring options.
I'm not sure of the protocols in situations like this... I've only really contributed code to KLE and IJP often reworked what I did (front end more than back end). Javascript is not my strong point :-)

I'll see what you did and then see if I can push it in separate commits so that for example increasing the number of layouts can be added apart from a rewritten scoring algo.

Patrick hasn't accepted (yet) the two fixed layouts (Arensito and Balanced 12) that I submitted via Github.

In other news I mailed Hakon (designer of Arensito) to ask if he has/could make a KLA ergo version. Didn't bounce (yet), but no reply yet either.
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2016-Oct-08 14:33
Slightly modified a few corner keys.

Can you perhaps point me to the KLA file? :-)

thanks, Ian
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2016-Oct-08 16:59
you can do it for me. see attachment

Did you download this with Opera? When I downloaded KLA with Firefox it fixed all the links, so that when I click Configure I run the local downloaded version, and don't get redirected back to real KLA site. Also filenames don't get .download added to them.

Damn. On the other hand Firefox seems to have turned things like jqplot.pieRenderer.min.js into jqplot_002.js.
Sigh. :-)

Maybe should use wget or something to spider the site. Or get the git repo to work properly.
Title: Re: Balanced Keyboard Layout
Post by: Den on 2016-Oct-08 17:23
Can you perhaps point me to the KLA file? :-)

thanks, Ian

see attached
Title: Re: Balanced Keyboard Layout
Post by: Den on 2016-Oct-08 20:17
Did you download this with Opera? When I downloaded KLA with Firefox it fixed all the links, so that when I click Configure I run the local downloaded version, and don't get redirected back to real KLA site. Also filenames don't get .download added to them.

Damn. On the other hand Firefox seems to have turned things like jqplot.pieRenderer.min.js into jqplot_002.js.
Sigh. :-)

Maybe should use wget or something to spider the site. Or get the git repo to work properly.

I downloaded with Vivaldi (Blink/Chromium).

I fixed the page to point to local config page. And removed footer.

Streamlined scores to even the categories. Final scores should be between 10 and 20.

Added new column in summary page to show difference in effort relative to best layout.

2 attachments
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2016-Oct-09 04:49
Hakon came back to me and pointed me to a diagram of his layout, I've captured it and think it's correct, will mail him to doublecheck.
http://www.pvv.org/~hakonhal/main.cgi/keyboard


Alice
http://patorjk.com/keyboard-layout-analyzer/#/load/twzzXRrd

Google:
http://patorjk.com/keyboard-layout-analyzer/#/load/vr6bBjQl

Dates USZ
http://patorjk.com/keyboard-layout-analyzer/#/load/mbqLKfms

Thanks for the code updates, will look at it later. Might be necessary to scale your scores from 10-20 to 100 - 200, to better differentiate.
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2016-Oct-09 10:02
see attached

thanks :-)

Need to run tests with this and schizo's layouts and Arensito Ergo ...

Gonna take a while. Not looking forward to redoing everything with your scoring, but necessary... :-)
Title: Re: Balanced Keyboard Layout
Post by: Den on 2016-Oct-09 15:52
thanks :-)

Need to run tests with this and schizo's layouts and Arensito Ergo ...

Gonna take a while. Not looking forward to redoing everything with your scoring, but necessary... :-)

Only if you agree with the new score system and it works as expected. I should fix the summary page to somehow let you see the individual score for each category that make up the final score.
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2016-Oct-09 16:23
Only if you agree with the new score system and it works as expected.

:-) I'll only know that after I compare a stack of results... Though I suppose I could do a few of the usual top performers vs a few of the usual worst performers to get an idea ...

I should fix the summary page to somehow let you see the individual score for each category that make up the final score.

That would be nice.... We really need an "export to csv" function here but JS can't write to files? How about "download results"? I've never done anything like that in JS, but I did knock together some code (borrowing ideas elsewhere) for KLE download jpg/png etc.

Sitting here trying to decide if I should start with abovementioned layouts or not ... it's 22:22.... guess I should.
Title: Re: Balanced Keyboard Layout
Post by: Den on 2016-Oct-09 16:50
:-) I'll only know that after I compare a stack of results... Though I suppose I could do a few of the usual top performers vs a few of the usual worst performers to get an idea ...

That would be nice.... We really need an "export to csv" function here but JS can't write to files? How about "download results"? I've never done anything like that in JS, but I did knock together some code (borrowing ideas elsewhere) for KLE download jpg/png etc.

Could be easier to serialize into JSON and go from there.

uploaded KLA to my site if you want to try my version:
http://shenafu.com/code/keyboard/Keyboard%20Layout%20Analyzer.html#/
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2016-Oct-09 18:25
Schizo, Arensito Kinesis and Beakl34 Kinesis results are up.

I've been smacked down the rankings, unless you included dates and times.

Must add my mod to schizo still... might have some more changes to make. But I really don't like AltGr+shift+key == space....

Then I can start looking at your scoring :-)... thanks for putting it up on the web.

Cheers, Ian
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2016-Oct-09 18:36
Mmm now that as surprising ... was not expecting it at #9, given how well it did while I was evaluating it. Tested on Quadgrams (because that's the last test I had loaded in my other browser).

vs Patrick's scoring.
Title: Re: Balanced Keyboard Layout
Post by: Den on 2016-Oct-09 21:43
my scores take into account the weights of each finger for distance, finger usage, and consecutive finger. original KLA only for finger usage.

The values may be controversial. They are relative, with 1.0 as baseline. Lower value means less effort.

Code: [Select]
Distance Weights

PINKY = 2.0;
RING = 1.3;
MIDDLE = 1.0;
INDEX = 1.1;
ONE THUMB = 1.0;
BOTH THUMBS = 2.0;


Finger Usage and Consecutive Finger Weights

PINKY = 2.0;
RING = 1.2;
MIDDLE = 1.0;
INDEX = 1.1;
ONE THUMB = 1.0;
BOTH THUMBS = 2.0;

For Consecutive Finger, the values are squared

You can see that I penalize two thumbs, but not one thumb. That's why schizo's layout scores higher (worse). But I'm not sure that's enough to pull it down that far.
Title: Re: Balanced Keyboard Layout
Post by: anamnesis on 2016-Oct-09 22:28
Hi,

Fascinating work. It may take me a bit to follow the entire chain of thought for this, but I definitely like what I see so far.  I learned colemak years ago and can use it at a workable 80+wpm average, but I've come to realize even before looking into all of this that a lot of the initial assumptions are flawed, in particular the over prioritization of the home row. 

Admittedly, my typing technique has actually changed dramatically over the past year and a half concurrently with the evolution of my technique at the piano using the methodologies of Dorothy Taubman (https://www.youtube.com/watch?v=47w_6IKHA1M).  I've actually gotten to the point where I'm questioning the basic principles of strict touch-typing in general, and I'm finding that Sean Wrona's more flexible style isn't so inconceivable at all now.
Title: Nothing
Post by: iandoug on 2016-Oct-10 02:45
Thought I would share this unexpected screen from last night's tests... Quadgrams, consecutive finger use.

Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2016-Oct-10 03:15
Just noticed Arensito Kinesis results not showing up on Ergo page, I need to tweak the Ajax call but am busy with other changes to that page so will only be done later. Have urgent work to do first... :-)
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2016-Oct-10 10:43
Got KLA running properly locally (ie the repo).

Bootstrap js and css were in the wrong place (I guess the install process did not set them up... but node/bower/grunt is not something I know much about...).

Can now look at putting your changes in :-)
Title: Re: Balanced Keyboard Layout
Post by: schizoID on 2016-Oct-10 11:37
Schizo, Arensito Kinesis and Beakl34 Kinesis results are up.

I've been smacked down the rankings, unless you included dates and times.

Must add my mod to schizo still... might have some more changes to make. But I really don't like AltGr+shift+key == space....

Then I can start looking at your scoring :-)... thanks for putting it up on the web.

Cheers, Ian

my scores take into account the weights of each finger for distance, finger usage, and consecutive finger. original KLA only for finger usage.

The values may be controversial. They are relative, with 1.0 as baseline. Lower value means less effort.

Code: [Select]
Distance Weights

PINKY = 2.0;
RING = 1.3;
MIDDLE = 1.0;
INDEX = 1.1;
ONE THUMB = 1.0;
BOTH THUMBS = 2.0;


Finger Usage and Consecutive Finger Weights

PINKY = 2.0;
RING = 1.2;
MIDDLE = 1.0;
INDEX = 1.1;
ONE THUMB = 1.0;
BOTH THUMBS = 2.0;

For Consecutive Finger, the values are squared

You can see that I penalize two thumbs, but not one thumb. That's why schizo's layout scores higher (worse). But I'm not sure that's enough to pull it down that far.

I put space on shift+alt+key for highest scores because I didn't know about bug in KLA.
Actually in that moment I wanted to place space under AltGr+SpaceBar but results gown down in KLA.
So now you can change it to AltGr+SpaceBar for tests, it is clear that results must go up.

Now my config for SpaceBar is: when it press-released alone it is acts as a space; when it presed with another key it is acts like a shift.
But I don't know where I can evaluate such config.
May be original KLA, because it adds no cost for Shift/AltGr + key when Shift/AltGr are in home position? ;)

PS. This post was typed with SpaceBar as a space and as a Shift =)
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2016-Oct-10 12:11
Now my config for SpaceBar is: when it press-released alone it is acts as a space; when it presed with another key it is acts like a shift.
But I don't know where I can evaluate such config.
May be original KLA, because it adds no cost for Shift/AltGr + key when Shift/AltGr are in home position? ;)

PS. This post was typed with SpaceBar as a space and as a Shift =)

interesting idea .. I was just about to ask if Linux supports such a thing, and then you said you have it working ....
Is this in xkb file?
How do you do shift-lock?

[edit]
No matter, you're using the modified evdev driver. Am pondering the approach ... and how to make KLA understand it and score it ...
thanks, Ian
Title: Re: Balanced Keyboard Layout
Post by: Den on 2016-Oct-10 19:51
Got KLA running properly locally (ie the repo).

Bootstrap js and css were in the wrong place (I guess the install process did not set them up... but node/bower/grunt is not something I know much about...).

Can now look at putting your changes in :-)

Gonna streamline the code in scoring section. Put everything in arrays and objects so they can be interacted in more ways. Like print and export category results. This also allows to easily add and remove new categories if necessary.
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2016-Oct-11 02:51
Gonna streamline the code in scoring section. Put everything in arrays and objects so they can be interacted in more ways. Like print and export category results. This also allows to easily add and remove new categories if necessary.

Okay, I'm going to go slowly in any event so I'll start somewhere else than the scoring :-)
Title: Re: Balanced Keyboard Layout
Post by: Den on 2016-Oct-12 00:56
Gonna streamline the code in scoring section. Put everything in arrays and objects so they can be interacted in more ways. Like print and export category results. This also allows to easily add and remove new categories if necessary.

In summary page (http://shenafu.com/code/keyboard/Keyboard%20Layout%20Analyzer.html#/results), hover over each layout to view their scores in each category.

Attached new 7z file.
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2016-Oct-12 04:34
In summary page (http://shenafu.com/code/keyboard/Keyboard%20Layout%20Analyzer.html#/results), hover over each layout to view their scores in each category.

Attached new 7z file.

Cool, thanks. Helps to understand where your score comes from.

Just wondering... the components vary quite a bit (eg 6.xx vs 0.yy). So is it fair to just add them, or should they be scaled somehow before being added?
I have not looked at how you do your sums.
Just wondering if, for example a major improvement in one of the smaller numbers is going to count for little against the big distance number. Or a small improvement in distance will compensate for another metric that's actually very bad.

The values in the second column depend heavily on which layout comes first. I suppose that is as it should be. I just have a nagging feeling that we should be comparing to some "Max Score" (or vice versa, showing How Much Better than Worst Possible Score) or somesuch. If you know what I mean. :-)

Schizo compared against QWERTY but QWERTY is not the worst. I suppose it's a useful benchmark to compare against, at least in ANSI-104 world. I suppose in theory it would be possible to automagically include QWERTY by default (have the layout hard-loaded) and compare against it. ie Coleman is 23% better than QWERTY on this test, etc.
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2016-Oct-12 05:01
Schizo compared against QWERTY but QWERTY is not the worst. I suppose it's a useful benchmark to compare against, at least in ANSI-104 world. I suppose in theory it would be possible to automagically include QWERTY by default (have the layout hard-loaded) and compare against it. ie Coleman is 23% better than QWERTY on this test, etc.

PQE = numround(score * 100 / qwertyscore,2);
PQE Percent Qwerty Effort
Title: Re: Balanced Keyboard Layout
Post by: Den on 2016-Oct-12 05:36
The low penalty from consec fingers and hand reflect their low impact and frequency. Opt shows same finger occurs approx. 3% of keys. Realistically most good layouts are smart enough to minimize these. Same hand is not all bad due to some good rolls. Also this analyzer is not sophisticated to score trigrams, which may penalize more harshly.

Comparing to qwerty is not our goal. Everyone knows it sucks for over a century. Theres ample stats and arguments to show that everyone should stop using it.

Our goal is to find the best layout. So we need meaningful comparisons between the cream of the crop. Qwerty is so far down the list we just as soon forget it existed. By comparing to the best of a set, that gives consistent direction of extra effort. It's easier to see a jump in effort in different claases of layouts.
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2016-Oct-12 15:29
In summary page (http://shenafu.com/code/keyboard/Keyboard%20Layout%20Analyzer.html#/results), hover over each layout to view their scores in each category.

Attached new 7z file.

Um, are you not able to work with a cloned repo rather than download-and-save from live site?

I duplicated my working from-repo version, to use for applying your changes.

I tried on the first file, template.js, found the few changes you made, copied them across to the only template.js file, which is in /build , but when I ran grunt in that folder it created a new template.js so clearly the file I was fiddling in was the wrong one, but it's the only one I see...

~/projects/kladen $ locate templates.js
/home/ian/1web/keyboard-site/kla-den3/Keyboard Layout Analyzer_files/templates.js.download     (this is your kla.7z version 3)
/home/ian/projects/kladen/js/build/templates.js          (this is the duplicated repo site)

It's going to be tricky taking your changes from a built file and putting them into something that needs to be built by grunt/whatever.
I guess I need to figure out where the heck it gets what it needs to build templates.js

I also see that some files are missing from the repo, eg
require_once('../../../app-data/kla/config.php');
Neither path or file exists.
Probably some variables needed for saving on Patrick's server.

On the positive side, I was able to add a preset text to the dropdown, so in theory I'll be able to add all my tests (and presumably layouts as well), which should speed up testing ... no need for continuously pasting texts and layouts.

Will poke around some more ....
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2016-Oct-12 15:42
I need to modify the .htm files in /partials.

eg in here
   
                            <tr ng-repeat="layout in results.summary.rankedLayouts" >
                                <td ><div class='text-right'>#{{$index + 1}}</div></td>
                                <td></td>
                                <td ><div class='text-left'>{{layout.layoutName}}</div></td>
                                <td><div class='text-right'>{{layout.score.toFixed(2)}}</div></td>
                            </tr>

Going to study up a bit on Angular and node etc. Been a year since I worked on Angular stuff.
Title: consecutive finger usage
Post by: iandoug on 2016-Oct-12 16:49
Did I miss something somewhere? :-)

comparing Patrick's same-finger scores to yours, eg Alice and QWERTY
Patrick:
6      1    170   64   0   0     70    22   44    63    440
Yours
12.0 1.2 170.0 70.4 0.0 0.0 77.0  22.0 52.8  126.0 531.4
 
Some the same, some different. Any ideas?
Also what does it mean that you used the same finger 1.2 times in a row? :-)

Yeah I'm tired and not thinking straight :-)
Title: Re: consecutive finger usage
Post by: Den on 2016-Oct-13 16:58
Did I miss something somewhere? :-)

comparing Patrick's same-finger scores to yours, eg Alice and QWERTY
Patrick:
6      1    170   64   0   0     70    22   44    63    440
Yours
12.0 1.2 170.0 70.4 0.0 0.0 77.0  22.0 52.8  126.0 531.4
 
Some the same, some different. Any ideas?
Also what does it mean that you used the same finger 1.2 times in a row? :-)

Yeah I'm tired and not thinking straight :-)

Patrick original only shows the raw numbers, under the Units: Key Presses option. This doesnt factor in the finger weights.

My code adds a field Units: Finger Penalty and sets that as default to be shown. The fingers weights are accounted for. You can still select Units: Key Presses and they should match what you see on Patricks site.
Title: Re: consecutive finger usage
Post by: iandoug on 2016-Oct-13 17:10
Patrick original only shows the raw numbers, under the Units: Key Presses option. This doesnt factor in the finger weights.

My code adds a field Units: Finger Penalty and sets that as default to be shown. The fingers weights are accounted for. You can still select Units: Key Presses and they should match what you see on Patricks site.

Ah. I didn't notice that. In truth, I only usually selected from the dropdown lists on the Finger Usage page, to select hand-vs-hand. I see your metrics pop up there too.

How do you feel about the status of your scoring algorithm? I'm asking because I don't want to add a lot of scores with your algos, and then have you change the algos next week.... :-)

thanks, Ian
Title: Re: consecutive finger usage
Post by: Den on 2016-Oct-13 17:18
How do you feel about the status of your scoring algorithm? I'm asking because I don't want to add a lot of scores with your algos, and then have you change the algos next week.... :-)

thanks, Ian

Seems good to me. Maybe a bit disappointed in BEAKL 32. Probably because finger effort is not as meticulous as AdNW Opt.

You have more data at hand. Just take a cursory glance of dozen layouts and see if the results are within reason.
Title: Re: consecutive finger usage
Post by: iandoug on 2016-Oct-13 17:25
Seems good to me. Maybe a bit disappointed in BEAKL 32. Probably because finger effort is not as meticulous as AdNW Opt.

You have more data at hand. Just take a cursory glance of dozen layouts and see if the results are within reason.

Was planning on putting them on a separate page, will start with the three tests from Patrick, and all the layouts. Trying to figure a way to make the dropdowns work on your version, so that I don't have to keep copy-pasting layouts and inputs... I see you added an img folder for the cup image, did you need to modify any paths in the code or did it just work? (Am hoping adding layouts and inputs will be as easy)
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2016-Oct-13 19:39
Something for you to play with. From the speed typing competition. For testing layouts with. Supposed to be difficult to type ... :-)
MTGap and Colemak do poorly compared to 'leading' layouts... :-)
Title: Re: consecutive finger usage
Post by: iandoug on 2016-Oct-14 07:47
My code adds a field Units: Finger Penalty and sets that as default to be shown. The fingers weights are accounted for.

Okay, please help me to understand how to interpret, for example, your left pinky getting a score on the distance page of 162.6. What does that actually mean? The cm score was 81.3.
So you multiply the cm by 2 because?

Thanks, Ian
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2016-Oct-14 16:26
Ergodox is available.

https://ergodox-ez.com/collections/frontpage/products/ergodox-ez-bundle-with-blank-keycaps

But rather expensive in Rands... and at the moment has "excess" keys given state of our current designs.

I still think I want a centre numpad and traditional arrow cluster (did I just contradict myself? :-) )
Title: Re: consecutive finger usage
Post by: Den on 2016-Oct-15 04:32
Okay, please help me to understand how to interpret, for example, your left pinky getting a score on the distance page of 162.6. What does that actually mean? The cm score was 81.3.
So you multiply the cm by 2 because?

Thanks, Ian

Instead of penalty, maybe should call it effort. The multipliers are approximate, relative each fingers' strengths.
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2016-Oct-15 05:03
I asked because I'm trying to figure out /decide which metrics to include into the database, for your scoring.

In the mean time I'm fixing a bunch of other things on my site. Past week was rather hectic work-work-wise, coming week should be a bit calmer. So hope to get your scoring done.

Title: Re: Balanced Keyboard Layout
Post by: Den on 2016-Oct-15 18:47
I asked because I'm trying to figure out /decide which metrics to include into the database, for your scoring.

I suggest use the penalty scores, rename it Effort, with a note that lower scores are better. So you have Overall Effort, Effort from Distance, Effort by Finger, and Effort from Same Hand. 
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2016-Oct-15 20:03
I suggest use the penalty scores, rename it Effort, with a note that lower scores are better. So you have Overall Effort, Effort from Distance, Effort by Finger, and Effort from Same Hand.

Okay, I think I will see how it goes with Overall effort, Distance effort, and SameFinger effort, almost like with Patrick's scoring, except taking finger weights into account.
Please remember each extra metric I have to capture is 136 * 42 (currently) == 5712 numbers to type .... :-)

FWIW I think I'll get better separation by kicking your overall score up by 10, as per
 "                                <td><div class='text-right'>{{(layout.score * 10).toFixed(2)}}</div></td>\n" +
@ line 596 in templates.js
Trust that's the only place I need to change.

I saw some code when I was looking for that that implies I just need to put the presets into ./preset folder, but on the other hand it was doing a http call and we're not running your version through a server. Ow. Have to make another plan until such time as I can get all your code into Patrick's repo version.

Have finished fiddling on my site for the time being. Your Ergo/Alt layouts are up, as are Schizo's. Added in those two typing tests, from http://seanwrona.com/typing.php
found by searching for the guy's name mentioned in the post above with the video.

Cheers, Ian
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2016-Oct-16 05:59
FWIW I think I'll get better separation by kicking your overall score up by 10, as per
 "                                <td><div class='text-right'>{{(layout.score * 10).toFixed(2)}}</div></td>\n" +
@ line 596 in templates.js
Trust that's the only place I need to change.

Realised in bed that if I do that then your popup explaining the score won't be accurate anymore. Might have to tweak that a little. I don't want to fiddle with your scoring, I'm just trying to get better separation on the Overall Effort. I've got over 130 layouts, and squeezing them all into a range from 10.05 (my Alice 74.99) to 17.33 (Dvorak left-handed) means the differences are going to be very close to the eye.

I saw some code when I was looking for that that implies I just need to put the presets into ./preset folder, but on the other hand it was doing a http call and we're not running your version through a server. Ow. Have to make another plan until such time as I can get all your code into Patrick's repo version.

Also realised in bed that I *can* run your version through a web server, and after a bit of fiddling with Nginx's configs this morning managed to get it to work... the non-standard file extensions caused some issues. So now the presets (Alice etc) load, must just move ALL my tests there and add them to the dropdown.

Then must make the layout selection work... that should speed up testing considerably if I can eliminate all the copy-pasting of layouts and tests.

Cheers, Ian
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2016-Oct-16 12:46
Busy capturing Patrick's three tests with your scoring.

Vukeys (+ dangvu) looking very good... unless you include AltGr layouts...

It even beats my layouts that do well on Patrick's scores. Very depressing :-)

Title: Den's scoring
Post by: iandoug on 2016-Oct-16 15:26
A funny thing happened on the way to the scoreboard ..... :-)

Show you in a bit...

Life is full of surprises.
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2016-Oct-16 15:52
Okay, the three tests from Patrick are up on my site with your scoring, as tweaked by me.

http://www.keyboard-design.com/best-layouts.html

You will find the ANSI page interesting. :-)
And possibly annoying at the same time :-)

The rankings will likely change a lot once I add more prose (and even more when I add the tech stuff), at the moment the word lists make 2/3 of the score and unbalance it a bit.

In general, at the moment the AltGr layouts are STILL doing very well, followed in general by those where the keys were remapped.

Cheers, Ian
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2016-Oct-16 18:24
Okay, the three tests from Patrick are up on my site with your scoring, as tweaked by me.
You will find the ANSI page interesting. :-)

Whoops sorry, cancel that ... had Opted 1 as ANSI when it's Ergo .. apologies. But that does explain a few things :-)
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2016-Oct-16 19:02
Okay, the three tests from Patrick are up on my site with your scoring, as tweaked by me.


Also Google home page score. That's the worst one to do, runs for ages.
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2016-Oct-17 16:09
So taking away the left shift does dramatic things to the score ... (as per Beakl36) ..
Mmmm :-)
Title: Hand use
Post by: iandoug on 2016-Oct-17 17:59
Hi

Have you compared the hand-vs-hand pie charts in your version vs Patricks?

thanks, Ian
Title: Schizo
Post by: iandoug on 2016-Oct-18 04:13
If I (we?) understand Patrick's scoring correctly, then he rewards things under the middle finger much more than if they are under the pinky or thumb (which get the same low multiplier).

So putting space under the middle finger or index finger will (artificially?) boost the score for any text with a lot of spaces, even if you need AltGr (+shift) + key to do it.

I think that explains schizo's rather amazing scores via Patrick, and why they are lower via your scoring.

In the mean time I've borrowed ideas from both you and schizo... I learn from the best :-)
Title: Scoring oddity
Post by: iandoug on 2016-Oct-18 07:12
Hi

Was trying to improve my "just rearrange the keys" because Vu Keys and cousin beat it on your scoring.

So I got something that scored better, but when I checked the results in Patrick's scoring I noticed an anomaly.

Below, the B == Better, W = worse. The scores are on the three default KLA tests.

Den
Old  115.88  108.04  109.23
New  114.12  102.80  101.65
       B       B       B

Patrick
Old    71.05  73.91  73.00 
New    68.63  72.54  74.37
         W      W      B

So I find it curious that your scoring shows dramatic improvement in 2/3, while Patrick thinks it's actually worse 2/3 (and a different 2/3 at that). It's just key-rearrange, no fancy tricks, all English tests.

Old layout is Ian OAEH 71.05 73.91 73.00 69.00 which you have, while new is attached.

Were you expecting such behaviour from your scoring model?
I'm guessing yours is more correct, but divergence like this makes it tricky to satisfy both.
I would expect divergence where there is AltGr or other 'tricks' involved, but was surprised on a "just rearrange keys" layout.
The Alice score on Patrick is 'dramatically' different, which worries me :-)
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2016-Oct-18 11:20
More curious results.
Am busy doing Keyboard Layout Editor with your scoring.
Attached results from that, plus the top layouts on the list as scored by Patrick.

I'm wondering if we have uncovered another 'problem' with Patrick's scoring, or if some weighting in your scoring is a bit off.
FWIW, Klausler does very well with your scoring on English ... went through all the English inputs to compare your scoring with Patrick's scoring for the two layouts in previous message. In over 80% of the cases, your scoring rates the new one as better, while it's vice-versa in Patrick's scoring. So there is something radically different in the measuring somewhere... :-)

Whoops, wrong Dvorak. What was bothering me was that all the layouts came out worse than "Personalised" which is very rare... especially with something like MTGap in the mix.
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2016-Oct-18 14:13
Been trying to find some research on relative strength of the fingers, and Google has been rather unco-operative.  Guess they tweaked their algorithms again in the wrong direction, or too many assumptions.

Anyway best I've found so far is this, which is about grip strength rather than pressing strength.

================================
In the past, individual digit strength was measured using digital hand-held dynamometers or other force transducer devices (11–13). It is difficult to use these results clinically because they are not directly comparable with our study in which the Jamar dynamometer was used. Based on individual digital measurements, MacDermid et al (2) suggested the ulnar digits (little and ring fingers) contribute a lesser proportion of overall grip strength. Digital contributions to overall grip strength have been approximated at 25%, 35%, 26% and 15% for the index, long, ring and little fingers, respectively (1,2). However, forces produced by the individual digit do not act only on that digit and do not act in isolation. In the current study, grip strength significantly decreased when the ulnar digits were excluded. Exclusion of the little finger from a functional grip pattern decreased the overall grip strength by 33%. Exclusion of the ring finger from a functional grip pattern decreased the overall grip strength by 21%. Exclusion or neutralization of both ring and little fingers gave a loss of 54% grip strength. However, this does not suggest that the contribution of the index and middle fingers in a normal hand would be equal to 46% grip strength. When compared with past research measuring individual digital strength, it is clear that the little finger is an important contributor to overall grip strength beyond individual digital strength. This would appear to support past research indicating that activation of little finger motor units also cause tension in other fingers (4).
==================================
from https://www.ncbi.nlm.nih.gov/pmc/articles/PMC2851460/

What I found curious was how similar index and ring are approximated above.... with ring even stronger than index. One (well, me) tends to think of the ring finger as weak ... perhaps I was wrong.

Was thinking I need some data about fingers:
1. relative (press) strength
2. relative flexibility
3. average "finger length" ratios.
4. average "hand sizes" ... which is a problem since they vary so much. Trying to model exactly how much effort is needed for the pinky to hit += on a keyboard (which I've just hit with my middle finger...). Sometimes I think the default finger map of the keyboard is way wrong. I never hit anything on the top row with my pinky. Mmm maybe I should do some tests on KLA replacing all the pinky keys with which finger I ACTUALLY use ... but I guess the distance penalties will hit hard.

I was trying to figure out if we can see when you can hit a key by just moving the finger, or when you need to move your whole hand as well. Because clearly that is more "effort". And it should be scored as such.
Title: BEAKL Opted 36
Post by: iandoug on 2016-Oct-19 08:35
Are there different versions of Opted 36?

Scores in my spreadsheet differ from what I'm getting in tests now so now I'm not sure which is the Official version. Maybe you need to add suffixes or something to differentiate versions? :-)
Title: Re: Balanced Keyboard Layout
Post by: Den on 2016-Oct-21 03:55
i have read similar research on finger strengths, and that's how i came about the relative strengths, weights, and efforts. and yes, the ring finger is very underrated by other keyboard enthusiasts, who probably haven't read these studies. even the piano teacher in that video laments the unjust rap the ring finger gets.

Are there different versions of Opted 36?

Scores in my spreadsheet differ from what I'm getting in tests now so now I'm not sure which is the Official version. Maybe you need to add suffixes or something to differentiate versions? :-)

I attached the last version of BEAKL 36 Ergo. It varies from the one you have by a bit.
Title: Re: Balanced Keyboard Layout
Post by: Den on 2016-Oct-21 04:00
i have tried to reassign outside keys from pinky to other fingers. the farther distance is offset by the low weight penalties. in the end, the scores didn't change that much. but you can try and see for yourself.

Title: Re: Scoring oddity
Post by: Den on 2016-Oct-21 04:40
Hi

Was trying to improve my "just rearrange the keys" because Vu Keys and cousin beat it on your scoring.

So I got something that scored better, but when I checked the results in Patrick's scoring I noticed an anomaly.

Below, the B == Better, W = worse. The scores are on the three default KLA tests.

Den
Old  115.88  108.04  109.23
New  114.12  102.80  101.65
       B       B       B

Patrick
Old    71.05  73.91  73.00 
New    68.63  72.54  74.37
         W      W      B

So I find it curious that your scoring shows dramatic improvement in 2/3, while Patrick thinks it's actually worse 2/3 (and a different 2/3 at that). It's just key-rearrange, no fancy tricks, all English tests.

Old layout is Ian OAEH 71.05 73.91 73.00 69.00 which you have, while new is attached.

Were you expecting such behaviour from your scoring model?
I'm guessing yours is more correct, but divergence like this makes it tricky to satisfy both.
I would expect divergence where there is AltGr or other 'tricks' involved, but was surprised on a "just rearrange keys" layout.
The Alice score on Patrick is 'dramatically' different, which worries me :-)

the new layout seems to benefit from the new distance scoring that includes the weight for each finger, which Patrick's didn't account for. it has higher finger usage and same-finger, but the better hand alternation helped negate those disadvantages.

overall, distance has the greatest variance, so it tends to be the greatest factor.
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2016-Oct-22 15:40
I attached the last version of BEAKL 36 Ergo. It varies from the one you have by a bit.

Non-ergo too please :-)

thanks, Ian
Title: Re: Balanced Keyboard Layout
Post by: Den on 2016-Oct-22 16:02
Non-ergo too please :-)

thanks, Ian

I dont have 36 non-ergo because it's not meant for standard.

Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2016-Oct-22 16:33
This is what I have/had ... have not replaced the ergo one yet. Actually busy doing tests at the moment and very annoyed I seem to have made a lot of typos with one of my new layouts (either that or I lost the layout and what I have now happens to score the same on 1 test... which is unlikely).

Attached.
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2016-Oct-22 16:44
I dont have 36 non-ergo because it's not meant for standard.

See http://patorjk.com/keyboard-layout-analyzer/#/load/r7T1MdwZ    :-)

Cheers, Ian
Title: Re: Balanced Keyboard Layout
Post by: Den on 2016-Oct-23 16:04
See http://patorjk.com/keyboard-layout-analyzer/#/load/r7T1MdwZ    :-)

Cheers, Ian

There was a preliminary version, but i gave up on it because it seemed unlikely to be adopted for standard and not much different than 34. You can use that one since it seems unlikely i will update it in the near future.
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2016-Oct-23 16:33
There was a preliminary version, but i gave up on it because it seemed unlikely to be adopted for standard and not much different than 34. You can use that one since it seems unlikely i will update it in the near future.

FWIW, and bearing in mind I want to recheck 36's scores because I might have made some errors,  that layout is currently your top performing ANSI layout.

That "enter on left ring" idea is very interesting. Did you come up with it yourself? I have borrowed it, trust you don't have copyright on it :-)
I refer it as an EnterRing mod ...

I couldn't figure out how that layout was doing so well, and managed to overlook the Enter key for quite a while ...
In truth I've tried putting Enter in other places (like on Index, home row, etc) but Patrick's scoring never liked the idea.

Thanks, Ian
   
Title: Re: Balanced Keyboard Layout
Post by: Den on 2016-Oct-23 18:03
FWIW, and bearing in mind I want to recheck 36's scores because I might have made some errors,  that layout is currently your top performing ANSI layout.

That "enter on left ring" idea is very interesting. Did you come up with it yourself? I have borrowed it, trust you don't have copyright on it :-)
I refer it as an EnterRing mod ...

I couldn't figure out how that layout was doing so well, and managed to overlook the Enter key for quite a while ...
In truth I've tried putting Enter in other places (like on Index, home row, etc) but Patrick's scoring never liked the idea.

Thanks, Ian

BEAKL 36 was created from Opt, so it's a great layout on its own right. But it's only for really daring enthusiasts to try. Even myself prefer to reserve two pinky keys for modifiers and modes (e.g. num lock and control).

Kinesis makes me accustomed to below-bottom row keys, and I'd really rather not put Enter, a common key, on the pinky. In fact, one may even consider putting Enter on the main 30 block, by pushing a less-used punc elsewhere.
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2016-Oct-24 13:22
Ergodox is available.

https://ergodox-ez.com/collections/frontpage/products/ergodox-ez-bundle-with-blank-keycaps
But rather expensive in Rands... and at the moment has "excess" keys given state of our current designs.
I still think I want a centre numpad and traditional arrow cluster (did I just contradict myself? :-) )

Dunno if you noticed, MassDrop now has the kit on sale. They put the "list" price at around 600 which I know is a lie.
Actually started "configuring" my purchase when I noticed all the comments and read the latest ones ... looks like the build quality on these things leaves a lot to be desired. And they don't deliver to sunny South Africa... :-(

So I need to think about it a bit more. The prebuilt option above looks like a better deal... though I would have to find a way to label the keycaps. Have the same problem with the board I want to build....
Title: Re: Balanced Keyboard Layout
Post by: daaawooo on 2016-Oct-24 21:56
hello,

I'm joining in as owner of an infinity ergodox. I got it 2-3 weeks back, build it last weekend.
Until now I was a lurker of this thread.

I want to seize the opportunity during switching keyboards also to switch layouts, QWERTZ (I'm German) to something better.

Currently I figuring out the effort for my fingers to press certain keys on the ergodox.
For a first timer with a split keyboard it is hard to keep the wrist straight and depending on that fact the effort changes for the thumb.
The thumbs can use only 2-3 keys from the thumbcluster with a low effort - plus one key two below the index finger's home position.
The other 3-4 keys from the thumbcluster have a very high effort, if touchtyping "from above" / without laying the wrist on a wrist rest the efforts get better (lower).
Below is a picture from KLA with an effort grid (not a layout) just from ease of movement.
But after looking at the picture:
- the relatively strong middle finger hits only 4 keys (waste of power ?)
- the thumb (most people think he is one of or the strongest, there are some complaints/health issues on geekhack with ergo keyboards depending on hand/thumb size) needs to hit 8 keys (overloading an overrated finger ?)

@Den
What are your effort-grid-numbers/values for the thumbs on an ergo ?

@iandoug
Yes, ergodox isn't cheap, but the whole mechanical kb hype took off very well in the last few years. 10 years back you could pull mechanical kb for ps2 out of the trash for free, nowadays those things changing the owner for 10-100 bucks.

Please note the ergodox @ massdrop is an "infinity ergodox" (a DIY kit, with programmable LCD-displays) for about US$ 250 with shipping but wrist rest option etc. not included but available in same or different drops for extra money.
In contrast the "ergodox ez" comes with wrist rest, tilt/tent kit for about US$ 325 with shipping - ready to use.
The ergodox is open-source so everybody can download the schematics, CAD/CAM-data, etc. and modify and manufacture it, so there are different versions out in the wild.

Outside the US shipping gets higher, customs, taxes, ...





Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2016-Oct-25 03:12
Until now I was a lurker of this thread.
Lurking is good :-)

For a first timer with a split keyboard it is hard to keep the wrist straight and depending on that fact the effort changes for the thumb.
The thumbs can use only 2-3 keys from the thumbcluster with a low effort - plus one key two below the index finger's home position.
The other 3-4 keys from the thumbcluster have a very high effort, if touchtyping "from above" / without laying the wrist on a wrist rest the efforts get better (lower).
Below is a picture from KLA with an effort grid (not a layout) just from ease of movement.

Is this based on how it feels, or some sort of objective measurement?
I'm asking because I'm interested in the methodology, not to criticise.
Also Den has (or borrowed) an interesting mod where the Enter key is on the bottom row ring finger. So the difficulty on this position is important to get right.

But after looking at the picture:
- the relatively strong middle finger hits only 4 keys (waste of power ?)
- the thumb (most people think he is one of or the strongest, there are some complaints/health issues on geekhack with ergo keyboards depending on hand/thumb size) needs to hit 8 keys (overloading an overrated finger ?)

Yes, curiously it seems as if Patrick rated the effort on the thumb to be the same as the effort on the pinky. We weren't sure if we agreed with that.
I know some manufacturers put heavier springs under thumb keys (eg space bar), which may be contributing to the problem. It's one of the reasons I don't like the MS 4000... hurt my thumbs.

I don't have a suitable keyboard to experiment with, but it "seems" as if the thumb is the most flexible thing on the hand, and should be able to hit more keys than any other finger. But it's a blunt tool, and I'm guessing that the fact that thumb keys tend to be 1.5 to 2 units in size, that people hit them on the edge rather than dead centre like 1u keys, and this off-centre action is heavier on the thumbs. If you couple that with heavier springs then you will have problems I guess...


@iandoug
Yes, ergodox isn't cheap, but the whole mechanical kb hype took off very well in the last few years. 10 years back you could pull mechanical kb for ps2 out of the trash for free, nowadays those things changing the owner for 10-100 bucks.

Please note the ergodox @ massdrop is an "infinity ergodox" (a DIY kit, with programmable LCD-displays) for about US$ 250 with shipping but wrist rest option etc. not included but available in same or different drops for extra money.
In contrast the "ergodox ez" comes with wrist rest, tilt/tent kit for about US$ 325 with shipping - ready to use.

The cost of everything is relative. You compare what MassDrop is charging for a Kit vs fully-built direct from Taiwan, vs Kinesis fully-built with Cherry keys (and more keys).
What really worried me were the comments on MassDrop about badly drilled holes, cables not working, switches not working, etc.... I don't need that.

In truth I've probably spent more than what they're asking just buying the bits and pieces for my own keyboard (Teensy++, Cherry brown, Gateron brown and red, DSA PBT blank keycaps, proper soldering iron, etc..). So it's not so much the price as bang for the buck/quality for what you pay.

Thanks for your inputs :-)

Cheers, Ian
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2016-Oct-25 06:49
Problem 2.

When I do real tests while typing some text in my shifted version I accidentally typed [  I'll ] . This was another BIGGER problem: movement of right thumb when you type something mixed with Alt_R and Shift_R. Consider quoted text, dialogs, constants in the programming languages. For example, in the BEAKL 4 Mod Ian AltGr 2 for typing a start of the dialog [ "I've]  you need to do this (assuming that your thumb at AltGr in home position, but it difficult because finger is not relaxed completely at ordinal keyboard at this position): hit AltGr, hit [ "]  with the SAME hand (try it), move thumb to Shift_R, hit it hold it, hit [ I] , move thumb to AltGr, hit it, hold it, hit [ '] . Try to do all of these quickly as you can =) Yes, I can try to move such key combinations (for example move [ ']  and [ "]  to another keys without AltGr and Shift_R), but who knows how much of such sequences can occur in different types of texts and with which symbols? And even if I need to type just one such sequence in the middle of something long, it would be very annoying.

Work in progress, just a proposal... comments welcome.
Menu/OS should obviously be blue ... :-)
Title: Meet the I-Board
Post by: iandoug on 2016-Oct-25 17:26
Above layout enhanced into Ergo form factor. The I-Board.

http://www.keyboard-design.com/layouts/ergo//75/i-board.html
Title: Re: Balanced Keyboard Layout
Post by: daaawooo on 2016-Oct-25 19:19
Is this based on how it feels, or some sort of objective measurement?
I'm asking because I'm interested in the methodology, not to criticise.

I took Den's efforts from his standard effort grid from page 1 then I played around with the ergodox and my hand filling the "blanks" - just subjective values for my hands / fingers.
Long term effort values may differ, but somewhere I need to start.
Someone else may have different initial values.

Yes, curiously it seems as if Patrick rated the effort on the thumb to be the same as the effort on the pinky. We weren't sure if we agreed with that.
I know some manufacturers put heavier springs under thumb keys (eg space bar), which may be contributing to the problem. It's one of the reasons I don't like the MS 4000... hurt my thumbs.

I don't have a suitable keyboard to experiment with, but it "seems" as if the thumb is the most flexible thing on the hand, and should be able to hit more keys than any other finger. But it's a blunt tool, and I'm guessing that the fact that thumb keys tend to be 1.5 to 2 units in size, that people hit them on the edge rather than dead centre like 1u keys, and this off-centre action is heavier on the thumbs. If you couple that with heavier springs then you will have problems I guess...
Currently on my standard 104/105 kb with QWERTZ the thumbs play a strong role without pain issues (even pressing CTRL-X/C/V with one hand, which should be bad). With this in mind I would give the thumb a start value of zero for the home position and at least 2 more thumb operated keys value 1.

Sometime I press  CTRL-X/C/V with pinky plus middle or index finger from some hand, should also be bad.

Healthier should be pressing CTRL with whatever finger on one hand and the X, C or V with index finger of the other hand.
Which brings me to your "Programmer's Keyboard v3" layout, it's missing some modifiers on both sides below the 6x3 cluster.
Somewhere I read, modifiers should be on both sides and symmetric, see healthy point above even it reduces the number of available "direct" keys.
The one with highest usage on the inside directly besides space-key at least on an standard keyboard.
With a split keyboard the question is only one space key or two ? I maybe go for two space keys.

What really worried me were the comments on MassDrop about badly drilled holes, cables not working, switches not working, etc.... I don't need that.

In truth I've probably spent more than what they're asking just buying the bits and pieces for my own keyboard (Teensy++, Cherry brown, Gateron brown and red, DSA PBT blank keycaps, proper soldering iron, etc..). So it's not so much the price as bang for the buck/quality for what you pay.

My ergodox is maybe not A+ quality but A, everything fits.
The default acrylic case is very scratch-prone, but I wouldn't spend even more money for other optional cases.
Having no cable problems, but I using the supplied cables, even to connect both side using a 6 ft. long cable. Me and most other people hate this fact, but currently it's unclear which cable of the shelf from your electronic market or amazon works correctly. But two 6 ft. cables are cheaper than one 6 ft. plus one 1 or 2 foot otherwise the infinity ergodox would have been even 5 bucks more ...

I wanted Alps/Matias switches so the other ergodoxes were out of the picture.


Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2016-Oct-26 01:26
Currently on my standard 104/105 kb with QWERTZ the thumbs play a strong role without pain issues (even pressing CTRL-X/C/V with one hand, which should be bad). With this in mind I would give the thumb a start value of zero for the home position and at least 2 more thumb operated keys value 1.

I see the Z is in a difficult position on QWERTZ. However I thought "everyone" on QWERTY hit ctrl-z/x/c/v with one hand... I certainly always have, and I thought that was one of the ideas behind the shortcut in the first place. Also my pinky is shorter than normal and I don't have trouble using one hand for this.

Which brings me to your "Programmer's Keyboard v3" layout, it's missing some modifiers on both sides below the 6x3 cluster.
Somewhere I read, modifiers should be on both sides and symmetric, see healthy point above even it reduces the number of available "direct" keys.
The one with highest usage on the inside directly besides space-key at least on an standard keyboard.
With a split keyboard the question is only one space key or two ? I maybe go for two space keys.

Um, there's one space key, a Ctrl on both sides, an Alt on left and replacement for AltGr on right. There's only 1 shift key, but that's a consequence of the scoring telling us it's better to have a single shift on the right thumb.
So which modifiers do you think are missing?

Thanks, Ian
Title: Re: Balanced Keyboard Layout
Post by: daaawooo on 2016-Oct-26 13:31
I see the Z is in a difficult position on QWERTZ. However I thought "everyone" on QWERTY hit ctrl-z/x/c/v with one hand... I certainly always have, and I thought that was one of the ideas behind the shortcut in the first place. Also my pinky is shorter than normal and I don't have trouble using one hand for this.
For me Ctrl-Z on QWERTZ is actually effort lesser than the other three Ctrl-X/C/V.
For touch typing you should not use 2 fingers on one hand at the same time, hence the paired modifiers and most times even symmetric modifiers.


Um, there's one space key, a Ctrl on both sides, an Alt on left and replacement for AltGr on right. There's only 1 shift key, but that's a consequence of the scoring telling us it's better to have a single shift on the right thumb.
So which modifiers do you think are missing?

The sailers wheel is Crtl ?
Above that is Alt and AltGr ?
OK, on non-US layout it's quite normal to have only one Alt because (the need) of AltGr.
All on the outside for the weak pinky ?

Shift is the up-arrow below 'W' ?
What is to the left of "Shift" ?

What is below "2" ?
A modifier ?
To the right of that is the Spacebar with Enter/Return on layer 2 ?
No Enter/Return in reach for touch typers on layer 1?

The darker colored dots are LEDs for visualize the selected layer ?
So you can lock 'Alt'-layer ?

For simpler discussion more default symbols should be used (later for production of course your favorite icons/symbols).

Where are your home positions for all fingers ? HIEA ? STNR ?
It looks like home of right thumb is "Shift" but left thumb is not on "Spacebar" as home, but spaces are more often then shifted keys.



Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2016-Oct-26 14:41
The sailers wheel is Crtl ?

Yes.
Please see Xah Lee's page: http://xahlee.info/comp/unicode_computing_symbols.html

Above that is Alt and AltGr ?
OK, on non-US layout it's quite normal to have only one Alt because (the need) of AltGr.
All on the outside for the weak pinky ?

No, that's CapsLock and Tab. Keyboard Layout Editor doesn't have Rounded Rectangle A (because I could not find it in Unicode) so I used A in Circle instead. I don't like the arrow version.
These are less-used keys on the pinky.

The top left key in OS/Windoze + Menu + Esc.... all little-used by most people. Some specialist programs (apparently Emacs or Vim) use Menu a lot, but I can't design for every use case.

Shift is the up-arrow below 'W' ?
What is to the left of "Shift" ?

Yes. That's the NumPunc (number punctuation) key, basically a relabeled AltGr.

What is below "2" ?
A modifier ?

Normal Alt key.

To the right of that is the Spacebar with Enter/Return on layer 2 ?
No Enter/Return in reach for touch typers on layer 1?

Yes. That idea comes from Schizo. Remember the left thumb is on that key, and the right thumb is on the NumPunc/AltGr, so you press both together and I don't think it's a problem.... :-)

The darker colored dots are LEDs for visualize the selected layer ?
So you can lock 'Alt'-layer ?

No, it's CapsLock and ScrollLock leds ... no need for NumLock.

For simpler discussion more default symbols should be used (later for production of course your favorite icons/symbols).

That's what I did ... did you read the text on the page? Also the X1 page? http://www.keyboard-design.com/layouts/100/ANSI-104-Ian-X1.html

Where are your home positions for all fingers ? HIEA ? STNR ?
It looks like home of right thumb is "Shift" but left thumb is not on "Spacebar" as home, but spaces are more often then shifted keys.

See above pages. Home is:
HIEA Space  NumPunc STNR

You could maybe read the posts in this forum from Schizo, and the discussion around his ideas. It's one of the things that encouraged Den to produce the different scoring system, taking finger strength into account.
Schizo took Arensito layout ideas to new places, and we built on that. I took those ideas and put them onto Den's BEAKL 4 as modified by me, which was already a very strong layout, particularly at English, and it's currently at X1 layout.

Patrick's scoring puts my AltGr 3 layout above the X1, while Den's scoring swaps them around. But Patrick's scoring on these AltGr layouts looks a bit wrong... it appears that the more keys you use, the higher the score.
I'll build a page showing the AltGr 3 layout in the next few days. Here's a comparison on Alice.
http://patorjk.com/keyboard-layout-analyzer/#/load/v7vGTccS
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2016-Oct-26 14:47
In truth, if we could find a way to make KLA work with the I-Board physical layout, the scores will be even higher than on ErgoDox, because of the key sizes.
Title: Re: Balanced Keyboard Layout
Post by: Den on 2016-Oct-26 14:58
In truth, if we could find a way to make KLA work with the I-Board physical layout, the scores will be even higher than on ErgoDox, because of the key sizes.

The keyboards are simply another set of JSON objects. So you define new keyboard layout and have the Configuration page accomodate it.
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2016-Oct-26 15:35
@daaawooo : I'm focusing on English because that's what I use. German/Scandinavian/French/Spanish etc layouts are going to have different requirements... particularly as regards AltGr usage.

I use Linux, about the only times I need accented letters are when I'm working in HTML, and then I use entity-encoding like &eacute; to get é etc. which I just did with Linux's "compose" key function, which is missing from my X1 layout... have to figure out where I can put it. At present on this MS Natural keyboard I have set the left Win key to be "compose".
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2016-Oct-26 15:38
The keyboards are simply another set of JSON objects. So you define new keyboard layout and have the Configuration page accomodate it.

Guess I will have to take a look at that sometime then... :-)
Maybe on the weekend.
Title: Re: Balanced Keyboard Layout
Post by: Den on 2016-Oct-26 16:05
Guess I will have to take a look at that sometime then... :-)
Maybe on the weekend.

Actually you have to supply an image for the heat map. Configuration page might be auto generated based on JSON definitions.
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2016-Oct-26 16:25
Actually you have to supply an image for the heat map. Configuration page might be auto generated based on JSON definitions.

Yeah I was just looking at that page now... printed our the ErgoDox part to use as a template. Have you been able to figure out what the s683_225 means here:

KB.keyMap.standard.s683_225 = {};
KB.keyMap.standard.s683_225.width = 754;//756
KB.keyMap.standard.s683_225.height = 252;//254

KB.keyMap.ergodox.s683_225 = {};
KB.keyMap.ergodox.s683_225.width = 935;
KB.keyMap.ergodox.s683_225.height = 360;

The 935 and 360 are on-screen pixel dimensions, etc. Maybe the numbers were from a previous version that he tweaked? eg 745 -> 683, 252 -> 225 ?
Title: Re: Balanced Keyboard Layout
Post by: Den on 2016-Oct-26 16:45
Yeah I was just looking at that page now... printed our the ErgoDox part to use as a template. Have you been able to figure out what the s683_225 means here:

KB.keyMap.standard.s683_225 = {};
KB.keyMap.standard.s683_225.width = 754;//756
KB.keyMap.standard.s683_225.height = 252;//254

KB.keyMap.ergodox.s683_225 = {};
KB.keyMap.ergodox.s683_225.width = 935;
KB.keyMap.ergodox.s683_225.height = 360;

The 935 and 360 are on-screen pixel dimensions, etc. Maybe the numbers were from a previous version that he tweaked? eg 745 -> 683, 252 -> 225 ?

It's some hardcoded figure. Not sure what it means, but just use the same name for compatibility.
Title: Re: Balanced Keyboard Layout
Post by: daaawooo on 2016-Oct-26 17:50
Please see Xah Lee's page: http://xahlee.info/comp/unicode_computing_symbols.html
Ah thanks, I knew his site but not this specific page.
There is a big gap between theory, standards, real life, present, history ...
After reading the page 4 words/phrases are stuck in my brain:
- sometimes
- suggestion(s)
- but is rarely used
- I haven't seen

As for the hype/lifestyle of mechanical keyboards and keycap sets, those symbols are out of the picture.
People want, design and use keycaps with written labels like: super, hack, meta, ...
or novelty keycaps with everything on it but not the unicode symbols.


Yes. That idea comes from Schizo. Remember the left thumb is on that key, and the right thumb is on the NumPunc/AltGr, so you press both together and I don't think it's a problem.... :-)
Sounds like high effort to me.
May strongly differ if you:
- write prose
- write code
- just want to confirm a lot of dialogs, execute actions e.g. using a filecommander or old school editor

For me:
I use Total Commander instead of Explorer doing my file stuff, most keys/combos used in such a session are: cursor up, cursor down, del, ins, tab, enter, backspace, space, esc, f5, f6, f3, f4, f7, home, end, page up, page down, alt+f1, alt+f2, ctrl+f3, ctrl+f4, ctrl+f5, ctrl+6, numpad *, alt+numpad+, alt+numpad-, alt+f7, ctrl+m, alt+f9, alt+f5, up to 3 letters (to quickly jump to files/folder starting with this letter combination) ... no mouse.



That's what I did ... did you read the text on the page? Also the X1 page? http://www.keyboard-design.com/layouts/100/ANSI-104-Ian-X1.html
No, because my future will be strictly ergo, but now I see your X1 has classic written labels and also explains the missing 'Enter'.


I'll build a page showing the AltGr 3 layout in the next few days. Here's a comparison on Alice.
http://patorjk.com/keyboard-layout-analyzer/#/load/v7vGTccS
The 2168 Presses of 'Enter' are 'space' and space+altgr for 'enter' together ?
In German for prose 'space' and 'e' are quite head to head and 'enter' should be quite low in the rank.
For code 'space' easily takes the lead (of visible chars, with non visibles like enter or tab it's depending on code language).


@daaawooo : I'm focusing on English because that's what I use. German/Scandinavian/French/Spanish etc layouts are going to have different requirements... particularly as regards AltGr usage.
My daily work/usage is two-thirds English, one-third German, so usage of äöü߀... are not that high.
Title: X1 Ergodox
Post by: iandoug on 2016-Oct-28 06:32

X1 in Ergodox form factor.

http://patorjk.com/keyboard-layout-analyzer/#/load/9vm0gnGj
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2016-Oct-28 06:34
I'll put those Ctrls back in a more traditional place ... won't affect scoring.
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2016-Oct-28 17:14
Guess I will have to take a look at that sometime then... :-)
Maybe on the weekend.

Okay, got it working "basically" on your version of KLA. Not entirely happy with it as I had to kludge the last Ctrl key.
I basically took the Ergodox object, created a new one, and made it look how I wanted it to. I tried replacing the rotate code with the section from the standard layout, but that didn't want to work, so reverted to the Ergodox code for now.

This section:

KB.keySet.ergolinear.x1 = {
    "label": "X1 Ergolinear",
    "fingerStart": {
        "1": 13,
        "2": 14,
        "3": 15,
        "4": 16,
        "5": 38,
        "6": 20,
        "7": 19,
        "8": 20,
        "9": 21,
        "10": 22,
        "11": -1,
        "false": -1
    },
    "keyboardType": "ergodox",
    "author": "Ian Douglas",
    "authorUrl": "",
    "moreInfoUrl": "",
    "moreInfoText": "X1 ErgoLinear",
    "keys": [

works, but if I switch keyboardtype to ergolinear (as per the name of the object) then it barfs. So I guess that the types are defined/used somewhere that I haven't found yet (currently hacking kb.js.download).

Good news is that the heat map works automagically.

Scoring (on your scoring) is as expected, slightly better than X1 on ErgoDox, just because the keys are tighter together, I suppose.

Screenshots follow.

ToDo:
1. get rid of the rotation code.
2. find a way to label the Insert key... I modified Patrick's hard-coded conversions from u:xx to words but it gets confused with the dash character. Same with the code for Menu. I'll have to use non-standard high ascii or something... oh wait, maybe negative numbers will work... will try later.
3. Don't know if I should stick the centre numpad in for "completeness" or just leave it out as an unnecessary complication/confusion to users. See screenshot of compact X1. descended from I-Board layout.

Actually made a mockup of that pic, with keys stuck on to see how it feels to type. Might swap the Alts and space/shift around, feels more natural under the thumbs that way.

Scores were on Putin I think ... was testing various things. Heatmap may be from Typing Champ 2.



Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2016-Oct-28 17:42
Using u:-xx works to set the text on the keys, after adding entry in key.js.download.

My thing is only half-working ... the hard-coded default layout works, but not pasting in (or presumably loading from menu).

Think it's related to the keyboardtype issue above, I see I need to add some code at the top of kb.js.download to handle the new layout type.
Title: Re: Balanced Keyboard Layout
Post by: Den on 2016-Oct-28 21:15
a minor change that would be very helpful is to print the "Space" on the keyboard. 

add this at end of key.js.download:
Code: [Select]
KB.Key.labels[32] = "Space";

you might as well fill out the bottom row. for extra keys, like arrows and page control.
Title: Re: Balanced Keyboard Layout
Post by: Den on 2016-Oct-28 21:41
don't forget the KB.glyphLayouts part at the top of kb.js
Title: Re: Balanced Keyboard Layout
Post by: Den on 2016-Oct-28 23:46
better to copy from Standard layout. it's much simpler, doesn't involve rotation. then erase anything to do with variable key width.
Title: Re: Balanced Keyboard Layout
Post by: Den on 2016-Oct-29 01:07
Updated my analyzer (http://shenafu.com/code/keyboard/Keyboard%20Layout%20Analyzer.html#/config)

try it out and send me your layouts to be uploaded

see images
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2016-Oct-29 04:21
Updated my analyzer (http://shenafu.com/code/keyboard/Keyboard%20Layout%20Analyzer.html#/config)

try it out and send me your layouts to be uploaded

see images

For these, you need to swap AltGr and RShift ... scores will be better. Don't need AltGr in these setups.

Oh wait. scratch that ... you have Enter on AltGr. Mmm that's a puzzle.
Title: Re: Balanced Keyboard Layout
Post by: Den on 2016-Oct-29 05:24
it was put together quickly to test new layout. not worried about that prototype's score. nevertheless it does show some tiny improvement. probably bigger effect on worse layouts. (mainly due to thumb modifiers.)
Title: Nav keys
Post by: iandoug on 2016-Oct-29 07:59
Been contemplating the nav keys ... on for example BEAKL34 ErgoLinear I would put them

Home Left Right End            Pageup Up Down Pagedown

What I like about it is that it gets rid of part of the centre block ... on the other hand you now need two hands to work the arrows ...

I will pay attention to how I use the arrows, eg what my left hand is doing at the time. It is easier to drop the hands back a bit than to move to the centre. But again, on the other hand, if you are using the numpad, then having the arrows and Home/End//Pageup/Pagedown close by is convenient.

I had trouble getting kb.js to indent the top row of keys. It seemed to ignore that directive, but was happy to leave a space between the other keys as instructed.

This ergolinear layout will probably suck for gamers. I might need to bring the F keys back, even though they are hardly used. I use F2 (edit in my file manager). F3 (next) and Alt-F4 (close window) and that's about it. Okay, sometimes F1.... :-)
But hitting Alt+AltGr+4/F4 seems a bit awkward.
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2016-Oct-29 08:44
Updated my analyzer (http://shenafu.com/code/keyboard/Keyboard%20Layout%20Analyzer.html#/config)

Trust you didn't change the scoring? :-)
Title: Re: Balanced Keyboard Layout
Post by: Den on 2016-Oct-29 15:27
Trust you didn't change the scoring? :-)

Not that i remember. Havent touched in a while.
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2016-Oct-29 16:17
[grateful I don't have to redo the scoring... :-) ]

Been trying to make the test name (well, the file name, for now) print on the results page.

It is set in controllers.js around line 220 and put in $scope.data.textPreset
However when I try to persuade Angular to print it on the results page, it is empty.
(templates.js around line 657)

I guess this is some sort of Scope issue, and presumably the results code can no longer see it....
I tried setting a normal JS variable to that value in controllers.js, but that's also not visible at results time.

Scope in JS looks even more complex than scope in Ada....
Title: Ergoliniear
Post by: iandoug on 2016-Oct-29 19:01
Something is not right.

After lots of fun and games I eventually got your KB.keyMap.ergolinear working here (instead of the modified Ergodox version I was using.) I took a while to discover that you had made other changes to the file... :-)

However the scoring on this version is worse than on the same layout on Ergodox. Also the distance figures are higher.

So that leaves me with two possibilities (AFAICS).

1. there's a bug in Patrick's Ergodox code, which may also explain the substantially higher scores on Ergodox layouts, or
2. there's a bug in the changes you made.

I'm guessing it is to do with determining the centre of each key, for distance measuring purposes.

Comparisons:
X1 on Ortholinear using modified Ergodox map, vs X1 or Ergodox, vs X1 on Ortholinear using your map:
Alice scores:
97.27   :   97.59  :  99.71  (cf X1 on ANSI gets 98.67)
Alice distances:
28052 :  28205  :  29240  (cf X1 on ANSI gets 28641)

Here's what I was using before: (the hack for the rotated Ctrl key is first entry in var tCoords = )

// Key Map for ErgoLinear

KB.keyMap.ergolinear = {};

// 50 pixels = 1.9cm
// 26.315789 pixels = 1cm
KB.keyMap.ergolinear.s683_225 = {};
KB.keyMap.ergolinear.s683_225.width = 792;
KB.keyMap.ergolinear.s683_225.height = 197;
KB.keyMap.ergolinear.s683_225.pixelsPerCm = 25.7894732;//26.315789;
(function() {
    var ii,
        km = KB.keyMap.ergolinear.s683_225,
        normKeySize = 50,
        row,
        keyCount = [12,12,12,6],
        index = 0,
        curX = 0.5,//2.5
        curY = 0.5,//2.5
        keyWidths = {};

    km.leftX = curX;
    km.leftY = curY;

    var sw = 46;
    var sh = 46;
    var sSpacing = 2;

    function keySpacing(key) {
        var keyOffset = {};
        keyOffset[6] = 214;
        keyOffset[18] = 214;
        keyOffset[30] = 214;
        keyOffset[37] = 194;
        keyOffset[39] = 118;

        // keys that begin a row
        keyOffset[0] = 0;
        keyOffset[12] = 0;
        keyOffset[24] = 0;
        keyOffset[36] = 0;

        var ret = (typeof keyOffset[key] !== 'undefined') ? keyOffset[key] : sSpacing;

        return ret;
    }

    var idx = 0;
    var yOffset = [
        [0, 0, 0, 0, 0, 0,         0, 0, 0, 0, 0, 0],
        [0, 0, 0, 0, 0, 0,         0, 0, 0, 0, 0, 0],
        [0, 0, 0, 0, 0, 0,         0, 0, 0, 0, 0, 0],
        [0,             0, 0,   0, 0               ]
    ];

    var rowY = [
        0,
        0 + sh + sSpacing,
        0 + sh + sSpacing + sh + sSpacing,
        0 + sh + sSpacing + sh + sSpacing + sh + sSpacing,
        0 + sh + sSpacing + sh + sSpacing + sh + sSpacing + sh + sSpacing
    ];

    var keyWidth = {}; // these keys are all 1u
    var keyHeight = {}; // these keys are all 1u

    var rotation = {};

    var xOffset = 0;
    var yPos = 0;
    var row, col;
    var idx = 0;

    for (row = 0; row < yOffset.length; row++) {
        for (col = 0; col < yOffset[row].length; col++) {
            if (col === 0) {
                xOffset = 0;
            } else {
                xOffset = xOffset + (keyWidth[idx-1] || sw);
            }
            xOffset += keySpacing(idx);

            km[idx] = {};
            km[idx].x = xOffset + 0.5;
            km[idx].y = rowY[row] + yOffset[row][col] + 0.5;
            km[idx].w = keyWidth[idx] || sw;
            km[idx].h = keyHeight[idx] || sh;
            km[idx].row = row;

            idx++;
        }
    }

    var rotatePoint = function(angle, aroundPoint, rotatingPoint) {
        var s = Math.sin(angle);
        var c = Math.cos(angle);

        rotatingPoint.x -= aroundPoint.x;
        rotatingPoint.y -= aroundPoint.y;

        var newX = rotatingPoint.x * c - rotatingPoint.y * s;
        var newY = rotatingPoint.x * s + rotatingPoint.y * c;

        rotatingPoint.x = newX + aroundPoint.x;
        rotatingPoint.y = newY + aroundPoint.y;
    }

    var tCoords = [
        {x: 741, y: 145, r: 0},
        {x: 422, y: 200, r: 0.45},
        {x: 313, y: 203, r: 0.45},
        {x: 357, y: 224, r: 0.45},
        {x: 401, y: 245, r: 0.45},
        {x: 380, y: 289, r: 0.45},

        {x: 466, y: 220, r: -0.45},
        {x: 510, y: 199, r: -0.45},
        {x: 487, y: 265, r: -0.45},
        {x: 508, y: 309, r: -0.45},
        {x: 531, y: 244, r: -0.45},
        {x: 575, y: 223, r: -0.45}
    ];
    for (ii = 0; ii < tCoords.length; ii++) {
        km[idx] = {};
        km[idx].x = tCoords[ii].x;
        km[idx].y = tCoords[ii].y;
        km[idx].w = keyWidth[idx] || sw;
        km[idx].h = keyHeight[idx] || sh;
        km[idx].row = 4;
        km[idx].coords = [
            {   x: km[idx].x,                 y: km[idx].y },
            {   x: km[idx].x + km[idx].w,     y: km[idx].y },
            {   x: km[idx].x + km[idx].w,     y: km[idx].y + km[idx].h},
            {   x: km[idx].x,                 y: km[idx].y + km[idx].h}
        ];
        rotation[idx] = tCoords[ii].r;
        rotatePoint(rotation[idx], km[idx].coords[0], km[idx].coords[1]);
        rotatePoint(rotation[idx], km[idx].coords[0], km[idx].coords[2]);
        rotatePoint(rotation[idx], km[idx].coords[0], km[idx].coords[3]);

        km[idx].mountPoint = {};
        km[idx].mountPoint["top"] = {};
        km[idx].mountPoint["right"] = {};
        km[idx].mountPoint["bottom"] = {};
        km[idx].mountPoint["left"] = {};

        var xSum = 0, ySum = 0;
        for (var cc = 0; cc < km[idx].coords.length; cc++) {
            xSum += km[idx].coords[cc].x;
            ySum += km[idx].coords[cc].y;
        }

        km[idx].mountPoint["top"].x = xSum / km[idx].coords.length;
        km[idx].mountPoint["top"].y = ySum / km[idx].coords.length;
        km[idx].mountPoint["right"].x = xSum / km[idx].coords.length;
        km[idx].mountPoint["right"].y = ySum / km[idx].coords.length;
        km[idx].mountPoint["bottom"].x = xSum / km[idx].coords.length;
        km[idx].mountPoint["bottom"].y = ySum / km[idx].coords.length;
        km[idx].mountPoint["left"].x = xSum / km[idx].coords.length;
        km[idx].mountPoint["left"].y = ySum / km[idx].coords.length;

        idx++;
    }

    km.rotation = function(idx) {
        if (rotation[idx]) {
            return rotation[idx];
        }
        return 0;
    };

    for (index = 0; index < idx; index++) {

        if (km[index].coords) {
            var xSum = 0, ySum = 0;
            for (var cc = 0; cc < km[index].coords.length; cc++) {
                xSum += km[index].coords[cc].x;
                ySum += km[index].coords[cc].y;
            }
            km[index].cx = xSum / km[index].coords.length;
            km[index].cy = ySum / km[index].coords.length;
        } else {
            km[index].cx = km[index].x + (km[index].w/2);
            km[index].cy = km[index].y + (km[index].h/2);
        }

        // set the mount points - these are points where dialogs will attach to keys
        // all our keys are squares, so this is simple
        if (typeof km[index].mountPoint === 'undefined') {
            km[index].mountPoint = {};
            km[index].mountPoint["top"] = {};
            km[index].mountPoint["right"] = {};
            km[index].mountPoint["bottom"] = {};
            km[index].mountPoint["left"] = {};

            km[index].mountPoint["top"].x = km[index].x + (km[index].w/2);
            km[index].mountPoint["top"].y = km[index].y;
            km[index].mountPoint["right"].x = km[index].x + km[index].w;
            km[index].mountPoint["right"].y = km[index].y + (km[index].h/2);
            km[index].mountPoint["bottom"].x = km[index].x + (km[index].w/2);
            km[index].mountPoint["bottom"].y = km[index].y + km[index].h;
            km[index].mountPoint["left"].x = km[index].x;
            km[index].mountPoint["left"].y = km[index].y + (km[index].h/2);
        }
    }
})();
// End keymap ergolinear
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2016-Oct-29 19:07
The scores on your version should be fractionally higher than what I had, since I had like a 1 pixel space between keys, which you don't have.
Title: Re: Balanced Keyboard Layout
Post by: Den on 2016-Oct-29 20:13
the pixelsPerCm might not be accurate on my map. if you use the same value as Standard, the scores improve a bit.

the gap between keys shouldn't matter. it's the total distance between keys. e.g. the default normKeySize is 50 and no gap = 50. but i can make the  normKeySize 48 and gap 2 = 50 still. the total distance remains the same.

Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2016-Oct-30 04:22
Mmm. Okay I thought that maybe I had screwed up the transference of your code into my code, so I ran the tests on your live side with the same results.

#1 X1 Ergodox 97.59 +0%
#2 X1 ANSI    98.67  +1%
#3 X1 Ergolinear 99.71 +2%

I see the pixels/cm are different. That is curious.. should they not be all the same?

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;

Think I will ask Patrick about that....

And then you set
KB.keyMap.ergolinear.s683_225.pixelsPerCm = 25.315789;

Was that a typo or did you mean 25 not 26?

thanks, Ian
Could not sleep last night. Hate it when lines of code get the better of me.
Title: Re: Balanced Keyboard Layout
Post by: Den on 2016-Oct-30 06:50
I see the pixels/cm are different. That is curious.. should they not be all the same?

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;

Think I will ask Patrick about that....

And then you set
KB.keyMap.ergolinear.s683_225.pixelsPerCm = 25.315789;

Was that a typo or did you mean 25 not 26?

I looked at difference between standard and ergodox and thought that wider layout should have lower PPC. But actually dont understand their relationships. We need to delve deeper.
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2016-Oct-30 07:10
I looked at difference between standard and ergodox and thought that wider layout should have lower PPC. But actually dont understand their relationships. We need to delve deeper.

I have asked Patrick. I suspect (well, it would be logical) it should be the same for all layouts, which means I'll have to redo my scores for the Ergo layouts. Which may lead to issues with my version being out of sync with Patrick's live version. Hopefully he's update the live version.

I think when I was playing around I first tried the standard code (and that pixels/cm), then swopped out the bottom part for the ergo code because that allowed me to specify the gap between the keys. I still don't understand how your code works to create the gap... it seems almost like it's building it from the outsides in :-)

I should start using git on these pages so I can track what I do.

Title: Re: Balanced Keyboard Layout
Post by: Den on 2016-Oct-30 09:17
I think when I was playing around I first tried the standard code (and that pixels/cm), then swopped out the bottom part for the ergo code because that allowed me to specify the gap between the keys. I still don't understand how your code works to create the gap... it seems almost like it's building it from the outsides in :-)

The layout is symmetrical, so split the loop in half. The offset for left-half is obvious due to coordinates system. Zero starts at the left and top. So left-half rows all start at zero + any border offset.

Then the reverse is true for right-half: right-half rows all align at the right edge = max width. For computational efficiency inside the loop (simplest math operation is addition) find the leftmost offset of the current row in the right-half, then build the remaining keys left to right.
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2016-Oct-30 09:35
The layout is symmetrical, so split the loop in half. The offset for left-half is obvious due to coordinates system. Zero starts at the left and top. So left-half rows all start at zero + any border offset.

Then the reverse is true for right-half: right-half rows all align at the right edge = max width. For computational efficiency inside the loop (simplest math operation is addition) find the leftmost offset of the current row in the right-half, then build the remaining keys left to right.

Thanks, will look at it again with that insight.  In truth the addition in the second loop was what confused me ... I was expecting subtraction, if building from right edge (which also didn't make sense because then the indexes of the keys would get messed up ... so total confusion :-) )

However that only works for your layout with full bottom rows, if there are gaps like in mine then we need to use Ergodox approach, AFAICS.

Am going to put this stuff on hold a bit until I hear back from Patrick.

Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2016-Oct-31 17:43
https://github.com/patorjk/keyboard-layout-analyzer/issues/11
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2016-Nov-01 16:35
So for the first time I take a good look at Aus der Neo-Welt ... and was quite surprised to see a lot of familiar features ... from where the comma and period are, to the punctuation on AltGr, and all the Greek letters and other punctuation, often on the same keys I put them on the previous versions of my Programmers Keyboard ... even the home row to an extent ..... I'm sure I dabbled in AO at some point but decided the bigram was too common in English (probably less common in German/Dutch), while OE is very common.

Given it was programmatically generated we should take that as confirmation we're on the right track :-)
Title: Re: Balanced Keyboard Layout
Post by: Den on 2016-Nov-02 05:29
I corrected PPC for ergolinear back to match Standard: 26.315789. This should improve scores for ergolinear layouts.

AdNW of course is pretty good, since it belongs to the current reigning family of layouts: HIEA-STR.

Actually OA/AO is not common at all: a mere 0.05%. OE/EO together is 0.04%.

Xah had an idea to find the best the layout that incorporates all the common languages of the world. including English, Chinese, European, etc. That could be interesting. From isolated informal testing, HIEA-STR tend to do very well across most languages. Probably due to Dvorak's breakthrough idea to split the keyboard into vowel and consonant districts, which is easily adaptable and efficient due to nature of spelling in most languages.
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2016-Nov-02 05:46
I corrected PPC for ergolinear back to match Standard: 26.315789. This should improve scores for ergolinear layouts by a tiny bit.

Yeah I did the same on the version I have here, now need to doublecheck a few things... I had Ergo set to same as Standard which I now know is wrong.

Actually OA/AO is not common at all: a mere 0.05%. OE/EO together is 0.04%.

I see I closed my bracket too quickly... I meant OE is common in German/Dutch, not English.
Re OA/AO probably some comparative testing showed me other options better... when it comes to bigrams I see how many words pop into my head (and I had soar and roar and roam etc... ) so possibly I thought it was too common.

Xah had an idea to find the best the layout that incorporates all the common languages of the world. including English, Chinese, European, etc. That could be interesting.

Interesting yes, doable, I doubt... :-)
Also why? You may type in English and Chinese, but I'll type English and maybe Afrikaans on occasion. Afrikaans is mostly the same character set as English, just makes more use of accented characters like ë ê é è etc. At least no ß.

Okay, I see you specified "Common" ... so where does that leave us? Chinese, English and Spanish? Maybe French? Hindi? Arabic? Going to be a challenge :-)

Cheers, Ian

Title: Re: Balanced Keyboard Layout
Post by: Den on 2016-Nov-02 06:07
Xah wanted a universal layout that can be used efficiently everywhere in the world.

It's not that difficult when you consider that BEAKL already scores so well in English, French, German, and Pinyin. (You can get corpus of various languages by browsing wikipedia in different languages. I got Pinyin corpus from lyrics of Chinese songs.)

Accented letters can be served with AltGr tailored to each language.
Title: Re: Balanced Keyboard Layout
Post by: daaawooo on 2016-Nov-02 13:35
I see I closed my bracket too quickly... I meant OE is common in German/Dutch, not English.

OE and EO not common in German, look at "deutsch.txt.2" in opt.7z (from those adnw people).

Your X1 ergo does well with a mixed corpus of English, C, Assembler (6502, 68k) and German.

Edit: But I do not like the concept of AltGr-Space for Enter.
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2016-Nov-02 14:56
OE and EO not common in German, look at "deutsch.txt.2" in opt.7z (from those adnw people).

Found this, you are right, I am surprised. Also about use in Dutch.  I can think of quite a few words in Afrikaans that have oe. Maybe they're not commonly used enough.
http://practicalcryptography.com/cryptanalysis/letter-frequencies-various-languages/german-letter-frequencies/

Unfortunately they don't have similar for Dutch  (but do have a few other languages if you're interested :-) )
Another URL for future reference:
https://www.uow.edu.au/~dlee/software.htm  (scroll down to word lists)

Your X1 ergo does well with a mixed corpus of English, C, Assembler (6502, 68k) and German.

Geez when last did I do 6502 assembler?... :-) Think my Atari 800 had that chip. Writing vertical interrupts to move things on screen....

Edit: But I do not like the concept of AltGr-Space for Enter.

Likewise, I was actually thinking about it today while driving... in particular, the fact that you need two hands to make it work. Not cool. But the scoring shows that it makes sense, somehow. Maybe only mathematically and not practically.

Have also made some tweaks to the nums and puncs in X1, on Ergolinear, which got consistently better scores than current version. Results on ANSI may be different due to key staggering etc. Will do some more tests and then share.
Difference was typically not much ( eg like 0.1 to 0.2, except on some of the date or number tests, where it was much better. But the little bits add up to better average.)

Cheers, Ian

Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2016-Nov-02 15:01
Your X1 ergo does well with a mixed corpus of English, C, Assembler (6502, 68k) and German.

You should include Arensito Ergo in your panel. It's where the whole AltGr thing started (well for me, anyway). So we always compare against it. However Arensito does not do the best in English, which knocks it down in anything with normal English words (as opposed to numbers and punctuation).
Title: Re: Balanced Keyboard Layout
Post by: daaawooo on 2016-Nov-02 17:02
You should include Arensito Ergo in your panel. It's where the whole AltGr thing started (well for me, anyway). So we always compare against it. However Arensito does not do the best in English, which knocks it down in anything with normal English words (as opposed to numbers and punctuation).

mmh, at Den's KLA I found only Arensito Kinesis as preset, but with dedicated 'enter'. Is there a another one ?
How the AltGr is located on this layout, it's very hard to press on my ergodox with my thumbs.


Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2016-Nov-02 17:12
mmh, at Den's KLA I found only Arensito Kinesis as preset, but with dedicated 'enter'. Is there a another one ?
How the AltGr is located on this layout, it's very hard to press on my ergodox with my thumbs.

Yes, same thing,  I couldn't remember the name when I was typing the reply, there is only one layout map in KLA for Ergodox/Kinesis.

I got that layout from the author of Arensito himself, so I can't comment on the practicality of it. I think possibly Ergodox has too many keys on the thumb (or in the wrong spots), and the small ones are supposed to be rarely used, not frequently like an AltGr layout would use them.
http://www.pvv.org/~hakonhal/main.cgi/keyboard
There are some minor differences but he was happy with the layout.
Title: Re: Balanced Keyboard Layout
Post by: daaawooo on 2016-Nov-02 17:19
Found this, you are right, I am surprised. Also about use in Dutch.  I can think of quite a few words in Afrikaans that have oe. Maybe they're not commonly used enough.
http://practicalcryptography.com/cryptanalysis/letter-frequencies-various-languages/german-letter-frequencies/

Unfortunately they don't have similar for Dutch  (but do have a few other languages if you're interested :-) )
Another URL for future reference:
https://www.uow.edu.au/~dlee/software.htm  (scroll down to word lists)

Slight differences but generally the same for German.
The opt.7z from adnw.de also counts "space" into n-grams. For default he uses a corpus explained at page 35 (in English) of Anleitung.pdf.
But you can specify your own corpus and n-grams gets calculated.

Geez when last did I do 6502 assembler?... :-) Think my Atari 800 had that chip. Writing vertical interrupts to move things on screen....

Yeah, this old times with VBI, DLI, Players, Missiles ;-)

Likewise, I was actually thinking about it today while driving... in particular, the fact that you need two hands to make it work. Not cool. But the scoring shows that it makes sense, somehow. Maybe only mathematically and not practically.
Current scoring strongly favors less finger movement even it results in usage of modifiers.

Title: Re: Balanced Keyboard Layout
Post by: daaawooo on 2016-Nov-02 17:31
I think possibly Ergodox has too many keys on the thumb (or in the wrong spots), and the small ones are supposed to be rarely used, not frequently like an AltGr layout would use them.
http://www.pvv.org/~hakonhal/main.cgi/keyboard
AltGr, Alt, Ctrl, Meta, Menu are on those hard to reach keys.
Arensito or your X1 Ergo aside here my personal findings of thumbs usage on ergodox.

Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2016-Nov-02 17:40
AltGr, Alt, Ctrl, Meta, Menu are on those hard to reach keys.
Arensito or your X1 Ergo aside here my personal findings of thumbs usage on ergodox.

Why is Control hard to reach? I can understand the other small ones.

I'm asking because of the Backspace/Delete keys here:
http://www.keyboard-design.com/layouts/ergo/75/x1-ergo-compact.html

I have a lifesize mockup and they don't SEEM to be hard to reach, although you do need to move your hand a bit.
Above design has changed a bit, but those keys still the same.
Title: Re: Balanced Keyboard Layout
Post by: daaawooo on 2016-Nov-02 18:38
Why is Control hard to reach? I can understand the other small ones.

I'm asking because of the Backspace/Delete keys here:
http://www.keyboard-design.com/layouts/ergo/75/x1-ergo-compact.html

I have a lifesize mockup and they don't SEEM to be hard to reach, although you do need to move your hand a bit.
Above design has changed a bit, but those keys still the same.

(Using a wrist pad and) my thumb is horizontal, already fully stretched hovering over SHIFT or ALT (left/right thumb on X1 ergo).
So I can not extend the thumb even more to reach for a farther key (= Ctrl on X1 ergo).
To do that I need to bend my wrist to the inside, which I would rate as a high effort.

If Backspace and Delete ranked not that high, this should not be a problem.

Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2016-Nov-03 18:40
Your X1 ergo does well with a mixed corpus of English, C, Assembler (6502, 68k) and German.

The -+T+- HT01 does better at English (so far, in the tests I've done).
http://www.keyboard-design.com/layouts/ergo/75/Ergo--+T+-HT01-75.54.html

If you ever find yourself testing it, I would be interested in your findings... :-)

Thanks, Ian
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2016-Nov-04 10:43
The -+T+- HT01 does better at English (so far, in the tests I've done).
http://www.keyboard-design.com/layouts/ergo/75/Ergo--+T+-HT01-75.54.html

If you ever find yourself testing it, I would be interested in your findings... :-)

Started playing with this a bit, trying to put the X1 key layout on. Eventually ended up putting the T on the left thumb.

This gets better scores on Den's scoring, but not on Patrick's. Down to the low low 90s now on Alice.

#1 -+T+- HT02 90.58 +0%
#2 -+T+- HT01-75.54 91.63 +1% (like (3) with single Shift key)
#3 -+T+- HT01 orig 94.42 +4%
#4 X1 Ergolinear 97.44 +8%
#5 MTGAP Thumbshift 104.03 +15%

Wonder how the scoring handles typing "T'.... Den?


Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2016-Nov-04 14:58
Revised. Now below 90. But still not better on Patrick's scoring.

#1 -+T+- HT02a 89.42 +0%
#2 -+T+- HT01-75.54 94.42 +6%
#3 X1 Ergolinear 97.44 +9%
#4 X1 Ergo 97.59 +9%
#5 MTGAP Thumbshift 104.03 +16%
#6 Colemak Thumbshift 105.82 +18%

Patrick's scoring (plus layout).
http://patorjk.com/keyboard-layout-analyzer/#/load/cQPHLxQN
Title: Re: Balanced Keyboard Layout
Post by: daaawooo on 2016-Nov-04 16:28
The -+T+- HT01 does better at English (so far, in the tests I've done).
http://www.keyboard-design.com/layouts/ergo/75/Ergo--+T+-HT01-75.54.html
If you ever find yourself testing it, I would be interested in your findings... :-)

For my mixed corpus X1 beats -+T+- HT01 and HT02a with a big gap, like all the other ones without AltGr+Space for Enter.
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2016-Nov-04 17:50
For my mixed corpus X1 beats -+T+- HT01 and HT02a with a big gap, like all the other ones without AltGr+Space for Enter.

You have code in your corpus, these +T+ layouts have not paid attention to that yet... :-)
That's why I'm only testing against English at the moment.

The original is one of the first that I did, when I was playing with KLA and I think one of Den's layouts, or possibly MTGap or HIEAMSTRN. Can't remember.

Am pondering if it is possible to do an AltGr trick while still keeping the H or T on the thumb ... but then the thumb will likely be doing a lot of work if I put space and Enter on same key. Then I can move punctuation onto the keys and scores on programming and other technical tests will go up.
Title: Re: Balanced Keyboard Layout
Post by: Den on 2016-Nov-05 04:59
As lazy typist, bottom row feels better and faster. The top row requires slight movement of entire arm to reach. Whereas bottom row can be typed simply by curling the fingers.

I'll test some adjustment to effort grid and see if Opt gives different layout. Sometimes changes to these values have no impact on optimal layout. I'll make bottom ring finger more favorable than top ring finger. Likewise, bottom inside index preferred over than top inside index. Overall weight of layout will tend toward bottom row to facilitate my lazy style.
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2016-Nov-05 05:33
If I remember correctly, Patrick's scoring favours the top row over the bottom ... so one way of boosting score was to simply swap two letters around from bottom to top row. I did that a lot :-)

It doesn't seem to make a difference on your scoring, at least not while I was testing Ergolinear/Ergodox layouts the other day. ANSI is more complex because of the lateral movements as well.
Title: Re: Balanced Keyboard Layout
Post by: Den on 2016-Nov-05 15:51
There's some theory that "sticky keys" for modifiers are healthier than holding and releasing them. This is the style that supertypist Sean Wrona uses. He uses CapsLock instead of shift (unless typing punctuation.)

My proposal is to turn ScrollLock into NumPunc sticky key. First because US keyboards usually don't have AltGr anyway. So I need something common on most keyboards (at least logically). This is separate from NumLock which I use to initiate a ten-key purely for fast numeric entry.

Second this is very easily programmed in autohotkey on Windows, and probably Xorg on Linux as well.

Third as the initial pargraph suggests, this is ergonomic. Especially if one types long strings of puncs, as one might when coding. Then you don't have to hold down AltGr for long periods of time.
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2016-Nov-05 17:14
There's some theory that "sticky keys" for modifiers are healthier than holding and releasing them. This is the style that supertypist Sean Wrona uses. He uses CapsLock instead of shift (unless typing punctuation.)

My proposal is to turn ScrollLock into NumPunc sticky key. First because US keyboards usually don't have AltGr anyway. So I need something common on most keyboards (at least logically). This is separate from NumLock which I use to initiate a ten-key purely for fast numeric entry.

Second this is very easily programmed in autohotkey on Windows, and probably Xorg on Linux as well.

Third as the initial pargraph suggests, this is ergonomic. Especially if one types long strings of puncs, as one might when coding. Then you don't have to hold down AltGr for long periods of time.

Mm. Not opposed to your idea, but scroll lock is not very convenient on ANSI (dunno where it is on Kinesis).

Linux users usually make one of the Windows keys (or Menu) (or even Capslock) into a special key for "Composing" function (to enter special letters and things).

You could probably use it for your purposes as well. I see new keyboards replace the Menu key, for example, with something else ... my mech gamer's keyboard only has one Win key, on left, and right side has WinLock and Function (for bells and whistles on F keys).

Screenshot of Compose key options in KDE. Gnome and cousins are more primitive AFAIK. :-)

Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2016-Nov-05 17:17
@Den

Stumbled across this today, thought you may find it interesting. Would have been more fun optimising the keyboard with three extra letters... :-)

http://blog.dictionary.com/ampersand/
http://blog.dictionary.com/letters-alphabet/
Title: Re: Balanced Keyboard Layout
Post by: Den on 2016-Nov-06 01:19
@Den

Stumbled across this today, thought you may find it interesting. Would have been more fun optimising the keyboard with three extra letters... :-)

http://blog.dictionary.com/ampersand/
http://blog.dictionary.com/letters-alphabet/

alphabets across the world need more vowel letters. pathetic that we mix up 5 vowels to make up 30+ vowel sounds. makes transliteration between languages very cryptic and confusing. OTOH we have redundant consonants like Q and C and X.
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2016-Nov-06 10:45
Yeah oddly enough I was thinking about these things in bed this morning.

I guess at the moment humanity is stuck with:

1. ideographic (East Asian) scripts, requiring a huge number of characters, or
2. Western-style alphabets, manageable number of characters but each character has multiple sounds, depending on other letters in the word.

Neither is ideal.

Then we have the International Phonetic Alphabet, which I have never really come to grips with. In truth I have trouble making my tongue do as they describe :-)
It's also a rather large number of characters, not even sure if they have the clicky sounds that the Bushman or Ndebele tribes rely on. Another thing I can't do properly :-)
https://www.youtube.com/watch?v=Qg4Fp-A7IRw (https://www.youtube.com/watch?v=Qg4Fp-A7IRw)

And lastly we have something like Unifon, which has different versions for different languages, but a more manageable set of symbols (40 for English). Includes different vowel sounds.
(http://www.unifon.org/images/UNIFON%20Eye%20Chart%2050pxpin.jpg)

As I mentioned before I actually added those to a concept keyboard and then dropped them again ...

(http://iandoug.com/wp-content/uploads/2015/06/1.74.jpg)



 my concern is that because they encode pronunciation, it will over time add to the drift between American English and British English, eg dance is going to look different between the 2 variants because of the different ways of doing the "a". Since it's a different character rather than a dropped character (colour/color) it's yet another set of exceptions to code into any program dealing with words.

Unless we can somehow persuade the Yanks to start speaking English again ;-)

Just kidding. The range of accents just in England would also make a strictly-syllabylic spelling problematic. So in some ways the current bizarre English spelling is like Chinese ... the same character gets pronounced differently but the meaning stays the same.
The other problem with Unifon at the moment is the lack of lower case ... some fonts have "small caps" but they still look ugly standing in for lower case.

Cheers, Ian
Title: Re: Balanced Keyboard Layout
Post by: daaawooo on 2016-Nov-06 22:44
hallo Den,

if you already modifying and hosting your version of KLA.
It is possible to add support for other symmetric modifiers ? Currently this is only possible with Shift for Layer 2 - LShift, RShift.
(KLA prefers less finger movement over complex key combos.)
E.g. using AltGr as Layer 3 modifier. But even if I specify multiple AltGr's KLA uses only one.
Modifiers should be symmetric to hit the modifier with one hand and the modified key with the other hand.
Hitting both with one hand results in complex, strange, for some people painful or even impossible combos.


Title: X2
Post by: iandoug on 2016-Nov-07 04:30
So I tried to make X1 have the H on the thumb like the -+T+- layout on Ergodox, wasn't going to well so instead I went in the other direction and migrated the -+T+- layout to ErgoLinear. Made a few tweaks after playing around, will let the pictures do the talking.

Pros: seems to have consistently lowest distance.
Cons: same-finger usage is not the best. Especially for things like quadgrams where there are a lot of H-space/space-H combos.
Overall: score is best overall so far, but not always best for every test.
Only limited  number of tests because that's how far I've got doing all the  layouts with Den's scoring.

ToDo: See if I can optimise right index on X2. Also need to optimise punctuation on X1 v2.


Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2016-Nov-07 04:36
Den, my Ortholinear layouts are slightly different to yours ... you'll need to add two dummy keys to bottom row I think.
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2016-Nov-07 09:26
alphabets across the world need more vowel letters. pathetic that we mix up 5 vowels to make up 30+ vowel sounds. makes transliteration between languages very cryptic and confusing. OTOH we have redundant consonants like Q and C and X.

So I was thinking .... (always a dangerous thing... )

What if we reintroduced some letters.... the thorn for th? The bigram et is not so common, and hi will often bump into th, but the next most common is "in" ... could not find a character with the dot on the left vertical of the n, but there is an n with a centre dot.

So then we could write, for example, "thin" as þṅ if that shows up correctly in your browser....

Point being that we reduce 2 very common bigrams down from 2 letters to 1 letter, and improve efficiency in that way....

The & is already too well known to use as-in but there is a turned version ⅋.

I'll shut up now... :-)

Cheers, Ian
Title: Thumbhack T ....
Post by: iandoug on 2016-Nov-07 14:41

Does very well at English. Not good at technicals, but not an AltGr so that is to be expected. In truth I have not yet tried to optimise the numbers and punctuation beyond what was in the previous version.

People using English on Ergodox are welcome to test :-)

Title: Re: Balanced Keyboard Layout
Post by: parkher on 2016-Nov-07 18:49
Hi,
I just came across this forum and looked it over, sort of :)

I found a couple of "effort grid" pictures.
I really cannot agree with at least a couple of numbers in them. But perhaps they are both out-of-date already?

1. The additional inner column for the index finger. 

3
2
3

or

4
3
4

- the upper row (Y and  F in dvorak) is the easiest to reach because the fingers spread out, especially the index finger and the pinky. I can reach it easily while keeping the other three fingers touching their home keys.
- the home row (I and D in dvorak) requires significant effort or to move/shift the whole hand because the direction is not natural for the index finger.
These are the second hardest keys to reach overall, and, in my opinion,  should have the second highest penalty of all.
- the lower row (X and B in dvorak) is the hardest to reach and should have the highest penalty weight.

Those two keys are the only keys that I cannot comfortably reach while still touching the home keys with other three fingers.
I can reach any other key with any other finger with the rest of the four fingers touching their home keys.
Again: I can reach the top row with relaxed hand and relaxed index finger while other fingers are still on their home keys.
I cannot do so with the home row and bottom row keys: either fingers get tight, or the hand moves slightly.
Obviously, it is better to let the hand move slightly than to get it tight. But for the effort grid it is an important indicator of an additional effort.

I think the numbers for the inner column should be something like:

in the 1-4 system:

3.5
6
9


2. The pinky column:

7
5
7

or

4
1.5
4

Well, the pinky being shorter,  I don't have to curl it much to reach the lower key. It is easier to do than with the ring finger next to it.
So giving it a higher penalty than for the ring finger, or even the same one  - both seem wrong to me. It should have a lower penalty than the ring finger for the lower row.
Well, if there is an additional penalty for the pinky for being a weaker finger, then perhaps...
As to the upper row, the pinky requires more effort than for the lower row and also more effort than the ring finger, obviously. So no disagreement here. Except perhaps about the degree of the effort.
Except that the top key for pinky should have a higher effort number than the bottom key, not the same one. It is more difficult to reach up with a shorter finger, it requires less curling to reach down.
I probably should disclose that on my keyboards (Kinesis Classic and Advantage2)  the pinky column of keys is moved down quite a lot compared to the other columns, therefore to reach up with the pinky is quite easy. It might require more effort with some other keyboards, though (I don't have any to test). Not because of the distance between the keys - it is the same, the whole column is down. But because the initial shape of the pinky on the home key is more comfortable and relaxed and not already reaching up.

So, at least a lower number for the bottom key:

4
1.5
3

But again,  the whole pinky column is much easier than the two lower keys in the inner index finger column and should have lower penalty. 
And the top row of the inner column for me should have lesser penalty than the home row.
My numbers 6 and 9 there are not exactly a joke. They indicate the only keys requiring moving the whole hand.

For full disclosure, I have a couple of other keyboards as well - as in digital pianos :)
They may have caused my pinkys to become a bit stronger and a bit more independent, so I could be somewhat off about the effort required for pinkys.
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2016-Nov-08 12:30
@parkher :

Is this ANSI/ISO or Ergo layout?

Thanks, Ian
Title: VU Keys
Post by: iandoug on 2016-Nov-08 14:12
Den, what do you think of VU Keys layout?

If I just look at how it does on word tests (no punctuation) then it's currently a clear winner on your scoring.

So I was thinking of taking the letter layout, flipping L-R, and adding the punctuation back based on one of the AltGr layouts ...

The letter layout (flipped) already has quite a lot in common with some of where we are. Though putting A and N on pinkies is a little odd. But it clearly works....

On the three pure-words-only tests that I've done with your scoring (common, SAT, Difficult) it scores 99.4. Next best are my M1 and S1 layouts, followed by Balance Twelve at 105. Next mainstream layout after that is BvoFRak EN V0.5 at 106 and QGMLWY  at 108.9.
Title: Re: Balanced Keyboard Layout
Post by: parkher on 2016-Nov-08 14:47
I googled ANSI/ISO layout (never heard such a term before) and got pictures:

https://ultimatehackingkeyboard.com/blog/2015/09/09/ansi-or-iso-which-keyboard-layout-is-more-ergonomic

Both layouts are for two right hands, the rows of keys seem to be deliberately arranged in such a way that  both wrists have to be slanted like this: \ \.
No, I am using a keyboard for one left hand and one right hand like this: / \.. So I guess, ergo?
It does not have to be a split keyboard,  | |  is still better than \ \.

I don't know what the effort table would look like for such a \ \  two-right-handed keyboard -  it seems that the left hand  numbers then must be much much higher than the right hand numbers, not the same?
Because, if you keep the fingers of your left hand on their home keys and try to reach (with one finger) a key on the upper row or curl to reach for the lower row, the finger would land in the middle between two keys. So you would have to move the whole hand to a side (each time!) - that is an additional effort, and for the right hand there is no such additional effort.
So the effort table should  reflect that so that the layout prefers the right hand and minimizes the usage of the left hand.
I see that your effort tables have the same numbers on both sides, so they are not for those ANSI/ISO keyboards.



Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2016-Nov-08 15:00
:-)

See Wikipedia for better explanations.
https://en.wikipedia.org/wiki/Keyboard_layout#Mechanical_and_visual_layouts

Short version: ANSI == standard US, ISO == Standard European, both certified by different standards bodies.

I like your description of them being for two right hands ... was thinking in similar vein the other day without quite getting it so eloquent.

Are you using something like MS Natural keyboard (or Adesso version)?

Those designs complicate matters because their keys are odd sizes.
Title: Re: Balanced Keyboard Layout
Post by: parkher on 2016-Nov-08 15:51
I had Kinesis Classic QD for probably 16 years and now I got Advantage2 QD. And a set of blank key caps :)
I waited until they got rid of those rubber function keys.  But that did not make much difference because I need to learn to use them. I had them all mapped to real keys for years. It seems that I don't need them any more.
Title: Re: Balanced Keyboard Layout
Post by: rapidmotion on 2016-Nov-09 04:49
Hi, could someone help me locate the most recommended versions of Den and Ian's recent layouts, specifically for ANSI keyboard?  I guess they are scattered in various threads and webpages... It would be awesome to consolidate the layouts in one place, for comparison purposes.  And Ian, I have a hell of a time finding any of your layouts  :-)  Just the results you posted from patorjk.com, which allows me to see the layouts via heat maps.  But when it comes to some of the revisions you posted on your site, I can't seem to figure out how to access them.

I've been researching and reading the threads here, at GeekHack and elsewhere, to check out some of the latest layouts people are coming up with.  It looks like the two of you are doing amazing things... Just wish I could take a look at all the versions of these layouts (ANSI only) so I could finally choose one and start learning it.  I don't plan to get an ergo keyboard, so I need a great ANSI layout that I can commit to learning.  Would be great to compare several different versions of BEAKL (with and without Ian's mods) and also any great original layout Ian has put together.

I'm a programmer but I also do a lot of email/document typing, so I want one that favors both.  I was looking at MTGAP but from my reading it seems BEAKL may be "better" at least for my particular needs/wants.  I'm a very fast typist on QWERTY but never tried another layout, I think it's about time.

Any help would be appreciated... Thanks!
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2016-Nov-09 05:18
Hi, could someone help me locate the most recommended versions of Den and Ian's recent layouts, specifically for ANSI keyboard?  I guess they are scattered in various threads and webpages... It would be awesome to consolidate the layouts in one place, for comparison purposes.  And Ian, I have a hell of a time finding any of your layouts  :-)  Just the results you posted from patorjk.com, which allows me to see the layouts via heat maps.  But when it comes to some of the revisions you posted on your site, I can't seem to figure out how to access them.

Most of them are on Den's version of the analyzer, at http://shenafu.com/code/keyboard/Keyboard%20Layout%20Analyzer.html#/config

See after BLOU layout  and before BEAKL header in the layout dropdown. There's also a few further down.

There are a few on my site
http://www.keyboard-design.com/ansi-layouts-tested-with-keyboard-layout-analyzer.html

That site is a work in progress, dividing my time between capturing test results and tweaking layouts and building pages for said layouts :-)

At some point you need to look beyond ANSI because as a form factor it's terrible :-) (JMHO, YMMV... :-) )

I've attached a few of my more recent layouts. FWIW, you should also take a look at Vu Keys... does very well at English. Technicals could be better but that would require relabelling keys which may have been outside the design requirements.

Cheers, Ian


Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2016-Nov-09 07:14
Hi, could someone help me locate the most recommended versions of Den and Ian's recent layouts, specifically for ANSI keyboard?  I guess they are scattered in various threads and webpages... It would be awesome to consolidate the layouts in one place, for comparison purposes.  And Ian, I have a hell of a time finding any of your layouts  :-)  Just the results you posted from patorjk.com, which allows me to see the layouts via heat maps.  But when it comes to some of the revisions you posted on your site, I can't seem to figure out how to access them.

I have a lot of layouts, of varying quality/usefulness... most are going to be dropped at some point, so I don't want to waste time building a page for them. I try to have at least the top performers have a page, but even that is a moving target.
Title: Re: Balanced Keyboard Layout
Post by: rapidmotion on 2016-Nov-09 19:44
Thanks Ian!  I'll take a look.  I will probably choose one of your mods to BEAKL.  Like I said, I'm looking to make a long-term committment to a layout, learn it well, and potentially use it for quite some time.  Since you and Den seem to be doing the most recent innovation in this area, I am hoping to find a layout that seems to suit me well for both coding and prose, then stop looking for quite a while.  :-)  Meanwhile you guys (and others) will surely continue making improvements, new layouts, etc. but I'd rather just pick something to stick with at this point.  It will take time to switch obviously, and I want to get up to fast speed.  I'm quite fast on QWERTY and I use Razer Black Widow clicky version which suits me well enough so far.  I can type over 110 WPM at high accuracy.
Title: scoring
Post by: iandoug on 2016-Nov-11 13:38
@Den:

I have grown weary of typing in numbers (and besides, I'm picking up too many typos) so am looking to capture the data directly from the app. At present just using Javascript alerts of JSON.stringify of the arrays.

I'm able to get all the main scores, and the data for your mouseover popups. That's cool because all the layouts tested are shown at once.

However am having some trouble with the rest, in particular the distance figures. I've put alerts in services.js and analyzer.js, which ultimately show me the same numbers, but I can't find those numbers on the Distance results page.

This from analyzer.js after running Alice. Code is the first zip you posted.
Code: [Select]
{"distance":[0,13836,33075,112692,90897.87108911794,44520,51023.29733017433,167782.2306053457,77529,90375,19386.384726842654],
"fingerUsage":[0,604,743,1892,1303,2120,376,1715,1429,1163,276],"rowUsage":[0,2316,5522,1287,2471],"errors":[],
"keyData":{"0":{"count":0,"index":0},"1":{"count":0,"index":1},"2":{"count":0,"index":2},"3":{"count":0,"index":3},"4":{"count":0,"index":4},"5":{"count":0,"index":5},"6":
{"count":0,"index":6},"7":{"count":0,"index":7},"8":{"count":0,"index":8},"9":{"count":0,"index":9},"10":{"count":0,"index":10},"11":{"count":0,"index":11},"12":{"count":0,"index":12},"13":
{"count":0,"index":13},"14":{"count":0,"index":14},"15":{"count":6,"index":15},"16":{"count":163,"index":16},"17":{"count":696,"index":17},"18":{"count":249,"index":18},"19":{"count":98,"index":19},
"20":{"count":0,"index":20},"21":{"count":0,"index":21},"22":{"count":202,"index":22},"23":{"count":171,"index":23},"24":{"count":144,"index":24},"25":{"count":558,"index":25},"26":{"count":4,"index":26},
"27":{"count":25,"index":27},"28":{"count":0,"index":28},"29":{"count":592,"index":29},"30":{"count":561,"index":30},"31":{"count":1078,"index":31},"32":{"count":678,"index":32},"33":{"count":199,"index":33},
"34":{"count":387,"index":34},"35":{"count":517,"index":35},"36":{"count":867,"index":36},"37":{"count":464,"index":37},"38":{"count":131,"index":38},"39":{"count":48,"index":39},"40":{"count":0,"index":40},
"41":{"count":6,"index":41},"42":{"count":19,"index":42},"43":{"count":118,"index":43},"44":{"count":72,"index":44},"45":{"count":7,"index":45},"46":{"count":0,"index":46},"47":{"count":0,"index":47},
"48":{"count":252,"index":48},"49":{"count":186,"index":49},"50":{"count":418,"index":50},"51":{"count":141,"index":51},"52":{"count":68,"index":52},"53":{"count":0,"index":53},"54":{"count":0,"index":54},
"55":{"count":0,"index":55},"56":{"count":0,"index":56},"57":{"count":0,"index":57},"58":{"count":0,"index":58},"59":{"count":0,"index":59},"60":{"count":0,"index":60},"61":{"count":0,"index":61},
"62":{"count":0,"index":62},"63":{"count":0,"index":63},"64":{"count":0,"index":64},"65":{"count":0,"index":65},"66":{"count":2120,"index":66},"67":{"count":0,"index":67},"68":{"count":0,"index":68},
"69":{"count":0,"index":69},"70":{"count":0,"index":70},"71":{"count":0,"index":71},"72":{"count":0,"index":72},"73":{"count":0,"index":73},"74":{"count":327,"index":74},"75":{"count":24,"index":75},"length":76},
"charData":{"8":{},"9":{},"13":{},"16":{},"17":{},"18":{},"27":{},"32":{},"33":{},"34":{},"35":{},"36":{},"37":{},"38":{},"39":{},"40":{},"41":{},"42":{},"43":{},"44":{},"45":{},"46":{},"47":{},"48":{},"49":{},
"50":{},"51":{},"52":{},"53":{},"54":{},"55":{},"56":{},"57":{},"58":{},"59":{},"60":{},"61":{},"62":{},"63":{},"65":{},"66":{},"67":{},"68":{},"69":{},"70":{},"71":{},"72":{},"73":{},
"74":{},"75":{},"76":{},"77":{},"78":{},"79":{},"80":{},"81":{},"82":{},"83":{},"84":{},"85":{},"86":{},"87":{},"88":{},"89":{},"90":{},"91":{},"92":{},"93":{},"94":{},"95":{},"96":{},
"97":{},"98":{},"99":{},"100":{},"101":{},"102":{},"103":{},"104":{},"105":{},"106":{},"107":{},"108":{},"109":{},"110":{},"111":{},"112":{},"113":{},"114":{},"115":{},"116":{},"117":{},
"118":{},"119":{},"120":{},"121":{},"122":{},"123":{},"124":{},"125":{},"126":{},"8592":{},"8593":{},"8594":{},"8595":{},"8670":{},"8671":{},"8998":{},"9112":{},"9986":{},"-1":{},"-16":{},
"-18":{}},"tmp":{"prevShiftInfo":{},"prevAltGrInfo":{},"prevFingerUsed":4,"prevHandUsed":"left","prevKeyIndex":44},"consecFingerPress":[0,0,10,89,22,0,72,53,126,31,37],
"consecFingerPressIgnoreDups":[0,0,10,8,22,0,1,25,27,13,1],"consecHandPress":{"left":1119,"right":901,"thumbs":324},"consecHandPressIgnoreDups":{"left":1038,"right":720,"thumbs":253},
"modifierUse":{"shift":352,"altGr":24,"shiftAltGr":0},"numKeys":11596,"corpusChars":11245,"pixelsPerCm":25.7894732,"layoutName":"BEAKL Opted4 Ergo Alt"}

The consecFingerPressIgnoreDups figures show up on the Misc page, no problem.

However I can't find the distance figures... neither Distance Penalty nor Centimetres. Do the numbers above need to be massaged in some way? Or am I looking in the wrong place?

Can you perhaps advise?

Also, the numbers in your popup... I am debating adding them to my database. However on the one hand I want to keep things "kinda comparable" to Patrick's scoring, on the other, you're measuring things that he is not so maybe I should not worry about being "comparable" as far as the results go.

Thanks, Ian
Title: BEAKL Opted34 Kinesis
Post by: iandoug on 2016-Nov-12 09:09
@Den:

BEAKL Opted34 Kinesis is missing a question mark.
Title: Molengo
Post by: iandoug on 2016-Nov-12 09:18
@Den

Um, is there a particular reason why "code" renders in Molengo font? It's not very readable, especially given the font size and unusual digits.

Oddly I was on this site on my phone earlier today and IIRC it rendered in something Courier or Mono, which was much more readable.

I see it looks better in Chrome than in Firefox.

Thanks, Ian

(yeah it's been bothering me for a long time... eventually I was motivated to ask.)
Title: Re: scoring
Post by: iandoug on 2016-Nov-12 11:33

However am having some trouble with the rest, in particular the distance figures. I've put alerts in services.js and analyzer.js, which ultimately show me the same numbers, but I can't find those numbers on the Distance results page.

Okay my intuition eventually told me the secret ... those numbers are pixels, I need to divide them by the appropriate pixels/cm and then you get the cm value.

Cheers, Ian
Title: Efficiency
Post by: iandoug on 2016-Nov-12 15:46
Is this a viable metric?

Assume that for a given layout, the fingers have to move 27186 cm. (Den's distance measurement)

The input text had 11245 characters.

Let's assume an imaginary ideal layout, where the next key you have to type is always exactly 1 key away.

So the minimum distance that the fingers could move is (numchars) x (1.9 cm + 0.8 cm) where 1.9 is the distance between keys and 0.8 is the down+up distance.)

Which in this example is 30,361.5

Then we can define a LayoutEfficiency as (Minimum/Actual) x 100/1

Which in this case =    30,361.5 x 100 / 27186  == 111.68% (this for BEAKL Opted4 Ergo Alt on Alice)

So for QWERTY on Alice  we get

30361.5 * 100 / 40041.4 ==  75.82 % efficiency.

This does not take fingers used into account, just plain distance.

Is this pointless or illuminating?

Title: Re: Molengo
Post by: ADMIN on 2016-Nov-12 18:52
@Den

Um, is there a particular reason why "code" renders in Molengo font? It's not very readable, especially given the font size and unusual digits.

Oddly I was on this site on my phone earlier today and IIRC it rendered in something Courier or Mono, which was much more readable.

I see it looks better in Chrome than in Firefox.

Thanks, Ian

(yeah it's been bothering me for a long time... eventually I was motivated to ask.)

What, complaining about Molengo is blasphemy.

Anyway I set code to use Source Code Pro (https://fonts.google.com/specimen/Source+Code+Pro) font.

@Den:

BEAKL Opted34 Kinesis is missing a question mark.

question mark should be shift-3
Title: Re: Molengo
Post by: iandoug on 2016-Nov-13 04:08
What, complaining about Molengo is blasphemy.

Yes, I suspected as much, which is why I never said anything before. Luckily I have no fear of the gods. :-)
Unless you're one of them :-)

Anyway I set code to use Source Code Pro (https://fonts.google.com/specimen/Source+Code+Pro) font.

Thanks :-)

question mark should be shift-3

Thanks, fixed in two places.

I'm picking up other errors in assorted layouts (not yours), I fixed Anglian by moving it to ISO layout, but I see Ina is missing a bunch of characters too. Will probably have to drop it.

Cheers, Ian
Title: Re: Efficiency
Post by: iandoug on 2016-Nov-13 13:47
Is this a viable metric?

[snip]

Then we can define a LayoutEfficiency as (Minimum/Actual) x 100/1
[snip]

Is this pointless or illuminating?

Some results from Alice. All ANSI and Ergo layouts mixed. No European.
Bottom of the table:
Ergodox Colemak jjt-symbolmod: 39.24 %
TNWMLC (Worst CarpalX layout): 64.36 %
Typematrix: 64.39 %
QWERTY: Top Row +Thumbs: 67.43 %
One-handed Dvorak (Right): 72.86 %
QWERTY untangled: 73.16 %
One-handed Dvorak (Left): 74.59 %
QWERTY-Programmer: 75.59 %
QWERTY: 75.83 %
NasiraJ: 75.83 %
ABCDEF: 75.89 %
QWERTY: Wide Mod: 76.52 %

Top of the table:
LoDi 71.70 14835 143 : 8540 : 12763  - 19.txt: 123.14 %
LoDi 70.68 14830 166 : 8504 : 12741  - 15.txt: 123.16 %
X1 Ergolinear tweaked: 123.19 %
X1 Ergolinear: 123.19 %
Colemak Thumbshift: 123.6 %
MTGAP Thumbshift: 123.72 %
Arensito Kinesis: 126.21 %
X2 Ergolinear 20161107: 126.32 %
X2 Ergolinear HaltgrSpace A: 126.32 %
X2 Ergolinear HspaceAltgr B: 126.32 %
X2 Ergolinear AltGrHspace C: 128.86 %
-+T+- HT01-75.54: 129.87 %
-+T+- HT02: 132.87 %
-+T+- HT02a: 136.91 %

As expected the AltGr and/or ergo layouts come out well... but I was rather surprised that the two LoDi (plain ANSI, no special tricks except relabel) layouts did so well. I developed them quite a while back, they were supposed to be "Low Distance" by design. And they come out as the best ANSI for this metric, for Alice.

So yeah I was somewhat surprised :-)
Probably won't so so well with the technical tests though.
Title: bad layouts
Post by: iandoug on 2016-Nov-14 06:40
We can ignore the following layouts due to errors... either missing characters or requiring two keys with same finger. KLA does not approve of finger gymnastics.

I've fixed two I think (Balance 12 (again), and moved Anglian from standard to european). Some I can't/won't fix, like Ina, which is missing 5 characters, I can't assume to know where the author would want them.

So can ignore:

standard.Anglian
Ina
AntiBracket
both one-handed Dvorak layouts
ergodox BuTeck-(AdNW)
Ergodox Colemak (V1)

[edit]
also
ABCDEF (rough) - missing brackets
BvoFRak V1.0 FR  - no $
STNDC - no {} but double [] ... suppose could pick a set to swop...

[edit again]
Ergodox/Colemak/Cub  - missing | and &

[edit again again]
Ergodox/QGMLWB/Cub  - missing | and &
Ergodox/QGMLWY/Cub  - missing | and &
Ergodox/Workman/Cub  - missing | and &
Ergodox Gelatin - missing `
TaserFR - missing  ` %

Fixed layouts attached.
Also for Tallus the left hand side AltGr confuses KLA, it wants to use it to type the ` above it and can't. Suggest replacing it with another Tab or something else innocuous. There is an AltGr in traditional spot.
Title: BEAKL Opted4 Ergo Alt
Post by: iandoug on 2016-Nov-14 12:08
@Den

BEAKL Opted4 Ergo Alt is missing @ ... please advise :-)

94 glyphs need more than 31 keys :-)

thanks, Ian
Title: Re: BEAKL Opted4 Ergo Alt
Post by: Den on 2016-Nov-22 15:54
@Den

BEAKL Opted4 Ergo Alt is missing @ ... please advise :-)

94 glyphs need more than 31 keys :-)

thanks, Ian

i'ma rework it to fit it in
Title: Re: % efficiency
Post by: Den on 2016-Nov-22 16:21
The scoring algorithm already does something similar. The penalty score is exra effort over a baseline. The baseline is number of characters times minimum effort to hit a (home) key (not taking into account finger weight. The baseline may vary if that layout is missing characters.

I'm not sure efficiency 100% or greater makes sense in context. It's like saying an object can move faster than the speed of light.
Title: Re: BEAKL Opted4 Ergo Alt
Post by: iandoug on 2016-Nov-23 13:52
i'ma rework it to fit it in

Okay. I've finished checking all the working layouts with all my input tests and your scoring. Just need to check a few things before making live on site.
[and yes Ian is annoyed that after all that my AltGr 3 layout comes out better overall than X1 or X2 ... because of the numerals on the home row, which gives excellent scores on the dates/currency tests. Other layouts get really poor scores on those tests.]

I've also got some other variants to test, so I'll wait for your fix, then I can test them all at the same time. That's still going to be a lot of copy-pasting but at least not typing numbers off the screen.

Then I need to modify Patrick's code and do it all again with his scoring....

Cheers, Ian
Title: Re: % efficiency
Post by: iandoug on 2016-Nov-23 14:03
The scoring algorithm already does something similar. The penalty score is exra effort over a baseline. The baseline is number of characters times minimum effort to hit a (home) key (not taking into account finger weight. The baseline may vary if that layout is missing characters.

I'm not sure efficiency 100% or greater makes sense in context. It's like saying an object can move faster than the speed of light.

What do you mean things can't go faster than the speed of light? We need to be able to if we're ever gonna get off Terra and go Elsewhere :-)
[yeah Ian has had problems with that concept ever since I learned it. Professor could not explain what happens when an alien riding on a light beam switches on a torch. Should have pointed out the flaws in the suppositions.]

But yeah, greater than 100% may be the wrong way of expressing the metric. I suppose I could divide by a 100 and call it a Factor rather than a percentage. Same thing just different packaging.

Samples attached.
Title: Re: BEAKL Opted4 Ergo Alt
Post by: Den on 2016-Nov-26 08:27
I've also got some other variants to test, so I'll wait for your fix, then I can test them all at the same time. That's still going to be a lot of copy-pasting but at least not typing numbers off the screen.

Then I need to modify Patrick's code and do it all again with his scoring....

Cheers, Ian

Completed BEAKL Opted4 Ergo Alt. I moved a lot of puncs around.

And since you mentioned that 94 chars would not fit 31 keys, I messed around with Opt again. This time using exactly 32 keys symmetrically. Also tweaked the settings to see if I can force N back onto the home row. I saw a few layouts it spit out had the W on the pinky. This reduces pinky usage and same-pinky penalty even more. The drawback is high same-finger usage, especially on the right index. The puncs on AltGr mainly derived from Arensito as a base. In short, this is the best BEAKL so far by far for both prose and code.

Introducing BEAKL5 ErgoLinear:

Code: [Select]
BEAKL5

  QYOUX FGRCV
J HIEA. LSTNW Z
  '"),( BDMPK

I updated my KLA page with these two layouts (the first two layouts you'll see).
http://shenafu.com/code/keyboard/Keyboard%20Layout%20Analyzer.html#/config

Title: Re: Balanced Keyboard Layout
Post by: Den on 2016-Nov-26 09:19
So I was thinking .... (always a dangerous thing... )

What if we reintroduced some letters.... the thorn for th? The bigram et is not so common, and hi will often bump into th, but the next most common is "in" ... could not find a character with the dot on the left vertical of the n, but there is an n with a centre dot.

So then we could write, for example, "thin" as þṅ if that shows up correctly in your browser....

Point being that we reduce 2 very common bigrams down from 2 letters to 1 letter, and improve efficiency in that way....

The & is already too well known to use as-in but there is a turned version ⅋.

I'll shut up now... :-)

Cheers, Ian
Sometimes IPA chars show up if you put them inside the code tags.

TH and NG should have their own letters, as they are basic sounds and very common in many languages.

J should have the English Y sound, like it is in Scandinavian languages. Then Y has the IPA
Code: [Select]
/ʉ/ (middle u) (as in Uber) (can be used in place of /ʊ/, as in book, and /y/ found in e.g. Mandarin and Cantonese)


Replace QXC with three more vowels. Such as these:
Code: [Select]
IPA sounds:

/ə/ (schwa)
/ɔ/ (short o)
/ɐ/ (short u)

Schwa is neutral sound, and so can be used to approximate other similar sounds. The last two are quite common by themselves, but also commonly used in diphthongs.

Altogether, the nine vowels cover nine distinct sections of the vowel chart as described in IPA. As such, they can better approximate more sounds across all languages.
Title: Re: BEAKL Opted4 Ergo Alt
Post by: iandoug on 2016-Nov-26 09:36
Completed BEAKL Opted4 Ergo Alt. I moved a lot of puncs around.
Introducing BEAKL5 ErgoLinear:
I updated my KLA page with these two layouts (the first two layouts you'll see).
http://shenafu.com/code/keyboard/Keyboard%20Layout%20Analyzer.html#/config

Damn, should have waited an hour or three... :-) had no idea when you would get around to it so ran the tests on 5 new variants.... okay will redo it again with your two new ones, then the whole Den Scoring side should be up to date, and I can look at redoing Patrick's scoring with all the new layouts etc. Still have to add Ergolinear on that side as well.

Thanks, Ian
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2016-Nov-26 09:43

TH and NG should have their own letters, as they are basic sounds and very common in many languages.
Altogether, the nine vowels cover nine distinct sections of the vowel chart as described in IPA. As such, they can better approximate more sounds across all languages.

Weird, I was just thinking about this stuff over brunch this morning... and for some reason got to thinking about reversing letters like k and c, which I see is included in your suggestions. Also thought about ng, there is a character ŋ (eng) which apparently comes from Latin (and is in IPA)... so I guess those Romans were one step ahead of us again... they didn't even need a J... :-)

Cheers, Ian
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2016-Nov-26 10:22
TH and NG should have their own letters, as they are basic sounds and very common in many languages.
J should have the English Y sound, like it is in Scandinavian languages. Then Y has the IPA
Altogether, the nine vowels cover nine distinct sections of the vowel chart as described in IPA. As such, they can better approximate more sounds across all languages.

Perhaps we should move this to a separate topic?

I'm much in favour of fixing English spelling, and while we're at it, get rid of all the ridiculous stuff inherited from the French (cough, thorough.....), and silent letters (gnome, lamb).

Only problem I have is that we're going back to Unifon, and with it, the problem of regional pronunciations leading to different spellings. Unless we can somehow force everyone to speak BBC English... :-)

Presume you are familiar with the old joke?

The European Commission has announced an agreement whereby English will be the official language of the EU, rather than German, which was the other contender. Her Majesty's Government conceded that English spelling had room for improvement and has therefore accepted a five-year phasing in of "Euro-English".

In the first year, "s" will replace the soft "c". Sertainly, this will make sivil servants jump for joy. The hard "c" will be dropped in favour of the "k", Which should klear up some konfusion and allow one key less on keyboards.

There will be growing publik enthusiasm in the sekond year, when the troublesome "ph" will be replaced with "f", making words like "fotograf" 20% shorter.

In the third year, publik akseptanse of the new spelling kan be expekted to reach the stage where more komplikated changes are possible. Governments will enkourage the removal of double letters which have always ben a deterent to akurate speling. Also, al wil agre that the horible mes of the silent "e" is disgrasful.

By the fourth yer, peopl wil be reseptiv to steps such as replasing "th" with "z" and "w" with "v".

During ze fifz yer, ze unesesary "o" kan be dropd from vords kontaining "ou" and similar changes vud of kors be aplid to ozer kombinations of leters. After zis fifz yer, ve vil hav a reli sensibl riten styl. Zer vil be no mor trubls or difikultis and everivun vil find it ezi to understand ech ozer. ZE DREM VIL FINALI COM TRU!

Herr Schmidt

Cheers, ian


Title: Re: BEAKL Opted4 Ergo Alt
Post by: iandoug on 2016-Nov-26 14:35
Introducing BEAKL5 ErgoLinear:

Swap O and U, and R and W.

Cheers, Ian
Title: Den's scoring all done
Post by: iandoug on 2016-Nov-29 11:11
Finally got the site updated with Den's scoring.

http://www.keyboard-design.com/

Also hosting fork of Den's fork of Patrick's KLA locally, with most layouts linked to it, so that the curious can investigate the layouts.
Need to link the layout names in the results to that as well.

Also some minor page editing now necessary since data no longer captured manually but saved directly from console.log and processed.

I've added an ANSI chars test, to check new layouts for completeness (ie compared to ANSI 104, no Euro or special UK chars included) ... console.log will report missing chars.

Next up is either getting Patrick's scoring to work with Ortholinear layouts (btw I added 2 variants of that, since Den's is slightly different to mine), and add some other analysis like hand balance.

Cheers, Ian
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2016-Dec-14 15:40
Well this explains what the four Tarmak layouts are all about ... been wondering about those for a long time :

https://forum.colemak.com/topic/1858-learn-colemak-in-steps-with-the-tarmak-layouts/
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2016-Dec-17 12:19
Getting the AltGr under the thumb is getting easier .... new design coming.

https://massdrop-s3.imgix.net/img_thread/dciCG03RZ6QVM9YdppWP_363A5637%20copy.jpg
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2016-Dec-30 15:32
So there I am, lying in bed last night thinking about my sore right thumb... years of using it on the space bar and for  copy/paste operations are taking its toll, and it's getting more sensitive on the edge.

Then I had an idea, which may or may not be a good one.....

We push all keys with the tips of our fingers, except the thumb.... for that we (well, me... dunno about you...) use the side of the last joint.

What if the keys for the thumb were mounted flipped 90 degrees, ie on their side,  so that for example you would push it towards the other keys instead of down?

In layouts like ErgoLinear, where the thumb is not supposed to move much, but rest on a single key, how would that work, to push towards the other keys instead of down? In practice the thumb would probably lie on the keyboard base and slide forward. That action may lead to callouses forming unless we put a nice slick surface for the thumb to slide on.

Critiques welcome :-)

Cheers, Ian
Title: Re: Balanced Keyboard Layout
Post by: Den on 2016-Dec-31 00:57
there have been attempts to put the thumb keys on a vertical plane. however i don't think it works as good as you imagine.

the thumb hitting inwards towards the palm works best when it's countering the movement or grip of the other fingers or palm. that's why it's called the opposable thumb, to oppose the action of the hand and fingers. it works great such as for ergonomic mice because the mouse is held down by the hand. this provides resistance for the thumb to press against. on the other hand, an independent thumb that strikes orthogonally to the direction of gravity loses much of its effectiveness by using more effort.

then there are issues with technical and aesthetic designs you must overcome.

the main thing to get right is the tenting angle. if the keyboard tents about 40 to 45 degrees, then have the thumb keys 90 degrees of that. so the thumbs strike not totally perpendicular to the direction of gravity, but like 45 to 50 degrees.
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2016-Dec-31 02:51
there have been attempts to put the thumb keys on a vertical plane. however i don't think it works as good as you imagine.

I think part of the problem would be retraining typing habits, and also if you are a strict touch-typist or a hoverer like me...


then there are issues with technical and aesthetic designs you must overcome.


Yeah, realised that. Although one possibility would be to actually have the thumbkeys on a lower plane so that they go under the other keys. Suppose the only way to test would be to build a model and see how it feels.

the main thing to get right is the tenting angle. if the keyboard tents about 40 to 45 degrees, then have the thumb keys 90 degrees of that. so the thumbs strike not totally perpendicular to the direction of gravity, but like 45 to 50 degrees.

So I go walkabout to see where you got the 45° figure from ... in my previous readings the figures I've seen for tenting were usually much lower, and typically similar to the rotation for the two halves of a split design (ie around 15°, or say 10° to 20°).

Most useful link I found was this: https://geekhack.org/index.php?topic=62717.0

where Jacobulus mentions a figure up to 45°. I've seen some postings from him on DeskAuthority, he clearly has a lot of knowledge/experience behind what he says, which I respect.

Have you seen any designs with a 45° tent, and thumbcluster then at around -45°? I'm trying to imagine how it would look, especially if you also have to include a negative pitch of say -10°.

Thanks, Ian
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2016-Dec-31 09:30
mmm.
(https://dump.bz/storage-2/1216/sCtA4mSbO6LqPHdBP0SoNDxgqyVIHaF9.jpg)

No tenting in sight :-)

I guess Androids don't have wrist problems.
Title: Re: Balanced Keyboard Layout
Post by: torusJKL on 2017-Jan-13 00:07
Hi

I'm interested to use the BEAKL layout on a Planck keyboard.

Because I like the control key on the left and right pinky I moved some keys around.
How can I test this layout in the keyboard analyzer?

Code: [Select]
* ,-----------------------------------------------------------------------------------------.
 * | Tab    |   Q  |   Y  |   O  |   U  |   X  |   F  |   G  |   R  |   C  |   V  |  Z       |
 * |--------+------+------+------+------+-------------+------+------+------+------+----------|
 * |Ctrl/Esc|   J  |   H  |   I  |E/FN5 |A/FN2 |   L  |   S  |   T  |   N  |   W  |Ctrl/Enter|
 * |--------+------+------+------+------+------|------+------+------+------+------+----------|
 * |Shift/( |   /  |   "  |   \  |   ,  |   .  |   B  |   D  |   M  |   P  |   K  |Shift/)   |
 * |--------+------+------+------+------+------+------+------+------+------+------+----------|
 * | Ctrl   | GUI  | Alt  | Hyper| Del  |    Space    | Bksp | Left | Down |  Up  |Right     |
 * `-----------------------------------------------------------------------------------------'

Thanks!
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2017-Jan-13 00:58

I'm interested to use the BEAKL layout on a Planck keyboard.


The problem with KLA is that each form factor has to be physically added to the code... and Planck is not yet done.

So you (or someone else) would first need to add that code, then ask Patrick to update his live version to include it, or run your own version.

If you had to send the changes to me or Den I'm sure we could look at adding it to our "forks" (they're not real forks since they're based on downloads of the live version rather than from building from the original source).

Hope that helps. One of the things on my massive ToDo list is to have a way of magically taking a layout from KLE and converting it then using it in KLA. (KLE == www.keyboard-layout-editor.com)

Cheers, Ian
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2017-Jan-13 01:56
The problem with KLA is that each form factor has to be physically added to the code... and Planck is not yet done.

Also just realised that Planck has several layers, and at the moment KLA only supports these:
Shift  + key
Alt-Gr + key
Shift+AltGr + key

So supporting something like Planck + cousins would likely require other code changes as well over and above the code for loading the form factor.

Cheers, Ian
Title: Re: Balanced Keyboard Layout
Post by: Den on 2017-Jan-13 04:02
So I go walkabout to see where you got the 45° figure from ... in my previous readings the figures I've seen for tenting were usually much lower, and typically similar to the rotation for the two halves of a split design (ie around 15°, or say 10° to 20°).

45 is just my observation when I put my hands at rest on the table, and which is just comfortable enough when tapping my thumbs (against air). this seems the best compromise and comfort for two different factors: wrist pronation and gravity.

Hi

I'm interested to use the BEAKL layout on a Planck keyboard.

Because I like the control key on the left and right pinky I moved some keys around.
How can I test this layout in the keyboard analyzer?


Thanks!

First, H should be on the pinky and A on the index home.

Here's a refined layout. I removed redundant keys.

Code: [Select]
* ,-----------------------------------------------------------------------------------------.
 * | J      |   Q  |   Y  |   O  |   U  |   X  |   F  |   G  |   R  |   C  |   V  |  Z       |
 * |--------+------+------+------+------+-------------+------+------+------+------+----------|
 * |Ctrl/Esc|   H  |   I  |E/FN5 |A/FN2 |   .  |   L  |   S  |   T  |   N  |   W  |Ctrl/Enter|
 * |--------+------+------+------+------+------|------+------+------+------+------+----------|
 * |Shift/( |   '  |   "  |   \  |   ,  |   /  |   B  |   D  |   M  |   P  |   K  |Shift/)   |
 * |--------+------+------+------+------+------+------+------+------+------+------+----------|
 * | Tab    | GUI  | Alt  | Hyper| Del  |    Space    | Bksp | Left | Down |  Up  |Right     |
 * `-----------------------------------------------------------------------------------------'
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2017-Jan-13 04:36
45 is just my observation when I put my hands at rest on the table, and which is just comfortable enough when tapping my thumbs (against air). this seems the best compromise and comfort for two different factors: wrist pronation and gravity.

I have been contemplating this in my head for a while ... I think there may be a problem having the thumb keys at 90 degrees to the rest, because that will need to be on a separate, (lower?) surface, which may be problematic for key combos where you need the thumb plus another key (as typically in Arensito-based layouts). I'm still trying to visualise physical construction in my head ... :-)

Eg if hands are on table then thumb naturally hits against table while fingers are up in air?...
Title: Re: Balanced Keyboard Layout
Post by: veruna on 2017-Jan-26 12:04
professionals are different form normal people like coding need symbol, and gaming need short cut often qwerty and macro.
for someone who doesn't code, the newest v5 is a very strange layout with "J, Z"out there and so many punctuations in the center.
is there a layout for normal user, like blogging, chatting etc.
Title: Re: Balanced Keyboard Layout
Post by: veruna on 2017-Jan-26 12:42
While using shenafu configurator, I can seperate each key into primary and shift part like your layout, ' and “ are on different keys under H and I. but I dont know how to combine shift+esc or ctrl+enter using that configurator, can some one tell me?

btw, my keyboard is ergodox
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2017-Jan-26 12:53
professionals are different form normal people like coding need symbol, and gaming need short cut often qwerty and macro.
for someone who doesn't code, the newest v5 is a very strange layout with "J, Z"out there and so many punctuations in the center.
is there a layout for normal user, like blogging, chatting etc.

What we are trying to do here is find the optimal layout for typing English. There's side projects looking at alternatives to English as she is currently spelled.

Any new layout is going to feel strange until you get used to it ... blame muscle memory for that.

I suggest you look at the better layouts that don't put the punctuation on AltGr, and try a few to see which work for you... should be doable on your ErgoDox AFAIK.
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2017-Jan-26 12:56
While using shenafu configurator, I can seperate each key into primary and shift part like your layout, ' and “ are on different keys under H and I. but I dont know how to combine shift+esc or ctrl+enter using that configurator, can some one tell me?

btw, my keyboard is ergodox

I assume you are referring to Den's fork of the Keyboard Layout Analyser, that is for comparing layouts and there's some things hard-coded in at the moment, including which key combinations are available... it's only Key, shift+Key, AltGr+key, and shift+AltGr+key.

Title: Re: Balanced Keyboard Layout
Post by: veruna on 2017-Jan-26 13:07
I made a little modification for Chinese double pinyin and English writing , "J" "Z" back to base area and ";" "?" punctuation too, I hope these changes won't affect too much.
Title: X6.?H layouts
Post by: iandoug on 2017-Mar-05 08:46
Hi

Eventually updated by Keyboard Design site (www.keyboard-design.com (http://www.keyboard-design.com)) with what I've been busy with.

Introducing the X6.x layouts... which are a bit radical even by our standards. The X6.3H is best at English, while the X6.1H is best overall.

Layouts attached...

So I dunno ... not sure how "pleasant" it will be typing on these ... or if we need to relook at your scoring algo ...

Cheers, Ian
Title: Re: Balanced Keyboard Layout
Post by: Den on 2017-Mar-05 21:23
I made a little modification for Chinese double pinyin and English writing , "J" "Z" back to base area and ";" "?" punctuation too, I hope these changes won't affect too much.


yea in consideration of pinyin, moving those letters in better places is great idea. one thing i would move Z to index bottom instead. but actually the Z on the left hand may not be wise. because you would be typing many 3 and 4-grams with the same hand. e.g. zhou, zhe, zou, zhai, etc. on the other hand, the right hand is full of consonants already. though you may consider moving K to the left hand and move Z to its old spot in the right pinky bottom.

consequently, in consideration of other languages and much time with the BEAKL, we should keep all the letters within the main 3x10 block. probably put parentheses at the outside, so I can still type them without any shifting.
Title: Re: Balanced Keyboard Layout
Post by: Den on 2017-Mar-07 23:09
with a few modifications, excellent for English-Zhongwen (EZ):

Code: [Select]
BEAKL EZ 1

QYOUK FGRCV
HIEA. LSTNW
'"J,X BDMPZ

see attachment for full layout.

for more radical approaches to slightly improve pinyin at expense of english:

Code: [Select]
BEAKL EZ 2

QJAUK WDRMZ
HOEIY GSTNP
'X"., BCLFV

Code: [Select]
BEAKL EZ 3

QJOU' MDNCV
YEAI. RHTSW
Z"XG, KLPBF

apparently the vowel bigrams are improved for pinyin. in particular AU is now a roll rather than typed with the same finger. home row vowels are rearranged. H is moved to the consonant district. Y takes its place at the left pinky. G also interestingly moves to the vowel district at the index bottom. probably to raise hand alternation for tri- and quadgrams involving two vowels and NG.

unfortunately for the last two versions, the same finger rates are quite high.

so BEAKL EZ 1 the version recommended.
Title: Re: X6.?H layouts
Post by: Den on 2017-Mar-07 23:24
So I dunno ... not sure how "pleasant" it will be typing on these ... or if we need to relook at your scoring algo ...

I would think higher penalty for modifiers because they disrupt the flow. but in the end it doesn't make a difference since it would affect all layouts.

for that matter, using shift feels much better than double tapping caps lock.
Title: Re: Balanced Keyboard Layout
Post by: veruna on 2017-Mar-16 17:07
thx for reply Den
yes, the letter "z" is more frequent than the Full stop/Period mark "." in Chinese, so I took your advice and put it at index bottom.
I think before picking or adjusting keyboard layouts, one must first know what he/she needs. no one layout can do all the job perfectly. let me illustrate below.

1. situation, this part is to understand your need.
   maybe your work is speed typing, like you are working in the Press writing articles, or you are a secretary? or maybe you are a novelist, you want your typing as natural and fluent as your thoughts? or maybe you don't even use a keyboard, you just use one hand (thumb) to write a novel like the author of "fifty shades of grey"?

   or maybe you are a programmer, and your work requires special punctuations like hyphen, special parentheses? you can just combine the most common punctuations with other keys like when holding=shift/CTRL, but hit=Parentheses/question mark.
   
   does your work needs your right hand constantly holding the mouse, while your left hand have to do some common editings, like in adobe video editing? is traditional short cut a must like you're using vim very often? or you are just like me, habitually using mouse to surf the Internet while using my left Hand to do some copy/paste? to solve this problem, I just put all short cuts on another layer on my left hand, so I can one hand operate, while right hand is holding the mouse.

   or maybe you are a gamer, you have to use the default WASD to control the movement, and you need a space on the left hand to jump while your right hand is using the mouse to aim? luckily, most of the new games are customizable.   
   
   or maybe you need to type in mult-languages like me? I have to type/translate on some En-Cn conferences or meetings.
   I use double pinyin for fast Chinese input, not full pinyin, they are totally different things. double pinyin is already optimized for QWERTY, so any other layouts will just make it worse. I have to choose my priority, I pick English so I changed my English input to BEAKL.
   the problem about Chinese is, the Apostrophe ' is very common in English like in "it's" , "don't" etc. but not in Chinese. and the Semicolon ";" is a must in Microsoft double pinyin, it stands for the sound "英(ing)", that's why I have a ";" there at left pinky. same as letters J stands for "安", Z "诶". so my next step is to combine double pinyin and bleak.
   and another problem is that most Chinese input method use left and right CTRL to select 2nd and 3rd words of the same pronunciation, also use shift to change language input method, so I have to have a separate CTRL stand alone down there for palm hit. I can't combine those modifier keys with other letters or function keys.

2. preference, this part is mostly for layout authors to consider.
   are you an inward or an outward roller? just imagine you playing a piano, and watch you finger rolling.
   do you prefer one hand combo or two hands alternation when typing? there is a lot of bigram or trigram in English. 
   do you prefer a layout that is formed by the logic of phonetic (vowel centered) or one by letter frequency?
   are you willing to compromise some feature to use a "do all" layout, or do you want a highly customized layout that just "right" for you?
Title: Re: Balanced Keyboard Layout
Post by: veruna on 2017-Mar-16 18:04
and I how do I put the @ above the ' ?

in Microsoft double pinyin, zhou is "vb".

I put a full set of spacing key (including del and enter) to the left hand thumb area is because when my right hand is holding mouse, I can edit txt without switching right hand.

by changing from MS double pinyin to XiaoHe double pinyin, I can finally kick the punctuation ";" out of the main area.

this is too complicate, it makes my head ache.
Title: Re: Balanced Keyboard Layout
Post by: Den on 2017-Mar-17 00:18
thanks for comprehensive reply into the pinyin issue. i don't type chinese, so didn't know about double pinyin. it sounds reasonable since mandarin is very structured monosyllables. For maximum efficiency, you might even want to optimize double pinyin if possible (just like one optimizes English text). however that may be limited or impossible by the IME software.

Punctuations can be personalized to suit your purpose without much impact on the letters.

there may be need to have subsets of BEAKL for various usages. like BEAKL EZ was a first attempt to compromise between English and Mandarin (full) pinyin. for better compatibility, the semicolon may be taken into consideration. but better yet, have the layouts be independent of the IME or qwerty punctuation.

You could put CTRLs on the thumb cluster. or in the worst case, move them to outside the pinky on the home row.

@ is shifted.

2. my answers to your questions:
Title: Re: Balanced Keyboard Layout
Post by: Den on 2017-Mar-19 21:02
new goals:

Assessments:


Ex.
Title: Re: Balanced Keyboard Layout
Post by: Den on 2017-Mar-22 07:14
Updated KLA on my site (http://shenafu.com/code/keyboard/Keyboard%20Layout%20Analyzer.html?#/config) with new Matrix keymap, which is Ergolinear with number row and two extra thumb keys. Therefore new BEAKL EZ Matrix layout. see attached. (Also fixed the unshifted letter to stay at the bottom left corner of the keycap.)

On actual keyboard, you can fill the numbers on the number row. I omitted them on KLA since I don't know how that would affect the scores. New BEAKL EZ Matrix scores similarly to BEAKL 5 Ergolinear, except 5 is somewhat better at code.

Also not shown is the ten-key layer that overlays the left hand. The math symbols are in the same place as normal or alt-gr layers, and the numbers are optimized as discussed earlier in this thread. Like so:
Code: [Select]
ten-key layer

  +=*
  3976
-5102,
 /48.:

Home fingers are 5102. Tab is hit with thumb on matrix layout. There is room for Enter at the pinky if you decide to include it.
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2017-Mar-22 07:30
Interesting. Is that a Delete key under Backspace? (ie on Alt-Gr)

Will ponder it later... :-)

Thanks, Ian
Title: Re: Balanced Keyboard Layout
Post by: veruna on 2017-Mar-22 19:37
Thx for the update Den.

I'm developing a new double pinyin layout based on BEAKL EZ Matrix. since all other double pinyin layouts are based on Qwerty.
Just rearranging the Chinese according to frequency is easy, but taking the finger travels into account is hard. and there are still some dilemmas I can't solve.

Will post the new design here once I find an acceptable solution.

Btw, there is an "export" button on your KLA site, can i just download it, save it as a hex file and flash it into my ergodox?
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2017-Mar-22 20:34
Btw, there is an "export" button on your KLA site, can i just download it, save it as a hex file and flash it into my ergodox?

That exports the KLA layout, for saving and re-importing into KLA. Won't work for your ROM... :-)
Title: Re: Balanced Keyboard Layout
Post by: veruna on 2017-Mar-22 20:50
That exports the KLA layout, for saving and re-importing into KLA. Won't work for your ROM... :-)

k, thx iandoug.
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2017-Mar-26 03:50
Updated KLA on my site (http://shenafu.com/code/keyboard/Keyboard%20Layout%20Analyzer.html?#/config) with new Matrix keymap, which is Ergolinear with number row and two extra thumb keys. Therefore new BEAKL EZ Matrix layout. see attached. (Also fixed the unshifted letter to stay at the bottom left corner of the keycap.)

Okay have fiddled with my local version and on second attempt and some cleanup, am able to import EZ. I'm not pre-loading it.

Can you remember where you did this: "Also fixed the unshifted letter to stay at the bottom left corner of the keycap." ?

Speaking of cleanups, your preloaded version of Arensito should be replaced with the "fixed" version ... the version in KLA is missing two characters.

I assume your ErgoLinear QWERTY is still a work in progress, given the missing characters :-) ... or are there enough there to test English prose?

Thanks, Ian
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2017-Apr-08 16:13
new goals:
  • more keys for gaming hotkeys
  • conjoin ten-keys math symbols into alt-gr layer
  • add number row and more thumb keys to ergolinear blueprint
  • retain some standard symbols unshifted (e.g. semicolon, slash)
  • may lose points in test, but should provide overall better intuitiveness and accessibility

Assessments:
  • Some games need a lot of hotkeys, especially for the left hand while driving the mouse with the right. Also they keys should be activated without any shifting in order give the best response time.
  • Output the same math symbols regardless if num-lock or alt-gr is down.
  • Returning number row will provide many benefits. Provides a simple way to type numbers. Provides more keys for gaming and for ten-key.
  • Certain keys have been hijacked by other input methods (ex. microsoft double pinyin dilemma as seen previously in this thread). So it behooves to retain those keys for accessibility and backward compatibility.
  • For the most part, we have optimized the letters very near to the theoretical limits (based on current understanding). So more care toward improving the overall keyboard experience.


Ex.
  • Number row left hand could contain +=*. Accessible by both ten-key and alt-gr with the same fingers.
  • Standard unshifted symbols would include .,'-/;  ... With .,-/ the same as their ten-key places

Okay, some comments on above.

1. I realised when doing the early iterations of my Programmers Keyboard that it would not be possible to balance programmers requirements with gamers requirements. So I expected to have two different versions for two different use cases.

2. re goals 2 - 5, not quite sure what you are doing with the numbers... I'm still going with a central numpad (latest version attached.... I've actually started building this. Consider it Prototype Number 1 :-) ).
I want to add numpads (conventional plus what I'm building) to KLA and then see what KLA tests say about them.

Re Assessment 4, that's a whole different ball game... I focused on English even though I sometimes have to type in Afrikaans, and live in a country with 10+ official languages. But today I stumbled across iBus for Linux/Unix, and realised that perhaps there's a better way to deal with the problem than with the limitations that a 104-keyboard imposes on us.

I first found this:
http://www.2daygeek.com/install-ibus-typing-booster-improve-speedup-your-typing-speed-in-arch-linx-fedora-debian-ubuntu-centos-opensuse/

then went to see about iBus... their self-docs are rather sucky, but it seems that it was designed as a better input method for East Asian languages:
see eg
github home: https://github.com/ibus/ibus/wiki
wikipedia: https://en.wikipedia.org/wiki/Intelligent_Input_Bus
Comparisons: https://blogs.gnome.org/happyaron/2011/01/15/linux-input-method-brief-summary/

I see from Wiki page that something similar exists for the Windows world.

Cheers, Ian
Title: Maltron
Post by: iandoug on 2017-Apr-13 18:25
Decided to see how Maltron layout does, converted onto ErgoDox form factor since that seems closest without making custom form factor for it.

Scores are not so good, with either your scoring or Patrick's.

Must still doublecheck all characters there, and put in the missing modifier keys etc.

Title: Re: How to make my own Balanced Keyboard Layout
Post by: jems on 2017-Apr-14 03:43
Hi all I am a normal pleb not clever at all.
However I have been trying to teach myself to type and it feels like BEAKL principles would be the best layout. I want to convert my keyboard to BEAKL layout so I learn a healthy less effortful layout that qwerty
So please can you tell me what to do?
This is what I think i need to do:
download and run a program like  MSKLC
Use the BEAKL layout to fill in the blank keys with BEAKL keys
(or do you already have a .msi file and setup file created for plebs that you are willing to share?)

put stickers on my keyboard for the new layout
teach myself to type using BEAKL layout
be happy.
many thanks
jems
Title: Re: Maltron
Post by: iandoug on 2017-Apr-14 15:21
Decided to see how Maltron layout does, converted onto ErgoDox form factor since that seems closest without making custom form factor for it.
Scores are not so good, with either your scoring or Patrick's.
Must still doublecheck all characters there, and put in the missing modifier keys etc.

Fixed. Attached.
Title: Yak
Post by: iandoug on 2017-Apr-16 15:46
Stumbled across this:

https://github.com/wincent/yak-layout

Layout is 'curious' given that it was evolved. Initial testing does not show it performing very well.

JavaScript would not be my first choice language for a layout evolver... :-)

Cheers, Ian
Title: Re: How to make my own Balanced Keyboard Layout
Post by: Den on 2017-Apr-17 23:53

I agree I (we) should provide easy ways for users to install BEAKL.

I use and prefer autohotkey. This script converts Dvorak into BEAKL EZ:
http://shenafu.com/code/keyboard/dv2beakl ez.ahk (http://shenafu.com/code/keyboard/dv2beakl ez.ahk)

note some keys have been remapped on my Kinesis keyboard. like ` and \ to the outside pinky. numlock to the left of number row.

MSKLC is probably the better solution long term. but I don't have experience with it.

Title: Re: Yak
Post by: Den on 2017-Apr-18 13:09
Stumbled across this:

https://github.com/wincent/yak-layout

Layout is 'curious' given that it was evolved. Initial testing does not show it performing very well.

JavaScript would not be my first choice language for a layout evolver... :-)

Cheers, Ian

It's looks really lopsided to the left hand (and the KLA confirms my suspicion). What is the deal with the top row? He says he wants to reduce pinky usage, but his layout has 'DAU' all on the left pinky.

JavaScript could be interesting if it was a webpage that has UI to allow users to fidget with the parameters. Nothing to download or install. Alas that doesn't seem to be the case. (Although after seeing his layout, I wouldn't trust it anyway.)
Title: Re: Balanced Keyboard Layout
Post by: Den on 2017-Apr-18 14:19
MSKLC is crap. found Keyboard Layout Manager instead: http://www.klm32.com/ (http://www.klm32.com/)
Title: Re: Yak
Post by: iandoug on 2017-Apr-18 14:46
(Although after seeing his layout, I wouldn't trust it anyway.)

I've been poking around the web and came across this:

RSTHD layout: https://xsznix.wordpress.com/2016/05/16/introducing-the-rsthd-layout/

I loaded it on ErgoLinear as an AltGr layout, actually installed over my x6.4 layout which is top scorer at the moment, so it inherited some punctuation placements from that, others were as per layout and the rest where I thought best.
Scores are pretty good.

Have also put Maltron onto ErgoDox (did I say that before), and both Maltron and RSTHD do pretty well at the bi-tri-quad-etc tests.  Especially the 7/8/9-gram versions. Normal English better than most.... suppose is affected by where they put the periods, commas and brackets etc.
Want to put Maltron onto ErgoLinear  as well.... compare apples with apples :-)

The Plum layout is also above average so far in initial tests (loaded on ErgoLinear as per above): https://en.wikipedia.org/wiki/PLUM_keyboard

And then clearly we are missing out on a fortune in patent royalty income...  :-)
http://www.xpertkeyboard.com/

Cheers, Ian
Title: Re: Balanced Keyboard Layout
Post by: Den on 2017-Apr-18 15:32
RSTHD scores about 2-6% better than BEAKL EZ on Matrix. We can surmise that letter on thumb has some benefits. However compared to your -+T+- HT01-75.54 layout that puts H on the thumb, RSTHD is about 5% worse. So it still seems our results from Opt for putting H instead of E on thumb is preferred and more optimal.
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2017-Apr-18 16:02
RSTHD scores about 2-6% better than BEAKL EZ on Matrix. We can surmise that letter on thumb has some benefits. However compared to your -+T+- HT01-75.54 layout that puts H on the thumb, RSTHD is about 5% worse. So it still seems our results from Opt for putting H instead of E on thumb is preferred and more optimal.

Yeah I tried E, T, A, N on thumb and it just would not get better scores... that's how I ended up with H.

Anyway came across this on the Colemak site:


Colemak using MK-Type V2.Staggerfix (Left thumb uses bottom row)
___________________________________________________________
| q | w | f | p | g | 7 | 8 | 9 | ` | [ | ] | \ | / | BSp |
|   A | R | S | T | d | 4 | 5 | 6 | j | l | u | y | ; | ' |
|    z | x | c | v | b | 1 | 2 | 3 | h | N | E | I | O    |
|        |   |   |   |   | 0 | - | = | k | m | , | .      |
| Ctr | Wn |     | Shift              | Spa | W | M | Ctl |
-----------------------------------------------------------

Where the key takeaway is the split home row ... (caps are home).

Interesting idea. Although I really don't know why they waste time trying to find a good layout on a keyboard designed for two right hands (as someone here described it... :-) )
The whole ANSI/ISO thing must be chucked in the bin where it belongs.

Was trying to load it but don't know where the other characters go and how they end up with so many blank keys... so just gave up.

Cheers, Ian
Title: Re: Balanced Keyboard Layout
Post by: Den on 2017-Apr-19 15:00
Any theory why H on thumb scores best?

Maybe due to being the most frequent bigrams and trigram. Split the trigram THE. This has 2 consonants and 1 vowel. To balance the rest of the keyboard, 1 consonant--the middle one--is moved to thumb.

moreover Maybe these algorithms don't punish thumb - finger bigrams. I saw something in Opt that penalize thumb - index. But we can assume T E goes on middle finger, which is not affected by this penalty. So it seems middle finger is more premium location than thumb. If E is on thumb, then best place for TH is roll inward. Noting that in some algorithms rolling is less optimal than alternating fingers, especially if alternation involves thumb.

RSTHD uses the same hand for all 3 letters of the trigram most common trigram THE. which works for him since he prefers 2 and 3 keys long sequences.

(notably RSTHD is yet another layout that divides into vowel and consonant districts. also it has space on the vowel side, just like what we've discovered earlier.)

Actually studying my digram chart (http://www.shenafu.com/digrampop.html) , I think I see (partly) why H works best at thumb instead of other letters. There is a parallel amongst the four most common bigrams, including the space character.

E_
_T
TH
HE

1. The top 4 digrams are made of 4 different characters. So the thumb keys should nominate these as highest priority.

2. H is in the exact same situation as space, relative to T and E.

3. Putting T or E on thumb would imbalance the other bigram. ex. if E is on thumb, then TH must be typed with fingers. conversely, T on thumb means HE is typed with fingers.

4. If H is on thumb, both bigrams score better because thumb is involved for both.

5. Just realized that any finger to thumb is really an inward roll. So if H is on thumb, ideally it should on the same hand as T to make TH an inward roll. on the contrary, HE on the same hand is an outward roll. Same deal with space (instead of H).

6. Once you put more letters on the thumb, H falls out of favor. for instance, 3-letter thumb clusters are optimized for I_RN. see previous post for such a layout: http://shenafu.com/smf/index.php?topic=89.msg835;topicseen#msg835 . (Amazingly vowel and consonant districts are still maintained.) This seems to agree with my assessment that finger-thumb is inward roll. consider bigrams like: ei, ai, oi, tr, pr, dr, fr, gr, cr.


Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2017-Apr-19 15:26
Any theory why H on thumb scores best?

I think you nailed it :-)

Just realised how to load that split-home layout above, but busy running all tests on a whole bunch of new layouts at the moment and I'm not going to start over again... literally takes a more than a day, and ties Firefox up.

Will put it in the next batch, if there is one. In tests so far (English) RSTHD is beating Maltron on ErgoLinear, most cases.

Discovered there's a bug in latest AJAX results code, works in Firefox but not Chrome so need to track it down before I can roll the results to live. Hate those sort of bugs :-)

Busy soldering my first DIY keyboard ...

Cheers, Ian
Title: Re: Balanced Keyboard Layout
Post by: Den on 2017-Apr-20 07:15
N on the thumb seems the exception, as all its common bigrams are outward rolls. maybe moving N to thumb would reduce same finger usage. having all three STN on the fingers seems crowded.

Actually P_RN, L_RN and U_RN are even better than I_RN.

Code: [Select]
\/ou-   bdmcq
zeai.   phtsy
j"'.x   kfwgv
    l_ rn

Code: [Select]
\/ou-   fdlcz
jeai.   yhtsb
q"',x   kmwgv
    p_ rn

Code: [Select]
\/o.x   bdclq
zeaiy   fhstw
j"',-   kpgmv
    u_ rn

Note left top pinky can be left empty. Moving 3 letters to thumb leaves one of the finger keys unused.

Some KLA tests seem to suggest 1-letter-on-thumb (-+T+- HT01-75.54) scores slightly better on regular prose and bigrams/trigrams test than these 3-letters-on-thumb layouts. But sometimes that layout (-+T+- HT01-75.54) does quite poorly on real world texts (social media, random cut-paste). Regardless, these 3-letters-on-thumb layouts score consistently high on all forms of text.
Title: Re: Balanced Keyboard Layout
Post by: Den on 2017-Apr-20 07:22
If you're going to move the home row on a regular (unergonomic) keyboard, maybe move the whole row up so that the formerly bottom row can be used as thumb row. then put the letters and space on the thumb row as discussed.

We know Arensito moves entire rows up, but it didn't try to put letters on the thumb row. Modified with thumb-letters, Arensito would score much better for text, plus it already scores great on code. That could make it a serious contender.
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2017-Apr-20 07:28
Some KLA tests seem to suggest 1-letter-on-thumb (-+T+- HT01-75.54) scores slightly better on regular prose and bigrams/trigrams test than these 3-letters-on-thumb layouts. But sometimes that layout (-+T+- HT01-75.54) does quite poorly on real world texts (social media, random cut-paste). Regardless, these 3-letters-on-thumb layouts score consistently high on all forms of text.

"-+T+- HT02a" does much better at English (entire left column on my comparison site) than "-+T+- HT01-75.54" ... average effort 91.8 vs 97.7.

Do you have some scores handy? Eg Alice?

Thanks, Ian
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2017-Apr-20 07:38
Some KLA tests seem to suggest 1-letter-on-thumb (-+T+- HT01-75.54) scores slightly better on regular prose and bigrams/trigrams test than these 3-letters-on-thumb layouts. But sometimes that layout (-+T+- HT01-75.54) does quite poorly on real world texts (social media, random cut-paste). Regardless, these 3-letters-on-thumb layouts score consistently high on all forms of text.

One version of my programmer's keyboard had E, T, space and return on the thumbs... but testing with Ergodox on KLA failed to get good scores... maybe there were other issues at play but I just could not make it work. I probably dragged N and A into the mix as well before ending up at H. It's something to look at again, with months of experience to help :-)

My X6.4 layout  (with h on same key as space, on left thumb) is still looking the best so far, except for 6/8/9-grams, where Maltron on ErgoLinear beats it.

About to start all the programming/tech tests.

Cheers, Ian
Title: Re: Balanced Keyboard Layout
Post by: Den on 2017-Apr-20 09:39
Now I kinda want to try 3-thumb layout on my kinesis. This also changes (upgrades? ) my former numpad that lacked a thumb key. Need to replan the entire physical keyboard.

Although a more programmable keyboard would be better for testing. (Hey lend me the DIY keyboard when you're done, will ya?  :P )
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2017-Apr-20 09:52
This also changes (upgrades? ) my former numpad that lacked a thumb key. Need to replan the entire physical keyboard.

Although a more programmable keyboard would be better for testing. (Hey lend me the DIY keyboard when you're done, will ya?  :P )

Funny you should mention numpad thumbkey... I did exactly that for next version (still in planning, while building version 1).

Screenshot attached :-)

Let me first see how version 1 turns out... :-)

Cheers, Ian

Title: Re: Balanced Keyboard Layout
Post by: Den on 2017-Apr-20 13:31
- renamed layout files to <label>.<type>.json
- edited scripts to load new file names (template.js, controller.js, /api/get-layout.php)

https://shenafu.com/code/keyboard/kla.7z


Title: Re: Balanced Keyboard Layout
Post by: Den on 2017-Apr-20 20:38
"-+T+- HT02a" does much better at English (entire left column on my comparison site) than "-+T+- HT01-75.54" ... average effort 91.8 vs 97.7.

Do you have some scores handy? Eg Alice?

Thanks, Ian

see attached. for random twitter text, -+T+- HT01-75.54 drops about 12% performance. probably not optimized for puncts, so hiccups at URLs? Tower of Hanoi code, it drops 21%.

btw P_RN sounds sexy for layout name. <_<
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2017-Apr-20 21:26
see attached. for random twitter text, -+T+- HT01-75.54 drops about 12% performance. probably not optimized for puncts, so hiccups at URLs? Tower of Hanoi code, it drops 21%.

btw P_RN sounds sexy for layout name. <_<

Try attached. Note  my version of ErgoLinear is slightly different to yours.

Twitter URLs? You mean shortened? Basically random letters?

P_RN sounds interesting, like to see it :-)

Cheers, Ian
Title: Re: Balanced Keyboard Layout
Post by: Den on 2017-Apr-21 19:40
Now I kinda want to try 3-thumb layout on my kinesis. This also changes (upgrades? ) my former numpad that lacked a thumb key. Need to replan the entire physical keyboard.

Although a more programmable keyboard would be better for testing. (Hey lend me the DIY keyboard when you're done, will ya?  :P )

Kinesis Advantage thumb cluster doesn't feel good for finger-thumb rolling. might have to settle for 1 thumb-letter.
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2017-Apr-22 04:47
Kinesis Advantage thumb cluster doesn't feel good for finger-thumb rolling. might have to settle for 1 thumb-letter.

I suspect (without actually having tried it myself, but based on dummy keyboard tests when developing my own designs) that what looks good and obvious in terms of those thumb clusters, is not so practical given the angle that our thumbs operate at. This unsubstantiated opinion (:-)) applies to Maltron and children (Kinesis and ErgoDox). But lots of people swear by those layouts so maybe I'm wrong.. :-)

You use Vivaldi, right? Which is Chromium in disguise... which is (back to roots) based on KHTML. At the moment local versions of KLA do not work in either Chromium or Konqueror (using either of the two supported render engines). The page loads without text. So I thought it was font-related... Firefox say the site uses Lato, pulled in via Google font api. Don't have it installed locally (strangely enough... only Noto family). But I can't figure out why Firefox has no trouble but my other two browsers don't work.

The live version works fine in both browsers... so I dunno if local version has some bad change that's breaking it or what. Most annoying. Maybe I must pull remote to separate folder and run some diffs. And start using git.. :-)
Title: Re: Balanced Keyboard Layout
Post by: Den on 2017-Apr-22 14:42
I suspect (without actually having tried it myself, but based on dummy keyboard tests when developing my own designs) that what looks good and obvious in terms of those thumb clusters, is not so practical given the angle that our thumbs operate at. This unsubstantiated opinion (:-)) applies to Maltron and children (Kinesis and ErgoDox). But lots of people swear by those layouts so maybe I'm wrong.. :-)

The problem is the main thumb keys are long, which obstruct the other keys. This is okay for independent utility keys, but not for combination rolling with fingers, especially when speed and accuracy is involved. Big keys also affect the impact point of striking a key. It feels weird to hit a key other than at the center.

Instead, they can split the big keys into smaller keys. This should improve rolling with fingers and provides extra keys for the thumbs.

Quote
You use Vivaldi, right? Which is Chromium in disguise... which is (back to roots) based on KHTML. At the moment local versions of KLA do not work in either Chromium or Konqueror (using either of the two supported render engines). The page loads without text. So I thought it was font-related... Firefox say the site uses Lato, pulled in via Google font api. Don't have it installed locally (strangely enough... only Noto family). But I can't figure out why Firefox has no trouble but my other two browsers don't work.

there's something about enabling cross-server scripts for local servers.

Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2017-Apr-22 15:55
The problem is the main thumb keys are long, which obstruct the other keys. This is okay for independent utility keys, but not for combination rolling with fingers, especially when speed and accuracy is involved. Big keys also affect the impact point of striking a key. It feels weird to hit a key other than at the center.

Instead, they can split the big keys into smaller keys. This should improve rolling with fingers and provides extra keys for the thumbs.

See attached for my attempt at a thumb cluster. Did not work as well as I thought it would.
It's one of the things I like about the ErgoLinear layout, but getting a single-size key (1U) that is thumb-friendly (ie convex rather than concave) seems to be impossible.

There's something about enabling cross-server scripts for local servers.

I installed Vivaldi, the 'developer tools' (which I suppose are straight from Chrome) tells me the Javascript is not being executed because it is text/octet-stream and not text/javascript. I presume this is because all the .js files end .js.download... will try renaming everything and see if that fixes it. Funny that Firefox handles the wrong mime type just fine. It's also sad that there are now effectively only 3 layout engines and JavaScript engines running the web (Google, Firefox and Microsoft...).

Am reluctant to rename all the layouts from standard.layoutname to layoutname.standard because then I need to also change them all in the iMacros script in Firefox that does the automated testing for me.
But I agree the standard.layoutname may have made sense in the past but now mixes up different variants of same layout.

Currently testing 182 layouts... need to remove all my 'experiments' so that it goes faster. Took over 3 days, and now the loading process is making me jump through hoops because I had slight differences in the layout files and the names I loaded into the database, and MariaDB for some reason is now doing case-sensitive searches where it never used to before...

Will post results table later.

Cheers, Ian
Title: Top layouts
Post by: iandoug on 2017-Apr-22 18:14
Finished loading all the tests locally. Will upload to live site tomorrow.

Anyway, here's the current top layouts (selected), I dropped the decimals
LayoutStyleAll testsAll EnglishProgrammingAll other tech
X6.4H ErgolinearErgolinear11691113148
X6 ErgolinearErgolinear11697113141
BEAKL 4 Mod Ian AltGr 3ANSI123100118156
MTGap TS ErgoLinear 2Ergolinear124104122151
Maltron ErgolinearErgolinear12698128160
RSTHD ErgoLinear 2Ergolinear12697124162
Colemak TS ErgoLinear 2Ergolinear126101119160
Arensito ErgolinearErgolinear127110119151
Ian X4ANSI12899114171
Nawfal ErgolinearErgolinear129109121156
Dvorak ErgolinearErgolinear130111128155
BEAKL5 ErgoLinearErgolinear131109126160
BEAKL EZ MatrixErgolinear133107124169
schizoKBD-shifted ANSI133101120181
Plum ErgolinearErgolinear137118131161
ArensitoANSI137117127167
Arensito Kinesis Ergodox139111132177
Ergodox MTGAP ThumbshiftErgodox159105141231
-+T+- HT02a Ergodox16295137257
Ergodox Colemak ThumbshiftErgodox163104141243
Maltron 90 ErgodoxErgodox175101180265
AOEYK ANSI177112179265
Right Pinky's FriendANSI187119198275
Dvorak ANSI198124211295
VU KeysANSI200109199323
MTGapANSI200117206311
Balance TwelveANSI202112188328
QGMLWYANSI203117202322
ColemakANSI204115200324
Capewell ANSI210123205328
NormanANSI210126207325
QWERTYANSI229161224323
QWERTY ProgrammerANSI274162230438

Nawfal is here: https://forum.colemak.com/topic/955-how-about-this-layout/
Plum is here: https://en.wikipedia.org/wiki/PLUM_keyboard

I made both into Ergolinear by superimposing over my X6.4H layout.

Results seem to confirm strength of Ergolinear and/or AltGr punctuation/numerals, in particular X6.4 assignment.

Now have to retype all those numbers for my own page... :-((

Wonder what the Colemak fanbois will have to say ... :-)

Note: I've added a few more tests, which are quite heavy on the numbers: 500 blake2 hashes, and 500 (x2) "sums" like 4 + 5 - 2 /7 etc. So layouts with numbers on top row suffer. Also another 'words' test.
Cheers, Ian
Title: ANSI Top Ten @ English, just rearrange keys
Post by: iandoug on 2017-Apr-22 18:25
attached.
Title: Re: Top layouts
Post by: iandoug on 2017-Apr-23 08:50
Finished loading all the tests locally. Will upload to live site tomorrow.

Have loaded a representative sample of 60 layouts here:
http://www.keyboard-design.com/build-a-custom-keyboard-1/design.html
(scroll down a bit).

Scores for All tests, English tests, Programming tests, and Other Tech tests.

I dropped most of mine, yours, and Schizo's as well as most lesser-known ones, particularly the weaker ones.

There's some unfamiliar names on the list, found on the web (mostly on the Colemak forums). Some of them actually do quite well.

Cheers, Ian
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2017-Apr-30 06:51
Colemak using MK-Type V2.Staggerfix (Left thumb uses bottom row)

Where the key takeaway is the split home row ... (caps are home).

Just noticed that AOEYK also does a split-home-row thing.. has forefinger on traditional home row and the other three on the next row up. In fact seems a more natural approach for where to put the fingers.

Cheers, Ian
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2017-May-01 08:28
Anyway came across this on the Colemak site:
Colemak using MK-Type V2.Staggerfix (Left thumb uses bottom row)
___________________________________________________________
| q | w | f | p | g | 7 | 8 | 9 | ` | [ | ] | \ | / | BSp |
|   A | R | S | T | d | 4 | 5 | 6 | j | l | u | y | ; | ' |
|    z | x | c | v | b | 1 | 2 | 3 | h | N | E | I | O    |
|        |   |   |   |   | 0 | - | = | k | m | , | .      |
| Ctr | Wn |     | Shift              | Spa | W | M | Ctl |
-----------------------------------------------------------

Well this is interesting. I loaded the layout and ran it against Alice.

Scores attached.
Layout attached. "Enter" was left as an exercise for the reader so I put in on left ring, which I know from experience does good things to score.

Will include this layout in my next batch of tests. Must take a look at your pron as well... :-)

Cheers, Ian
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2017-May-01 08:49

Code: [Select]
\/ou-   fdlcz
jeai.   yhtsb
q"',x   kmwgv
    p_ rn

Where do you put  enter and altgr?

Do you have a complete layout handy?

thanks, Ian
Title: Re: Balanced Keyboard Layout
Post by: philippe.quesnel on 2017-May-03 22:36
Hi Den and Ian ;-)
I have been going through these posts and checking out your layouts / ideas ..
I tried using Den's 'costs', with some personal modifications (the 'angleZ' bottom left hand ergo mod popular w. Colemak) with the 'MTGAP' optimizer and I am getting some interesting results.

The original link I had originally followed, that brought me here, had higher pinky costs than the ones we can see on the 1st page of these messages.
In the "Newer thoughts" notes, Den mentions that the pinky costs should be higher .. so I used the costs in the other chart (9 vs 7 for pinky). I was wondering which costs are you actually using !??

ie
Original keyboard effort

Code: [Select]
7 1 1 1 3 3 1 1 1 7
5 0 0 0 2 2 0 0 0 5
7 2 3 1 3 3 1 3 2 7

or
Code: [Select]
9   1   1   1   5   5   1   1   1   9
5   0.5 0.5 0.5 2   2   0.5 0.5 0.5 5
9   2   3   1   5   5   1   3   2   9

??

thank you
Title: Re: Balanced Keyboard Layout
Post by: philippe.quesnel on 2017-May-03 22:41
oh, and Ian, do you have a blog explaining the special AltGr and remapped control keys, as in "BEAKL 4 Mod Ian AltGr 3" ?
what about arrow keys, insert etc where are those placed  / accessed ?
thx ;-)
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2017-May-04 01:50
hi Philippe
The original link I had originally followed, that brought me here, had higher pinky costs than the ones we can see on the 1st page of these messages.
In the "Newer thoughts" notes, Den mentions that the pinky costs should be higher .. so I used the costs in the other chart (9 vs 7 for pinky). I was wondering which costs are you actually using !??

Den will probably give a better answer but I think Patrick's KLA uses different weights to the charts you quoted. IIRC Den used the quoted weights in his version of the https://translate.google.com/translate?hl=en&sl=de&u=http://www.adnw.de/&prev=search (https://translate.google.com/translate?hl=en&sl=de&u=http://www.adnw.de/&prev=search) ADnW analyzer.
The actual 'weights' used depends on whether you are using Patrick's scoring or Den's scoring in KLA. Den includes vertical distance as well as horizontal distance.

Code: [Select]
KB.dScoring = []; // relative to KB.PRESSDISTANCE = 21;
// lower means more effortless
KB.dScoring[KB.finger.LEFT_PINKY] =    2.0;
KB.dScoring[KB.finger.LEFT_RING] =     1.3;
KB.dScoring[KB.finger.LEFT_MIDDLE] =   1.0;
KB.dScoring[KB.finger.LEFT_INDEX] =    1.1;
KB.dScoring[KB.finger.LEFT_THUMB] =    1.0;
KB.dScoring[KB.finger.RIGHT_THUMB] =   1.0;
KB.dScoring[KB.finger.RIGHT_INDEX] =   1.1;
KB.dScoring[KB.finger.RIGHT_MIDDLE] =  1.0;
KB.dScoring[KB.finger.RIGHT_RING] =    1.3;
KB.dScoring[KB.finger.RIGHT_PINKY] =   2.0;
KB.dScoring[KB.finger.BOTH_THUMBS] =   2.0;
KB.dMod = KB.dScoring.reduce( sumArray, 0 ); // sum of all values above

KB.fScoring = []; // relative to KB.PRESSDISTANCE = 21;
// lower means more effortless
KB.fScoring[KB.finger.LEFT_PINKY] =    2.0;
KB.fScoring[KB.finger.LEFT_RING] =     1.2;
KB.fScoring[KB.finger.LEFT_MIDDLE] =   1.0;
KB.fScoring[KB.finger.LEFT_INDEX] =    1.1;
KB.fScoring[KB.finger.LEFT_THUMB] =    1.0;
KB.fScoring[KB.finger.RIGHT_THUMB] =   1.0;
KB.fScoring[KB.finger.RIGHT_INDEX] =   1.1;
KB.fScoring[KB.finger.RIGHT_MIDDLE] =  1.0;
KB.fScoring[KB.finger.RIGHT_RING] =    1.2;
KB.fScoring[KB.finger.RIGHT_PINKY] =   2.0;
KB.fScoring[KB.finger.BOTH_THUMBS] =   2.0;
KB.fMod = KB.fScoring.reduce( sumArray, 0 ); // sum of all values above

Cheers, Ian
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2017-May-04 02:23
oh, and Ian, do you have a blog explaining the special AltGr and remapped control keys, as in "BEAKL 4 Mod Ian AltGr 3" ?
what about arrow keys, insert etc where are those placed  / accessed ?

Short answer: if the key is not shown, it does not matter where you put it as far as the scoring goes.

Long answer....

I have a rather outdated page which shows the layout on a full keyboard:
http://www.keyboard-design.com/layouts/100/ANSI-104-BEAKL4-Mod-Ian-AltGr-3.html
Those scores are from Patrick's KLA, so higher score is better.

KLA assumes a perfect typist who never makes mistakes, has no need for backspace or delete or to move around with arrow keys. My reality is very different :-)

The history of the AltGr layouts is buried in this discussion... basically Håkon Hallingstad who did the Arensito layout came up with the idea (as far as I can see) and we became aware that KLA was favouring this layout when it should not have been. The reason was that KLA only measured horizontal distances, and ignored vertical. Den redid the scoring to correct this at some point.

Then Schizo came along with his layouts, which did unusual things (even more than Arensito). The scores were annoyingly good, so I took a good look at how they were achieved. And built on that foundation.

The problem with Arensito/Schizo is that they are putting a good logical idea on a bad physical layout, the result is awkward for your hands and fingers to actually type. They will work better on Ergodox/Kinesis hardware.

This led to the development of the Ergolinear layout, which deals with some of the problems of Kinesis/Ergodox (those double-sized keys, excessive thumb cluster, etc.).

As above, the Ergolinear layout I used for testing does not concern itself with Nav keys.

But like I say, the physical ANSI keys are not going to be comfortable to type because the AltGr is too much under your hand. It's even worse on the Microsoft Natural (original version) that I currently use.

I'm guessing you're trying to figure out how to do these layouts on a GH60 or Planck or somesuch. I have not attempted that exercise yet... I don't like the Planck... prefer a split layout.

If you're interested you can look at the keyboard I'm building (which is going to be a "prototype", already planning the next version) here: http://www.keyboard-design.com/build-a-custom-keyboard-1/design.html
(see the glossy black X6.5 under the table).

Den's version of Ergolinear has nav keys on the bottom row (like Kinesis) ... mine leaves them blank and drops them in the real world.

I think if you're trying to translate this to a mini layout you may need another layer with Nav, function keys, maybe a more traditional numpad, etc.

Hope that helps :-)

Cheers, Ian


Title: Re: Balanced Keyboard Layout
Post by: philippe.quesnel on 2017-May-04 12:13
Thx Ian.
For the weights / costs, I was referring to the BEAK idea of a 3x3 "home grid" iso the traditional home row, hence the large costs on the pinkies, even on the home row. (are Den's and your layouts still based on this idea?)

Wow, designing your own keyboard !! You are more ambitious than me, bravo ;-)

I am using a traditional US keyboard .. have been thinking of getting a kinesis, but they are sooooo expensive !!
It would run me up to about $600CAD here in Montreal !! (without even being able to try it 1st)
And eventually, if I switch, I would want one at work (40hrs/week on the computer) and one at home ... $$$$
Actually at home I have a Microsoft Sculpt Ergonomic, better hand angles, separated hands, Alts more useable with thumbs, but still staggered !!!

I use special chars on AltGr with a numpad on Shift-AltGr
and an 'extend' layer on CapsLock (LAlt on the Sculpt) for arrow keys and copy/paste/cut/undo

Maybe I should stop fiddling with different layouts and stick to one ;-p
After +20yrs of computer programming I decided about a year ago to learn touch typing, and realized :
1) even after all this time on a keyboard, I was still starting from scratch
2) touch typing on QWERTY was crazy,
so might as well learn a new layout.
The rest is history, it's an interesting hobby though hehe

cheers, Phil
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2017-May-04 13:19
Thx Ian.
For the weights / costs, I was referring to the BEAK idea of a 3x3 "home grid" iso the traditional home row, hence the large costs on the pinkies, even on the home row. (are Den's and your layouts still based on this idea?)

FWIW my current layout proposals are simply those that get the best scores on Den's scoring on KLA, which is based on the weights I posted yesterday. I think that 3x3 grid was something Den was toying with but I don't think it was included in the scoring algorithm in KLA. I have reasonably frequently used letters on the pinkies (home row) and it works okay scoring-wise. 
For example me: I+R, Maltron: A+R, MTGap: I+R, Colemak: A+O ....

It's better to use the pinky now and then than to have to move a ring finger to access a key continuously. Also we only have 8/10 fingers and there's 26 letters + punctuation etc... so they all have to work :-)

The sad truth is that good keyboards are expensive. Save $50 a month... :-)

Cheers, Ian
Title: Splitting letters
Post by: iandoug on 2017-May-04 13:40
@Den...

So while reading the recent posts, I had a truly bizarre idea ... that the frequency of letters is different for uppercase and lowercase.

So "logically" the upper case and lower case should be on different keys... (yeah. Major learning curve.)

Google kicked this out: see table on page 390 in this PDF extract:
http://link.springer.com/content/pdf/10.3758%2FBF03195586.pdf
if that doesn't work, go here first and accept cookie:
http://link.springer.com/article/10.3758/BF03195586  (get the  supplementary material Jones-BRM-2004.zip (575 kb) here ... has the raw scores for all the ASCII chars.)

Executive summary: most common uppercase is TSANCINBRP, while most common lowercase is etaonisrhl.

I will need to play with to get into a usable form. Will see if I can run a test over the weekend. Suspect score will be good and usability difficult :-)
Interesting that s is so low in lowercase vs upper. And H does not even feature in upper (ranks 13). Which may be part of the reason why my X6.4 with h/H on space key works.

And what about E ... only ranks 11!
Food for thought. People will think I'm going insane... :-)
Title: splitting letters
Post by: iandoug on 2017-May-04 14:43
Nah, made a layout (attached), ran it against the English tests, scores are as per X6.4H +/- <0.5.

So no real improvement, unless my first allocation of Caps sucked.

Here's the frequency lists, I only played with the caps.
etaonisrhldcumfpgywbvkxzjq
TSAMCINBRPEDHWLOFYGJUKVQXZ

Cheers, Ian
Title: Re: Balanced Keyboard Layout
Post by: Den on 2017-May-04 15:25
I tried using Den's 'costs', with some personal modifications (the 'angleZ' bottom left hand ergo mod popular w. Colemak) with the 'MTGAP' optimizer and I am getting some interesting results.

The original link I had originally followed, that brought me here, had higher pinky costs than the ones we can see on the 1st page of these messages.
In the "Newer thoughts" notes, Den mentions that the pinky costs should be higher .. so I used the costs in the other chart (9 vs 7 for pinky). I was wondering which costs are you actually using !??

Code: [Select]
9   1   1   1   5   5   1   1   1   9
5   0.5 0.5 0.5 2   2   0.5 0.5 0.5 5
9   2   3   1   5   5   1   3   2   9



That chart is good enough for optimizers to find the ideal layout. I messed around with many permutations to see if it makes a difference to finding the best layout. For that matter, little changes to the finger effort costs don't play a big role. Other factors like hand alternation costs drastically affects the final layout.

Nevertheless, a standard chart is useful to compare the exact scores between vastly different layout families. Such as on KLA to compare layouts created by different people and software. But KLA uses a prescriptive scoring system for finger effort not easily visualized in a single chart.
Title: Re: splitting letters
Post by: Den on 2017-May-04 17:18
Nah, made a layout (attached), ran it against the English tests, scores are as per X6.4H +/- <0.5.

So no real improvement, unless my first allocation of Caps sucked.

Here's the frequency lists, I only played with the caps.
etaonisrhldcumfpgywbvkxzjq
TSAMCINBRPEDHWLOFYGJUKVQXZ

Cheers, Ian

What is the frequency of capital letters overall? If they are around punctuations frequency, then rearranging them wouldn't improve much, if at all.

Did you take into account bigrams? to avoid same finger and same hand penalties. e.g. 'M' is almost always followed by a vowel, especially 'e', so you should discourage putting them on the same key. likewise 'Co', 'Is', etc..
Title: Re: splitting letters
Post by: iandoug on 2017-May-04 18:39
What is the frequency of capital letters overall? If they are around punctuations frequency, then rearranging them wouldn't improve much, if at all.

Did you take into account bigrams? to avoid same finger and same hand penalties. e.g. 'M' is almost always followed by a vowel, especially 'e', so you should discourage putting them on the same key. likewise 'Co', 'Is', etc..

Re (1), that data is in the .zip file but I need to play with it. Also it's a bit suspect, eg they have a "web" corpus with ZERO "&" ... which surely can not be correct.

Re (2), no I did not, just worked through the list allocating in the usual manner, eg middle home, index home, ring home, pinky home, middle top, middle bottom, etc... leaving some where they are and mixing the alternation.  The cap vowels are no longer all on the same hand. Maybe they should be.

In this case M came out on e, with no other vowels on same finger. It was just a quick and dirty attempt, because I was actually busy with work work.. :-)

Am in two minds about spending more time on the idea. I also realised I should look at frequency of all chars overall (which may mean punctuation goes where caps now are, etc) and then got disappointed when I saw the issues in the supplied data. In testing the new layout was better in some cases and worse in others. Suppose it depends on which caps are used, and how many there are. Think it did better in the longer tests like Classics Collection. Was not better with Alice.

Learning such a layout is going to be a mission.... :-)
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2017-May-04 18:55
I use special chars on AltGr with a numpad on Shift-AltGr
and an 'extend' layer on CapsLock (LAlt on the Sculpt) for arrow keys and copy/paste/cut/undo


French? that's a different problem to English. I have been thinking about it... we basically need an entirely different approach to ISO layouts where they try to have a dedicated key for every possible ê é è ë, á à ß ø Ø etc etc. Too many combos to have a dedicated key. The Linux system with "compose" key is better (and is how I did those... with some effort, since I hardly use them). But how do we teach Windoze/Mac to do compose key method?

Or do we for example add another row to Ergolinear layout, with all the modifiers on, and then teach keyboard/host OS to understand what you mean when you type letter followed by modifier (which in effect is just another way of Linux Compose method)...

Wikipedia tells me that Compose method is possible on Windows and Mac...

The next problem is how to teach KLA to understand Compose sequences... so that we can evaluate ISO layouts... :-)
Title: Re: Balanced Keyboard Layout
Post by: philippe.quesnel on 2017-May-04 20:21
That chart is good enough for optimizers to find the ideal layout. I messed around with many permutations to see if it makes a difference to finding the best layout. For that matter, little changes to the finger effort costs don't play a big role. Other factors like hand alternation costs drastically affects the final layout.

Nevertheless, a standard chart is useful to compare the exact scores between vastly different layout families. Such as on KLA to compare layouts created by different people and software. But KLA uses a prescriptive scoring system for finger effort not easily visualized in a single chart.
ok, thank you
Title: Re: Balanced Keyboard Layout
Post by: philippe.quesnel on 2017-May-04 20:37
French? that's a different problem to English. I have been thinking about it... we basically need an entirely different approach to ISO layouts where they try to have a dedicated key for every possible ê é è ë, á à ß ø Ø etc etc. Too many combos to have a dedicated key. The Linux system with "compose" key is better (and is how I did those... with some effort, since I hardly use them). But how do we teach Windoze/Mac to do compose key method?

Or do we for example add another row to Ergolinear layout, with all the modifiers on, and then teach keyboard/host OS to understand what you mean when you type letter followed by modifier (which in effect is just another way of Linux Compose method)...

Wikipedia tells me that Compose method is possible on Windows and Mac...

The next problem is how to teach KLA to understand Compose sequences... so that we can evaluate ISO layouts... :-)

I use the AltGr layer for programming symbols stuff.

As for french, I kinda just ignored the problem (mostly) in general, in Windows I just switch off Autokey / PKL and goto French Canadian keyboard in the O/S. (switch layouts in Linux)

And yes, I guess that keyboard (standard Windows) does 'compose', but for a specific set of characters.
You can also create a keyboard that does this in MKLC (they're called dead keys)

Title: Re: splitting letters
Post by: iandoug on 2017-May-05 02:45
What is the frequency of capital letters overall? If they are around punctuations frequency, then rearranging them wouldn't improve much, if at all.

Took the spreadsheet, added the rows, sorted descending. Space is presumably first (and missing).

e t a o i n s r h l d c u m p f g . y w b - , v 0 k 1 T A I S 2 C ' " / 3 E D 9 : M N = R P ; 4 O B 5 ) L ( H F x 8 W 6 7 G _ U j q z J < ? Y @ * V K ! | $ ~ [ ] % X & + # Q Z } { > ` \ ^

Title: Re: splitting letters
Post by: iandoug on 2017-May-05 02:47
Took the spreadsheet, added the rows, sorted descending. Space is presumably first (and missing).

e t a o i n s r h l d c u m p f g . y w b - , v 0 k 1 T A I S 2 C ' " / 3 E D 9 : M N = R P ; 4 O B 5 ) L ( H F x 8 W 6 7 G _ U j q z J < ? Y @ * V K ! | $ ~ [ ] % X & + # Q Z } { > ` \ ^

the corpus clearly never had much programming text ... + should be much higher. And ; probably too, depending on language. Can't see how : would rank higher than ; unless you are dealing with dramatic scripts etc.
Title: Row allocation for Ergolinear
Post by: iandoug on 2017-May-06 05:59
@Den:

See attached, which is row usage analysis. The Ergolinear is assuming that there is a numrow, so everything is shifted up.
I've taken a look at the code and see that rowDisplayData has code for only showing 3 rows, but can't figure out where to change what to get row usage data correct.

Do you think this affects the scoring at all? From what I could see, scoring works off Home Finger Position rather than "home row"... or am I missing something?

Thanks, Ian
Title: Work in progress.
Post by: iandoug on 2017-May-06 06:10
Looks promising.
Number tests could be better. Will see if can optimise.
Title: shift-ALtGr
Post by: iandoug on 2017-May-10 12:57
@Den: any ideas about the wisdom/viability or otherwise of putting Space on shift-AltGr?

Been playing with layouts where it is set like that, (or Enter on Shift-AltGr) when it suddenly dawned on me that such things may be forbidden?... But on the other hand I've seen talk of putting CapsLock on Shift-Shift, so in theory it must be possible to define a modified modifier to do something unusual?

I suppose OS is going to play a role in this?...

Thanks, Ian
Title: There's a patent on that... :-)
Post by: iandoug on 2017-May-11 09:37
@Den Some time back in this long discussion you said something about the the vowels being on the left and the consonants on the right... there's a patent on that :-)

"1974 English Keyboard Scheme, U.S. Pat. No. 3,847,263 issued to X. X adopts the horizontal arrangement of QWERTY. X relocates 24 letters of the alphabet from their former location on the QWERTY keyboard; 2 letters retain their former positions (to wit: HX). X places 9 most used keys on the home row (to wit: AEHIONRST) and selects the vowel "U" for the 10th position. The X feature is to place the vowels (AEIOU) on the same side, to be typed by one hand, with consonants on the other side of the home row, to be typed by the other hand."

https://www.google.com/patents/US5718590

I was actually searching for some discussion as to why Burroughs-Bower layout never took off... it's vastly superior to QWERTY.
But patent above has some interesting reading.

I feel like I should patent some of my layouts, but 1) only patents worth having are US, Euro and maybe China, and
2) Costs of getting those .... will need lawyers in each territory. Just seems frightfully expensive for nothing... because if someone infringes then I need to sue them, again with the lawyers....

Given the silly layouts that got patented, what we (and others like MTGap, Capewell, Colemak etc) came up with should also be patented. Or something. On the other hand we all stand on the shoulders of giants...

So I dunno... I suppose publishing online provides "prior art" to stop someone else hijacking the designs.

Current "Seelpy" layout I'm working on is a notch above others in testing so far, but it's unlike anything else I've seen on a keyboard. (It actually is "new/novel" and qualifies for a patent AFAICS.) So public acceptance is going to be difficult, despite the obvious benefits for the fingers. Will publish once testing is done (after now restarting for the 4th or 5th time).

In other news Halmak has released a new/final version, which I've added to my mix: https://github.com/MadRabbit/halmak

Not sure how he is measuring or how Workman is rated so much better than Colemak... my testing puts Colemak in the top echelon with MTGap, Maltron, VU Keys and RSTHD (all on ErgoLinear). Didn't make Workman ErgoLinear because its ANSI and Ergodox scores were not that good.

Cheers, Ian
Title: Maltron
Post by: iandoug on 2017-May-11 09:46
Mmm so they also mention the Maltron layout which is patented...

https://www.google.us/patents/US4244659

Was wondering about that.
Title: Re: Balanced Keyboard Layout
Post by: philippe.quesnel on 2017-May-11 12:08
Didn't know there were patents on keyboard layouts !!
which brings me to this: Ian, do you mind if I use your 'BEAKL 4 Mod Ian AltGr 3' alt layer ?

I have been trying out layouts using the Arensito / Ian AltGr 3 idea (putting digits / symbols on alt layer), with a (slightly) modified version of the MTGAP optimizer.

Since I'm using std keyboards, I am trying the idea of using Space as the Alt/layer key.
With Autokey I can use space as an alt key AND as the normal space.
If only I could use the 2 spacebars on the Ergo Sculpt as separate keys .. it would be just incredible !! (2 thumbs !)

Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2017-May-11 12:40
which brings me to this: Ian, do you mind if I use your 'BEAKL 4 Mod Ian AltGr 3' alt layer ?

Be my guest ... :-) Like to know how it feels in practice.
FWIW the X4 variant is slightly better than the AltGr 3 ... it was developed from AltGr3 and I changed the naming scheme.
I probably need to revisit the ANSI layouts in light of what the better ErgoLinear layouts do. But ANSI is just so bad in too many ways that I got annoyed with it :-)

Since I'm using std keyboards, I am trying the idea of using Space as the Alt/layer key.
With Autokey I can use space as an alt key AND as the normal space.
If only I could use the 2 spacebars on the Ergo Sculpt as separate keys .. it would be just incredible !! (2 thumbs !)

How do you use space as an Alt key? Shift=space or somesuch?

I assume you are on Windows, there should be some software that will allow you to sniff the "scan code" that the keyboard is sending the OS when a key is pressed. Possibly if you are lucky, the two space bars are sending different codes, and it's the OS that "knows" that both are space bar... and which you may be able to modify....?

Nah, scratch that ... looks like MS only built in a backspace on left hand space.
https://superuser.com/questions/687615/microsoft-sculpt-keyboard-linux-support

Title: Re: Balanced Keyboard Layout
Post by: philippe.quesnel on 2017-May-11 14:33
Be my guest ... :-) Like to know how it feels in practice.
FWIW the X4 variant is slightly better than the AltGr 3 ... it was developed from AltGr3 and I changed the naming scheme
Great thank you. I will have a look at X4
I have files on GitHub, so I give credit to the original author there :-)
How do you use space as an Alt key? Shift=space or somesuch?
I assume you are on Windows, there should be some software...
Yes, as I mentioned I'm using AutoHotkey (on Windows). I believe Den is using it also.

You can remap keys to other keys.
It also supports two keys hotkeys,
so you can define for example Space & J :: LeftArrow,
normally the prefix key becomes 'hidden', but if you also define Space :: Space, then space can be used normally.

I Just started using this, and sometimes if space is typed too quickly vs another key, they end up actually being typed together, which does not give the wanted results ;-p

Possibly if you are lucky, the two space bars are sending different codes
Unfortunately, as you found out (thx for looking!) the Sculpt Ergo outputs the same scan code for the two space bars.
I believe in the previous generation it could be programmed to have one of the two space bars output a different key, something like Control, but this is not supported anymore
Title: Re: Balanced Keyboard Layout
Post by: philippe.quesnel on 2017-May-14 16:26
Hi again.
I had been using a slightly modified version of MTGAP,

and now just started using AdNW and was wondering if you (Den?, IanDoug?) were usually running with the the -2 or the -3 option ?

Also, do you use as input "..the files with -t in their name, only digrams and trigrams are accounted for that are in the interior of words and that do not contain hyphenation points." or the 'normal' ones ?

thx
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2017-May-14 17:06

and now just started using AdNW and was wondering if you (Den?, IanDoug?) were usually running with the the -2 or the -3 option ?


Regret have spent all my time with KLA and not yet got around to playing with AdNW .. but it looks like time with KLA may now be coming to a slower use and then I can start with AdNW and see what it has to say about the layouts.

Den is good with AdNW.

Cheers, Ian
Title: Re: Balanced Keyboard Layout
Post by: philippe.quesnel on 2017-May-14 17:18
Regret have spent all my time with KLA and not yet got around to playing with AdNW .. but it looks like time with KLA may now be coming to a slower use and then I can start with AdNW and see what it has to say about the layouts.

Den is good with AdNW.

Cheers, Ian

ok thank you .. this is a very time consuming 'hobby' indeed !! ;-)
Title: Re: Balanced Keyboard Layout
Post by: philippe.quesnel on 2017-May-14 17:19
I am also beginning to question the "I love rolls" thing... looking into more alternation.
It seems that rolls are easier to me (brain wise), but might be causing tensions in my left forearm,
and at the same time, rolls between pinky-ring finger on the left hand feel pretty weak.
ie INEA left hand mtgap !!

Was wondering what your preferences / experiences / thoughts were on this topic  ?
merci
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2017-May-15 02:48
I am also beginning to question the "I love rolls" thing... looking into more alternation.
It seems that rolls are easier to me (brain wise), but might be causing tensions in my left forearm,
and at the same time, rolls between pinky-ring finger on the left hand feel pretty weak.
ie INEA left hand mtgap !!

Was wondering what your preferences / experiences / thoughts were on this topic  ?

Regret I am not the best person to ask about that... see the pic of my hands below. Was born that way. So I tend to use ring finger where others will use pinky, and thus my opinions are academic based on numbers in tests rather than personal experience.

In truth after you previous to last message about bigrams I was thinking about the difference in bigrams/trigrams inside a word as opposed to at the end, because at the end it's in effect a trigram (bigram+space) rather than a simple bigram that you are measuring, and how to type a space makes a big difference (if space is not on the big space bar.). This effect surfaced in my latest round of tests, where I paid attention to some layouts where space is not on the space bar (eg schizoKBD-AltGrSpc).

So yeah, I can imagine that IN on left pinky/ring would get to you. For what it's worth, Maltron puts AN in the same space, and you probably type AND more than IN ...

I've finished with the tests rounds, so by way of comparison, here's a curated list of the top layouts (all Ergolinear) as a way of comparing how they handle that roll, and alternation.
Base scores (as per Den's scoring, lower is better):

X6.4H Ergolinear115.3
Vu Keys Ergolinear 1119.2
QGMLWY Ergolinear 1123.5
SorenK Ergolinear 1123.6
Maltron Ergolinear124.5
MTGap Thumbshift Ergolinear 2124.8
RSTHD ErgoLinear 2125
Colmak Thumbshift Ergolinear 2125.7
Arensito Ergolinear128.8

Next two positions were Nawfal Ergolinear (129.7) and Dvorak Ergolinear (131.3), then three BEAKL layouts (131 to 133 scores).
Note: all of these layouts are in effect "LAYOUT mod X6.4H" ..  I based the AltGr level off of the X6.4H layout, some layouts had punctuation already specified, so I left that, and filled in the gaps as per X6.4H and "best guess". Possibly/probably some can be improved.
QGMLWY is an evolved layout from Martin Krzywinski (the CarpalX project).
SorenK I found on the Colemak forums as ANSI and turned into ErgoLinear when I saw how it did as ANSI.
https://forum.colemak.com/topic/90-dvorak-user-pondering-punctuation-placement/#p406

Layouts attached for discussion :-)
Title: Re: Balanced Keyboard Layout
Post by: philippe.quesnel on 2017-May-15 13:44
thank you again.
I guess with much shorter pinky, my current/old typing technique would be perfect, I don't really use the pinky ;-)

I tried out the default layout generated by AdNW (with a US kbd config I created) and it looks interesting,
even though I am kinda slow with it now, it's not as natural (less rolls, which I am more used to),
but it does feel comfortable / less stresses, I'll try it out a bit more.

I spent time on CARPALX before and didn't really like .. numbers/stats vs personal taste I guess !?
I'll have a look at SorenK, especially since you say it was doing well on ANSI, thx

X6.4H seems to be doing well whatever you're testing ! ;-)
explains that it's on top in the general scores !

Ergoooooo rules !!! hehe

bonne journée
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2017-May-15 14:51

X6.4H seems to be doing well whatever you're testing ! ;-)
explains that it's on top in the general scores !


It's not the best at some of the number-based stuff. As mentioned before, it's difficult to optimise for both natural language and programming/numbers etc.

However in the real world if you're entering a lot of numbers you'd use the numpad not the main 30-keys area. So I try to focus on English mainly. Den tries to cater for Eastern languages as well, which is a lot harder, I think :-)

I actually have a new layout (Seelpy) which is even better at English etc, but it is dramatically unconventional and I'm not sure how it will work in the real world. I'll post it in the next few days. Looks like getting a patent is not going to be viable... besides which new layouts have a stunning worldwide rejection rate.... :-)

Apart from SorenK, take a good look at Vu Keys. (either ANSI or Ergo). It's annoyingly good. Here's the ANSI top scores for my English tests:

Colour guide:
green: Keys are just rearranged
yellow: Keys are rearranged and modifiers relabeled
blue: Keys are relabeled (anything goes)
pink: Digits and/or punctuation are accessed via AltGr

Vu Keys is best for "just rearrange" the keys .... Colemak was 18th with 118, SorenK 25th with 120, and MTGap 28th with 120 (ignoring decimals). QWERTY scored 167.

Cheers, Ian
Title: Vu Keys
Post by: iandoug on 2017-May-15 14:57
@Den don't suppose you've come across Dang Vu, who I think is the person behind Vu Keys (and presumably the almost identical dangvu that's in Patrick's github repo)?

Google turned up a doctor but I'm not sure it's the same person...
Title: Scoring algorithm
Post by: iandoug on 2017-May-16 04:26
@Den:

If I understand the scoring algo correctly, then we measure from home to key, plus press, plus back again to home.

That makes sense in most cases, except when same key needs to be pressed again.

But I can see another situation ... say you are entering a long number. Then it will make no sense to keep returning to home, because you are going to need to move back to the digits row (eg QWERTY) again most likely.

I suppose coding that sort of logic is going to be very difficult. On the other hand, for tests involving numbers, any layouts with digits on home row will benefit greatly. That's part of the reason why the X6 layouts get good score... the four most common digits are on home row. But this reduces English scores slightly (eg we could have used the same slots for () or ? or ! or ; or : and boosted English score).

I was contemplating tweaking the scoring to NOT assume an automatic return to home, but I can see it's not a trivial change, if doable at all. We can't have a situation where index and ring are on bottom row (waiting for next move) while pinky has to go to top row...

Title: Re: Balanced Keyboard Layout
Post by: philippe.quesnel on 2017-May-16 12:04
I tried Vu keys, very nice, interesting balance of rolls vs alternation, feels comfortable.
Also a great candidate for the 'AngleZ' and 'Curl' mods as done in Colemak ModDH, which suits my taste.

Didn't care too much for Sorenk's OstnReai.
(of course these are all quick tests, typing texts from the net .. maybe if I properly learned the layouts I would appreciate them more)

It's all so personal, right !?

And a scoring algo might say "this layout is great" .. but maybe *I* won't like it as much as one that has a lower score,
where someone else would go gaga over it.

You bring a good example of that iandoug, with the subject of "we don't always go back to Home"
I agree that in some circumstances, I'll keep my hand hovering over a previous key because I know the next key I'll type with that hand is already under my fingers.
Or use different 'non-std' fingers for some key combinations.

I had this crazy idea of 'dynamic/adaptive layouts' recently, since the layouts are constructed to be efficient with the most used characters and bi-tri-grams, some words / key combinations are logically going to be harder to type (vs the most used)
So I was thinking, what if I could (easily) switch to partial layouts (/layers) that are better with less common characters ?
Would the cost of the actual switching layer/layout be worth the easier typing of garder words ?
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2017-May-16 15:37
I tried Vu keys, very nice, interesting balance of rolls vs alternation, feels comfortable.

Thanks, good to hear. It does share some similarities (though hands are swapped) with what Den and I evolved, but I never used it as a starting point. It wasn't even on my radar until I started doing comprehensive tests with all the layouts.

I had this crazy idea of 'dynamic/adaptive layouts' recently, since the layouts are constructed to be efficient with the most used characters and bi-tri-grams, some words / key combinations are logically going to be harder to type (vs the most used)
So I was thinking, what if I could (easily) switch to partial layouts (/layers) that are better with less common characters ?
Would the cost of the actual switching layer/layout be worth the easier typing of garder words ?

The real cause of the difficult combos is something simple (like all good magic tricks, the secret is simple).

I will post something either later tonight or tomorrow (busy with major upgrades to my site now, it's all intertwined).
Part of the answer to your question is how do you switch layers... with a pinky on shift? Or a thumb that lives on shift, and another thumb that lives on AltGr, and hardly has to move?

Which is why the Ergolinear (and Ergo Thumbshift) layouts score so well.. take the work off the pinky.

More later :-)
Title: Seelpy 1
Post by: iandoug on 2017-May-16 18:06
Okay it's nearly tomorrow here, been busy with this stuff most of the day and I need to get some sleep... :-)

1. I have posted the results of the latest round of tests on my site. It includes the new layouts and well as new tests.
http://www.keyboard-design.com/best-keyboard-layouts.html

2. I made a page about Seelpy 1, the new best performer. Comments welcome. Please be gentle. I know it's unconventional and may not work in the real world.
http://www.keyboard-design.com/layouts/ergo/60/seelpy-1-ergolinear.html

3. Loaded the new layouts and presets to the fork of KLA. If the layouts still appear to be Numbered, you need to clear your cache or hard-reload the page. You're getting the old version.
http://kla.keyboard-design.com/#/config

4. Or you can interrogate the database (ANSI or Ergo) from the links here, follow the Den Scoring ones.
http://www.keyboard-design.com/best-layouts.html

Please report any problems :-)... I think I checked most things.
Title: Re: Seelpy 1
Post by: philippe.quesnel on 2017-May-16 19:48
Okay it's nearly tomorrow here, been busy with this stuff most of the day and I need to get some sleep... :-)

1. I have posted the results of the latest round of tests on my site. It includes the new layouts and well as new tests.
http://www.keyboard-design.com/best-keyboard-layouts.html

2. I made a page about Seelpy 1, the new best performer. Comments welcome. Please be gentle. I know it's unconventional and may not work in the real world.
http://www.keyboard-design.com/layouts/ergo/60/seelpy-1-ergolinear.html

3. Loaded the new layouts and presets to the fork of KLA. If the layouts still appear to be Numbered, you need to clear your cache or hard-reload the page. You're getting the old version.
http://kla.keyboard-design.com/#/config

4. Or you can interrogate the database (ANSI or Ergo) from the links here, follow the Den Scoring ones.
http://www.keyboard-design.com/best-layouts.html

Please report any problems :-)... I think I checked most things.
Wow great work !!!  :D

I happened to notice that the link for BLOU in KLA was not working ..
so just in case, here's the link to the blog where it's from (mtgap) :
https://mathematicalmulticore.wordpress.com/2010/06/24/new-keyboard-layout-project-have-we-been-mistaken-all-along/

ps: BLOUREA, as I call it, is on my list of "hmm, kinda like this".
Haha problem is, this list is currently growing iso shrinking !!

I am very very curious about Sleepy, heuu I mean Seelpy.  ;)
Since I'm a bit nuts and always hoping to find "the one", I'll try and see about a US kbd version, using my AutoHotkey 'Space is space and AltGr' newest thing (or something like that)
I will very probably need to finally get on the Remapped Control Keys bandwagon too.

have a good rest
Title: Re: Balanced Keyboard Layout
Post by: philippe.quesnel on 2017-May-16 20:04
hmmm, Seelpy really needs two thumb keys to make sense, of course.
Hehe, still want to try it, so I'll try something like Space = Shift, AltGr = AltGr ;-)
Title: Re: Balanced Keyboard Layout
Post by: philippe.quesnel on 2017-May-16 23:44
Ok, so I have a working version of Seelpy on Windows with AutoHotkey using some of my autohotkey scripts for layers.

Since I don't have a key there, I moved the rightmost bottom key to 1st row  (could try to use Shift I guess).

So, Spacebar accesses the Shifted layer
Alt accesses the AltGr layer

.. and it's nuts !! as expected ;-p
I am able to use in this implementation Ctrl-C/V, Ctrl-D, Ctrl-Q also work ..
even though they are harder to use of course: Alt-Ctrl-.. or Space-Ctrl-..

The Alt layer is on "plain Alt" so left or right can be used, which I think is nice / works like when using either left/right Shifts. But I lose some normal Alt-XX shortcuts functionality.
Could just use RAlt for layer and get back std Alt-XX stuff (tried and it works)

All interesting experiments .. now I need to try to memorize this layout to see how useable it is with my setup.
And see how I like it hehe ;-)
(I do have help images on screen as part of my autohotkey scripts, but with 3 layers, you still have two other layers not displayed to find the next key !!)
Title: Re: Seelpy 1
Post by: Den on 2017-May-17 01:09
Hurry up and patent it. You're going to be rich!

Just home row and thumb seems fun.
Title: Re: Seelpy 1
Post by: iandoug on 2017-May-17 01:15
I happened to notice that the link for BLOU in KLA was not working ..

Um, can you be more specific? It works from here when I select it...

(yes, I copied the layout from that URL you posted)

thanks, Ian
Title: Re: Seelpy 1
Post by: iandoug on 2017-May-17 01:56
Hurry up and patent it. You're going to be rich!

Just home row and thumb seems fun.

I checked the numbers... I can't afford it, and I don't see any current manufacturers plonking down large amounts of money for something that will likely never be a big seller. QWERTY is too entrenched (just go ask the Colemak fanboys).

It looks like getting major market coverage will cost about 1 million Rands (about USD 76k at current rates). Then there are yearly renewal fees after that. That's before you even look at cost of manufacturing and marketing etc. I'm guessing Maltron only patented theirs in a few selected countries, and get a licence fee from Kinesis. They probably make more that way than from their own sales.

So yeah, getting rich would be nice, but the deck is stacked against small guys with radical ideas :-)

cheers, Ian
Title: Re: Seelpy 1
Post by: philippe.quesnel on 2017-May-17 11:44
Um, can you be more specific? It works from here when I select it...

(yes, I copied the layout from that URL you posted)

thanks, Ian
Oops, sorry for the confusion.

If I load BLOU, the link under "More Info" says "Web" and points to http://kla.keyboard-design.com/web which fails if I try to click it / follow it.

Which is why I posted the MGTAP link in my message, in case the link had been lost.

thx
Title: Re: Seelpy 1
Post by: iandoug on 2017-May-17 12:18
If I load BLOU, the link under "More Info" says "Web" and points to http://kla.keyboard-design.com/web which fails if I try to click it / follow it.

Which is why I posted the MGTAP link in my message, in case the link had been lost.

Ah, yes... I need to go through all the json files with the layouts and make sure they all have the correct info. What typically happens is I grab an existing layout, edit it, change the name, and save it... but the "meta data" is not directly editable via the web interface, you need to do in an editor and I tend to forget/skip that step.
It's on the ToDo list... :-)
Title: Re: Balanced Keyboard Layout
Post by: philippe.quesnel on 2017-May-17 12:24
"Newborn whales, dolphins and porpoises may be the first casualties of the Vancouver park
board's ban on new cetaceans at the Vancouver Aquarium."

.. what's so special about this sentence, you ask ?
1st thing I typed with Seelpy, during my lunch break hehe, it's something else that Seelpy !!

"Same finger" gets a new meaning here : when t-h is on the same key but different layers hihi ;-)
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2017-May-17 14:04
.. what's so special about this sentence, you ask ?
1st thing I typed with Seelpy, during my lunch break hehe, it's something else that Seelpy !!

"Same finger" gets a new meaning here : when t-h is on the same key but different layers hihi ;-)

Interesting choice. Yeah that t-h worries me, I've tried various things to split them up but so far nothing has worked in terms of improving the score.
I even swapped e with space, which worked for some tests but not others. Part of the problem is the T ... maybe that need to swap to left hand. I've tried moving it to index finger but no real difference, and then you end up with T-h on same finger, not good.

On the other hand perhaps when you get the timing right, as if playing a video game, then it may be extremely fast.

I must finish my keyboard that I can test that layout on Ergolinear hardware.  As well as the poor X6.4H...

On a totally unrelated note, I was quite horrified to see how badly the Workman Programmer layout does overall, given that I was originally going to use it for my keyboard. So I suppose there is some benefit to all this keyboard research after all...

At some point I must dangle this layout in front of the Colemak guys, and then run for cover... :-)
Title: Re: Seelpy 1
Post by: Den on 2017-May-17 18:40
I checked the numbers... I can't afford it, and I don't see any current manufacturers plonking down large amounts of money for something that will likely never be a big seller. QWERTY is too entrenched (just go ask the Colemak fanboys).

It looks like getting major market coverage will cost about 1 million Rands (about USD 76k at current rates). Then there are yearly renewal fees after that. That's before you even look at cost of manufacturing and marketing etc. I'm guessing Maltron only patented theirs in a few selected countries, and get a licence fee from Kinesis. They probably make more that way than from their own sales.

So yeah, getting rich would be nice, but the deck is stacked against small guys with radical ideas :-)

cheers, Ian

At least post entry to deskthority wiki. Some geekhack users who use advanced layers on ergodox may also appreciate this novel layout.
Title: Re: Seelpy 1
Post by: iandoug on 2017-May-18 01:44
At least post entry to deskthority wiki. Some geekhack users who use advanced layers on ergodox may also appreciate this novel layout.

Yeah, I also thought that would be a good idea. I should probably first post an entry about Ergolinear, as well as add entries for some other good layouts like Vu Keys. DT wiki sometimes seems to be haphazardly maintained.... guess the site owners are also very busy.
Title: Re: Balanced Keyboard Layout
Post by: Den on 2017-May-18 03:01
Interesting choice. Yeah that t-h worries me, I've tried various things to split them up but so far nothing has worked in terms of improving the score.
I even swapped e with space, which worked for some tests but not others. Part of the problem is the T ... maybe that need to swap to left hand. I've tried moving it to index finger but no real difference, and then you end up with T-h on same finger, not good.

Well actually space -T is also some finger. For that matter, check bigrams that involve space before and after a character.
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2017-May-18 03:13
Well actually space -T is also some finger. For that matter, check bigrams that involve space before and after a character.

One step ahead of you... :-) already made changes to remove cap letters above space and replace with punctuation with 'zero' or low chance of being preceded or followed by space... currently = ! @ but should probably swap out ! and replace with _
= is more problematic, it is needed for programming (ie wants to be on a major finger) and may or may not be space surrounded, depending on programmer style.

Will take a look at the space-char bigrams. Think I have them somewhere here.

Cheers, Ian
Title: Seelpy 1.3
Post by: iandoug on 2017-May-18 03:44
Still a work in progress.

Image shows same-finger usage for Alice, measuring key presses. Finger penalty likewise down. Right middle much better ;-)
Title: Re: Seelpy 1.3
Post by: philippe.quesnel on 2017-May-18 12:23
Still a work in progress.

Image shows same-finger usage for Alice, measuring key presses. Finger penalty likewise down. Right middle much better ;-)
Hehe, very nice. Getting closer to the unattainable 'no costs' ;-)

I 'hand-tested' a bit yesterday evening again, and I could start to see how it could flow (with a lot of practice !!)
Unfortunately for me, using AltGr to access one of the 'layers', even on a Sculpt Ergo which has Alt keys closer to the center, is just too slow, makes no sense. The spacebar works great as a thumb key, but Seelpy needs two thumbs keys .. as you well know ;-)

Trying to see how it could be adapted for 'dumb keyboards', seeing as you are getting such could results with this idea !
My current idea would be lowercase letters mainly on mid/top row on two 'layers' but use Shift to get uppercase letters.
(I can get this to work with AutoHotkey on Windows, but it is an unusual way of doing things?)
Not expecting as good results of course since this would be going half-way on the idea.

Do you use an optimizer program to create your layouts or create them by hand ?
(I tried *once* to create one by hand .. and failed miserably hahaha)

bonne journée
Title: Re: Seelpy 1.3
Post by: iandoug on 2017-May-18 13:02
Hehe, very nice. Getting closer to the unattainable 'no costs' ;-)

Trying to see how it could be adapted for 'dumb keyboards', seeing as you are getting such could results with this idea !

Do you use an optimizer program to create your layouts or create them by hand ?

Okay I've made some futher tweaks (pics from Alice below). It's not necessarily better on all tests, need to do proper cycle of tests which takes like 3 days to do to compare.
Same finger presses are getting very low.

I think you will struggle to get this comfortable on anything ANSI-like... it would work best on Ergolinear, and possibly Ergodox/Kinesis. I am grateful for feedback, as you know it's all theoretical this end at the moment.

I did take a look at AdNW optimiser (and Michael's one before) but found Michael's layout restrictions too restrictive and didn't spend enough time with AdNW before getting involved with KLA.

So yeah, I do it by hand and eye. Rely a lot on frequency tables and common sense and intuition. There are layouts that put A or N on the pinky, which in theory is insane, but they still manage to get decent scores, so it's a combination of art and science I guess.... I treat it like a game, play with patience and persistence like any good programmer... :-)

Something that has been worrying me a bit lately is that we are placing a lot of faith in Den's scoring model. While the results look sane, it is possible that some weightings may be a little wrong, (eg using a 5 where a more correct number would be 4.635, for example) which could be sending me down the wrong path.... but determining if that is the case will be difficult.

This version gets better scores on the number tests, even though I think version 1 looks more human-friendly with the number layout.
Also Ctrl-x/c/v is now thoroughly borked.

Anyway, pictures of Alice for your viewing pleasure :-)

Title: Re: Balanced Keyboard Layout
Post by: Den on 2017-May-19 02:49
KLA counts thumbs as a third hand. so same hand scores will be very low even if you overuse the thumbs and you type consecutively on the same hand between thumb and fingers. When thumbs count as the same hand as other fingers, adjusted scores will offset the lower distance, bringing scores closer to other layouts.

see this section of code in kb.js:

Code: [Select]
KB.finger.leftRightOrThumb = function(finger) {
    switch(finger) {
        case KB.finger.LEFT_PINKY:
        case KB.finger.LEFT_RING:
        case KB.finger.LEFT_MIDDLE:
        case KB.finger.LEFT_INDEX:
            return "left";
        case KB.finger.RIGHT_PINKY:
        case KB.finger.RIGHT_RING:
        case KB.finger.RIGHT_MIDDLE:
        case KB.finger.RIGHT_INDEX:
            return "right";
        case KB.finger.LEFT_THUMB:
        case KB.finger.RIGHT_THUMB:
        return "thumbs";
        case KB.finger.NONE:
            return "none";
        case KB.finger.BOTH_THUMBS:
            return "both";
    }
    return "none";
};

Another weird thing is the unusually low same finger penalty. Apparently using thumbs can buffer the finger-to-finger combinations. But this is lesser effect on score, whereas same hand has a bigger effect. This is the real reason for the existence of your layout; the essential benefit that is not affected by any scoring algorithm.

Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2017-May-19 03:05
Another weird thing is the unusually low same finger penalty. Apparently using thumbs can buffer the finger-to-finger combinations. But this is lesser effect on score, whereas same hand has a bigger effect. This is the real reason for the existence of your layout; the essential benefit that is not affected by any scoring algorithm.

So noted, thanks. I think I should stare at that code tonight .... :-)

Cheers, Ian

I suppose one benefit of Seelpy is that it will be harder to type CH when you mean Ch.
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2017-May-19 04:25
So noted, thanks. I think I should stare at that code tonight .... :-)

eow, 5000 lines... will have to print the relevant parts. Maybe all those templates and things need to be moved to a separate file, so that the business side of the code is easier to deal with.
Title: Re: Balanced Keyboard Layout
Post by: Den on 2017-May-19 16:14
The scoring may also be flawed in that more keys pressed is not punished. Intuitively, more key presses should lead to higher effort scores on finger usage; which is obviously not the case currently. Thus shifting to use two fingers for one character has negligible load on the score.

Is this the desirable outcome? That is, is using two key presses to print a letter more ergonomic than a single key press to reach a more distant key?

Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2017-May-19 17:28
The scoring may also be flawed in that more keys pressed is not punished. Intuitively, more key presses should lead to higher effort scores on finger usage; which is obviously not the case currently. Thus shifting to use two fingers for one character has negligible load on the score.

Is this the desirable outcome? That is, is using two key presses to print a letter more ergonomic than a single key press to reach a more distant key?

I thought that was the whole point of your revised scoring mechanism... to count vertical distance as well as horizontal distance, because Patrick's scoring seemed to be rewarding Arensito for the extra keypresses when it should not have.

I actually tried putting 4 chars on the keys under middle and index today, but the scores went down. So 3 works but 4 does not.... perhaps that demonstrates that your scoring is working?

If your worry is accurate then all the AltGr layouts need to be dumped... :-)

Which brings me back to my comment about the reliability of your scoring algo... if for example we agree a thumb press is very little effort compared to a pinky. The problem comes in the relative effort you assign to each.. and if you are say 0.1 off, then multiplied by hundreds or thousands of presses, it makes a difference. And leads to us developing based on wrong data.

Please don't take that as a criticism... I don't know if the numbers are wrong or not. As I've said previously, known good layouts like Colemak or MTGap get good scores, and bad layouts like QWERTY or ABCDEF get bad scores, so your algos are at least "mostly" correct if not "perfectly" correct. And I don't know if they ARE not correct, it was just a possibility I had to consider.

Maybe we should discuss the effort weightings... I didn't get around to staring at the code yet, I was instead staring at Seelpy, looking for optimisations. I've got Alice down to 83.14 now (same finger usage went up slightly, had a low of 6, at one point but is now at 18 for that score on Alice. The word tests are less than optimal, I had to optimise for prose OR word tests, and prose is more important. (issue is q vs ' on pinky or inner index).

Most surprising tweak was swapping e and a. Oh yeah, along the way, I solved the t-h problem too. Want to do some further tests then will post latest version.
Seelpy is basically a chording layout, with only one activator per hand. So the distance is less, but the thumbs work more.
Two chording keyboard examples here: https://hackaday.io/project/46-hackadayio-project/log/11239-hacklet-17-keyboards

Didn't we look at relative strength and dexterity of fingers a few months back? Or relative pressing strength? I remember seeing some research about that....
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2017-May-19 17:43
The other thing is that the order of the letters on the key makes a major difference, eg

a
b c    vs

c
b a

Gives very different scores. Even though both are same key, just different thumbs.
Also it seems like scoring is better if you use the thumb on the other hand vs the thumb on the same hand. Mostly.  Eg in above layouts, if that key is on left hand, then AltGr slot leads to better scores if it is a more frequent letter. And vice versa if key is on right hand. Or so it seems.

Title: Re: Balanced Keyboard Layout
Post by: Den on 2017-May-19 22:13
the finger weights are not the issue. thumbs are supposed to be preferred to pinkies.

the controversial part is the denominator used to calculate the final score. in particular the finger usage section. to compensate for some layouts might be missing characters, score is normalized for how many keys pressed by that layout. but this assumes typists prefer one key per character.

as denominator, higher value reduces score. ie less effort. so more shifts would actually score better. but this is contradictory if finger usage counts efforts of finger presses but huge amount of presses are ignored in the score.

so correct denominator would not encourage more shifts.

your layouts still score amazing on distance. but should score worse for finger usage and same hand.
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2017-May-20 03:43
the controversial part is the denominator used to calculate the final score. in particular the finger usage section. to compensate for some layouts might be missing characters, score is normalized for how many keys pressed by that layout. but this assumes typists prefer one key per character.

Um, okay, so you didn't modify Patrick's approach in that section of code (sorry I'm still bombed from lack of sleep Thurs night and haven't looked at the code).

So we will need to modify it then... so this is also part of the reason why Arensito / AltGr layouts do so well? I assumed he would have considered it because clearly some text has shifted letters, and he allows both AltGr and Shift-AltGr for entering text.

eow.... if we change that scoring then a lot of my 'research' is going to turn out to be barking up the wrong tree... .:-) No matter, the experience will help for the next part.

I was actually wondering about how the algos handle "key not found" because I accidentally left some off recently (typing lowercase instead of upper), and the score was higher than it should have been.

I suppose the "hard-ass" approach will be to abort when you find something that can't be typed, and say to either fix the text or fix the keyboard.... else you are comparing apples and oranges.

Then the logic behind "normalizing" can be changed.

Thoughts?
I have actually removed most of the "character not found" from my inputs, still a few left (usually French accents, but Keyboard Layout Editor has a few arrows etc.). My database-loader program checks for them as well and prints a report at the end.
Title: Re: Balanced Keyboard Layout
Post by: philippe.quesnel on 2017-May-20 21:28
I guess evaluating 'how good a layout is' in code is pretty complex and ends-up being an approximation  ..
heck even by hand, it will differ from person to person depending on taste, morphology etc.

I did some fiddling with Mtgap optimizer, modified it to test the idea of using the 'Seelpy idea' on 'dumb kbds'.

As a start I tried a skeleton layout with just 14 keys (most comfy keys) to map 26 lowercase letters + ., on two 'layers'
(unshifted / shifted as far as mtgap knows, I actually use a 2nd layer accessed by Spacebar, each can then use Shift for uppercase versions)

and I did notice that mtgap doesn't seem to account for same-finger on same key
(well, of course, who would've thought that it could happen !!? hehe)

I will do a simple / direct test to confirm this ..

I don't know the code for AdNW and couldn't see anything in the config files that would allow to split/move shifted/unshifted between different keys, so I could not try this idea out with AdNW.

One thing I noticed while test typing a bit, is that personally in this scenario, I kinda prefer an actual Space key on the main keys iso using the Spacebar to enter spaces (does a lot of Spacebar presses otherwise!).
Also, I prefer having Sp on both layers (on the same key).
Space on main keys makes for nice 'rolls' ;-)

Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2017-May-21 11:31
Also, I prefer having Sp on both layers (on the same key).

Mmm interesting idea, I don't know if KLA will take that feature into account.

The XPeRT layout has two eE keys (one for each hand) but scores badly on KLA tests. So I don't know if it's just a bad layout (patent and all) or just KLA not picking best eE to use in particular situation.
Title: Re: Balanced Keyboard Layout
Post by: philippe.quesnel on 2017-May-21 12:29
Mmm interesting idea, I don't know if KLA will take that feature into account.

The XPeRT layout has two eE keys (one for each hand) but scores badly on KLA tests. So I don't know if it's just a bad layout (patent and all) or just KLA not picking best eE to use in particular situation.
just to be clear, by Sp I  mean space :-)
Title: Re: Balanced Keyboard Layout
Post by: Den on 2017-May-21 15:39
Seelpy is different style of typing with different merits than traditional. may be preferred if you like chording or you have health problems that prevent you from reaching keys. (although for full chording, might look into stenotype.)

there is claim that chording is slower than traditional typing: http://www.tifaq.org/keyboards/chording-keyboards.html

Arensito is overall great layout for prose with low distance and same finger. its idea for coding is awesome because symbols are common for programmers and who wants to reach all around the keyboard.

some hybrid between seelpy, arensito, and adnw/beakl may or may not work. utilize extra layers, but not as extreme as seelpy with chording. optimizing uppercase still has merit.
Title: Re: Balanced Keyboard Layout
Post by: Den on 2017-May-21 15:40
if we revise the scoring system, you would have to redo all the comparison charts.
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2017-May-21 17:03
if we revise the scoring system, you would have to redo all the comparison charts.

:-)
I do that regularly anyway ;-)
I don't mind, I am a seeker of truth... :-)

Was actually going to modify my loader program to just load "extra" file for each test, so that I don't have to redo all tests for all inputs, which takes forever, even though I have iMacros doing the grunt work. There must be a way to run all that javascript "headless" (perhaps Phantom.js?) so that it a) runs faster and b) does not chew up all the memory on my box and c) lets me still work in FF.

[Speaking of which... if I read the code correctly, evertime you add a new layout, KLA "extends" an array in memory to handle the layout... but does it ever release that memory?
Trying to figure out why KLA chews up memory over time, regardless of browser used... and closing browser does not release ALL the memory ... I need to exit out of KDE and restart it to get the memory back.]

On the other hand I have been "fixing" the inputs to get rid of non-ANSI characters so need to redo all tests anyway... have decided once a month is enough :-)

I have also been adding new tests to the mix... added in 300 Trump tweets (which are mostly English as opposed to LOL GTG T2YL8r teenchat), but they have timestamps and some shortened URLs so bit of a mixed test.
I did play around a bit with The Philmarilion but decided it had too much foul language for republishing. I was actually looking for an IRC log with geektalk ... but they seem to have frequent bad language so I guess that's a bad idea.

Have added some more code ( Pangram Checker) in assorted popular/vibey curly-braces languages (C, C++, C#, Java, JavaScript, PHP, Rust, Go) to the mix. Also a bunch of pangrams themselves.

Gentoo has finally bumped me up to FF 52 (was on45 or somesuch before), it seems to be a bit snappier. Hopefully the JS engine is improved.
Tried to split kb.js into three (putting logical layouts in 1 file, physical layouts in another, and the do-sums stuff in the other), severely broke it. Eventually got it to behave itself, but the "personalised" routines were borked, even though I never touched that code. Something to do with how it loads (or didn't load) the hidden QWERTY layout that then gets renamed to Personalized. So will have to restore from live site and try again more carefully.
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2017-May-21 17:26
there is claim that chording is slower than traditional typing: http://www.tifaq.org/keyboards/chording-keyboards.html

Arensito is overall great layout for prose with low distance and same finger. its idea for coding is awesome because symbols are common for programmers and who wants to reach all around the keyboard.

I think I did actually read that page once before, in one of my "research alt keyboards" periods (been doing that on and off for years). On the other hand that page dates from 2002....  I agree a full-blown chording keyboard (typically one-handed) will probably be slower than a decent typist. Part of the problem will likely be the key travel... sure it will be more than modern Cherry-style keys. And if you need three or four keys at a time, then it HAS to be slower so that the controller can decided that you actually mean "A" and not "x" which is one finger different.

My tests show that Arensito struggles a bit with English... may be a consequence of the designer being Scandinavian rather than English, so not tailored for English. Very good at programming and other tech tests though.

Speaking of symbols, something that really surprised me was how badly the "Programmer" variants of common layouts do in the tests (as in: bottom of the table). Is this a case of reality trumping logic? :-)
Attached shows worst layouts sorted on "Other Tech", which is mostly numbers/dates/etc.


Title: Re: Balanced Keyboard Layout
Post by: philippe.quesnel on 2017-May-21 21:26
Ooouf, 5 keys (10?) chording kbd !! Really ?
That can't be very quick typing ;-)
"At least 15 hours of training and practice are necessary to learn the chord patterns that represent individual letters and numbers" ..
again, "really?", I which it was so easy to become efficient with a new layout !! hehe

I think another important layer, that we sometimes mention but don't actually take into consideration for layouts, is an 'editing layer'. I discovered that idea with DremayR's 'extend' layer for Colemak.
As Xah mentioned (I believe), we seem to do more editing than typing (programmers .. that's me, at work, 40hrs/week, so most of my kbd time), so it makes sense to have easier / more efficient access to main editing keys.
I know I usually #include mine when trying out a different layout

Quote
Speaking of symbols, something that really surprised me was how badly the "Programmer" variants of common layouts do in the tests (as in: bottom of the table). Is this a case of reality trumping logic? :-)
Attached shows worst layouts sorted on "Other Tech", which is mostly numbers/dates/etc.
Hahaha, wow, Workman programmer has similar overall score as WORST carpalx !!?
Ok, you try on *purpose* to create the WORST layout .. and actual layouts have the same score !!!!
creepy / weird / "I don't understand this"
Title: Re: Balanced Keyboard Layout
Post by: philippe.quesnel on 2017-May-21 21:49
Here's an example result for a barbone / 14keys layout from a modified Mtgap àla Seelpy. (for 'dumb kbd'  ;D )
Using 'Curl'/AngleZ ergo mods,
ie Lower left row shifted left 1key, so o-x are typed with the index,
also, the same pos is considered the 5th home pos instead of mid column of home row

As usual for mtgap, SC same finger is in there ;-p
UE and AO too!

Code: [Select]
Hands: 47% 52%
Fingers: 8.0% 12% 15% 13% 0.00% 0.00% 17% 17% 10% 8.0%

(2nd layer, access with Space/thumb)
    q  j          k  z
 .  v  y  ,    f  w  p  g
        x      b

(main layer)
    m  u          d  c
 i  n  e  a    h  t  s  r
        o      l

Compared to traditional Mtgap 30 keys
Code: [Select]
y  p  o  u  j   k  d  l  c  w
i  n  e  a  ,   m  h  t  s  r
q  z  /  .  :   b  f  g  v  x

I'm also trying out this idea with more keys, 16, 18..
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2017-May-22 03:41
@philippe:

Yeah, regarding editing... I am constantly nagged by the voice in the back of my head that I should pay attention to that... I can't live without the backspace key... problem is that only way to test such things is by using keylog as input, and then I can't publish the keylog because it will contain things I don't want spread.

We'll probably need to modify KLA to handle all the other keys ... as well as have bigger test layouts than the standard main block.

Personally I'm rather horrified at the direction that my designs are heading (multi layers on reduced key count), because I have previously ranted to Den about how I DON'T want that, as I have enough trouble getting + and = the right way round already... or [ and { etc. But clearly in terms on KLA testing having to move the hands less leads to better scores.

I suppose putting editing on main keys will be better on something like Ergolinear than on ANSI, even if only because the keys are not staggered. (Before I forget, current Seelpy layouts destroy Ctrl-x/c/v ease-of-use etc but better workaround will be to put dedicated cut/copy/paste keys along unused (by me, Den has nav there) keys on bottom row. Then we can optimize keys without worrying about legacy issues.)

Mmm... if you put editing in main block, that just leaves the Function keys to worry about... and the numpad. I suppose you could do a numpad in three rows if you doubledecker the numbers  and don't have too many other things, but printing all that on the keys is going to get a bit messy :-)

I will ponder your MTgap layouts... interesting ideas... :-)
Title: Re: Balanced Keyboard Layout
Post by: philippe.quesnel on 2017-May-22 11:09
For the edit layer, I use this (modified from DreymaR's extend layer)
Code: [Select]
Esc                     PgUp   Home  ^    End   Del
     Shf  Alt  Ctrl     PgDn   <     v    >     Bs
^z   ^x   ^c   ^v             ^c    ^x   ^v    ^z
Still not 100% comfy with it yet, but enough that "can't live without it now" ;-)
Title: Re: Balanced Keyboard Layout
Post by: philippe.quesnel on 2017-May-22 11:24
Hahaha life is funny.
As I was adding more and more keys testing 'Seelpy for dumb kbds' w. Mtgap: 14,16,18,
I decided to just go directly to 30,32 keys

Full circle back to almost all letters on main layer and symbols on 2nd layer ..
sounds like Ian X4 / Arensito & cie !!
(that was where I was at, experimenting, before trying out the Seelpy idea hehe)

quick run gives (2 letters only on 2nd layer)
Code: [Select]
@  ?  $  `  ~      z  {  }  %  #
:  (  ) SP  [   ]  ;  "  =  !  |
/  <  >  \      *  j  +  &  ^

,  y  o  u  '      g  n  d  v  q
a  i  e SP  _   c  r  h  t  s  f
.  -  k  x      w  l  p  m  b

2 letters only on 2nd layer .. and I was not using 2 keys ('most costly') of the 32 !
So might as well just go back to 'all letters' + 5 symbols main layer with
2nd layer all symbols !!  ::) ;D
(Should make for much quicker runs too 15seccs vs > 15mins)
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2017-May-22 11:41
For the edit layer, I use this (modified from DreymaR's extend layer)
Code: [Select]
Esc                     PgUp   Home  ^    End   Del
     Shf  Alt  Ctrl     PgDn   <     v    >     Bs
^z   ^x   ^c   ^v             ^c    ^x   ^v    ^z
Still not 100% comfy with it yet, but enough that "can't live without it now" ;-)

"Insert" key?
Title: Re: Balanced Keyboard Layout
Post by: philippe.quesnel on 2017-May-22 12:44
"Insert" key?
Yes, that is one of the keys I did not keep from the original DreymaR extend layer.
I had it at first, but I guess with the learning curve of all this (new layouts too etc), since I don't seem to use Ins very much, it just got dropped off. Brains overloading ;-p

It might get its own spot back  eventually ;-)

Just realized DreymaR has a post on just his extend stuff !
https://forum.colemak.com/topic/2014-extend-extra-extreme/

otherwise : https://forum.colemak.com/topic/1438-dreymars-big-bag-of-keyboard-tricks-linuxxkb-files-included/

Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2017-May-22 13:32
since I don't seem to use Ins very much,

My laptop put it in the Shift layer... much to my disgust. I think some Apple keyboards also drop it.

I use it a lot ... sometimes in text editing but mostly for copy/paste operations (since left hand is on track ball).
Title: Re: Seelpy 1.3
Post by: iandoug on 2017-May-22 16:54
Hehe, very nice. Getting closer to the unattainable 'no costs' ;-)

Testing... there are zeros there :-)
Same-finger usage for a few layouts and tests....
Title: Re: Balanced Keyboard Layout
Post by: Den on 2017-May-22 17:54
What if hand alternation is not your thing? That is, you prefer to type longer strings on the same hand. This is candidate layout that Opt spat out:

Code: [Select]
               1566.637 total effort   166.280 positional effort    left right
                   3.437 same finger rp   0.000 shift same finger top 17.8 10.9
 zoinx kdcfv      58.603 hand alternat.  42.329 shift hand alter. mid 27.1 22.2
 "aer, lhtsb       2.155 inward/outward  34.936 inward or outward bot  5.7 10.8
 q'u.j ympgw      21.014 adjacent         9.285 shift adjacent    sum 54.1 45.9
                  13.247 no hand altern. 30.932 two hand altern.
                   6.737 seesaw           6.521 indir same finger
                  1.6 14.3 18.3 16.6  3.5  2.0 16.7 14.2  9.3  3.7 Sh  3.5  2.0

Compared to Colemak, which also prides itself on long same hand strings. Never typed in Colemak, but did a few sentences to compare with this new layout. Right away can feel Colemak is quite uncomfortable with its finger acrobatics (seesaw) and frequent ring-pinky combos. Don't understand the hype.

On the other hand, this new ZOINX layout feels really good with the rolls and combos. The only flaw is the OU bigram. Overall feels much better than Colemak. Secretly I think it's another success of reducing pinky usage, which naturally leads to fewer ring-pinky awkwardness.

Surprisingly, no matter how much I try to penalize hand alternation, the optimal layouts still end up with vowels on the same hand. For example, below layout has even lower hand alternation, but retains vowel district.

Code: [Select]
jpinz k.dcv
faorm hetsb
q"ulx ',ygw

Well not quite true. This next one has even lower hand alternation. The vowel district is retained for the most part, except E is moved to other hand. (not recommended due to very high same finger.)

Code: [Select]
qpinz k.hcx
faorm yetsg
wbulj ',"dv
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2017-May-23 02:24
FWIW, I've tried numerous times to swap the main consonants with one or more vowels, and it's always failed to impress KLA. Even things like y.

So I'm quite surprised you end up with e and t on same hand (balanced, I suppose, by n and r both moving to the opposite side). And n not on home row? That's a bit weird. Like QWERTY weird :-)
Title: Re: Balanced Keyboard Layout
Post by: Den on 2017-May-23 03:57
Be aware these are optimized for inward rolls. So index fingers are where bigrams and trigrams end. So NRE end up on index allows great rolls; and they do feel great. We've seen this before when working on putting letters on thumbs. RN consistently put on thumbs. Also based on my effort chart that doesn't discriminate by rows. Instead focus on home block. So theory and practice meet, creating very comfortable layouts.

R on home row eases combos with other consonants on any row. At expense of worse distance putting N on top; which mainly combo with vowels. IN bigram probably dictates that they go on same row; however AE have priority on home row over I,  Forcing IN to top row.
Title: Re: Balanced Keyboard Layout
Post by: Den on 2017-May-23 19:36
Revised scoring:

http://shenafu.com/code/keyboard/Keyboard Layout Analyzer 2.html (http://shenafu.com/code/keyboard/Keyboard Layout Analyzer 2.html)

 (old URL with old scoring still work)

changes:
- finger usage per character (was per key press)
- penalty for modifier key up (same as modifier key down)
- thumb count as same hand to fingers
- extra distance for lateral movement (x-axis)
- added default layouts (seelpy, maltron)

Result:
Scores for finger usage and same hand may be different than before. Over-reliance on thumbs and modifiers (shifts, altrgr) will net higher (worse) score than before.
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2017-May-24 02:07
Revised scoring:
- extra distance for lateral movement (x-axis)

Can you maybe clarify that a bit? Not sure I follow.

FWIW I thought you were already counting up+down on all fingers...

Title: my Ergolinear
Post by: iandoug on 2017-May-24 02:25
@Den

attached zipfile with setups for kb.js for my variant of Ergolinear, as well as current 4 best Seelpy layouts... 1.22 is best at English text and programming, the others are better at words/*-grams (1.4) or number-stuff. (1.8, 1.17)

I call your variants ergolinearden and matrix this side, so you will probably have to rename my variant and then refer to that wherever necessary.
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2017-May-24 03:17
Mmm.

So new algo still likes  X6.4H Ergolinear and -+T+- HT02a for Alice, but not Seelpy so much... Results are currently a bit puzzling (compare Alice vs KLE for example). Will take a closer look at your changes later.

Was doing some comparisons between Patrick original, Den 1 and Den 2... but they seem to like different things, so getting a top five for each will take some time. Must still add ergolinear layouts to Patrick's code to see what it thinks.

In other news, one of the Seelpy layouts could have been called Seelpy Omega (based on letters on home row) which sounds like a high-end mattress...
But it was not to be. We are now at Seelpy Omage. Or Iomagel.


Title: Re: Balanced Keyboard Layout
Post by: Den on 2017-May-24 03:52
Can you maybe clarify that a bit? Not sure I follow.

distance is square root of x+y. but i made it 2x+y to penalize lateral reaching. reasonable to keep?

Quote
FWIW I thought you were already counting up+down on all fingers...

will check again later if modifiers are already counted elsewhere.
Title: Re: Balanced Keyboard Layout
Post by: Den on 2017-May-24 03:53
- added sub tests to results table
- added matrix section
- added 3-thumb matrix layouts (L_RN, P_RN, U_RN)

attached screenshot of classics test
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2017-May-24 04:11
distance is square root of x+y. but i made it 2x+y to penalize lateral reaching. reasonable to keep?

My gut feel is that it should be different for different fingers, perhaps in proportion to effort assigned finger. Or perhaps that will effectively lead to "double-counting" ie double penalty?
2x does seems a bit 'harsh' for x in relation to y, but that's just an observation based with zero science to back it up.
BTW I presume you mean square root of (2x squared + y squared). In which case 2x is very harsh (eg compare difference between 3 squared and 6 squared).
MMm so is it (2x) squared or 2(x squared)?
I suppose the correct multiplier to use would be (effort to move finger horizontally - effort to move finger vertically) but no idea where to find that/those number(s)... :-)

It just feels like moving pinky should take more effort than moving index. In truth, I tend to move my whole hand rather than just the fingers sideways. Trying to 'monitor' my movements as I type here on my MS Natural QWERTY, where index fingers fly around a lot..... :-)
Probably a consequence of being a 'hoverer' rather than a proper touch typist.
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2017-May-24 04:37
Started poking around to answer my own question about difference in horizontal vs vertical distance.

Found this research paper from clever people at Google.
http://dl.acm.org/ft_gateway.cfm?id=2858421&type=pdf

Which introduced me to Manhattan Distance, but can't see why they would want to use that as opposed to diagonal.

Anyway will take a look at the layouts for KLA as well as my own evaluation of swiping layouts.

The thing that amazes me is why these clever people don't ask the obvious question:   WTF do you need a staggered layout on a touch screen?
I can only assume that it's because they want to maintain similarity to QWERTY layout. Which is silly.

[edit] Mmmm I see many Android keyboards are now semi-staggered... bottom row lines up while top row does not.

Cheers, Ian
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2017-May-24 04:47
@Den, can you maybe make a zip file when you are done? :-)

thanks.
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2017-May-24 07:33
It just feels like moving pinky should take more effort than moving index.

I struggle to switch my index finger from home to inner row. It gets about half way, before I have to move my hand as well. Pinky on the other hand (pun not intended)  can easily move between home and outer row.

Your experience the same? Suppose might depend a lot on hand size.

Found a research paper that compared key sizes, but test subjects were Big Men. (or men with Big Fingers). At 16mm horizontal, errors increases and typing speed decreased, as opposed to standard 19mm.
Doubt that they were all touch typists.

Anyway, so how do we model "move hand" vs "move finger" ....

On this MS Natural, a move like J-Y on QWERTY is a real stretch. Need to move hand left and up. Which raises the issue.... I keep my fingers in "home" posture, more or less, and move my whole hand up to hit the Y key. So basing the "effort" on the relative strength or flexibility of the index finger is not correct, because the whole hand (as opposed to the finger) is doing the move.

Mmm. this stuff is more complex than I thought ... :-)
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2017-May-24 08:11
Found this in a patent application. Since you are looking at bringing P_RN to keyboards, might have some ideas....
Title: All the p-rn that's out there..
Post by: iandoug on 2017-May-24 11:34
switched a few keys around. Better on Alice on Den2, might be worse on other inputs/scoring.
Title: Re: Balanced Keyboard Layout
Post by: philippe.quesnel on 2017-May-24 12:06
What if hand alternation is not your thing? That is, you prefer to type longer strings on the same hand. This is candidate layout that Opt spat out:

...

Compared to Colemak, which also prides itself on long same hand strings. Never typed in Colemak, but did a few sentences to compare with this new layout. Right away can feel Colemak is quite uncomfortable with its finger acrobatics (seesaw) and frequent ring-pinky combos. Don't understand the hype.

On the other hand, this new ZOINX layout feels really good with the rolls and combos. The only flaw is the OU bigram. Overall feels much better than Colemak. Secretly I think it's another success of reducing pinky usage, which naturally leads to fewer ring-pinky awkwardness.

Exactly ! I usually like rolls .. but not too much either, the same way that I don't like 'too much alternation'.
I think a nice combination of rolls / alternation feels / works best (for me hehe).

I seem to find lately that high(er) same-hand, ala Colemak etc makes it difficult to get a comfortable layout as you mentioned.
But when I had tried AdNW recently, I did not like the resulting (US kbd) layout, even though the numbers were very good ;-)

Quote
FWIW, I've tried numerous times to swap the main consonants with one or more vowels, and it's always failed to impress KLA. Even things like y.

So I'm quite surprised you end up with e and t on same hand (balanced, I suppose, by n and r both moving to the opposite side). And n not on home row? That's a bit weird. Like QWERTY weird :-)
I WAS thinking just yesterday that getting one vowel alone on one hand would help get better balance of rolls / alternation (alternation helping in avoiding bad same-finger home-jump etc apparently (?)) but didn't see a way of doing this..
Fits in to what Den s just saying here ;-)

@Den, I'll have a look at this ZOINX layout, thx
Title: Re: Balanced Keyboard Layout
Post by: philippe.quesnel on 2017-May-24 12:10
Mmm.

So new algo still likes  X6.4H Ergolinear and -+T+- HT02a for Alice, but not Seelpy so much... Results are currently a bit puzzling (compare Alice vs KLE for example). Will take a closer look at your changes later.

Was doing some comparisons between Patrick original, Den 1 and Den 2... but they seem to like different things, so getting a top five for each will take some time. Must still add ergolinear layouts to Patrick's code to see what it thinks.

In other news, one of the Seelpy layouts could have been called Seelpy Omega (based on letters on home row) which sounds like a high-end mattress...
But it was not to be. We are now at Seelpy Omage. Or Iomagel.
Hahaha ;-)
Get the H in there : Homage to Seelpy !
Title: Re: Balanced Keyboard Layout
Post by: philippe.quesnel on 2017-May-24 12:25
I struggle to switch my index finger from home to inner row. It gets about half way, before I have to move my hand as well. Pinky on the other hand (pun not intended)  can easily move between home and outer row.

Your experience the same? Suppose might depend a lot on hand size.

Found a research paper that compared key sizes, but test subjects were Big Men. (or men with Big Fingers). At 16mm horizontal, errors increases and typing speed decreased, as opposed to standard 19mm.
Doubt that they were all touch typists.

Anyway, so how do we model "move hand" vs "move finger" ....
Yes, when I finally decided I should learn touch typing about a year ago .. I found that I didn't like reaching mid column home row keys and of course left hand bottom (staggered) row .. hence my preference for Colemak's ModDH 2 ergo mods (angleZ : shift left hand bottom row left) and 'Curl' : prefer index on bottom row vs index on id column home row .. which causes more problems with home-jump Aarrg.

Yes #2, I also tend to move my whole hand for some keys / key combinations, that's where Seelpy kind of layouts were comfortable, since it reduced hand / finger movements

Yep, modeling all this is not obvious !
Title: Re: Balanced Keyboard Layout
Post by: philippe.quesnel on 2017-May-24 14:44
..

On the other hand, this new ZOINX layout feels really good with the rolls and combos. The only flaw is the OU bigram. Overall feels much better than Colemak. Secretly I think it's another success of reducing pinky usage, which naturally leads to fewer ring-pinky awkwardness.
Oh by the way .. I might adopt this one just for the name !!!
ZOINX, love it hehe !!!
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2017-May-24 15:14
I played around a bit with ZOINX and ended up with ZOURX.

Scores from Den 1, Den 2, Patrick and layout attached.

I didn't split ' and " like schematic above. Put ;: there instead.

At least it beats Colemak on all three :-)

Dunno how the rolls will feel.
Title: Re: my Ergolinear
Post by: Den on 2017-May-24 17:16
@Den

attached zipfile with setups for kb.js for my variant of Ergolinear, as well as current 4 best Seelpy layouts... 1.22 is best at English text and programming, the others are better at words/*-grams (1.4) or number-stuff. (1.8, 1.17)

I call your variants ergolinearden and matrix this side, so you will probably have to rename my variant and then refer to that wherever necessary.

Since Matrix is superset of all 3, keep Matrix and abandon Ergolinear. Rework all ergolinear layouts into Matrix. You can just leave unused keys as empty.
Title: Re: Balanced Keyboard Layout
Post by: philippe.quesnel on 2017-May-24 19:37
Code: [Select]
               1566.637 total effort   166.280 positional effort    left right
                   3.437 same finger rp   0.000 shift same finger top 17.8 10.9
 zoinx kdcfv      58.603 hand alternat.  42.329 shift hand alter. mid 27.1 22.2
 "aer, lhtsb       2.155 inward/outward  34.936 inward or outward bot  5.7 10.8
 q'u.j ympgw      21.014 adjacent         9.285 shift adjacent    sum 54.1 45.9
                  13.247 no hand altern. 30.932 two hand altern.
                   6.737 seesaw           6.521 indir same finger
                  1.6 14.3 18.3 16.6  3.5  2.0 16.7 14.2  9.3  3.7 Sh  3.5  2.0

On the other hand, this new ZOINX layout feels really good with the rolls and combos. The only flaw is the OU bigram. Overall feels much better than Colemak. Secretly I think it's another success of reducing pinky usage, which naturally leads to fewer ring-pinky awkwardness.

Hehe I can feel the 3x3 block / BEAK approach when trying this layout ;-)
Yep, OU is a bit of a drag .. sOUNd is really not fun to type !! (well, specially with my shifted left bottom row technique ! U-N becomes an index home-jump)
Hehe of course the test article I picked randomly is about sound, pfff hihi ;-p

Interesting layout.
Title: Re: Balanced Keyboard Layout
Post by: Den on 2017-May-24 20:34
more changes to KLA2:

- enlarged text input box
- reorganized layout dropdown list
- convert existing ergolinear layouts to matrix
- moved default layouts to new file: kbpresets.js
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2017-May-25 02:02
more changes to KLA2:

Something that would help would be to print the test name and/or filename on the results page.
I, with my limited Angular skills, got it to print the file name on the selection page after you select, via {{data.textPreset}} but that seems to vanish from memory by the time you print out the results. Angular is very much still one step away from black magic to me, most of the time :-)

I actually also need it logged to Console, so that the PHP database loader programs can pick it up.

Doing this will allow me to further automate the testing. At the moment I have automated "one test, all layouts" as well as "one test, some layouts", but would like "all layouts, all tests" (though that will eventually slow to a crawl due to memory consumption) or "all tests, some layouts" as a easier, faster way to add in new layout test results. (FWIW Firefox 52 and/or newer Linux kernel seems to properly release all memory when closed, unlike FF45 or 48 that I had before).

Suppose you would need Special Case for input text just pasted in rather than selected from dropdown.

Maybe somewhere further down the road, an option to "select scoring model" would be useful (Patrick, Den1 or Den2 ATM). Dunno if this would lead to a very messy analyzer.js file.

Cheers, Ian
Title: Re: my Ergolinear
Post by: iandoug on 2017-May-25 02:07
Since Matrix is superset of all 3, keep Matrix and abandon Ergolinear. Rework all ergolinear layouts into Matrix. You can just leave unused keys as empty.

I had been thinking along the same lines myself. It's logically the correct decision, I'm just emotionally attached to the Ergolinear name.....

You can't escape the Matrix, Neo. It's all around you... you are part of it...

Cheers, Ian
Title: Re: Balanced Keyboard Layout
Post by: Den on 2017-May-25 03:28
you can create new .js files to call the functions directly without going through the gui. then you can run any tests with any layouts and direct the results to wherever you like.



Title: Re: Balanced Keyboard Layout
Post by: Den on 2017-May-25 03:47
Somehow stumbled upon the next BEAKL 6 candidate. Good distance and Low same finger.

Code: [Select]
q.auj wdrcv
hoeiy gtsnp
z/,x' kmlbf

however KLA2 seems to score better with older BEAKL vowel district. (I also want to keep the puncs in certain places to coincide with the numpad layer.) Even better distance and same finger.

Code: [Select]
BEAKL 6

qyouj wdrcv
hiea, gtsnp
/'x.z kmlbf
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2017-May-25 06:10
Found this in a patent application. Since you are looking at bringing P_RN to keyboards, might have some ideas....

I loaded it on Matrix but it can't work ... the layout assumes a driver that accepts Shift by itself, then shifts the NEXT key, and returns to lower case.
KLA can't handle that.
So I made a few tweaks and added the missing characters. Also moved the U in an attempt to reduce left thumb usage, which is way too high.

Results from Alice using Den1 and layout attached.
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2017-May-25 08:12
- added 3-thumb matrix layouts (L_RN, P_RN, U_RN)

Looking at P_RN ... you can't have things on AltGr on same thumb as AltGr... KLA objects, even if it is possible in real world to press both at same time.
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2017-May-25 10:03
Was annoyed with life so I played around with your P_RN some more... this gets a very respectable score at the expense of more same-finger use on left thumb.

I suspect with some tweaking it could beat X6.4H, as I only played with the letters and not the punctuation/brackets.

Gives me some food for thought :-)

Title: Re: Balanced Keyboard Layout
Post by: Den on 2017-May-25 11:35
Using thumbs for modifiers seems underutilizing them. Mods take up only 2% of key press. That's about the amount I'd allow for each pinky. That means one of the thumb is only doing as much work as the pinky. (The other thumb is for space, which accounts for 16% key press, which is about the right amount of effort for thumb.)

So mods could be assigned to the fingers. But where? Pinkies are okay if within the main 30 key block; possibly even home pinky. This is perfectly fine if we're putting letters on thumb cluster anyway. (Remember that left one key empty when migrating 3 letters to thumbs.)

Next project for Opt.
Title: Re: Balanced Keyboard Layout
Post by: philippe.quesnel on 2017-May-25 12:27
Somehow stumbled upon the next BEAKL 6 candidate. Good distance and Low same finger.

Code: [Select]
BEAKL 6

qyouj wdrcv
hiea, gtsnp
/'x.z kmlbf
Interesting.
Gave it a quick run and kinda like it.
As usual, I tweaked it a bit, swapped . x for my shifted left hand bottom row access
(I realized yesterday that the US kbd version of Arensito uses this shifted bottom left row thing too  ;))

Here's something that I came up yesterday with AdNW, using an US kbd adaptation of BEAKL 3.4, with shifted bottom left row (with adjusted costs for the shifted row)
Code: [Select]
xncdv -oiujz
wrstg ,aehpk
lfmbq '."y: 
B-V is not oBVious though, (poetic, that's how I realized it actually, typed 'obvious'), I kinda avoid it a bit by hitting the bottom B with my thumb ! I think BEAKL6 might be nicer.
Title: X6.4H dethroned...
Post by: iandoug on 2017-May-25 14:56
Played some more.

X6.4H has fallen. Long live the king. Ra rah.

This be on Alice.
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2017-May-25 17:56

- added 3-thumb matrix layouts (L_RN, P_RN, U_RN)

Um, how do you type "N" ?

KLA would like to know :-)

thanks, Ian
Title: Re: Balanced Keyboard Layout
Post by: Den on 2017-May-25 19:23
Um, how do you type "N" ?

KLA would like to know :-)

thanks, Ian

telekinetically. in fact, all typing should be done telekinetically.
Title: bug
Post by: iandoug on 2017-May-26 15:54
Decided to have a go at rewriting/porting analyzer.js to PHP, so it can run headless and hopefully faster for bulk testing. And not gobble up my memory.
If it works will look at doing it in Ada since I want to learn Ada and then it will run even fasterer. :-)

Anyway think there's a bug here:

        if (char2KeyMap[16].errors.length > 1) {
            analysis.errors.push("Fatal Error: AltGr key not set correctly.");
            return analysis;
        }

which I think should be
        if (char2KeyMap[-18].errors.length > 1) {
            analysis.errors.push("Fatal Error: AltGr key not set correctly.");
            return analysis;
        }

since 16 is used above for the Shift keys... and the GUI assigns hex 12 (== dec 18) to AltGr....
It's the same in original version. Presumably a typo by Patrick.
Title: pixels per cm
Post by: iandoug on 2017-May-29 04:42
@Den

Can you remember what the outcome was of the discussion re pixels per cm in the keymaps?

We have different values: (this be from code my side, in my current live version).

standard: KB.keyMap.standard.s683_225.pixelsPerCm = 26.315789;
Ergolinear Den: KB.keyMap.ergolinearDen.s683_225.pixelsPerCm = 25.315789;
Ergolinear Matrix (original): KB.keyMap.matrix.s683_225.pixelsPerCm = 26.315789;
Ergolinear Ian: KB.keyMap.ergolinear.s683_225.pixelsPerCm = 26.315789;

I remember asking Patrick about it and he said something about the Ergodox having smaller squares but the px/cm is same as standard above.

Pat's original code had 26 for standard and European and 25 for Ergodox.

So now I'm confused...
I'm sure the difference in px/cm affects the distance calculations and thus the scoring.

Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2017-May-29 09:32
will check again later if modifiers are already counted elsewhere.

Normal keys count up and down (am doing test of ab and DK on QWERTY on my local version of Den1 scoring).

So for ab the left pinky moves 0.8 which is 0.4 up and down.

For DK left pinky moves 7.7 cm which is worrying me a bit... the distance from centre to centre for A -> left shift is about 3cm, so total should be around 6.8 not 7.7

Unless KLA is computing distance as 7.7 - 0.8 = 6.9 / 2 = 3.45 but that seems a bit high on two ANSI keyboards I have here (low-end Gigagbyte 'gaming' with Cherry red switches, and low-end Microsoft model 200).

Perhaps Patrick's original model had slightly different key sizes which made the left shift bigger.
Mmmm he has size of 116 pixels == 116/26.315789 = 4.408 cm ... measured the base of the key and it's just under 4.2 cm
[edit; okay forgot about your modifier penalty which should account for the difference.... seems to be about 2mm]

Either way it does indeed appear to be counting up and down on Shift keys.

So doing it again elsewhere is double penalty...
Title: progress on PHP analysis version
Post by: iandoug on 2017-May-29 16:23
Seems to be going okay.
Wrote a routine to check all standard layouts for all standard ANSI chars. Removed layouts with missing chars (they had all previously been removed from dropdown in KLA anyway).
Wrote a routine to check all preset texts for non-ANSI chars. Have fixed them, either by deleting or just entering as HTML entity code. Not ideal, but typeable.

Wrote routine to build layouts in memory... loads the physical layout, then uses that to load logical standard layouts with centre of key co-ordinates.
A quick test to measure distance from z to p. Basically loads the physical layout, then sucked in ALL standard logical layouts, then measured from z to p on all of them, which required two key lookups per test.

Results:

~/1web/keyboard-design/kla/layouts/scores $ php build-keymaps.php
Arensito fixed: z to p is 8.8729 cm
BEAKL 4 Mod Ian AltGr 3: z to p is 3.8 cm
BEAKL Opted36: z to p is 2.3636 cm
BEAKL 4: z to p is 1.9632 cm
BLOU: z to p is 7.1698 cm
Balance Twelve: z to p is 4.0927 cm
Colemak Mod-DH (full): z to p is 5.6491 cm
Ian M1: z to p is 9.5 cm

[100+ similar results cut to save space]

TNWMLC (Worst CarpalX layout): z to p is 1.9632 cm
TTast: z to p is 10.5856 cm
TypeHacK Layout: z to p is 5.6491 cm
Typematrix: z to p is 16.0367 cm
Vu Keys: z to p is 11.4 cm
Workman: z to p is 14.198 cm
Workman for Programmers: z to p is 14.198 cm
XPeRT: z to p is 3.819 cm
Yak: z to p is 5.1124 cm
Done in 0 seconds (0 minutes).

So it seems to run quite fast. Now need to try measuring distances for text inputs and see how that goes....

If it runs fast enough to compare 100+ layouts at a time, that would be cool (as opposed to 6-12 via browser).
But let me not get ahead of myself :-)
Title: Re: Balanced Keyboard Layout
Post by: philippe.quesnel on 2017-May-31 21:57
@iandoug, I just discovered Balance Twelve (fixed) on KLA, did a few personal changes,
while trying it out I realized backslash '\' is missing !
there are two ^ on the shifted top (numbers) row  ;)

and by the way, thx for (sharing) all the work (both iandoug and Den)!

my two current favorites are "Balance Twelve (fixed)" (perso tweaks) and BEAKL Opted 36 (partial implementation + perso tweaks)
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2017-Jun-01 01:30
@iandoug, I just discovered Balance Twelve (fixed) on KLA, did a few personal changes,
while trying it out I realized backslash '\' is missing !
there are two ^ on the shifted top (numbers) row  ;)

Which URL?
It's correct on my fork here:
http://kla.keyboard-design.com/#/config

(No, I didn't just fix it now... :-) )

thanks, Ian
Title: Re: Balanced Keyboard Layout
Post by: philippe.quesnel on 2017-Jun-01 19:15
Which URL?
It's correct on my fork here:
http://kla.keyboard-design.com/#/config

(No, I didn't just fix it now... :-) )

thanks, Ian

Hmm, I can see that..
I have been using this link http://shenafu.com/code/keyboard/Keyboard%20Layout%20Analyzer%202.html#/main
as I had read here not too long ago that it had the latest revised scoring
Title: Re: Balanced Keyboard Layout
Post by: philippe.quesnel on 2017-Jun-01 21:53
my two current favorites are "Balance Twelve (fixed)" (perso tweaks) and BEAKL Opted 36 (partial implementation + perso tweaks)
Giving Ian X4 another peek ('adapted' ), since it gets such good scores, even with less changes in the modifiers department and as it fits with what I have been using with Symbols on Alt-gr, along with an 'extend' / editing layer on Space.
Also, the consonants on the right side are nicer on my left forearm which gets easily tense when stretching to reach mid column keys / touch typing

I compromise here by using the 'curl' ergo mod I found with Colemak ModDH, so less stretches to mid column, but more home jumps (O-U)
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2017-Jun-03 17:37
Giving Ian X4 another peek ('adapted' ), since it gets such good scores, even with less changes in the modifiers department and as it fits with what I have been using with Symbols on Alt-gr, along with an 'extend' / editing layer on Space.
Also, the consonants on the right side are nicer on my left forearm which gets easily tense when stretching to reach mid column keys / touch typing
I compromise here by using the 'curl' ergo mod I found with Colemak ModDH, so less stretches to mid column, but more home jumps (O-U)

Can you maybe post screenshots of your mods?

Given your comment above about consonants on the right, I did a little playing around. I took Vu Keys, which I know is good for English, and flipped right and left, then played around (mostly on home row) and eventually ended up with layout below, which for some tests beats Vu Keys. And of course MTGap and Colemak and Dvorak... :-)

Probably there's a swap I've missed. Anyway this falls under the "just rearrange keys" category so you won't need to relabel keys or anything...

Scores, screenshot and json attached.

Cheers, Ian
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2017-Jun-03 17:43
Hmm, I can see that..
I have been using this link http://shenafu.com/code/keyboard/Keyboard%20Layout%20Analyzer%202.html#/main
as I had read here not too long ago that it had the latest revised scoring

Yes it is... but I was expecting Den to tweak the scoring a bit... :-)
BTW results in post above are with Den 1 scoring. Let me see how my mod does on Den 2....
Title: Re: Balanced Keyboard Layout
Post by: philippe.quesnel on 2017-Jun-03 21:40
Can you maybe post screenshots of your mods?
Code: [Select]
layer1Sh := ""
 . ' J Y U ¬ @  M D C P Q Z '
 . ' I H A E \  G T S N R V '
 . ' | K O ^ ©  W L F B X '
 
layer1 := ""
 . " j y u ' !  m d c p q z "
 . ' i h a e [0]  [g] t s n r v '
 . ' $ k [o] 2 #  w [l] f b x '

I just swapped O-0 (zero) and G-L, so the 5th home pos is the index on the bottom row (for the left hand, it is to the left, ie Qwerty C, so it is the same movement as the normal right hand one)
As I said, it comes at the expense of the O-U jump (middle finger top - index bottom)
It does not score as well either, but just more comfy for me.

ps: I know, I know, moving the zero breaks the 'numbers on bottom row' thing, oh well, I wasn't used to it anyways, so I'm ok with it.  :P

Given your comment above about consonants on the right, I did a little playing around. I took Vu Keys, which I know is good for English, and flipped right and left, then played around (mostly on home row) and eventually ended up with layout below, which for some tests beats Vu Keys. And of course MTGap and Colemak and Dvorak... :-)

Probably there's a swap I've missed. Anyway this falls under the "just rearrange keys" category so you won't need to relabel keys or anything...

Scores, screenshot and json attached.

Cheers, Ian
Cool, thank you very much I will check it out.
The vowels on the left is another compromise for me:
1- I usually find it 'easier' (mentally) when the consonants are on the left ..
but
2- As mentioned, at the same time, it creates tensions in my left forearm
(had tendinitis in my left forearm too, a long time ago when I was a music student ! something 'special' with that left arm? hehe)
Title: Down arrow
Post by: iandoug on 2017-Jun-11 17:32
Just wondering.... when editing/typing, do you/people you know use the middle finger for the down arrow, or the thumb?

I find myself using my thumb and hardly ever the middle finger... particularly when editing text, eg say I need to add a comma/whatever at the end of a bunch of rows...

So it's end, ctrl-v, down, end, ctrl-v, down... etc. I find it easier to swing the thumb under than to move the middle finger.

Comments? (above on MS Natural, ANSI 104 would be the same...)

Thanks, Ian
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2017-Jun-11 17:37
And if people are actually using their thumb on Down, then the whole arrowkey cluster is wrong...

Games are a different use case.
Title: Re: Balanced Keyboard Layout
Post by: philippe.quesnel on 2017-Jun-11 18:18
I would need to pay more attention in general, but I do use the thumb for cases like the one you described.
But not in other situations I would think.
Title: Re: Balanced Keyboard Layout
Post by: mattiasthalen on 2017-Jul-10 05:03
I've tried to wrap my head around all the layouts here and it has left me quite confused.
Seems like BEAKL 5 Matrix is the way to go if using an Ergodox, right?
Title: Re: Balanced Keyboard Layout
Post by: veruna on 2017-Jul-12 00:18
double pinyin based on bealk 6
not much of science here, just arranged Chinese pronunciation by frequency.
(http://vnz.ucoz.com/otherpic/double_pinyin_bealk_6.jpg)
Title: Re: Balanced Keyboard Layout
Post by: Den on 2017-Jul-12 03:44
I've tried to wrap my head around all the layouts here and it has left me quite confused.
Seems like BEAKL 5 Matrix is the way to go if using an Ergodox, right?

BEAKL 5 and BEAKL EZ Matrix are pretty close. BEAKL 5 scores slightly better on KLA, by 1-4%. But it is unconventional by putting some letters outside the main 30-block. If you can tolerate that.

I personally use BEAKL EZ because I like letters inside. But most importantly, it overlaps perfectly with my numpad design, when taking into account the punctuations.
Title: Re: Balanced Keyboard Layout
Post by: Babieca on 2017-Jul-24 07:47
I've been using a standardized version of this layout since April 2014 and loving it
https://forum.colemak.com/topic/1832-widely-alternating-layouts-work-in-progress/
It scores pretty well on PKLA
Title: Mmm.
Post by: iandoug on 2017-Jul-24 16:25
@Den.
Stumbled across this while looking for something else.

http://qiita.com/ZeptByteS/items/6e6a3e46552dcb105948

If your Japanese is as bad as mine, Google translates quite well:
https://translate.google.com/translate?hl=en&sl=ja&u=http://qiita.com/ZeptByteS/items/6e6a3e46552dcb105948&prev=search
Title: Re: Mmm.
Post by: Den on 2017-Jul-24 17:59
@Den.
Stumbled across this while looking for something else.

http://qiita.com/ZeptByteS/items/6e6a3e46552dcb105948

If your Japanese is as bad as mine, Google translates quite well:
https://translate.google.com/translate?hl=en&sl=ja&u=http://qiita.com/ZeptByteS/items/6e6a3e46552dcb105948&prev=search

Very interesting. Even Japanese found out about my BEAKL theory and design. (Reminds me to update the layout on deskthority. )

E even tried to modify er own version. But some criticisms. H-I swap is unfounded.  I is more common than H, thus should be on faster finger. Moreover H on pinky means H-vowel bigrams will always be inward rolls; including H-I roll.

Title: Re: Mmm.
Post by: iandoug on 2017-Jul-25 01:51
E even tried to modify er own version. But some criticisms. H-I swap is unfounded.  I is more common than H, thus should be on faster finger. Moreover H on pinky means H-vowel bigrams will always be inward rolls; including H-I roll.

I saw some things I didn't like about BEAKRAK so started playing ... attached layout gets better scores on Den1 scoring on Alice at least.

His input text was a poor test ... lots of English words run together, no spaces, no Caps, no punctuation, no newlines....
Title: Re: Mmm.
Post by: Den on 2017-Jul-26 00:13
I saw some things I didn't like about BEAKRAK so started playing ... attached layout gets better scores on Den1 scoring on Alice at least.

His input text was a poor test ... lots of English words run together, no spaces, no Caps, no punctuation, no newlines....

BEAKRAK's worse offense is it violates the tenet of BEAKL by overloading the pinky, especially reaching outside the home column. Yes top pinky is very poor key, but it's still better than stretching the pinky sideways. The benefit of top pinky is it still decent for rolls with other top row keys. OTOH the outside pinky is just bad all around.
Title: Re: Mmm.
Post by: iandoug on 2017-Jul-26 01:52
BEAKRAK's worse offense is it violates the tenet of BEAKL by overloading the pinky, especially reaching outside the home column. Yes top pinky is very poor key, but it's still better than stretching the pinky sideways. The benefit of top pinky is it still decent for rolls with other top row keys. OTOH the outside pinky is just bad all around.

I was doing some tests with my modified version and KLA picked up some "impossible" fingerwork. So there are other issues with the design. Will see if it's worth spending time on to fix.
Title: Re: Mmm.
Post by: iandoug on 2017-Jul-26 16:46
I was doing some tests with my modified version and KLA picked up some "impossible" fingerwork. So there are other issues with the design. Will see if it's worth spending time on to fix.

Easy fix. They had Rshift on the left hand and LShift on the right hand. Just a quick swap needed.

Here's results on Alice (your original scoring)

Other layouts are variants from creator of HIEAMSTRN (lalop) that I found on Colemak forum. Getting ready to do a round of tests again, added a bunch of new layouts....
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2017-Jul-28 08:49
@Den

Getting the courage up to add some entries to Deskthority about ErgoLinear/Matrix etc ... is this the first place it surfaced?

 Reply #417 on: 2016-10-25, 12:49:50 (in this thread)

Trying to remember how we arrived at it... :-)

Geez, nearly a year ago. Doesn't seem that long :-)

thanks, Ian
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2017-Jul-28 08:54
@Den

GH discussion: https://geekhack.org/index.php?topic=90696.0
In case you missed it.
Title: den1 vs den2 scoring
Post by: iandoug on 2017-Jul-29 16:40
@Den

in Den2 scoring, you do at line 30 in analyzer.js:

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

Just wondering why you multiply the x distance by 1.5.

Thanks, Ian
Title: Re: den1 vs den2 scoring
Post by: Den on 2017-Jul-29 20:37
@Den

in Den2 scoring, you do at line 30 in analyzer.js:

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

Just wondering why you multiply the x distance by 1.5.

Thanks, Ian

penalize lateral movements
Title: Re: den1 vs den2 scoring
Post by: iandoug on 2017-Jul-30 03:16
penalize lateral movements

Yes, I figured, but by default then that's going to punish ANSI and to a lesser extent, ErgoDox layouts (ANSI because of the stagger, and ErgoDox because the large vertical keys' centre is not horizontal to the keys next to them).
[edit - which of course means Y distance, not X, silly boy]

Also the thumb clusters on ErgoDox are not horizontally aligned, which is further complicated by the fact that moving the thumb sideways is not as big an issue as moving the pinky sideways.

On ErgoLinear/Matrix the only things moving sideways are pinky, index and thumb. I think the only problem in that group is the pinky... to me it feels the same effort moving the index or thumb up/down or sideways.

I think the point I'm sort of aiming at are questions like
"is increasing the distance the best way of penalising horizontal movements?"
"is it fair to punish a thumb moving sideways as much as a pinky moving sideways?"

So I'm wondering if this is not a function of "finger penalty" rather than distance penalty? Or should we have different sideways penalties per finger?
Even doing that is going to punish ANSI for being ANSI, since the design dumps such a lot onto the right pinky.

(Yes ANSI sucks big time and needs to be dumped... I get so frustrated with the guys on the Colemak forums forever trying to find the perfect layout on a bad design. Lipstick on pigs and all that.)

Cheers, Ian

Title: Re: Balanced Keyboard Layout
Post by: Den on 2017-Aug-03 10:47
KLA version 3 to try out new scoring ideas

http://shenafu.com/code/keyboard/Keyboard%20Layout%20Analyzer%203.html

Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2017-Aug-03 11:42
KLA version 3 to try out new scoring ideas

Okay will take a look. From my side I've managed to add Ergolinear/Matrix to my local copy of Patrick's original.
Busy going through all the layouts on the dropdown vs all the layouts in "layouts" folder to see what's what, what needs to be added, what needs to be dropped, etc...

I was also working through your code (V2), and something puzzled me ... there was a penalty added for AltGr, and also for Shift, which is understandable, but then the code checked for AltGr+Shift, and added penalties again... but that seems double punishment. It didn't affect any of our layouts but would affect Some of the complex Euro ones that put things on ShiftAltGr.

So I don't know yet if that is what you were referring to about "redundant" penalties being removed... or something else.
Will be busy tonight so will only really have time over the weekend I think.

I was wondering if we should maybe take a step back and put the scoring ideas into words first, and then discuss them... Suppose we should start with what Patrick did. Might also be useful to do same exercise with ADNW/whatever's ideas, and Michael's (IIRC). Dunno how important in the real world, inward/outward rolls are. Nice to have I suppose, but are lots of them better or worse than few? Same with row jumps etc.
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2017-Aug-03 11:46
Oh yeah, the "Same Hand" metric ... how should that be interpreted?

Close to 50==better, or lower==better?
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2017-Aug-03 11:48
I've been wondering about speeding up KLA ... won't skipping the "Customised layout" routine help? I never use it. When you have 12 layouts, and a 300k input text (as per Scotty and his Dutch/English input) then each test takes quite a while to run...
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2017-Aug-03 12:13
Played around a bit... should there be such a big difference between MTGap on ANSI and MTGap on ErgoDox? Don't remember the thumbshift having such a dramatic difference before.
Input was Keyboard Layout Editor homepage.

Title: Re: Balanced Keyboard Layout
Post by: Den on 2017-Aug-03 12:48
I've been wondering about speeding up KLA ... won't skipping the "Customised layout" routine help? I never use it. When you have 12 layouts, and a 300k input text (as per Scotty and his Dutch/English input) then each test takes quite a while to run...

removing personalized layout does help. the bulk of processing is still generating graphs. analysis part is relatively quick.
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2017-Aug-03 13:02
removing personalized layout does help. the bulk of processing is still generating graphs. analysis part is relatively quick.

Wonder if switching to Google Graphs would be quicker?
Swap CPU cycles for bandwidth+pause?
BTW while we're on the topic, the finger usage pie charts should either start with right pinky, or else go anticlockwise, so that the left fingers end up on the left, and the right on the right. I realise this is Patrick's legacy code.
Haven't looked at how he calls the chart drawing routines.... was on the ToDo list :-)
Title: Re: Balanced Keyboard Layout
Post by: Den on 2017-Aug-03 13:47
Played around a bit... should there be such a big difference between MTGap on ANSI and MTGap on ErgoDox? Don't remember the thumbshift having such a dramatic difference before.
Input was Keyboard Layout Editor homepage.

pinky now has much higher penalty, which greatly affects same pinky scores.
Title: Re: Balanced Keyboard Layout
Post by: Den on 2017-Aug-03 14:13
Wonder if switching to Google Graphs would be quicker?
Swap CPU cycles for bandwidth+pause?
BTW while we're on the topic, the finger usage pie charts should either start with right pinky, or else go anticlockwise, so that the left fingers end up on the left, and the right on the right. I realise this is Patrick's legacy code.
Haven't looked at how he calls the chart drawing routines.... was on the ToDo list :-)

no option for counterclockwise. the best is set starting angle at the bottom of the circle.
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2017-Aug-03 14:20
no option for counterclockwise. the best is set starting angle at the bottom of the circle.

Elegant solution :-)
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2017-Aug-04 14:48
  • slightly more optimized (alas, major bottleneck is garbage collection from external libraries)

FWIW on my local version I've removed various external things like google analytics, AddThis, etc. Unnecessary clutter for our purposes.

Running tests on KLA eventually chews up my RAM (16 GB) and machine slows to a crawl. Even shutting browser does not always release all memory, have to exit out of KDE and restart it to reset RAM.
Tried 4 different browsers, all the same.
Title: Re: Balanced Keyboard Layout
Post by: Den on 2017-Aug-04 19:00
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2017-Aug-05 03:33
  • fixed graphs showing wrong values
  • removed redundant stuff from .html that's populated by template
  • removed social media crud

Over on GH, Scotty has picked up difference between same-finger usage in your summary table, and the values on the detail page.
I also noticed "unusual" results on the summary table.
This be with V3 of your scoring.

You on holiday now that you have time for this? :-)

Yeah I've been wondering why the same stuff was on the main HTML page as well as the template file. Also wondered why it was necessary to put the initial layouts into memory when they could be pulled off disk on demand.
Title: Re: Balanced Keyboard Layout
Post by: Den on 2017-Aug-05 05:18
Over on GH, Scotty has picked up difference between same-finger usage in your summary table, and the values on the detail page.
I also noticed "unusual" results on the summary table.
This be with V3 of your scoring.

Graph scores are raw. Summary scores are normalized.

Quote
Also wondered why it was necessary to put the initial layouts into memory when they could be pulled off disk on demand.

Load on demand would require AJAX, i.e. more complicated code. Just simpler to include another .js file with presets. However, that means the data might not match when loading layouts later, if preset and .json have different data.
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2017-Aug-05 13:00
Load on demand would require AJAX, i.e. more complicated code. Just simpler to include another .js file with presets. However, that means the data might not match when loading layouts later, if preset and .json have different data.

The code to load user-selected layout is already there, I thought it should be doable to have a short list of layouts in an array, and then run through the relay "faking" the user selecting them. It does call PHP on the backend to do the actual file reads.
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2017-Aug-05 13:14
However, that means the data might not match when loading layouts later, if preset and .json have different data.

If I read Patrick's code correctly then it first checks in memory to see if the named layout is there, before going to disk. In truth some of the preloaded layouts don't exist on disk. I put them there when I started having multiple versions with different preloads, and found some attempted loads failed.
Title: Re: Balanced Keyboard Layout
Post by: Den on 2017-Aug-05 16:41
ideas to improve KLA:
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2017-Aug-05 17:02
ideas to improve KLA:
  • allow user to customize parameters of efforts, penalty scores (e.g. per finger penalties, score category weights)
  • include other typing penalties (e.g. outward rolls, seesaw, finger usage percentage)

Seesaw is a new one for me.
Row jumps?
Big stretches? Though I suppose that's more in ctrl-combos than regular typing. And you're supposed to use opposite hands :-)

This goes back to my suggestion to put all this in words first, then maybe talk about how to rationally measure them, and how important each is to evaluating a layout.
Thought finger usage percentage was already included?

There's also another "bug" in distance measurements. All measurements are from centre of key to centre of next key. But in real world people hit large keys off-centre, possibly at "what would be closest centre if it was 1U wide".

I also stumbled across the fact yesterday that the Planck guys put their keys 19mm apart (centre to centre) while Cherry apparently uses 19.05 mm ...
I think KLE uses 19mm (and thus my home-made keyboard does the same).
Title: Re: Balanced Keyboard Layout
Post by: Sc0tTy on 2017-Aug-06 15:20
Hi guys, figured I create an account here to join the discussion on KLA :)

I just want to reiterate how much I appreciate both of you on your work with the KLA and layouts in general :)

Graph scores are raw. Summary scores are normalized.

I understand that the raw and summary scores are not the same, but how can a 100% flipped layout result in a difference score?
Unless I made a mistake in flipping the layout, which I haven't found, that score must be the same right?
And if there is a bug it will probably impact scores of all layouts as well.
I've attached both layouts for you to check out.
To clarify: all raw/sub results are the same for the original and flipped layouts its just the summary score that's different.

ideas to improve KLA:
  • allow user to customize parameters of efforts, penalty scores (e.g. per finger penalties, score category weights)
  • include other typing penalties (e.g. outward rolls, seesaw, finger usage percentage)

It would be awesome if there was an option to change the penalty for each key on the board. Another something I'd like to see is that you can remove and add more layouts to the test. It starts with 12 layouts but when I'm "hunting" for a new score I only need two: my WIP and my baseline. The other 12 layouts are useless to me unless I want to do a full comparison and usually its never against the 12 layouts that are preset.
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2017-Aug-06 15:38
It would be awesome if there was an option to change the penalty for each key on the board. Another something I'd like to see is that you can remove and add more layouts to the test. It starts with 12 layouts but when I'm "hunting" for a new score I only need two: my WIP and my baseline. The other 12 layouts are useless to me unless I want to do a full comparison and usually its never against the 12 layouts that are preset.

My 2c:

1. changing penalties makes comparing layouts more difficult, the playing field must be level, else your results will differ from mine, and whose will be correct?
Although I do understand that people have different hands and perhaps the "predefined" penalties are not appropriate for them.
But when wearing my hat of "evaluate all layouts to find the best" I need a stable baseline... :-)

2. agree on desirability of adjusting number of layouts in tests... I work at the same as you (but sometimes two WIP at the same time), and thus extra layouts just wastes time for each test, but when running auto-testing of all layouts, its nice to do bigger batches at a time. Only problem is browser timeouts, especially on large input tests. Need to find a balance between input size and number of layouts.

I have finally (I think) persuaded Patrick's original code to write what I need to the console.log so I can test all the layouts with his scoring. But need to first redo the database tables (layouts, tests, scores) to handle the new additions.
More work than it looks :-)
Need to find a way to automate it more ... perhaps add extra meta-data to the layout jsons, and read them directly, instead of maintaining a spreadsheet that gets exported to csv and imported to database.
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2017-Aug-08 16:16
@Den

Can you please mark these as either Major, Minor, or ForgetAboutIt?

standard.BEAKL-Opted36
standard.BEAKL-opted4
standard.beakl_stretch
ergodox.beakl_opted1
ergodox.beakl_opted3
ergodox.BEAKL-Opted4-Ergo
ergodox.BEAKL-Opted4-Ergo-Alt
ergodox.beakl34kinesis
ergodox.BEAKL-Opted36-Ergo
matrix.BEAKLEZ
ergolinearDen.BEAKL5

Thanks, Ian
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2017-Aug-09 05:36
@Den

Idea that came up from talking to Scotty on GH.

Proposal: on ErgoLinear/Matrix layouts, lower the pinky columns by about 1U, to provide a more natural location for pinky.
Won't affect current KLA models because there is no measurement for finger length in models, but will make a comfort difference in the real world.

Comments?
Title: Re: Balanced Keyboard Layout
Post by: Sc0tTy on 2017-Aug-09 14:45
Is there a list of all available keycodes in KLA ?

BEAKL Opted4 Ergo AltGr has a copy keycode for instance
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2017-Aug-09 16:12
Is there a list of all available keycodes in KLA ?

BEAKL Opted4 Ergo AltGr has a copy keycode for instance

Use the unicode glyph point, eg u:2398

See for example http://www.fileformat.info/info/unicode/char/2398/index.htm
(fileformat.info site is very useful for poking around Unicode).

Patrick uses some "special" codes (negative numbers) for left/right eg with shift key.

You know you can change what's on the key by clicking on it, right? :-)
Just checking. :-)

Above technique assumes the glyph is in the font you are using on the keyboard.

I sometimes put "unusual" characters on keys, to fill up slots, and sometimes to force KLA to display single glyph at bottom instead of floating to top left. Think Den fixed that bug.
Title: Re: Balanced Keyboard Layout
Post by: Sc0tTy on 2017-Aug-09 16:53
Use the unicode glyph point, eg u:2398

See for example http://www.fileformat.info/info/unicode/char/2398/index.htm
(fileformat.info site is very useful for poking around Unicode).

Patrick uses some "special" codes (negative numbers) for left/right eg with shift key.

You know you can change what's on the key by clicking on it, right? :-)
Just checking. :-)

Above technique assumes the glyph is in the font you are using on the keyboard.

I sometimes put "unusual" characters on keys, to fill up slots, and sometimes to force KLA to display single glyph at bottom instead of floating to top left. Think Den fixed that bug.

Yeah I know you can change the keys when clicking, but there is no list :P

Ah okay so you can just add random unicode, okay good to know :)
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2017-Aug-13 13:39
@Den

Working on my database loader program..... guess you added corpusChars to the scoring, Patrick doesn't have it, and that breaks my Efficiency calculations....

Let me see if I can stick it in... but then need to redo the first two "test" tests...

Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2017-Aug-16 04:52
@Den
Trying to wrap my head around the various scoring models and the results they produce.

This be top 30 with Patrick's original scoring:

Code: [Select]
+--------------------------------+-------+
| fullname                       | score |
+--------------------------------+-------+
| Seelpy Ergolinear 1.4          | 86.86 |
| Seelpy Ergolinear 1.8          | 86.73 |
| Seelpy Ergolinear 1.22         | 85.51 |
| Seelpy Ergolinear 1.17         | 85.50 |
| SchizoKBD AltGrSpc             | 79.64 |
| SchizoKBD shifted-AltGrSpc     | 79.62 |
| BEAKL 4 Mod Ian AltGr 3        | 75.31 |
| BEAKL Ergo Opted 4 Mod Ian     | 74.74 |
| SchizoKBD shifted              | 74.69 |
| Ian R1 p                       | 73.98 |
| MTGap  Ergolinear Thumbshift 2 | 73.93 |
| BEAKL Ergo Opted 1             | 73.66 |
| MTGAP Ergo Thumbshift          | 73.62 |
| BEAKL Ergo Opted 4             | 73.55 |
| X6.4H Ergolinear               | 73.54 |
| Ian M2 tweak                   | 73.40 |
| Dsend Ergo Thumbshift          | 73.36 |
| BEAKL Ergo Opted36             | 73.29 |
| X6.3H Ergolinear               | 73.26 |
| BEAKL Ergo Opted 4 Alt         | 73.24 |
| Vu Keys Ergolinear             | 72.89 |
| BEAKL Opted36                  | 72.53 |
| BEAKRAK Mod Ian                | 72.51 |
| BEAKL ErgoLinear 5             | 72.49 |
| BEAKL Matrix EZ                | 72.35 |
| BEAKL Ergo Modified            | 72.28 |
| X2 Ergolinear HspaceAltgr B    | 72.17 |
| X5 Ergolinear                  | 71.60 |
| BEAKL Ergo Opted 3             | 71.51 |
| Ian X4                         | 71.39 |

But if we take the first few and run them on Den1 scoring, we get

Code: [Select]
#1 Seelpy 1.22 Ergolinear 82.99 +0%
#2 Seelpy 1.17 Ergolinear 83.11 +0%
#3 Seelpy 1.8 Ergolinear 84.26 +2%
#4 Seelpy 1.4 Ergolinear 85.14 +3%
#5 BEAKL 4 Mod Ian AltGr 3 99.37 +20%
#6 schizoKBD-shifted 100.62 +21%
#7 schizoKBD-AltGrSpc 121.84 +47%
#8 schizoKBD-shifted-AltGrSpc 121.97 +47%
#9 Personalized 127.68 +54%

And on Den3

Code: [Select]
#1 Seelpy 1.4 Ergolinear +0% 102.30 41.64 26.90 0.09 33.68
#2 Seelpy 1.8 Ergolinear +0% 102.59 40.17 27.88 0.09 34.46
#3 Seelpy 1.22 Ergolinear +2% 104.52 40.73 28.64 0.19 34.97
#4 Seelpy 1.17 Ergolinear +2% 104.56 40.76 28.64 0.18 34.98
#5 BEAKL 4 Mod Ian AltGr 3 +11% 113.24 62.80 22.71 2.43 25.30
#6 schizoKBD-shifted +14% 116.68 63.37 23.48 2.99 26.83
#7 schizoKBD-AltGrSpc +24% 127.17 77.75 28.57 1.31 19.53
#8 schizoKBD-shifted-AltGrSpc +25% 127.38 77.97 28.57 1.31 19.53

Apart from the order, I'm looking at the percentage differences between top and others, the differences are much starker on Den1.

IIRC earlier versions of Den3 also produced a different order of results with BEAKLs on top ... what did you change between that and current version of Den3?

thanks, Ian
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2017-Aug-29 08:07
@Den

As far as differences between Den 1 and Den 3 go... if I want to understand the changes, I only need to compare the two analyzer.js, right?

Was doing some tests on Den 3 and Seelpy 1.5 was consistently beating Seelpy 1.22 (latest version), whereas on Den 1, 1.22 was best. So want to see why... :-)

Thanks, Ian
Title: Re: Balanced Keyboard Layout
Post by: Den on 2017-Sep-07 23:05
@Den

As far as differences between Den 1 and Den 3 go... if I want to understand the changes, I only need to compare the two analyzer.js, right?

Was doing some tests on Den 3 and Seelpy 1.5 was consistently beating Seelpy 1.22 (latest version), whereas on Den 1, 1.22 was best. So want to see why... :-)

Thanks, Ian

Den 3 puts much more emphasis on finger weights. especially punishes pinkies. Finger usages also more relevant; closer to distance scores.
Title: Re: Balanced Keyboard Layout
Post by: Den on 2017-Sep-08 00:22
Read other peoples' thoughts on finger weights. Some treat top-row middle and ring fingers as extended home row, because of natural curvature of the hands. Some don't mind stretching index to middle columns; ultimately still not as good as bottom and top row index.

Anyway, retweaked Opt, and got this:

Code: [Select]
jhau, gmrpz
qoeiy dstnb
/k'.x wclfv

(on Den 3) Higher distance offset by both lower finger usage and same -finger repetition.

Even lower usage on pinky (yay!). Less than 1% typed by the left pinky. H now on top ring; needs getting used to, particularly HE bigram, but any ring finger key is really faster than even home pinky. OEI on home row feels more Dvorak. Now left ring finger will do more work for OH, both common letters.

As for consonant district, this has reduced same finger usage (on Den 3) than previous BEAKL layouts. Interestingly, GMP/WCF are interchangeable between top and bottom rows. I prefer G on top row--NG rolls feel better like this. MP/CF tend to appear on the same row. C on bottom is slightly more comfortable, rolling together with N and T.
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2017-Sep-08 01:09
Anyway, retweaked Opt, and got this:

Code: [Select]
jhau, gmrpz
qoeiy dstnb
/k'.x wclfv

On which form factor? ANSI?

thanks, Ian
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2017-Sep-08 17:46
Played around a bit on ANSI. You won't like it because it has the H on the pinky, but I was stuck between my S2 layout and yours... (score around 139 on Den3).
Then I moved the H and got a fright ... some of the metrics are better, some not.

Can you please add Fira Sans or Hack to the font options? (for code).

BTW this mod also scores better on Den1, but not as well as S2. (all tests done with Alice only)
So Den3 scoring model clearly a different kettle of fish. I've finished running all the tests on Patrick's and Den1 scoring, need to do the whole exercise again with Den3 ... is it now considered stable, or are you still tweaking?




JYIU, GRCFZ
HOEAQ DTSNB
/K'.X WMLPV



attached.
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2017-Sep-08 17:49
Problem with this mod is that to type "The", you need left-pink-on-shift, right hand on T, then move left pinky to "h", which triggers a same-finger-usage count.
Title: Re: Balanced Keyboard Layout
Post by: Den on 2017-Sep-08 17:53
On which form factor? ANSI?

thanks, Ian

i only work with matrix
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2017-Sep-08 18:04
i only work with matrix

Please post json.. :-)

thanks, Ian
Title: Re: Balanced Keyboard Layout
Post by: Den on 2017-Sep-08 18:09
Played around a bit on ANSI. You won't like it because it has the H on the pinky, but I was stuck between my S2 layout and yours... (score around 139 on Den3).
Then I moved the H and got a fright ... some of the metrics are better, some not.

BTW this mod also scores better on Den1, but not as well as S2. (all tests done with Alice only)
So Den3 scoring model clearly a different kettle of fish. I've finished running all the tests on Patrick's and Den1 scoring, need to do the whole exercise again with Den3 ... is it now considered stable, or are you still tweaking?

Main issue is KLA is too simplistic, compared to other analyzers--like Opt. It doesn't consider stuff like trigrams, finger-pair weights (e.g. pinky-ring is bad), individual key weight, finger percentage, hand balance, etc.

So I'm wary of tweaking layouts from Opt just to get screaming scores on KLA.

Quote
Can you please add Fira Sans or Hack to the font options? (for code).
try to use the code tags, or Insert Code button.
Title: Re: Balanced Keyboard Layout
Post by: Den on 2017-Sep-08 18:42
Please post json.. :-)

thanks, Ian

see attached.

Revised number pad. (due to comma moved up a row.)
Code: [Select]
  +=*
  894,
-70123
 /65.:

actually looks neater than before. note puncs are fixed in place, but Opt still uses them to analyze and score. comma was missing from corpus.
Title: Re: Balanced Keyboard Layout
Post by: Den on 2017-Sep-08 22:34
Den3 QOL:
-- layout loaded as soon as selected (don't need to click Load button)
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2017-Sep-09 09:52
Main issue is KLA is too simplistic, compared to other analyzers--like Opt. It doesn't consider stuff like trigrams, finger-pair weights (e.g. pinky-ring is bad), individual key weight, finger percentage, hand balance, etc.

Yeah, I partly agree... the question is, has KLA captured the core of what makes one layout better than another, or are additional metrics necessary, as in other analyzers?

I intend to get to Opt once I finish testing with Den3, but the thing that is bothering me is that with Opt you can tweak parameters as much as you like, and someone could say that I tweaked it so that my layouts came out as best. Which is why for the moment  I am using scoring models from others....

FWIW, KLA does a reasonable job of saying that MTGap is better than QWERTY, for example. So it must be doing SOME things right.

I'm busy redoing my database-interrogation-pages to put all layouts/tests and analyzer results on one page (instead of 4 or 6 as at present). Just pick what you want to see. Did not do it before because Patrick's and your scores were in different tables with different things stored etc.

I don't like how "code" shows up ... maybe must try picking a bigger font size. Also putting "font" inside "code" does not work. So ended up just doing "font" with Courier. But Fira or Hack are better than Courier.
Title: Re: Balanced Keyboard Layout
Post by: Den on 2017-Sep-10 16:42
The advantages of KLA is ease of use and the appealing charts and graphs. As for its scoring, it does a good enough general measurement of key areas that are understood and agreed upon(distance, finger usage, same finger and hand) and to show the trends toward layouts with better efficiency and ergonomics. It also does well to involve the thumb, which some other programs tend to neglect.

As we continue to discover more optimal layouts and reach the plateau of efficiency, that's when we incorporate the minute nuances of typing in order to further differentiate the upper echelon of layouts. Advanced theories like inward rolls (Dvorak), finger weights (Workman, BEAKL), modifiers (Arensito, Seelpy),  etc.
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2017-Sep-10 17:25
As we continue to discover more optimal layouts and reach the plateau of efficiency, that's when we incorporate the minute nuances of typing in order to further differentiate the upper echelon of layouts. Advanced theories like inward rolls (Dvorak), finger weights (Workman, BEAKL), modifiers (Arensito, Seelpy),  etc.

Was playing around a bit earlier with Den3 ... your BEAKL5 does better than BEAKl7. What does Opt say?
Title: Re: Balanced Keyboard Layout
Post by: Den on 2017-Sep-10 19:42
Was playing around a bit earlier with Den3 ... your BEAKL5 does better than BEAKl7. What does Opt say?

Based on my latest configuration in Opt, obviously BEAKL7 is slightly better (~1.6%). That's its purpose--to find the best layout for a set of constraints. On KLA, BEAKL7 slightly loses by (~1.08%). Too close to call which is better.

On KLA, BEAKL5 scores a lot better on distance. Understandably more frequent letters are on the home row; about 5% more usage on home row. However it loses substantially in finger usage and same finger penalty.

OTOH, in Opt, you can set the effort for each key individually. Thus top and bottom row keys can have lower effort scores than home row keys. Also my settings penalize pinky-ring combos even more than ring-ring. Opt takes more factors into account.

So choose your poison. Do you prefer lower finger effort at the expense of distance? Do you care to take the load off the weaker pinky and distribute that load to the stronger fingers?
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2017-Sep-11 02:48
As we continue to discover more optimal layouts and reach the plateau of efficiency, that's when we incorporate the minute nuances of typing in order to further differentiate the upper echelon of layouts. Advanced theories like inward rolls (Dvorak), finger weights (Workman, BEAKL), modifiers (Arensito, Seelpy),  etc.

Stumbled across this:
https://github.com/mw8/white_keyboard_layout

However results from Den1 and Den3 against other ANSI layouts.....


Title: Re: Balanced Keyboard Layout
Post by: Den on 2017-Sep-11 17:46
Stumbled across this:
https://github.com/mw8/white_keyboard_layout

However results from Den1 and Den3 against other ANSI layouts.....

Did you properly set the keys to his preferred fingers? like the bottom row doesn't use the pinky for any letter.

At a glance, doesn't look that good. 'R' in the far bottom index. 'OU' typed with same finger. Very high same finger overall.

Some of his reasoning seem flawed. We can assess that in detail later.

There is not much difference between novels, academic, and email texts. They use the same words and letters in similar frequency. Besides, superior layouts can handle them all equally well, and come out on top regardless of what you throw at them--time and time again.
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2017-Sep-12 01:18
Did you properly set the keys to his preferred fingers? like the bottom row doesn't use the pinky for any letter.
At a glance, doesn't look that good. 'R' in the far bottom index. 'OU' typed with same finger. Very high same finger overall.
Some of his reasoning seem flawed. We can assess that in detail later.

MMm no I assumed home positions same as for regular ANSI ... will take another look.
Actually read through his philosophy last night and then realised why my attempts to improve it failed ... he takes the view that the hands should NOT alternate all the time, whereas AFAIK both your and Pat's scoring models want them to alternate.
And he may actually have a point there (eg "the" on an inward roll is clearly better than HE on left and T on right, but what happens with "ETHER" etc. )... but you need hand balance, so how do achieve that?
Will take another look later today.
Title: Re: Balanced Keyboard Layout
Post by: Den on 2017-Sep-12 02:16
he takes the view that the hands should NOT alternate all the time, whereas AFAIK both your and Pat's scoring models want them to alternate.
And he may actually have a point there (eg "the" on an inward roll is clearly better than HE on left and T on right, but what happens with "ETHER" etc. )

But this is a very specific case of trigram and three-finger combo. THE is the only trigram worth considering. Moreover ring-middle-index combo is rare, so it's not viable to fit every common trigrams this way. So do you destroy the health of the rest of the layout just to accommodate one trigram?

Despite that, there has been some claims that splitting all trigrams into 1-23 or 12-3 is best and fastest overall. The same also claims that frequent hand alternation is faster than long sequences using the same hand.

Look at this as a bell-curve of letters typed consecutively on the same hand. i.e. 1-gram, 2-gram, 3-grams, 4-grams, etc. for the same hand. Generally 2-grams are best, then 1-gram, then 3-gram. So frequent hand alternation errs on the side of more 1-gram, avoiding longer grams. On the contrary, low hand alternation leads to slower 3-grams, 4-grams, or worse.
Title: Re: Balanced Keyboard Layout
Post by: Den on 2017-Sep-12 02:19
Added to Den3: White layout and several academic text presets. QOL selecting a preset text from drop-down automatically applies it to the textarea.

See for yourself if academic text corpus makes a difference. As far as I can tell, it doesn't affect the ranking at all. The best 5 stays in the top 5.

Unfortunately, White's layout stays in the bottom tier through all tests. It really falls far short from his aim at both prose and code. Frankly it's terrible for either.

Sources:
http://www.jsrponline.com/Archives.php
http://www.scientificpapers.org/

Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2017-Sep-12 02:40
Added to Den3: White layout and several academic text presets.

Ah I see I need to move the home keys. Was wondering why on earth he put C on home and not I ... :-)
BTW his layout is missing the underscore, I put it as "natural" on the & key, and made & shifted. Was in two minds about that, it depends what sort of programs you write (and if you use underscores in names) which gets used more.

I think it is going to do badly on KLA simply because what KLA measures, and what he designed for, are opposite.
Personally I don't like the layout, I just threw it into the discussion because it takes a different approach to what we've been doing (aiming to balance hands and finger usage).

Just downloaded Den3 last night, will re-download. Luckily I hadn't gotten around to modifying the layouts and presets selection yet :-)

I normally try to strip the non-ANSI characters out of the inputs (or else replace them with HTML-entity code) so that they can be typed easily on ANSI, without required special key combos. Just in the interests of comparing apples with apples, else BePo/AdNW and similar with all their special characters will have key presses counted and layouts missing them won't.)
Title: Re: Balanced Keyboard Layout
Post by: Den on 2017-Sep-12 04:39
Something strange always bugged me: Why the final scores for same finger and same hand don't match the results in the misc. table. The most curious was how BEAKL 7 has such low same finger.

The issue is two-fold. One, for some reason, the final scores don't count same finger or same hand if the same key is pressed. This essentially ignores any penalty weighted by finger. e.g. double O or S on the pinky is discounted.

Two, the total keys pressed is taken into account. That gives an advantage to layouts that hit more keys for a given corpus. Instead, the final score coefficient should be consistent across the board for all layouts.

Solution:
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2017-Sep-12 04:53

Are you telling me the scoring model is completely broken? :-)

I assumed it was counting correctly, and the option to toggle "same key" in the Misc tab seems to support that.

Are you saying this is a bug on Patrick's side that got passed through to Den 1 and Den 3?

Maybe because Patrick did not count vertical distance, it was not necessary to add anything when same key pressed? Though key press count should have gone up.

Not quite sure you mean with "score coefficient" ... sounds like a divisor in a particular calculation?

It also seems like something similar to my "efficiency" calculation, which is based on the assumption you need to move 1 key to type the next letter. So it adds up all those distances, and then divides your actual distance by that, to get a percentage.
Which is probably a bit fuzzy :-)
Title: Re: Balanced Keyboard Layout
Post by: Den on 2017-Sep-12 05:03
The main context is the corpus. For any given text, count the number of times same finger and same hand has been used. So total number of keys pressed shouldn't matter at all.
Title: Re: Balanced Keyboard Layout
Post by: Den on 2017-Sep-12 05:44
Is shift-altgr ever used? Should I replace it with numpad layer?
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2017-Sep-12 05:55
Is shift-altgr ever used? Should I replace it with numpad layer?

Some Euro layouts use it. eg Aus der Neo-Welt (which is under ANSI not Euro.. :-) )
But "real" Euro layouts will probably use it more. Tried to find pics quickly but must be looking in wrong place.
or this.
https://en.wikipedia.org/wiki/Keyboard_layout#/media/File:Bangladesh_National_Keyboard_Layout.svg
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2017-Sep-12 05:58
https://u.teknik.io/nhIA31.png
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2017-Sep-12 12:35
Something strange always bugged me: Why the final scores for same finger and same hand don't match the results in the misc. table. The most curious was how BEAKL 7 has such low same finger.

Am trying to see what you are seeing ... but can't... where should I be looking?
I know we asked you about difference between summary page and Misc page, you said summary was standardised....
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2017-Sep-12 14:20
Am using this in key.js


KB.Key.labels = {};
KB.Key.labels[8] = "⌫";
KB.Key.labels[9] = "Tab";
KB.Key.labels[13] = "Enter";
KB.Key.labels[16] = "LShift";
KB.Key.labels[27] = "⎋";
KB.Key.labels[-16] = "RShift";
KB.Key.labels[17] = "Ctrl";
KB.Key.labels[18] = "Alt";
KB.Key.labels[-18] = "Alt Gr";
KB.Key.labels[20] = "CapLk";
KB.Key.labels[-91] = "OS";
KB.Key.labels[-93] = "R-Clk";
KB.Key.labels[-45] = "Ins";
KB.Key.labels[-93] = "Menu";
KB.Key.labels[32] = "⍽";


with the aim of preventing label clash.
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2017-Sep-12 15:43
Seelpy is different style of typing with different merits than traditional. may be preferred if you like chording or you have health problems that prevent you from reaching keys. (although for full chording, might look into stenotype.)

there is claim that chording is slower than traditional typing: http://www.tifaq.org/keyboards/chording-keyboards.html

Arensito is overall great layout for prose with low distance and same finger. its idea for coding is awesome because symbols are common for programmers and who wants to reach all around the keyboard.

some hybrid between seelpy, arensito, and adnw/beakl may or may not work. utilize extra layers, but not as extreme as seelpy with chording. optimizing uppercase still has merit.


Stumbled across this, posting here for future reference.

http://www.asetniop.com/about.shtml

Title: Re: Balanced Keyboard Layout
Post by: Den on 2017-Sep-12 18:32
GIT repo for Den3

https://bitbucket.org/Shenafu/keyboard-layout-analyzer
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2017-Sep-13 02:44
I see Wikipedia has an entry that wasn't there before:
https://en.wikipedia.org/wiki/Keyboard_layout#Modified_Blickensderfer

Tried it in KLA, as attached, scores are bad.
Tried fixing it to something more normal, got slight improvement but like White, don't think it's fixable without major home-row rearrangement. Which basically destroys the idea.
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2017-Sep-13 09:14
Another layout I can't improve much. Third one in a week...

http://scholarworks.rit.edu/cgi/viewcontent.cgi?article=1729&context=article

(PDF). Layout seems to be called Simulated Annealing.
Does barely better than QWERTY in KLA, which is not surprising given the home row.
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2017-Sep-13 12:09
Some suggestions for what to reward/penalise in analyzer.js

https://github.com/xsznix/keygen
Title: Ant Colony
Post by: iandoug on 2017-Sep-13 13:33
Another attempt by the clever people at using programs to find good layouts.

http://www-2.dc.uba.ar/materias/metah/Ant-Keyboard.pdf

I loaded it on Matrix, had to make a few changes/compromises and not all keys are there (all ANSI chars are though).

Results are reasonable, but I played around a bit on Den2 and Alice and managed to improve it. Still not wild about where all the punctuation is, some of the choices made no sense.

Anyway, screenshots attached.


Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2017-Sep-13 13:35
That GRY on left pinkie really bothers me.
And it looks like H really is a vowel :-)
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2017-Sep-13 14:54
You ever play with Evolve-Keyboard-Layout (German, python)

https://bitbucket.org/ArneBab/evolve-keyboard-layout

At first glance seems only for ANSI/ISO...
Title: integer programming
Post by: iandoug on 2017-Sep-13 15:49
More clever people:
http://resources.mpi-inf.mpg.de/keyboardoptimization/
links to PDF with layout:
http://resources.mpi-inf.mpg.de/keyboardoptimization/KO2014.pdf

I played a bit with their layout on Den1/Alice, screenshots attached.
Layout is not exactly as per their design, would require relabelling a few keys. But close enough for practical purposes in English.

@Den: the PDF also has a different hex swiping layout you might want to look at.


Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2017-Sep-13 16:14
Mmm. Interesting. Score is good, but same-finger usage is terrible.
Enough for today. :-)


Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2017-Sep-13 18:19
https://m.hexus.net/tech/news/peripherals/110024-x-bows-mechanical-ergonomic-keyboard-hits-kickstarter/

Not my cup of tea. Especially those blue switches.
Title: Re: Balanced Keyboard Layout
Post by: Den on 2017-Sep-13 19:20
Am trying to see what you are seeing ... but can't... where should I be looking?
I know we asked you about difference between summary page and Misc page, you said summary was standardised....

Normalization was a holdover concept from Patrick when he used percentages as part of the final score. However, we must question if that is correct method since my scoring system doesn't rely on percentages; it's straight up accumulative.
Title: Re: Balanced Keyboard Layout
Post by: Den on 2017-Sep-14 04:18
Test version at http://shenafu.com/code/keyboard/klatest/

Had to replace some presets because layouts won't work if missing relevant modifiers. (e.g. Maltron missing alt-gr).

changelog:
-- numpad as modifier (use key code u:90 for numlock) (not tested. preparation for next stage.)
-- tidy up the code (using http://jsbeautifier.org/ , http://jshint.com/ , and http://htmlformatter.com/ )
-- deleted extraneous files (social media related)

Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2017-Sep-14 04:28
Had to replace some presets because layouts won't work if missing relevant modifiers. (e.g. Maltron missing alt-gr).

Why does Maltron need AltGr? Or does Analyzer need it?
You can change the right-hand Alt to u:-12 to make it AltGr.
I made normal Alt under the G on Maltron.ergodox

BTW you need to fix things like U_RN layout because KLA can't handle pressing 2 keys with one thumb. :-)
We should also probably make this local:  http://patorjk.com/images/qwerty.png

Your P_RN seems to be missing &
Title: Re: Balanced Keyboard Layout
Post by: Den on 2017-Sep-14 05:30
created new file for sample text corpus. so it can be any length, and don't have to worry about formatting.
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2017-Sep-14 05:36
created new file for sample text corpus. so it can be any length, and don't have to worry about formatting.

You lost me... :-)
Oh, okay I guess you made a file for the dummy text that will load initially. :-)

Any reason you're not using Github?
Title: Re: Balanced Keyboard Layout
Post by: Den on 2017-Sep-14 05:42
Why does Maltron need AltGr? Or does Analyzer need it?
You can change the right-hand Alt to u:-12 to make it AltGr.
I made normal Alt under the G on Maltron.ergodox

something changed when adding the numpad modifier somehow.

Quote
BTW you need to fix things like U_RN layout because KLA can't handle pressing 2 keys with one thumb. :-)

lol plebe. these are advanced layouts for advanced beings.

Quote
We should also probably make this local:  http://patorjk.com/images/qwerty.png

done

Quote
Your P_RN seems to be missing &

fixed
Title: Re: Balanced Keyboard Layout
Post by: Den on 2017-Sep-14 05:43
You lost me... :-)
Oh, okay I guess you made a file for the dummy text that will load initially. :-)

wanted a longer sample to quickly test things reasonably. found a hack to basically use multi-line strings in javascript with no fuss. (no need to escape stuff, no concatenation, etc.)

Quote
Any reason you're not using Github?

too political
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2017-Sep-14 06:22
lol plebe. these are advanced layouts for advanced beings.

KLA exits the loop when it hits such a condition, leading to incorrect scoring for the layout.
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2017-Sep-14 06:55
Test version at http://shenafu.com/code/keyboard/klatest/

Tried to import layout, showed up on screen but Analyzer barfed.
Title: Re: Balanced Keyboard Layout
Post by: Den on 2017-Sep-14 08:11
finally fixed the discrepancy for same finger. find the proper way to access the array.

test uses straight scores now; no normalization.
Title: Re: Balanced Keyboard Layout
Post by: Den on 2017-Sep-14 08:13
Tried to import layout, showed up on screen but Analyzer barfed.

check if missing alt-gr
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2017-Sep-14 09:10
check if missing alt-gr

Yes it was. I modified Colemak Ergodox I think, looks like some of those layouts have the unicode code on them to print the alt symbol. That should be in key.js.
Don't think there is a unicode symbol for altgr though.
Layout is Pro XKB, found on GeekHack, adapted to fit on Ergodox. Does better on Den1 than DenLatest.
Title: Re: Balanced Keyboard Layout
Post by: Den on 2017-Sep-14 18:34
finally fixed the discrepancy for same finger. find the proper way to access the array.

test uses straight scores now; no normalization.

without normalization, scores soar too high on longer text. hard to compare when scores vary so much between different corpus. the key is to normalize against the size of corpus, which is a constant for all layouts.

edit: test uses again normalization that is proportional to text length. now all scores look more reasonable and matches the relative scores as shown in the in-depth charts.

Title: Re: Balanced Keyboard Layout
Post by: Den on 2017-Sep-15 04:49
-- preset dir renamed corpus
-- Den3 page moved to http://shenafu.com/code/keyboard/kla3/ , which is same as klatest up to now.
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2017-Sep-15 04:55
-- preset dir renamed corpus
-- Den3 page moved to http://shenafu.com/code/keyboard/kla3/ , which is same as klatest up to now.

Suggestion: change the HTML Title to include the scoring version (Den1/2/3 or somesuch)
Title: Re: Keyboard Layout Analyzer
Post by: Den on 2017-Sep-16 00:04
take advantage of angular by pre-populating lists for easier management, organization, and amendment. thereby removing the mess from template.js. lists will be edited in db.js.

right now text presets and layout lists are done. try at http://shenafu.com/code/keyboard/klatest/ , and check out the drop-down for text presets and layout presets.

Code: [Select]
snippet from template.js

    "        <div class='control-group'>\n" +
    "            <label class='control-label' for='text-presets'>Text Presets:</label>\n" +
    "            <div class='controls'>\n" +
    "                <select id='text-presets' ng-model='data.textPreset' ng-change='applyPreset()' ng-controller='CorporaController' ng-options='corpus.file as corpus.title group by corpus.type for corpus in corpora'>\n" +
    "                    <option value='' selected>[Select Text to Load]</option>\n" +
    "                </select>\n" +
    "                <button class='btn' type='button' ng-click='applyPreset()'>Apply</button>\n" +
    "            </div>\n" +
    "        </div>\n" +

Code: [Select]
snippet from controller.js

appControllers.controller('CorpusCtrl', ['$scope',
function ($scope) {
$scope.corpora = DB.corpora;
}
]);

appControllers.controller('LayoutCtrl', ['$scope',
function ($scope) {
$scope.layouts = DB.layouts;
}
]);

Code: [Select]
snippet from db.js

var DB = DB || {};

/////////////////////////////////////////////////////

DB.layouts = [

{file: "abcdef.standard.json", title: "ABCDEF", type: "US-International Keyboards"},
{file: "roughabcdef.standard.json", title: "ABCDEF (rough)", type: "US-International Keyboards"},
{file: "acemak1.standard.json", title: "Acemak 1", type: "US-International Keyboards"},
{file: "alice-7499-WIP.standard.json", title: "Alice 74.99 WIP", type: "US-International Keyboards"},
{file: "anglian.standard.json", title: "Anglian", type: "US-International Keyboards"},
....
];
// end DB.layouts

/////////////////////////////////////////////////////

DB.corpora = [

{file: "intro", title: "KLA Introduction", type: "Quick Tests"},
{file: "typing-champ-1", title: "Typing Championship 1", type: "Quick Tests"},
{file: "typing-champ-2", title: "Typing Championship 2", type: "Quick Tests"},
{file: "pi1000", title: "Pi 1000", type: "Quick Tests"},
...
];
// end DB.corpora

/////////////////////////////////////////////////////

Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2017-Sep-16 01:35
take advantage of angular by pre-populating lists for easier management, organization, and amendment. thereby removing the mess from template.js. lists will be edited in controller.js.

Mmmm :-)
On the one hand, cool and well done.

On the other hand.... we're drifting apart in terms of presets and layouts... (and FWIW I find NG even more frustrating that Jquery :-) )

1. presets: I've decided to categorise them differently:
   "Real world" tests (ie stuff a person may actually type), which includes the prose and programs. And would include those Academics.
   "Optimising" tests, which includes the word lists, punctuation tests, and assorted number tests.
   I've also added a bunch more presets (stuff I thought was interesting), and fixed the old ones to have only (I think, 99.9% or so..) ANSI chars.

2. layouts: our naming conventions are slightly different (I'm still with standard.blah etc) as well as still using three variants for ergolinear/matrix.
 Also got a whack of new layouts, some that were in the last round of tests (done Patrick and Den1, must still do Den3/DenLatest), plus 20 (and counting) for the next round.

So we must find middle ground/synchronise at some point :-)

Cheers, Ian
Title: Home row explorer
Post by: iandoug on 2017-Sep-16 18:30
I made a basic home row explorer.

http://www.keyboard-design.com/homerow-explorer.html

Needs to be prettied up a bit I think, but basics are there. Semantic UI is annoying me, I struggle to do simple things like putting a table in the centre ...
Want to switch to UI Kit but that requires careful redesign and lots of redoing of all existing pages... :-(

I mainly wanted this to have a way to quickly find layouts with matching home rows for "new" layouts, so that I can see if they're actually new or if I already have them.

Comments welcome :-)
Layouts were what is in my local Den1 folder. The Euro layouts don't play nice. Just doing very basic char<->ascii conversions, not all work nicely. Keys are stored as their lowercase ascii value/whatever was set as "primary" in the KLA json.

Cheers, Ian
Title: Re: Keyboard Layout Analyzer
Post by: Den on 2017-Sep-17 03:55
changed the layout of the text input area. arranged vertically so you can see more of the text and preset selections.

more preset categories.

filenames are trivial to change in batch with a simple regexp.
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2017-Sep-17 17:19
changed the layout of the text input area. arranged vertically so you can see more of the text and preset selections.

Looks cool. Works on dentest, didn't work on den3 this morning.

Have fixed most of the bugs on my homerow browser, the Euro layout characters display properly now. Also reverted to showing the "natural" (ie unshifted) character on the key.
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2017-Sep-18 17:03
Have fixed most of the bugs on my homerow browser, the Euro layout characters display properly now. Also reverted to showing the "natural" (ie unshifted) character on the key.

There's still at least one bug in the process... for example the standard Dvorak home row got picked up incorrectly by the program that checks the layouts and spits out the home rows.

Been busy most of the day with that program (ISP killed my connection...), making it look for duplicate characters on the keyboard as well as missing characters (and getting the home row).
In the process have found a bunch of broken-to-some-extent layouts that were in KLA. So am moving them out of my test panel. Have fixed a few that were trivial and unlikely to upset the original authors too much, but some like QWPR have lots of duplicates, and KLA does not know which key to use, and we don't know what KLA did, so comparing against it may be unfair.

So all this means I need to rerun all my tests again from scratch... :-((

Also have a basic "how many words can you type on home keys" program working... apparently that's a "useful" metric for evaluating layouts.... (haven't decided if I agree or not ... there should be some measure of "ease" given that it only looks at the letters, not if they are on pinky or index....)
http://proword-keyboardlayoutefficiency.blogspot.co.za/
though I'm doing it programmatically, not editing word lists in a text editor... :-)
I need to modify the basics to handle my special layouts where things are on AltGr etc ... at the moment it just takes the "regular" character on the key.
And that eNNe Dutch/English layout I developed with that guy on Geekhack (name escapes me now) comes out better than Maltron...


Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2017-Sep-18 18:13
There's still at least one bug in the process... for example the standard Dvorak home row got picked up incorrectly by the program that checks the layouts and spits out the home rows.

Fixed. Because Dvorak existed as preload not as file on disk. And there was another residue from Patrick that was not Dvorak but labelled as such....
Title: Re: Balanced Keyboard Layout
Post by: Den on 2017-Sep-18 18:26
counting individual words, and not corpus of prose? because rare words typed on home row don't really matter much. moreover, frequent pinky-ring combos can be just as adverse as off-home-row.

we already have lists of difficult words for analysis.

KLA measures row usage, but doesn't count it for the final score. although i have not verified the accuracy of those stats. since you can customize home row, i haven't looked at the code to see how it counts other rows.
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2017-Sep-19 01:56
counting individual words, and not corpus of prose? because rare words typed on home row don't really matter much. moreover, frequent pinky-ring combos can be just as adverse as off-home-row.

we already have lists of difficult words for analysis.

Yeah, which is why I am not convinced that it is a viable metric. Maltron used it because they got such a high score with that metric. But given that they count things like
AA AAH AAHED AAHS AAS AD
as "words" (valid for Scrabble, believe it or not) then I really don't know....
Current list of Scrabble words starts:
aa
aah
aahed
aahing
aahs
aal
aalii
aaliis
aals

I must make a zip file with my new tests ... has some more interesting word lists... :-)
Title: Re: Balanced Keyboard Layout
Post by: iandoug on 2017-Sep-19 06:25
homerow wordcounts...

Maybe Maltron used different rules to me.
http://proword-keyboardlayoutefficiency.blogspot.co.za/2011/02/most-efficient-keyboard-layout.html says
QWERTY - 198 words can be typed without taking the fingers from the home keys.
DVORAK - 3126 words can be typed without taking the fingers from the home keys.
COLEMAK - 5963 words can be typed without taking the fingers from the home keys.
MALTRON - 7639 words can be typed without taking the fingers from the home keys.

But I'm getting:
QWERTY    asdfjkl;   107
Simplified Dvorak    aoeuhtns   1301
Maltron US 90 on ErgoDox    anisethor   5245

So maybe they used entire home row rather than just keys under fingers. Or my program has bugs. Have asked author of post, but last seen on GH on 2015 so not expecting reply.

FWIW, top scores at moment are

eNNe 96.40PM    oieatsndr   6522
Y RINA QUO    rinaehtsc   5678
BEAKRAK mod Ian    dieatnrsh   5282
X2 Ergolinear    daeihntsr   5282
-+T+- HT02a    iaeotshnr   5245
Cole-e ErgoDox    arstenhio   5245
Cole-e-shift ErgoDox    arstenhio   5245
Maltron US 90 on ErgoDox    anisethor   5245
Maltron US 90 ErgoDox, mod Andreas    raoteshni   5245
Pro XKB    oaisetrnh   5245
Maltron Ergolinear    anisethor   5245
RSTHD Ergolinear 2