• You are not logged in.
  • Index
  • General
  • Keyboard Optimizer Genetic Algorithm

Keyboard Optimizer Genetic Algorithm

  • Started by SpeedMorph
  • 97 Replies:
  • Reputation: 0
  • Registered: 08-Mar-2008
  • Posts: 303

After looking at a few other websites about keyboards, I decided that making a genetic algorithm would be fun. I made it in Ruby, because that is the only language I know. Here are my scoring criteria:

Each position on the keyboard costs a certain amount:

14 10 10 11 22 22 11 10 10 14
3     1  0  0  10 10  0   0  1  3
19 18 17 16 24 13 11 15 15 19

This is based off what I've heard from others and my own experience. For instance, I find it harder to type the bottom row on my left hand due to the angle, thus it costs more.

In addition:
-using the same finger twice costs 50 points
-typing on the same hand (when not moving inward along the same line, i.e. qwer or ;lkj on QWERTY) more than twice costs 8*time of offense, which means the third time you type with one hand it costs 8, the 4th time it costs 16, the 5th time it costs 24, etc.
-Skipping from the bottom row to the top or vice versa costs 8 points.
-Moving outward and changing lines (i.e. dr or lp) costs 25 points.

Did I miss anything, or should I change anything?

Offline
  • 0
  • Shai
  • Administrator
  • Reputation: 36
  • Registered: 11-Dec-2005
  • Posts: 423

Probably the biggest thing you've missed are some of the existing projects, specifically
carpalx, Capewell's Keyboard Evolve, and Klauser's evolved layout.

Moreover, Ruby is a really bad choice for a language for such project because it's one of the slowest languages and a keyboard layout genetic algorithm needs to iterate through an astronomic amount of possible keyboard layouts for best results. Such a project should be written with a faster such language, such as C, C++, Java or D.

Offline
  • 0
  • Reputation: 0
  • Registered: 08-Mar-2008
  • Posts: 303

Well I did look at Klausler and Capewell's sites. And yes, I am aware that Ruby is very slow. I noticed that when Capewell said he could look at 1900 layouts per second, and I can only do 1 every 2 seconds (and I have reduced my word documents to 20 pages, at the expense of loss of accuracy). I might use a different language at some point, but that would require learning it. =D

Thanks for the links! You seem to know the location of every website in existence.

Last edited by SpeedMorph (14-Apr-2008 14:34:23)
Offline
  • 0
  • Reputation: 210
  • From: Viken, Norway
  • Registered: 13-Dec-2006
  • Posts: 5,343

I don't see why you penalize same-finger typing so hard. Some cases would warrant it, others not I think. For instance, the index fingers will easily type for instance "ln" in my experience. Try typing kiln kiln kiln kiln kiln with Colemak (or think up another similar case in dvorak if that's your poison) - it isn't so bad as you seem to imply. "Illness" of course, is awful.  :)

I can't say for sure, but all the aforementioned attempts at optimization algorithms (including yours) strike me as subject to somewhat arbitrary (or at the very least, highly subjective) rule sets, and the result is probably quite dependent on those. Your evolved layout can only be as good as the correlation between your axioms and actual typing efficiency. It will be a fun and interesting exercise for sure, but will it actually reflect layout quality for most users - or even for yourself?

*** Learn Colemak in 2–5 steps with Tarmak! ***
*** Check out my Big Bag of Keyboard Tricks for Win/Linux/TMK... ***

Offline
  • 0
  • Reputation: 0
  • Registered: 08-Mar-2008
  • Posts: 303
DreymaR said:

I don't see why you penalize same-finger typing so hard. Some cases would warrant it, others not I think. For instance, the index fingers will easily type for instance "ln" in my experience. Try typing kiln kiln kiln kiln kiln with Colemak (or think up another similar case in dvorak if that's your poison) - it isn't so bad as you seem to imply. "Illness" of course, is awful.  :)

I can't say for sure, but all the aforementioned attempts at optimization algorithms (including yours) strike me as subject to somewhat arbitrary (or at the very least, highly subjective) rule sets, and the result is probably quite dependent on those. Your evolved layout can only be as good as the correlation between your axioms and actual typing efficiency. It will be a fun and interesting exercise for sure, but will it actually reflect layout quality for most users - or even for yourself?

