Balanced Keyboard Layout

[Den]

Goals and Philosophy for Keyboard Layout Design:

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

• Minimize total finger effort and distance while balancing the usage of both hands and each finger
• Maximize 8 home row keys while realizing top row is not necessarily better than bottom row
• Following this effort chart, place the letters taking into account least effort, rolls, and letter frequency

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

• Minimize penalties while realizing that not all penalties are applicable or equal in practice. Many algorithms penalize row jumping, but in practice some jumps are actually easier than adjacent row rolling. For instance, on Qwerty keyboard, typing EV is easier than SZ.
• Take common punctuations into account based on modern computer usage. For instance, double quotes " are unshifted and replace the semicolon, which now requires a shift. Comma and period at the top close to the numbers to facilitate typing e.g. monetary values and IP addresses.
• Efficiency maximized for English, yet intuitive for other languages. Mainly, the vowels are placed in very prominent locations. Just about every language has heavy usage for AEIO (U and Y are not always popular in some languages). However, not every language has the same frequency for consonants. Some languages don't use T and H, for instance. In short, by putting the vowels in dominant keys, there is less waste when typing mixed languages.
• Maximize comfort and speed for the most common English short words, digraphs, trigraphs, and even quadragraphs and pentagraphs.

Newer thoughts

• Pinkies should have much higher effort costs
• Optimize pinkies for inward rolls and avoid outward rolls double letters
• Pinky candidates: wyhkpb
• Consider untraditional typing techniques, such as using ring finger instead of pinky to type corner keys
• Count number of words (in a corpus or dictionary) that can be typed by: home row (5), home block (9), and "good" keys (home row + home block - bottom ring) (10)
• Bottom row ring and index fingers are extremely fast. Sometimes 2x or more faster than the home pinky.
• Minimize pinky and inside index columns workload. Each column no more than 5%. Each pair of mirrored columns no more than 10%.
• Slide finger along two adjacent keys on the same column and even same row (e.g. "gh" and "nv" on Dvorak). This would reduce same finger penalties, but is tricky to perform.

Learn about my highly recommended layouts based on new effort theory

Spoiler  obsolete stuff:

Read my older stuff

1st layout Comparison Results and Analysis
2nd layout Comparison Results and Analysis
3rd layout Comparison Results and Analysis

Old effort chart similar to Workman:

[Den]

After several dozen iterative attempts and tweaking, my initial layout--which I proclaim the Balanced layout--is shown below.



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

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


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


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


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


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


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


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


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


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


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


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


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.

[Den]

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 to turn Dvorak into Balanced. Pause or exit the script at will.

[Den]

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 & AutoHotkey stand-alone executable

AutoHotkey script to convert Dvorak to Balanced & AutoHotkey stand-alone executable


Try it out and compare it to other popular layouts at this Keyboard Comparison Tool

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


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

Effort for each finger


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


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


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

Metrics


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


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

Effort for each finger


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

Keys for each finger


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


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

Metrics


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.

[Den]

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

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



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



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



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



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



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.

[Den]

NEW LAYOUTS BASED ON NEW EFFORT THEORY


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

