Show Posts

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

Messages - Den

Pages: [1] 2 3 4 ... 15
Added Hex Hung (highly recommended for twyping = typing + swiping)

All layouts in this post are for 2-thumb typing. For tablets, try split landscape.

Added Righty (highly recommended)
Favors right hand and top two rows.

Added Imagettem
Has space cluster on each side.

Added Easthorn
Favors right hand and top two rows

Hacks / Re: Balanced Keyboard Layout
« on: August 23, 2016, 02:59:16 PM »
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.

Hacks / Re: Balanced Keyboard Layout
« on: August 21, 2016, 03:44:35 PM »
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.

Hacks / Re: Balanced Keyboard Layout
« on: August 18, 2016, 06:21:12 PM »
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]




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

Hacks / Re: Balanced Keyboard Layout
« on: August 17, 2016, 05:09:57 PM »
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.

Arts, Literature, and Crafts / Re: [lang] Li-Ya-Hu
« on: August 13, 2016, 11:20:52 PM »
Simplify sounds for numbers, by digits, pairs, and trips -- in Liyahu's base 3/9/27

* Base 3 - base vowels IAU (no consonants)
* Base 9 - base vowels & vowel diphthongs from IAU (no consonants)
* Base 27 - consonants & vowel diphthongs

* Base 3--
- 0 u, 1 i, 2 a
* Base 9--
- 00 u, 01 ui, 02 ua, 10 iu, 11 i, 12 ia, 20 au, 21 ai, 22 a
* Base 27--
- 0.. h.., 1.. l.., 2.. y..
- ex. 102 lua, 222 ya, 020 hau
- ex. 120,102,002 lau-lua-hua; 212,110,021,220 yia-liu-hai-yau

One and two vi digits = base 36 (=27 double-vi + 9 single-vi). Used to divide cycles, circles, and tell time.
36 seconds per minute, 36 minutes per hour, 36 hours per day, 36 days per month.
10 months per year = 1 big month & 9 small months = 30 months per triade = 27+3 = 40 months between peak years = 27+9+3+1
Big month = extra 5 days. On peak year extra 6 days.

* Duodecimal Nomenclature, , p. 4

I actually tried Vertigo type layout on computer keyboard the other day ... thought it was a new idea. Scores on Patrick were not so good, it does not make sense to put little-used numbers on home row or prime index-finger spots. I guess mobile devices will be a different experience.

Am installing the software to test ... currently use paid-for SwiftKey.

Cheers, Ian

Mobile and stylus typing involves more of the wrist and thumbs, so up and down motion is more efficient. Thus arranging in columns rather than rows is more ergonomic. Actually, circular is most efficient, but there is a limit to column height before it blocks out the screen. So layouts still tend to spread more sideways than I'd like. But it still works great since you really only need to optimize the first ten or twelve keys. The rest can fall in place based on digrams, which I feel is more important than on desktop keyboard. Adjacentness helps the continuation of typing, and improves ergonomics and speed.

For 2-thumb layouts, I might need to put the core letters higher andd to the center where the thumbs naturally rest. However this will obstruct the view of the bottom letters.

Hacks / Re: Balanced Keyboard Layout
« on: August 12, 2016, 06:40:48 PM »
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.

Hacks / Re: Balanced Keyboard Layout
« on: August 12, 2016, 11:15:18 AM »
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

Hacks / Re: Balanced Keyboard Layout
« on: August 12, 2016, 11:01:29 AM »
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, 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.

Hacks / Re: Balanced Keyboard Layout
« on: August 12, 2016, 01:15:27 AM »
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.

Hacks / Re: Balanced Keyboard Layout
« on: August 11, 2016, 10:57:04 PM »
If you look at the numbers here:

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

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

How do you create and distribute xkb files?

Hacks / Re: Balanced Keyboard Layout
« on: August 11, 2016, 08:47:28 AM »
Silly me. I think I got your ' and " the wrong way around.

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

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

Hacks / Re: Balanced Keyboard Layout
« on: August 10, 2016, 10:40:56 PM »
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]
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.

Added BEAKL (2-hand typing on tablet landscape)

Set AnySoftKeyboard keys to height of 0.8. Home row is middle row. Use thumbs to hit shift and backspace.

Added 3rd party layouts (for comparison): Fitaly and Opti

Hacks / Re: Balanced Keyboard Layout
« on: August 07, 2016, 04:46:06 PM »
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. given a big enough tablet to fit ten fingers, might be easier to test logical layouts with automatic visuals.

Hacks / Re: Balanced Keyboard Layout
« on: August 07, 2016, 04:40:47 PM »
(@#&(@#&$( 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.

Hacks / Re: Balanced Keyboard Layout
« on: August 07, 2016, 04:34:01 PM »
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.)

Hacks / Re: Balanced Keyboard Layout
« on: August 05, 2016, 02:39:20 PM »
The deskthority wiki is not affiliated with wikipedia. Here is the link to my BEAKL entry:

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.

Hacks / Re: Balanced Keyboard Layout
« on: August 05, 2016, 01:52:27 PM »
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.

Hacks / Re: Balanced Keyboard Layout
« on: August 05, 2016, 01:32:59 PM »
Was it your vote here, or do you have a fan? :-)

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

Hacks / Re: Balanced Keyboard Layout
« on: August 04, 2016, 10:17:45 PM »
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.

Hacks / Re: One-handed Keyboard Layout
« on: July 21, 2016, 08:47:13 PM »
1st try

Right Hand Typing