Well yes, that is a very good point. As to the first thing you said, I will take that into account. As to the second thing, I am mostly doing this because it is fun, not really because I want a better keyboard layout. There are plenty of good layouts out there. If I come up with a result that looks good, I might actually use it.

By the way, here is the best layout it has come up with so far, scoring a 6.2 (Dvorak scores 5.8, and lower is better)

l d mb ;  k p u o w
r h t n g  c  i e a s
v z f j  x  . y '  , q

Which looks pretty good, except that o is not on the home row. The genetic algorithm makes some stupid mistakes like that.

Offline
  • 0
  • Reputation: 210
  • From: Viken, Norway
  • Registered: 13-Dec-2006
  • Posts: 5,343

You're already making assumptions, so why not make a few more while you're at it, and help your poor Ruby cope a little better in the process?

If for instance you force the 6-8 (or maybe 10?) most common keys to the home row your algorithm will have a much easier time of it already. Furthermore, if you force the 10 or so least common characters that are already in hard-to-reach QWERTY positions to stay put you'll gain some of the advantages of Colemak and likely not sacrifice anything noticeable (I'd let QWZXC,.'- stay in place, and probably M as well). If you don't give a rat's ass about QWERTY since you're Dvorak trained and don't need to use QWERTY at all, then by all means do the same thing with rare keys in awkward Dvorak places - after all, you're doing this only for yourself and not for the public.

By the way, I think your same-hand penalty looks elegant. Subjective of course, but interesting. Your top/bottom penalty also seems like a good idea to me.

*** Learn Colemak in 2–5 steps with Tarmak! ***
*** Check out my Big Bag of Keyboard Tricks for Win/Linux/TMK... ***

Offline
  • 0
  • Reputation: 23
  • From: Belgium
  • Registered: 26-Feb-2008
  • Posts: 480
SpeedMorph said:

By the way, here is the best layout it has come up with so far, scoring a 6.2 (Dvorak scores 5.8, and lower is better)

And how about Colemak and Qwerty? :-)

Last edited by ghen (15-Apr-2008 09:14:58)
Offline
  • 0
  • Reputation: 0
  • Registered: 08-Mar-2008
  • Posts: 303
ghen said:
SpeedMorph said:

By the way, here is the best layout it has come up with so far, scoring a 6.2 (Dvorak scores 5.8, and lower is better)

And how about Colemak and Qwerty? :-)

I have not tested QWERTY, and don't plan to, because I already know it sucks. Since scoring Dvorak, I have changed the scoring methods by increasing all the numbers by a lot so as to make the scoring more accurate. Colemak scores 6.548, and Dvorak with U and I switched scores 6.607. Also Capewell layout scores 7.054 and Arensito scores 7.421. But I believe my scoring system must be skewed, because my algorithm is coming up with layouts that score under 6, and they are clearly not that much better (if better at all, which is unlikely) than Dvorak or Colemak. Also I find it a bit surprising that Arensito and Capewell do worse than Dvorak.

One interesting thing I noticed is that almost every layout it generates has 3 or 4 of the vowels on one side of the home row.

Best layout so far, scoring 5.79 (not necessarily the best, but lowest score)

v l d b j z  f o m u
r h s n c y a e t i
q k x p ' g . ; w ,

The algorithm has a tendency to knock O off the home row.

(By the way, I took DreymaR's advice into account and lowered penalty for same finger to 30.)

And about restricting common keys to the home row, I am working on that. Which means I will probably start working on it within the next month or so.

Last edited by SpeedMorph (16-Apr-2008 01:27:08)
Offline
  • 0
  • Reputation: 1
  • Registered: 19-Jun-2007
  • Posts: 17

I've seen several of these 'tests' or benchmarks, and I've found that besides Klausler and DDvorak (and my own) layouts, no other 'well-known' layouts (including Colemak, Arensito, Capewell) perform that much better than Dvorak. Well, Colemak is consistently slightly more efficient. Arensito and Capewell are generally slightly worse (in most cases). But Klausler and DDvorak beat Dvorak by wide margins in most criteria. Especially regarding code, DDvorak takes a huge lead (though mine is a close second.)

You should test qwerty because it acts as control in a sense that we know it sucks. But if your program gives it a better score than other layouts, then we know your program is not working.

Nevertheless, I'd like to get my hands on your program so that I may do my own tests. (Actually I'd like to use it to test my own layouts since I'm assuming you're not interested in testing something this obscure.)