• Balance the workload between each hand and between the fingers and keys based on the fingers' strength and agility and the keys' potential for rolls and speed.
• Effortless means good rhythm in alternations and rolls, and getting a superior score in every keyboard metric, such as low distance, low penalties from same finger and same hands, etc. Possibly higher speed ceiling with less effort
• Advanced in the sense that it challenges traditional theories of typing.
  
  • It does not advocate the so-called home row in touch typing. It vehemently avoids favoring the home pinky and the inside index key. The home pinky is extremely slow, weak, and uncomfortable to type. Instead, it strongly recommends the home block that consists of the ring, index, and middle keys on the top, home, and bottom rows. These 9 keys form the core where the common letters (and sometimes punctuations) should be placed.
  • Related to the above, the pinky and inside index columns workload must be minimized. Each of these columns should have no more than 5% of the total key presses. Together, the two pinkies should not do more than 10% of the work; the two inside index columns together should not have more than 10% of the work. The latter is because the index home column already does a lot of work, so the inside column usage should be minimized.
  • The bottom ring and index keys are extremely fast and should not be avoided as other keyboard designers suggest. These can be sometimes up to 2x or faster than pressing the home pinky key.
  • Up and down finger movement is much faster, allows smoother rolls, and causes less strain than side-to-side movement (caused by pinky and inside index keys, and also by unnatural staggered keyboard design.)
  • Recommend additional layers that are accessed by modifiers like shift, alt-gr, and numlock, so that fingers stay in the home block, rather than reaching all over the keyboard for numbers and symbols. This reduces time looking for symbols, speeds up writing code and math equations, provides an efficient numpad, and eliminates the need for tenkey numpad on the far right side of a full standard keyboard (thereby shrinking the size of the keyboard and allows mouse to be comfortably closer to the body).

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

Spoiler  BEAKL 4:

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%

Spoiler  BEAKL 7:

Balanced Effortless Advanced Keyboard Layout (BEAKL) 7

(Creative Commons Attribution 4.0 License courtesy of http://patorjk.com/keyboard-layout-analyzer/#/about)

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.


(Creative Commons Attribution 4.0 License courtesy of http://patorjk.com/keyboard-layout-analyzer/#/about)

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:

• Effort scores for each key has been modified from AdNW's default to match my effort grid posted in original post, except multiplied by 10.
• Heavily favor inward rolls compared to outward rolls.
• Pinky target usage 5%, other fingers 15%.
• Shift keys moved to thumb row (instead of outside pinkies.)
• Opt defaults to 32 keys by adding 2 keys to the right side. So I changed German letters into 2 more punctuation: -_ and /?.
• Per above, sometimes letters may end up outside the 5x6 block, while punctuation end up inside.

Comparison to other layouts

• Beats everything else in AdNW optimizer with my customizations by far. BEAKL 7 is closest, then MTGAP. Everything else is far behind.
• Can compete head-to-head with MTGAP on other comparison tests using their own metric and effort values. BEAKL 7 lags behind somewhat.
• I was on the right track with BEAKL 7, but Opted is much better.

[iandoug]

hi

[/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

[Den]

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.

[iandoug]

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

[Den]

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 (at the top of forums list).

[Den]

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, 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:



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.

[iandoug]

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 :-)

[iandoug]

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

Thanks, Ian

[Den]

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

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.

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.

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


[iandoug]

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.)

[Den]

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. He compared one of my very early layout, Amuseum's Layout, 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.)

[iandoug]

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:


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:


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... :-)

[iandoug]

I haven't the patience to play with Michael Dickens' analyzer. (Maybe one day...) I did find something interesting while reading his old site. He compared one of my very early layout, Amuseum's Layout, 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 :-)

[Den]

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.

[iandoug]

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.

[Den]

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.

[iandoug]

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...

[iandoug]

Oh yeah. the 75.54 layout has a very low 'effort' ... much lower than MTGap which was optimised for low effort.
Scores from Alice:

[iandoug]

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.

[iandoug]

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.

[Den]

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, "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.

[iandoug]

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, "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

[iandoug]

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

[Den]

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.

[iandoug]

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

[iandoug]

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.



I hope posting this publicly does not come back to bite me.

[Den]

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.

[iandoug]

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

[Den]

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.

[iandoug]

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

[Den]

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.

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.

[iandoug]

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

[iandoug]

Perhaps you can define Ǝ as the definitive symbol for Enter.... :-)

[iandoug]

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?

[iandoug]

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 ...

[iandoug]

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.

[iandoug]

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 ;-)

[Den]

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.

[Den]

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.

[Den]

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.

[Den]

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


[Den]

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

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

Code: [Select]

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



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.

[iandoug]

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.

[Den]

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


[iandoug]

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