Code: [Select]
1061.422 total effort 199.759 positional effort left right
,gy.jz 11.856 same finger rp 5.290 shift same finger top 0.0 20.5
psrimx 0.000 hand alternat. 0.000 shift hand alter. mid 0.0 30.1
ctealk 1.264 inward/outward 85.651 inward or outward bot 0.0 18.5
fdnohv 44.765 adjacent 7.152 shift adjacent sum 0.0 100.0
bwuq 95.767 no hand altern. 0.000 two hand altern.
0.084 seesaw 0.000 indir same finger
--.- --.- --.- --.- --.- 18.7 26.3 22.2 21.3 11.5 Sh 0.0 4.8

Hacks / One-handed Keyboard Layout
« on: July 21, 2016, 11:59:45 AM »
One-handed keyboard layout

For standard or split keyboards.
Left or right hand.
Shift with thumb or locked for one key.
Layers--one or two.
Numbers or no.

Hacks / Re: Balanced Keyboard Layout
« on: July 19, 2016, 05:32:37 PM »
The one I saw on Massdrop was around 300 $ I think
you need to register before they let you see.

Apparently the place to buy is here
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.

Hacks / Re: Balanced Keyboard Layout
« on: July 17, 2016, 05:50:55 PM »
I might order the Ergodox (if it's still available) in order to customize and test the keyboard with new layouts.

Hacks / Re: Balanced Keyboard Layout
« on: July 16, 2016, 01:07:12 PM »
One layout to rule them all....

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.

Hacks / Re: Balanced Keyboard Layout
« on: July 16, 2016, 11:25:45 AM »
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.

Hacks / Re: Balanced Keyboard Layout
« on: July 16, 2016, 01:04:57 AM »
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

Hacks / Re: Balanced Keyboard Layout
« on: July 15, 2016, 07:45:07 PM »
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:

Code: [Select]
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.

Hacks / Re: Balanced Keyboard Layout
« on: July 15, 2016, 07:19:30 PM »
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

Hacks / Re: Corpus
« on: July 15, 2016, 06:51:57 PM »
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.

Hacks / Re: Balanced Keyboard Layout
« on: July 15, 2016, 06:41:39 PM »
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.

Hacks / Re: Balanced Keyboard Layout
« on: July 15, 2016, 06:34:56 PM »
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
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.

Hacks / Re: Balanced Keyboard Layout
« on: July 15, 2016, 05:15:16 AM »
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   :-)

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.

Hacks / Re: Balanced Keyboard Layout
« on: July 15, 2016, 04:24:37 AM »
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.

Hacks / Re: Balanced Keyboard Layout
« on: July 15, 2016, 04:01:08 AM »
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.

Hacks / Re: Balanced Keyboard Layout
« on: July 14, 2016, 11:04:05 PM »
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.

Hacks / Re: Balanced Keyboard Layout
« on: July 14, 2016, 05:00:36 PM »
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.

Hacks / Re: Balanced Keyboard Layout
« on: July 14, 2016, 01:13:49 PM »
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]

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.

Hacks / Re: Balanced Keyboard Layout
« on: July 13, 2016, 01:50:45 PM »
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.

Hacks / Re: Balanced Keyboard Layout
« on: July 13, 2016, 12:49:49 AM »
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.)

Hacks / Re: Balanced Keyboard Layout
« on: July 10, 2016, 12:29:09 PM »

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:
BEAKL Opted 2:

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]
znlcf 'uohq ZNLCF ;UOHQ
prtsd .aeik PRTSD :AEIK
vbmgw x,"yj VBMGW X()YJ

Hacks / Re: Balanced Keyboard Layout
« on: July 08, 2016, 12:57:40 PM »
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]
znmcg top 11.8
prtsd mid 22.2
vlwfb bot 8.4
sum 42.4
2.5 13.8 10.6 15.5
Code: [Select]
znlcf top 13.2
prtsd mid 22.2
vbmgw bot 7.0
sum 42.4
2.5 11.8 12.4 15.8

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]
'oiuj top 14.2
,aehk mid 21.8
q."yx bot 3.2
sum 39.2
14.7 15.7 7.5 1.2

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

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.

Hacks / Re: Balanced Keyboard Layout
« on: July 06, 2016, 06:52:11 PM »

And please ask your admins to implement
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).

Hacks / Re: Balanced Keyboard Layout
« on: July 05, 2016, 08:16:25 PM »
Just wondering how you arrived at these weightings, they differ a bit from those used in developing the Workman layout.

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.

Magic: the Gathering / Re: [YMTC] GameFAQs CCCs
« on: June 01, 2016, 11:19:12 PM »
RCCC #903: Make a Horse, Unicorn, Pegasus or Nightmare creature or Tribal

Triple Penetration

Tribal Sorcery -- Pegasus
Put three 1/1 white Pegasus creature tokens with flying, horsemanship, and shadow onto the battlefield.

Magic: the Gathering / Re: Planeswalkers and their signature cards
« on: May 28, 2016, 07:38:11 AM »
Good guys have Oaths. Bad guys have Curses.

Curse of Sotsnger

Enchantment -- Curse
Activated abilities of planeswalkers you don't control cost an additional "discard a card".
Whenever an opponent discards a card, you may gain 1 life and summon a 1/1 black Snake creature token with deathtouch.

Curse of Gorkhhesh

Enchantment -- Curse
When a planeswalker enters the battlefield under an opponent's control, ~ deals 2 damage to that player.
Whenever an opponent loses life or a permanent dies, you gain 2 life.

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