Offline
  • 0
  • Reputation: 0
  • Registered: 08-Mar-2008
  • Posts: 303
Amuseum said:

I've seen several of these 'tests' or benchmarks, and I've found that besides Klausler and DDvorak (and my own) layouts, no other 'well-known' layouts (including Colemak, Arensito, Capewell) perform that much better than Dvorak. Well, Colemak is consistently slightly more efficient. Arensito and Capewell are generally slightly worse (in most cases). But Klausler and DDvorak beat Dvorak by wide margins in most criteria. Especially regarding code, DDvorak takes a huge lead (though mine is a close second.)

You should test qwerty because it acts as control in a sense that we know it sucks. But if your program gives it a better score than other layouts, then we know your program is not working.

Nevertheless, I'd like to get my hands on your program so that I may do my own tests. (Actually I'd like to use it to test my own layouts since I'm assuming you're not interested in testing something this obscure.)

I will probably at some point post my programs on my blog, which is at mtgap.bilfo.com/blog

What is your layout? EDIT: never mind, I found it here: http://www.sagez.net/amuseum/layout.php
P.S. I love your BFUCK layout, that's exactly what I was thinking when I saw Arensito!

I have made some changes to my scoring program, and due to these changes, I will be tweaking the program for a while. On Capewell's genetic algorithm, he had a penalty for skipping over the home row, but the penalty was reduced if certain combinations were used, because they were easier to type. I didn't want to do anything like that because it would require something like this:

if skips over home row:
  add 30 to score
  if 1st location = w and 2nd location = v OR 1st location = o and 2nd location = n OR.....

And it does that about 15 times. That takes a lot of code, at least in Ruby. Maybe there is some better way of doing it in C++. Anyway, what I did under the revised program was only have a penalty for certain cases of row skipping.

+ 25 for same finger twice, and + 10 more if skipping a row
+ (5*n) for typing with the same hand for the nth time after the 2nd, except when rolling inward along the same row
(QWERTY positions) moving upward and outward (relative to 1 hand, not the whole keyboard) or downward and inward adds 10, and an additional 10 if it skips over the home row

Finger penalties are still the same.

I haven't run the genetic algorithm yet with this new scoring system. But with the previous scoring system, it would usually turn up a result very similar to Dvorak. Here are some of the better (by the previous scoring system) layouts it's gotten:

b l g d q j p y u c
r m t s h i a o e n
w v f ; z , . k ' x

g , . y x ' n f d u
i o a s v l r t h e
; q k p j c w m b z

w f  l m ; j p y ,  '
r  s n t d h i o a e
z x c g v u b k . q


That second one actually looks usable. But I knew my scoring system was skewed when my genetic algorithm thought that was way better than DDvorak, Arensito, Colemak, and Capewell.

In a way I am basing my scoring system off what results those 4 layouts get. First of all, my program should have to run for a very long time to get anything that beats these. Secondly, Arensito should do the best, just because I like that layout.

Last edited by SpeedMorph (19-Apr-2008 21:19:21)
Offline
  • 0
  • Reputation: 0
  • Registered: 08-Mar-2008
  • Posts: 303

Here are all the results for the best layouts. I changed the scoring system slightly.
+ 25 for same finger twice, and + 15 more if skipping a row
+ (5*n) for typing with the same hand for the nth time after the 2nd, except when rolling inward along the same row
(QWERTY positions) moving upward and outward (relative to 1 hand, not the whole keyboard) or downward and inward adds 15, and an additional 15 if it skips over the home row

