• You are not logged in.
  • Index
  • General
  • Keyboard Generation Program As Means of Developing AI

    Keyboard Generation Program As Means of Developing AI

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

    I have spent a good deal of time designing keyboard layouts both by hand and by computer. Both are about equally good, depending of course on who is doing it and what the program is like. But I've noticed that computers and humans use very different methods of creating keyboards. Computers use evolutionary algorithms. The human algorithm is much more complicated. The keys are interdependent: the benefit of placing one key in one place depends on all the surrounding keys, and the surrounding keys depend on it. It almost seems like a chaotic system.

    So would it be possible to write a computer program that uses more human means of designing a keyboard? The algorithm would be pretty complicated. It would probably go something like this (which is essentially how I design keyboards):

    1. Place either S, N, or T under the index fingers on the home row. These are always the best. (Colemak uses N and T, my own layout uses S and T, the Capewell Close Keys Layout uses S and T, Arensito uses N and S . . . )
    2. Decide if you want to optimize for hand alternation or for rolls. For simplicity, I will assume that we want to optimize hand rolls, since I have more experience with that.
    3. Find a cool home row. Usually you want vowels under the pinkies, and some sort of combination that encourages good rolling properties. One way to do this is to alternate between consonants and vowels like AREN SITO. There are other ways to do this as well. E should be under the middle finger, since it's the only one strong enough to handle E. After this, there are many ways to optimize the howe row.
    4. Place other keys around the home row. (Everything revolves around the home row.) They should primarily reduce same-finger and, if possible, optimize hand alternation.
    5. Aesthetics. Some people like ZXCV being in the bottom-left corner. I personally like the comma and period to be in logical positions: next to each other like in QWERTY or Colemak, or parallel like in my layout where they are each on a top row pinky spot.

    There are more subtleties. But if a computer algorithm was written to design a layout with these criteria and somehow have an evolutionary algorithm revolve around it, it could come up with good results a lot faster.

    Thoughts? Does anyone have any ideas for even faster optimization? The main point of this thread is to find an algorithm that uses heightened intelligence to come up with an optimized keyboard a lot faster.

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

    Interesting thoughts. I suppose that when you say things like 'find a cool home row' you're making it a first seed and then allowing a little optimization by the algorithm? The hard part will, as always, be to determine proper weights and priorities I suppose.

    *** 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: 27-Apr-2008
    • Posts: 166

    It seems that the most useful algorithm is the carpalx one:

    http://mkweb.bcgsc.ca/carpalx/?typing_effort

    You have probably already read it.

    You make quite a few assumptions in your designs. You'd be better to have no preconceived ideas about individual letters and let the model determine what is optimal. The carpalx model is a good one (to my mind):

        * limited use of weak fingers, like pinky and ring finger
        * limited use of bottom row
        * increased use of home row
        * limited finger travel distance
        * limited same-finger typing (e.g. uhm)
        * balanced hand-use vs right-hand priority (see below)
        * alternating hand-use vs rolling (see below)

    You'll notice that no mention is made about individual letters as you made in your first point above.

    "It is an undoubted truth, that the less one has to do, the less time one finds to do it in." - Earl of Chesterfield

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

    * limited same-finger typing (e.g. uhm)

    Just to illustrate how tricky it can get, consider alternative fingering! Since same-finger typing is so bad, good typists will often circumvent it with tricks. I'll type 'uhm' with middle-index-middle fingers (in Colemak, of course!) thereby saving effort.

    My most used alternative fingering is 'nk' and I'm quite safe using that. On the other hand, I do slow down on alternative fingerings that I'm not using a lot. As I said, it's tricky. If I were to type 'uhm' a lot, the problem with it would matter more but I'd also be better prepared to cope with it.

    That's one major reason why QWERTY still rules supreme I think: Good typists can get around some of the worst flaws, so they don't feel the need for a better layout as intensely as we layout freaks tend to think they ought to!

    *** 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
    simonh said:

    It seems that the most useful algorithm is the carpalx one:

    http://mkweb.bcgsc.ca/carpalx/?typing_effort

    You have probably already read it.

    You make quite a few assumptions in your designs. You'd be better to have no preconceived ideas about individual letters and let the model determine what is optimal. The carpalx model is a good one (to my mind):

    [design criteria]

    You'll notice that no mention is made about individual letters as you made in your first point above.

    The problem here is that it takes a whole lot longer without more specific criteria. One way for the program to find specific criteria (and thus speed up the keyboard generation process) would be to look at a bunch of layouts that are considered "good" and find common themes. This would require already knowing what "good" layouts look like, but that shouldn't be hard. We actually know good layouts better than we know good weightings. So a program could, in a way, work in reverse. This sort of program would have to be rather sophisticated, though. Patterns aren't always obvious. It could maybe be based on concepts of pattern-recognizing programs that are already out there.

    About Carpalx, they may have relatively sophisticated algorithms, but their output is pretty bad and I don't like the weightings.

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

    Thing is though, I know that Arensito and Dvorak and Colemak are good layouts and they were all made considering some design principles that I consider sound. Thus, putting that into a machine will make layouts that are almost but not quite 'Dvolemaksito', won't it? I don't really foresee that it'd surprise me in a positive way; I'd create a slew of layouts that were 'almost-as-good-as-and-maybe-unnoticeably-better-than' the original favorites I started out with.

    Maybe I'm just lacking vision, heh. But I'm doubting that this method will innovate enough, and furthermore it'll be hard to whip up objective and controllable success criteria for it (but that's true for any method of course).

    Last edited by DreymaR (28-Jul-2009 12:48:22)

    *** 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, the primary innovation here is not to make a better layout. The layouts we have are already very close to optimal, and it will be very difficult to get better. The point here is to write an algorithm that can very quickly come up with a good layout.

    The first step here, though, is to know which layouts are good. I would appreciate anyone who would take this series of questions.

    Offline
    • 0
    • Reputation: 0
    • Registered: 22-Aug-2009
    • Posts: 6
    DreymaR said:

    furthermore it'll be hard to whip up objective and controllable success criteria for it (but that's true for any method of course).

    I think this point nails the problem on the head.

    The difficulty isn't solving the problem, it is posing the problem. We've all, myself included (http://mkweb.bcgsc.ca/carpalx) made attempts to solve it by posing it a different way. Therefore, I think we should not be arguing layouts as much as the criteria that goes into a layout.

    Given that beyond the basics, subtle qualities of a good layout are actively disputed, any standardized test that evaluates a layout is only as good as its assumptions about what is good.

    I, for one, do not weigh aesthetics into a layout, since a layout should be easier to type on and not easier to look at. A standard QWERTY letter mask may attract more adopters, and in particular if some of the edge or home row keys are the same, but overall cosmetics simply makes a layout more familiar rather than less strenuous.

    The speed at which the algorithm runs should not be a factor in determining its usefulness. CPU cycles are cheap and once a solution has been found, we need not look for another one. Of course, that is, untill the next layout algorithm is developed :)

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

    In the pre-release version of Colemak, the semicolon was between the B and M buttons. It just didn't look aesthetically pleasing, which turned away a lot of people away from it.

    Aesthetics are certainly important, and they played a role in the design of Colemak.

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

    I agree: One of the strengths of Colemak is that it appeals both to the enthusiasts and the laypeople (well, the few laypeople who give a damn about layouts at any rate...). It isn't just a layout for the select few, potentially.

    The punctuation placement in Dvorak put me off a bit, and designs that let punctuation fly everywhere even more so. The exception I will make is the key between B and K - if you have such a key (Comfort layout). That can be practically anything since it shouldn't be hit much and is clearly placed between the two hand blocks.

    *** 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: 17-Mar-2008
    • Posts: 192

    I'd personally recommend using the extra key on a VK102 for either enter or backspace, and if you have backspace on caps lock the decision is even easier. It's kind of like the TypeMatrix.

    Umlaut-laden language users would of course find it handy to stick one of their funny vowels there. Dreymar, I'm looking at you...

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

    Yep, I'm loving my funny-vowel key!  :D

    Since I'm using PKL for the most part, my space bar doubles as my second Enter key - and it's a lot easier to hit than that tucked-away former B key! One of my reasons for demoting that key to funny vowel usage was its difficult position so it shouldn't be used for anything more common than, say, the letter 'J' (which in the other somewhat tricky position between the hands).

    *** 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
    Shai said:

    In the pre-release version of Colemak, the semicolon was between the B and M buttons. It just didn't look aesthetically pleasing, which turned away a lot of people away from it.

    Aesthetics are certainly important, and they played a role in the design of Colemak.

    Even though K and semicolon would be better switched, I agree with your decision there. But that's because the main goal of Colemak is very different from the goal of Carpalx or my layout. Our goals are create the best layout possible, by any means necessary. The goal with Colemak is to create a good layout that people will want to use as an alternative to QWERTY. And it does a far better job of that than my layout, which is why I endorse Colemak.

    Offline
    • 0
    • Reputation: 0
    • Registered: 07-Aug-2007
    • Posts: 69
    SpeedMorph said:
    Shai said:

    In the pre-release version of Colemak, the semicolon was between the B and M buttons. It just didn't look aesthetically pleasing, which turned away a lot of people away from it.

    Aesthetics are certainly important, and they played a role in the design of Colemak.

    Even though K and semicolon would be better switched, I agree with your decision there. But that's because the main goal of Colemak is very different from the goal of Carpalx or my layout. Our goals are create the best layout possible, by any means necessary. The goal with Colemak is to create a good layout that people will want to use as an alternative to QWERTY. And it does a far better job of that than my layout, which is why I endorse Colemak.

    You really find Colemak-semicolon easier to strike than Colemak-K?  The former involves moving the shorter and weaker pinky, considerably tougher than swinging the longer and more powerful index finger a little bit down, no? 

    Somebody should thrash out statistically the relative ease-of-strike values for all the key positions.  I am not sure the implicit assumptions behind Colemak and the explicit ones made by Martin K are beyond revising.  Colemak design, for instance, seems to assume that Colemak-D is easier than Colemak-F, and Colemak-G is easier than Colemak-V, which I cannot reconcile with my experience.  Colemak-G is quite misplaced in my opinion, and could have been left at its Qwerty position, strengthening the layout's claim to be reassuringly similar to Qwerty.

    That said, I do realize that if does make sense to occasionally gift an easier key to a less common letter, in order to not to work the strong fingers too much.   But the G and D positions were sufficiently achy that I reluctantly had to switch some five keys around for personal use.

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

    You really find Colemak-semicolon easier to strike than Colemak-K?  The former involves moving the shorter and weaker pinky, considerably tougher than swinging the longer and more powerful index finger a little bit down, no?

    Sorry, I wrote that wrong. What I meant was that the Colemak semicolon position is good for K because KO is a very rare digraph and some people have had problems with NK. But that switch in particular would not be as good.

    Somebody should thrash out statistically the relative ease-of-strike values for all the key positions.  I am not sure the implicit assumptions behind Colemak and the explicit ones made by Martin K are beyond revising.  Colemak design, for instance, seems to assume that Colemak-D is easier than Colemak-F, and Colemak-G is easier than Colemak-V, which I cannot reconcile with my experience.  Colemak-G is quite misplaced in my opinion, and could have been left at its Qwerty position, strengthening the layout's claim to be reassuringly similar to Qwerty.

    I agree. I am working on a program to evaluate ease-of-strike values as we speak.

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

    Using Dvorak, Carpalx (QGMLWB), Klausler, Capewell, Colemak, and MTGAP 2.0, I calculated the average costs of different positions.

    144 105  81  77 103 131  78  69  82 121 
     22  20  19  29  63  61  27   7  31  30 
    165 153 103 122 155 131  97 105 125 154

    And if you find those large numbers to be intimidating, here is a normalized version:

     23  16  11  11  17  27  11  11  13  25 
      2   3   6   2  14  13   4   1   5   3 
     27  26  13  19  24  21  15  17  21  24

    This is biased, of course, since each of these layouts takes other factors into account when placing keys. But it's good overall.q

    Last edited by SpeedMorph (28-Aug-2009 02:47:31)
    Offline
    • 0
    • Reputation: 210
    • From: Viken, Norway
    • Registered: 13-Dec-2006
    • Posts: 5,343

    Position cost, huh? So the left middle finger should have 6 times more trouble striking its home position than the right one? That sounds horribly horribly wrong to me but I must have misunderstood something. Please explain.

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

    Position cost, huh? So the left middle finger should have 6 times more trouble striking its home position than the right one? That sounds horribly horribly wrong to me but I must have misunderstood something. Please explain.

    The way I did it was I made costs based on what keys were placed where in the layouts that I mentioned. e is +0, t is +1, a is +2, o is +3 . . . z is +25. Since so many keyboards place e under the right middle finger, then yes, the left middle finger is supposedly six times harder than the right one. But you should really measure it in absolute cost instead of proportional cost.

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

    I don't see how that cost scoring system can translate into something useful?

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

    Let's say Colemak places e under the right middle finger (which it does). This position gets +0, since the designer of Colemak must think that that position is pretty easy. But Colemak places z under the left pinky on the bottom row. This position gets +25, since the designer of Colemak must think that that position is hard to hit. Repeat this process for every key on the keyboard and for several different layouts, and you get a pretty good average of the costs of different positions.

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

    Um, no? I don't suppose that Shai thinks of the costs in linear terms from most common letter to least common.

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

    Um, no? I don't suppose that Shai thinks of the costs in linear terms from most common letter to least common.

    No, but it's still useful as an estimation technique.

    Offline
    • 0
    • Reputation: 0
    • Registered: 17-Dec-2008
    • Posts: 59

    In my program, I chose to rank keys rather than rate them.  Personally, I think this is what we (layout designers) are really after.  We want to say, "I'd rather use the Qwerty J key than the Qwerty Y key," not, "Qwerty J is exactly 9.18273 times better than Qwerty Y."  What does it even mean for a key to be X times better or worse than some other key?  (I think this is what DreymaR is getting at.)

    I used similar reasoning for the other parameters.  For instance, I want typing to flow inward, as in Dvorak.  But how much better is inward flow than outward flow?  Is it 2.13 times better?  Should each outward sequence get a 5.743 point penalty?  I don't know that.  So, I just said, "Hey, try to get as much inward flow as you can without sacrificing too much else."  I give it hints as to what that means, but it gets to find the specifics.  :)

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

    In my program, I chose to rank keys rather than rate them.  Personally, I think this is what we (layout designers) are really after.  We want to say, "I'd rather use the Qwerty J key than the Qwerty Y key," not, "Qwerty J is exactly 9.18273 times better than Qwerty Y."  What does it even mean for a key to be X times better or worse than some other key?  (I think this is what DreymaR is getting at.)

    I used similar reasoning for the other parameters.  For instance, I want typing to flow inward, as in Dvorak.  But how much better is inward flow than outward flow?  Is it 2.13 times better?  Should each outward sequence get a 5.743 point penalty?  I don't know that.  So, I just said, "Hey, try to get as much inward flow as you can without sacrificing too much else."  I give it hints as to what that means, but it gets to find the specifics.  :)

    I tried doing that about a year ago, but it didn't get results that were anything like what I wanted. My implementation was probably not very good. I find numeric values to be efficient and easily readable by the computer, and (with a little calibration) can get very good results.

    Offline
    • 0
      • Index
      • General
      • Keyboard Generation Program As Means of Developing AI