Note: Any layout that has / on the home row has had it replaced with ' because they are similar in frequency, and having a different set of keys could skew the scoring, i.e. if one layout had Z for every letter, it would score a lot lower because keys would be used a lot less. For this reason I replaced the punctuation on the amuseum layout with the off-home row letters.

handcount = number of times beyond 2 a hand is used over, not counting inward rolls along a line
rowskipcount = moving upward and outward relative to 1 hand
fingercount = same finger used twice or more in a row
chars = number of characters that were used during the testing

At the end, the score is divided by the number of characters, so that 2 blocks of text of different sizes and same letter frequency have the same score. I scored these on a 120 page block of text, which is 20 pages of programming text and 100 pages of written documents, mostly school work.

(edited to be shorter, sorry about before, I just copied and pasted directly from my program)
qwerty score: "score"=>13.72, "rowskipcount"=>2419, "handcount"=>50803, "chars"=>257999, "fingercount"=>9697

amuseum score: "score"=>8.26, "rowskipcount"=>7249, "handcount"=>42227, "chars"=>257999, "fingercount"=>5410

arensito score:  "score"=>7.88, "rowskipcount"=>5765, "handcount"=>42782, "chars"=>257999, "fingercount"=>2872

capewell score: "score"=>7.82, "rowskipcount"=>8658, "handcount"=>35671, "chars"=>251411, "fingercount"=>2918

klausler score: "score"=>7.49, "rowskipcount"=>5486, "handcount"=>32517, "chars"=>257999, "fingercount"=>2427

ddvorak score:"score"=>7.29, "rowskipcount"=>2531, "handcount"=>27180, "chars"=>257999, "fingercount"=>5448

colemak score:  "score"=>7.22, "rowskipcount"=>4894, "handcount"=>31334, "chars"=>257999, "fingercount"=>2270

Amuseum, I had to change your layout so it would work, as I said above. Here's how I changed it:

'  , w h m g c u . z
s o e n l   d t a  i  r
j q y v k  b p f  ; x

The low Capewell and Arensito scores are due to the fact that they are based on ergonomic keyboards, but the question is, how much does that affect it? I can tell that on an ergonomic keyboard the bottom row is easier to hit, but I don't know if anything else is different about it in terms of keyboard scoring.

You can find my program here:
http://mtgap.bilfo.com/blog/2008/04/19/ … m-program/

Last edited by SpeedMorph (20-Apr-2008 17:49:03)
Offline
  • 0
  • Reputation: 210
  • From: Viken, Norway
  • Registered: 13-Dec-2006
  • Posts: 5,343

For ergonomic boards, I suggest that you adjust the weights for the top and particularly the bottom row to a somewhat better value to reflect the ease of hitting those keys. As a programmer, you might introduce a "board_type" type variable to trigger different weight sets.

For my own part though, I feel that stretching "along the grain" of the row stagger doesn't feel or work any worse than I'd imagine it would on a matrix board. The n-m stretch for instance (or the t-"old-c" which is my t-v stretch) feel as fine as I can imagine they would on such a board since my arms and wrists are aligned perfectly with the stretch. In fact, on a matrix board I'd be worried that the board would force me to use more parallel arms which would be uncomfortable I fear.

Oh: For the love of Eris, don't state empty resolution in your results! If your scores differ in the second decimal then you state them with three decimals (e.g., "score"=>7.219 for colemak)! To be more sophisticated, you could always try assessing the uncertainty in your scores (by running different syllabi, making what you deem minor changes to the weights/scoring and suchlike) - an exercise that could prove useful in other ways too. You're making us empirical scientists cry (well, at least I whimpered somewhat).  ;)

Last edited by DreymaR (20-Apr-2008 06:43:38)

*** Learn Colemak in 2–5 steps with Tarmak! ***
*** Check out my Big Bag of Keyboard Tricks for Win/Linux/TMK... ***

Offline
  • 0
  • Reputation: 0
  • Registered: 08-Mar-2008
  • Posts: 303

Here is a layout it just produced:

b d y v ; , w g o '
n s h r l m t e a i
q z f x j c p k . u

It doesn't seem to make sense, but hand count and finger count are very low. Same finger ratio is at 1.03%, and same hand is about 1/3 that of Dvorak. But to get that, it sacrifices a lot of positioning based on letter frequency (O is on the top row). Looking at the scoring criteria, it doesn't make sense to me that the program is doing what it's doing. Is it maybe possible that it's right to ignore letter frequency?

Using Colemak keeps my posts short.

Edit:
Here is another layout which was developed independently.

f c l w k j . p o y
n d r s m h e i a t
z ; q g x b u , ' v

I think it's putting O there just to spite me. Somehow it managed a same finger ratio of only 0.8, despite h and e being on the same finger. Okay, now I KNOW there's a bug.

Last edited by SpeedMorph (21-Apr-2008 03:56:17)
Offline
  • 0
  • Reputation: 0
  • Registered: 08-Mar-2008
  • Posts: 303

Well I modified some stats and got interesting results.

When I greatly increased the penalty for same finger, I got this:

c g i q a u r w p z
f t . e o , l d s h
y v j ' ; k x m b n

Its finger count is about one third that of Colemak.

When the price of each position is increased, here is the (predictable) result:

b y u . j z d c m f
r i e a h l o t n s
x q , v ; w g p k '

This next one was a bit surprising. When I increased the same hand penalty, here is the result:

x k m ; g h w a s p
d y f . , n t e i u
z v x j ' l r o b c

That doesn't look like it optimize hand alternation, and I don't see how I got that result.

Offline
  • 0
  • Reputation: 0
  • Registered: 08-Mar-2008
  • Posts: 303

I was typing the word "pinky" when I realized that typing a lot on one hand isn't necessarily hard. But is it possible to find some simple rule for what makes it hard? It looks to me like it's only hard to change direction.

I have changed the penalties of individual locations to only reflect distance, and not finger strength. Instead I will have a little thing that counts the usage of each finger, adding to its "tiredness". The final tiredness is then added to the score.

Every time a character is hit, the "tiredness" of each finger is reduced by 1.
Whenever a pinky is used, it gains 12 tiredness. (A pinky should be used about 8% of the time, so if there are on average 12 keystrokes between each use of a pinky (12*8 = approx.100%), it will be an ideal amount, and add 0 to the score. Is my math right?)
The ring finger gains 9 tiredness on each hit.
The middle and index fingers gain 8 tiredness.

There is currently a bug causing the tiredness subtraction not to work. The development team is working hard to fix this issue.

Last edited by SpeedMorph (24-Apr-2008 01:23:49)
Offline
  • 0
  • Reputation: 210
  • From: Viken, Norway
  • Registered: 13-Dec-2006
  • Posts: 5,343

Note how "inky" and "pinky" are okay, but "slinky" isn't quite. Similarly, "alkali" is horrible and "knee" too.

Sliding from one key to its' neighbor on the row below isn't bad; it's a tried and tested QWERTY trick for the ed digraph and seems to work well enough.

Jumping up a row isn't good. Jumping two rows up or down isn't good at all (up feels worst) - in my experience it's also bad even if there's one other keypress in between. Typing "ilk" is bad, but "like" isn't quite good either and "kiln" feels like a mess (worse than the similar "link" I think?); I think your tiredness parameter sets in there though.

Maybe a tired finger that gets pressed should gain more tiredness than a rested one?

Last edited by DreymaR (24-Apr-2008 08:33:47)

*** Learn Colemak in 2–5 steps with Tarmak! ***
*** Check out my Big Bag of Keyboard Tricks for Win/Linux/TMK... ***

Offline
  • 0
  • Reputation: 0
  • Registered: 08-Mar-2008
  • Posts: 303
DreymaR said:

Note how "inky" and "pinky" are okay, but "slinky" isn't quite. Similarly, "alkali" is horrible and "knee" too.
Maybe a tired finger that gets pressed should gain more tiredness than a rested one?

That is a clever idea, but I'm not sure how realistic that is. A finger that's already tired just gets more tired; it doesn't get EXTRA tiredness. Plus, implementing it would take work and I don't feel like changing the program right now. :D

Offline
  • 0
  • Reputation: 210
  • From: Viken, Norway
  • Registered: 13-Dec-2006
  • Posts: 5,343

I'd think that a tired finger that gets even more strain will cramp up more than a rested finger will. You're not really looking for tiredness, remember, but for speed? So if a tired finger has to do extra work I feel that it will do it extra slowly. But this is only based on my feelings about the thing, and nothing more.

*** Learn Colemak in 2–5 steps with Tarmak! ***
*** Check out my Big Bag of Keyboard Tricks for Win/Linux/TMK... ***

Offline
  • 0
  • Reputation: 0
  • Registered: 08-Mar-2008
  • Posts: 303
DreymaR said:

I'd think that a tired finger that gets even more strain will cramp up more than a rested finger will. You're not really looking for tiredness, remember, but for speed? So if a tired finger has to do extra work I feel that it will do it extra slowly. But this is only based on my feelings about the thing, and nothing more.

I suppose that makes sense. I think I might implement that.

But what exactly is it that makes it hard to type a lot on a hand sometimes, but not all the time? Changing direction is annoying. So is skipping lines, but not all the time. In "pinky", KY skips over the home row, but it's still not too hard.

Offline
  • 0
  • Reputation: 0
  • Registered: 08-Mar-2008
  • Posts: 303

URGENT UPDATE!!!!!! I have fixed a bug that was messing up the same hand count, and it is now easier to use and debug. Here's the new scoring system:

Up and out on 1 hand (QR, SP, EL, I; , XA, CT, ,N, .O and their reverse, Colemak positions): +5 (this goes against the hand's natural curve, making it difficult)

Changing rows on 1 hand: +(number of rows changed)^4. That means moving up or down 1 costs 1, and skipping over the home row costs 16.

Using the same finger twice: +25

Reversing direction on 1 hand: +4x, where x is the number of times in a row it's reversed direction

Assigned cost for each position:

15 11 10 12 20 20 11 10 11 15
3  1   0   0  10 10  0   0  1   3
21 18 17 16 24 16 12 16 16 20

Notice that the left side has slightly higher costs in some places than the right side. This is because of the asymmetry of the keyboard, and would be removed for testing for an ergonomic keyboard.


I got some strange results.

qwerty score: "score"=>13.16, "jumphomecount"=>2972.0, "rowskipcount"=>304, "handcount"=>595, "effort"=>29480, "chars"=>31040, "fingercount"=>1130
capewell score: "score"=>7.54, "jumphomecount"=>479.0625, "rowskipcount"=>1168, "handcount"=>660, "effort"=>15421, "chars"=>30247, "fingercount"=>348
arensito score: "score"=>7.45, "jumphomecount"=>711.0, "rowskipcount"=>727, "handcount"=>444, "effort"=>16059, "chars"=>31040, "fingercount"=>342
colemak score: "score"=>7.08, "jumphomecount"=>513.25, "rowskipcount"=>591, "handcount"=>390, "effort"=>15943, "chars"=>31040, "fingercount"=>305
nisa score: "score"=>7.08894, "jumphomecount"=>592.625, "rowskipcount"=>653, "handcount"=>692, "effort"=>15378, "chars"=>31040, "fingercount"=>219
ddvorak score: "score"=>6.74, "jumphomecount"=>388.25, "rowskipcount"=>322, "handcount"=>34, "effort"=>16036, "chars"=>31040, "fingercount"=>489
klausler score: "score"=>6.62, "jumphomecount"=>406.9375, "rowskipcount"=>601, "handcount"=>101, "effort"=>15993, "chars"=>31040, "fingercount"=>202


Jumphomecount is the number of times it jumps over the home row, where a single row jump counts as 1/16 of a jumphomecount.
Rowskipcount, despite the name, is when it moves up and out along 1 hand.
Handcount and fingercount are obvious.
Effort is the price of each position on the keyboard, divided by 11.3 because 11.3 is the average of all the positions, and I wanted to reduce the number so that it could be compared to the other values. For instance, "jumphomecount" is not the number of points that were added due to jumping home, it was the number of times it happened. I wanted effort to be similar.

Nisa is a layout that I designed this morning (with logic, not my genetic algorithm), and it's loosely based on Colemak. I got a few ideas from Colemak, such as the P G thing.* Its score on http://www.siteuri.ro/dvorak/ is 1.5% worse than Colemak, and using my criteria it is almost exactly tied with Colemak, about 0.01% worse. Here's what it looks like.

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

It was designed with no restrictions in mind except try to keep shortcuts in place, but that was low priority. I still managed to keep all the shortcuts except C in place. It has very low same finger count, and is the lowest on effort, but pays the price by having too much row jumping and some potentially annoying same hand stuff, such as CASF (case, face, sack).

I was surprised to see that Peter Klausler's layout actually did the best, and DDvorak did second best.  They still did just as well when I cut down on the same hand.

*In a previous thread someone asked why P and G weren't switched even though G was more common. Shai mentioned some stuff like PT/TP is more common than GT/TG (which I found to be true, though neither are very common) and to type P you have to bend your index finger back a little. I was about to disagree when I looked at my statistics and saw that G was only 20% more common than P. That's practically nothing, so I went with P G instead of G P.

Offline
  • 0
  • Reputation: 210
  • From: Viken, Norway
  • Registered: 13-Dec-2006
  • Posts: 5,343

Up and out on 1 hand (QR, SP, EL, I; , XA, CT, ,N, .O and their reverse, Colemak positions)

I don't see what you're getting at here. I don't find either of those particularly hard to type based on hand position (bar maybe QR and ;I which involve the two weakest fingers of a hand in succession), and I don't quite understand what the hands' natural curve is in this context.

What I find a bit hard would be stretching a weak finger after you've typed with its' inward neighbor: TF, SW, RQ, NU, EY, I;. But that's a bit ottomh.

*** Learn Colemak in 2–5 steps with Tarmak! ***
*** Check out my Big Bag of Keyboard Tricks for Win/Linux/TMK... ***

Offline
  • 0
  • Reputation: 0
  • Registered: 08-Mar-2008
  • Posts: 303
DreymaR said:

Up and out on 1 hand (QR, SP, EL, I; , XA, CT, ,N, .O and their reverse, Colemak positions)

I don't see what you're getting at here. I don't find either of those particularly hard to type based on hand position (bar maybe QR and ;I which involve the two weakest fingers of a hand in succession), and I don't quite understand what the hands' natural curve is in this context.

What I find a bit hard would be stretching a weak finger after you've typed with its' inward neighbor: TF, SW, RQ, NU, EY, I;. But that's a bit ottomh.

Well your fingers don't lie naturally straight. Your two middle fingers are longer. If you let your hands rest normally, your middle and ring fingers would rest on W,F,U, and Y. So typing the digraphs I mentioned above requires moving the index or pinky even farther forward, while the ring and middle fingers are already moved back, so your hands are playing Twister with the keyboard.

Offline
  • 0
  • Reputation: 0
  • Registered: 08-Mar-2008
  • Posts: 303

Yay! My program has gone under some big modifications and is now generating good layouts. I got this one after a few hours of running:

f . u m x k l c y ,
s o e t d h r n i a
v q ' g z b w p j ;

It has lower same finger than Colemak, and less effort. The same hand use isn't as good, and it jumps over rows more. Notice that it employs many of the same combos as Colemak: IY, EU, TDG. It got these through random generation, I didn't tell it to do that.

Offline
  • 0
  • Reputation: 210
  • From: Viken, Norway
  • Registered: 13-Dec-2006
  • Posts: 5,343

The HRNIA layout is born!  ;)

It's fascinating to see those similarities.

*** Learn Colemak in 2–5 steps with Tarmak! ***
*** Check out my Big Bag of Keyboard Tricks for Win/Linux/TMK... ***

Offline
  • 0
  • Shai
  • Administrator
  • Reputation: 36
  • Registered: 11-Dec-2005
  • Posts: 423

It looks like a good layout. The only major problem I see is that there is too much work on the pinky corner positions. You'd also want to try to avoid same-finger row jumping, such as with BL digraph.

Offline
  • 0
  • Index
  • General
  • Keyboard Optimizer Genetic Algorithm