The Keyboard Layout Project

The Keyboard Layout Project is an attempt to design a fully optimized keyboard layout, with no restrictions. It is one of the world’s most comprehensive studies on keyboard layouts and pulls together research from various other sources. I draw a lot of information for this project from the Colemak forum, which is currently the net’s most active site for keyboard layout-related ventures (especially those related to Colemak).

Updates on The Keyboard Layout Project may be found here.

Objectives

1. Find the optimal keyboard layout based on my own preferences.
2. Provide a means for others to design their own optimized layouts.
3. Continue research in the field of keyboard layout design.

Purposes

The Keyboard Layout Project was originally inspired by the inefficiency of QWERTY, the standard keyboard layout on nearly every computer. Many people spend hours each day typing at their computer, and deserve something more comfortable than QWERTY.

QWERTY is flawed, and we need something better. I recommend that people learn Colemak, as it is currently the most viable alternative to QWERTY (as well as being one of the best keyboard layouts out there). It is easy to download, easy to learn, and actually more optimized than other alternatives such as Dvorak.

But if Colemak is such a great layout, why does the Keyboard Layout Project exist?

The purpose of this project is not to produce a keyboard layout to replace QWERTY — at least, not immediately. Colemak is most suited to widespread use. However, Colemak is (a) stable, and (b) does not provide the same flexibility as the Keyboard Layout Project tries to provide.

A widely-used keyboard layout needs to be stable. The problem with stability, though, is that it cannot be customized. The Keyboard Layout Project is intended to demonstrate the creation of a customized layout and to provide the necessary tools to customize one’s own keyboard.

Methods

This project provides a large set of resources for researching keyboard layouts. The project is only run by one person, and there’s a limit to how much I can do; so I provide plenty of external resources. I have a list of alternative keyboard layouts. The list contains about two dozen alternative layouts, which is more than any other list as far as I know. It contains every keyboard layout that I’ve come across. colemak.com also provides a list of alternative layouts.

Designing a layout to be objectively better is a difficult process, as measuring typing efficiency is very difficult. Generally, estimates of whether one keyboard layout is better than another are subjective. There are certain things that everybody agrees on, for example, that moving your fingers around a lot is bad; but people don’t agree on just how bad it is.

I am trying to collect objective typing data by using a program called Amphetype. It gives detailed readings on your fastest and most accurately typed words. In collecting this data I have noticed that how fast different combinations are often depends more on the frequency of those combinations than on the keyboard layout itself. This makes it difficult to collect a sufficient amount of data. For this reason it is also important to collect data on multiple different keyboard layouts. I only know two layouts, so there is a limit to how far I can go. If you want to contribute, see here.

Other Projects

Colemak:

The QWERTY layout was designed in the 19th century to allow typewriter salesmen to easily type the word “typewriter” and to prevent typebars from sticking. We’ve been stuck with QWERTY ever since.
Colemak is a modern alternative to the QWERTY and Dvorak layouts. It is designed for efficient and ergonomic touch typing in English.
Learning Colemak is a one-time investment that will allow you to enjoy faster and pain-free typing for the rest of your life. Colemak is now the 3rd most popular keyboard layout for touch typing in English, after QWERTY and Dvorak.

This is the world’s best alternative layout. Its creator, Shai Coleman, put a great deal of time into tweaking Colemak. It currently has several thousand users and an active community.

Carpalx Keyboard Layout Optimizer:

The carpalx project introduces a quantitative model for typing effort and applies it to (a) evaluate QWERTY and popular alternatives, such as Dvorak and Colemak and (b) find the keyboard layouts that minimize typing effort for a given set of input documents. In the work presented here, these documents are English text, but they can be anything, such as corpora in French, Spanish and even programming languages, like C or Python.

While there are many alternate layouts, the carpalx project distinguishes itself, however, in that it not only proposes new layouts but also describes a fully baked parametric model of typing effort.

While I do not agree with some parts of carpalx’s model, it is undeniably a very detailed analysis of keyboard layouts that is worth looking into.

Keyboarding Theory

The most important posts to read would be those about keyboarding theory. Here is a list of such posts. Unlike some of my other posts, these generally do not assume that you are familiar with the technical details of keyboard design or with my own ventures (although all of my experiments may be found on my blog or, for some of the older material, my website).

How Hard to Type?
Optimized Evolutionary Algorithm for Keyboard Design, Part 1 and Part 2
Fast Typing Combinations
Have We Been Mistaken All Along?
Should a keyboard layout optimize for hand alternation or for rolls?

For a complete list, see: https://mathematicalmulticore.wordpress.com/category/keyboards/keyboarding-theory/

Most Recent Optimized Keyboards

Optimized for a Kinesis Advantage Pro:

Hands: 42% 41%
Fingers: 7.0% 8.0% 16% 12% 0.00% 18% 12% 11% 9.0% 7.0%

    `  %  /  +  #   ^  <  >  {  }  Q
 |  \  P  O  U  [   ]  D  L  C  W  @
    I  N  E  A  *   M  H  T  S  R  X
    &  K  =  Y  !   B  F  V  G  $  
    ~ \t                     J  Z  
                               \n SP

    1  2  3  4  5   6  7  8  9  0  q
 ;  .  p  o  u  -   "  d  l  c  w  :
    i  n  e  a  ,   m  h  t  s  r  x
    (  k  '  y  _   b  f  v  g  )  
    ? \t                     j  z  
                               \n SP

Fitness: 51887480
Distance: 77500
Finger work: 67705
Inward rolls: 6.56%
Outward rolls: 1.54%
Same hand: 42.23%
Same finger: 1.51%
Row change: 27.27%
Home jump: 6.18%
Ring jump: 1.76%
To center: 3.42%
To outside: 0.40%

* * *

Optimized for a standard keyboard:

Hands: 50% 49%
Fingers: 9.0% 9.0% 19% 14% 0.00% 0.00% 15% 15% 10% 9.0%

 ^  ~  [  {  <  |   #  >  }  ]  %  Q  Z    
    Y  P  O  U  =   K  D  L  C  W  X  +  @
    I  N  E  A  :   M  H  T  S  R  !       
    `  ?  *  ;  &   B  F  G  V  J          

 \  1  2  3  4  5   6  7  8  9  0  q  z    
    y  p  o  u  -   k  d  l  c  w  x  /  $
    i  n  e  a  ,   m  h  t  s  r  "       
    (  )  '  .  _   b  f  g  v  j  

Fitness: 17333300
Distance: 33192
Finger work: 0
Inward rolls: 10.09%
Outward rolls: 2.35%
Same hand: 34.47%
Same finger: 1.57%
Row change: 12.78%
Home jump: 1.06%
Ring jump: 3.17%
To center: 2.67%
To outside: 0.46%

* * *

Optimized for the main 30 keys of a standard keyboard:

Hands: 50% 49%
Fingers: 9.0% 9.0% 19% 14% 0.00% 0.00% 16% 15% 10% 8.0%

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

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

Fitness: 14239952
Distance: 55843
Finger work: 0
Inward rolls: 10.49%
Outward rolls: 2.41%
Same hand: 34.47%
Same finger: 1.40%
Row change: 12.56%
Home jump: 0.99%
Ring jump: 3.16%
To center: 2.41%

  1. October 28, 2012 at 4:01 pm

    Hi, I’m the owner of TypingWeb.com, the largest typing tutor on the net. We have hundreds of thousands of typists learning on our site every day. Your project is extremely interesting to me, and if you are interested I’d be happy to add your format (once completed or during testing if you’d like) to our list if supported keyboards, aiding users in learning as well as giving it plenty of exposure. We currently have around 30 of the most popular international keyboards, and we add new ones as users request them. Best of luck!

    • October 28, 2012 at 6:41 pm

      Hi Austin,

      I don’t think I’ve ever seen your site before, but it looks really good. I might have to try it out. ;)

      I’m happy to know that you like my keyboard layouts, and if you want to add one or some of them to your website, you certainly have my permission. That said, I generally don’t encourage people to use my layouts because I think people should use Colemak. While I do think my layouts are a little better, the marginal difference is quite small, and Colemak provides much better user support. But like I said, if you want to add my layout(s) to your site, feel free to do so.

    • October 28, 2012 at 6:48 pm

      Actually, I’ve been using your site and I like it. Could you be sure to add MTGAP 2.0 (described here) to your keyboard list? That’s the one I’m using right now.

  2. buster
    October 28, 2012 at 6:23 pm

    Why no mention of Maltron?

    • October 28, 2012 at 6:33 pm

      1. I don’t have a Maltron keyboard.

      2. Maltron is similar enough to Kinesis that you can use the Kinesis layout on a Maltron with only small modifications.

  3. ampelmann82
    October 28, 2012 at 7:00 pm

    Great project Michael, we are building KeyRocket to teach people keyboard shortcuts (and later other things) based on their behavior/input. Typing speed and Keyboard layout have been in my idea list for a long time. We should talk whether I can help with getting you a lot of typing data. We just need smart ideas how to protect privacy. Best from Berlin, Jan

  4. October 28, 2012 at 7:01 pm

    Nice project! I’ve been down a similar road a 6 years ago when deciding to stop using Qwerty and look for alternatives. I spent half a year finding my personal perfect optimized layout (I type in both English, Dutch, C# and Ruby).
    I’ve decided to opt for Dvorak with a little tweak: reversing the U and I. I am glad I did as otherwise I’d probably still be looking for the best alternative and relearning instead of just using a more efficient but still < 20% suboptimal layout; good enough. For the ultimate in language entry use Plover steno, syllable chord keyboard entry. http://plover.stenoknight.com/

  5. Ian Kelling
    October 28, 2012 at 7:41 pm

    I noticed the Kinesis keyboard layout does not have a shift key listed. I’m pretty sure the default location is not optimal. Have you thought about this?

    • October 28, 2012 at 7:49 pm

      Indeed I have. I wrote about this when I first got a Kinesis keyboard. I haven’t incorporated Shift into the program because it’s difficult to model its interactions with the other keys.

  6. Joel Wong
    December 21, 2012 at 1:02 pm

    Your layout for the 30 keys looks really cool. I might want to try it, if i ever get round to. What layout do you currently use and how do you find it?

    • December 21, 2012 at 6:56 pm

      I currently use MTGAP 2.0, but I think the layout on this page is better. I just think the difference is too small to justify re-learning another keyboard layout, which is why I still use version 2.0. I’d suggest you use the layout given on this page.

  7. Vivid
    June 7, 2013 at 11:36 am

    Hi, I am a Spanish guy and I have been looking for the right alternative layout. I type regularly in three languages, Spanish, English and German. I’ve half-learned a slightly modified version of Colemak where I’ve put the `ñ´ letter in place of :; and have also replaced ‘? by ´¨ as a dead key, since getting the accented vowels is usually more efficient with a dead key than with AltGr. The deal-breaking problem with Colemak for me is that it that it uses the right pinky way too much to the point that it hurts (the tip of the finger). This is due to the fact that the `o´ letter is more used in Spanish than in English and I also have to use that finger to get the accented vowels. So I have been looking for alternatives. One is QGMLWY, which has some appeal since it lowers the use of the pinkie in all three languages I use, and is more efficient than Colemak in German, slightly superior in Spanish and a little inferior to Colemak in English, according to http://patorjk.com/keyboard-layout-analyzer/. The problem is it has some combinations which are really uncomfortable, like cl (climb, climate) or yo (you, young, yo in Spanish). So I kept on searching and found your web and I’ve been trying your most recent layout and I think is really good for English. I also like the fact that the vowels are all on the left side so I can easily get the accented vowels with a dead key on the right pinky (alternation is good); but some very common Spanish trigraphs are not comfortable at all, `que´, `qui´. So my question is, would it be possible to create, via your program, a compromise international keyboard that keeps the most important Western European languages in mind (English, Spanish, German, French, Italian)? The point is to sacrifice a little efficiency in one specific language in order to achieve a more universal applicability.

    • June 7, 2013 at 4:42 pm

      Thank you for your interest! Yes, it would absolutely be possible to generate such a keyboard layout. Right now I only have typing data for English, so I can’t create a new layout based on what I have. If you could get some typing data for different languages and send it to me, I could incorporate it into my program’s data. Or, if you know a little programming, you could probably do it yourself: https://github.com/MTGandP/Typing

  8. Vivid
    June 9, 2013 at 8:02 pm

    Sorry, but I am clueless about programming, apart from some simple scripts for Autohotkey. I’ve been searching for these word data and all I have been able to come come up with is this:

    Frequency of letters in Spanish:

    http://www.sttmedia.com/characterfrequency-spanish

    Frequency of digrams and trigrams in Spanish:

    http://www.sttmedia.com/syllablefrequency-spanish

    Frequency of letters in German:

    http://www.sttmedia.com/characterfrequency-german

    Frequency of digrams and trigrams in German:

    http://www.sttmedia.com/syllablefrequency-german

    And here you can download huge lists with hundreds of thousands of words and their frequencies:

    https://skydrive.live.com/?cid=3732e80b128d016f&id=3732E80B128D016F!3584

    `es´ for Spanish and `de´ for German.

    Some letters, like á é í ó ú ä ë ï ö ü ß (in both German and Spanish), are created with 2 dead keys usually to the right of :; and to the right of `p´ in a US QWERTY keyboard.

    Thanks a lot for your interest in my idea too!

    • June 10, 2013 at 2:28 am

      Okay, thanks. I’ll look into it once I get a chance.

      • Vivid
        July 21, 2013 at 10:29 am

        Hi, you haven’t had a chance, have you?

        • July 22, 2013 at 8:09 pm

          Thanks for checking back with me. I’ll try to look into it within the next few days.

    • August 5, 2013 at 7:42 pm

      Okay, sorry for the delay. Those sites you linked to don’t provide detailed enough data, and I don’t want to spend the time to try to find better data. If you can find detailed data on characters and digraphs, you can use it to run the program. Put the digraph data into the file allDigraphs.txt and the character data into allChars.txt, using the same format that these files use. Each digraph/character has to have an integer that gives its relative frequency. If you find data that gives frequencies in terms of percentages, simply multiply the percentage by some large number and round to the nearest integer.

      This will require some work, but it should be doable. Let me know if you have any questions.

      You may also want to look into the Arensito keyboard layout, which I believe was designed with multiple languages in mind. http://www.pvv.org/~hakonhal/main.cgi/keyboard

      • Vivid
        August 6, 2013 at 10:29 pm

        Ok, thanks.

      • Vivid
        August 20, 2013 at 11:13 am

        A friend of mine has compiled the program for me and we have been able to mix frequencies of digraphs and characters from English, German and Spanish. The resulting keyboard is this:

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

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

        Now I would like to create a keyboard that will keep the signs in their qwerty places (bottom right corner) and will only move the letters. I would also like to replace the qwerty key ‘:;’ by the Spanish letter ‘ñÑ’. How can I do that? Where is the 30 key keyboard defined? And how? Because lower case and upper case letters seem to be linked (they both move to the same places) but not the signs. Where do you define that link and how?

        • August 21, 2013 at 3:20 am

          There’s not currently an option for keeping special characters in the bottom right corner.

          In tools.h there’s a line that says #define DEFAULT_KEYBOARD_30 which defines the 30 key keyboard. However, it will be difficult to get it to use ñÑ. By default, it can only use ASCII characters, and ñ is not part of the ASCII set. You’d have to modify the program to support other character sets, which would require some significant work. If you or your friend wants to take this on, I’d love to see what you come up with.

  9. Omid Nikta
    June 20, 2013 at 1:47 pm

    Hi, I am trying to create a layout for my language and would like to know how you compute the effort for every key (like 0 -8 -10 -10 40 40 on the home row). In fact, my language contains more than 30 characters, so we need to design a layout (on a ISO keyboard, not an ANSI, which contains one more key between left shift and “z”). So I need to now efforts for other keys, like these ” [ ] \. Thanks.

    • June 20, 2013 at 5:48 pm

      I didn’t have any rigorous method for computing the efforts. I basically just practiced typing different keys and tried to gauge how difficult they were to type.

      If you download the most recent version of the typing program, it contains my best guess as to the efforts for all the keys on the keyboard (although it doesn’t have an extra key between shift and ‘z’). You can find the key efforts table in the values.c file.

  10. Dave Ferree
    August 31, 2013 at 10:33 pm

    Patorjk.com’s Keyboard Layout Analyzer has been updated. Please submit the main 30 layout! I’d do it myself, but A) it isn’t mine and B) I have no idea what you are calling it.

    • September 1, 2013 at 5:52 am

      Feel free to submit it yourself. I’m calling it MTGAP.

  11. Dave Ferree
    November 25, 2013 at 4:59 pm

    Was just attempting to plug-in Arensito into the Patorjk Keyboard Layout Analyzer and became curious; Is there an optimized AltGr layer for MTGAP?

  12. Dave Ferree
    January 25, 2014 at 3:50 am

    Plugging away at Patorjk’s again, trying to fill in MTGAP on the Ergodox map, and I can’t make heads or tails of the Kinesis Advantage Pro layout you have posted here. Mind if I just put in the main 30 with shift on the left thumb and space on the right? I’d probably use the Ergodox Keyboards: Colemak(v2) layout as the base to fill in the blanks and just overlook the lack of Alt, Win, Delete and Arrow keys.

    • January 25, 2014 at 3:53 am

      That’s fine. That’s more or less the configuration I’m currently using.

  13. Mike Rouse
    February 19, 2014 at 6:04 pm

    Dave Ferree :
    Plugging away at Patorjk’s again, trying to fill in MTGAP on the Ergodox map, and I can’t make heads or tails of the Kinesis Advantage Pro layout you have posted here. Mind if I just put in the main 30 with shift on the left thumb and space on the right? I’d probably use the Ergodox Keyboards: Colemak(v2) layout as the base to fill in the blanks and just overlook the lack of Alt, Win, Delete and Arrow keys.

    It looks like you used the “Optimized for the main 30 keys of a standard keyboard” version for the Ergodox (starting row “Y P O U J”). Wouldn’t the Kinesis Advantage Pro version (Top row containing letters “| \ P O U [” ) be better? I can fairly easily submit it, but I don’t want to make it too confusing.

    In a completely different topic, I saw an article entitled “Case-sensitive letter and bigram frequency counts from large-scale English corpora,” by Michael N. Jones and D. J. K. Mewhort of Queen’s University (Kingston, Ontario, Canada), available here: http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.394.1855&rep=rep1&type=pdf

    Everyone knows about the standard ETAOIN SHRDLU (or more accurate but less mnemonic ETAOIN SRHLDCU), but the order of capital letters is the completely different TSAMC INBRP (EDHWL OFYGJ UKVQXZ). It might help determine where to put a single shift key, if that’s the layout you are using.

    It also has information on case-sensitive bigrams (AA counted separate from Aa, aA, and aa, for example), plus “Single-Unit Frequency of Various Nonalphabetic Characters (ASCII 33–64), and Bigram Frequency as Predecessor (#A) or Successor (A#) to an Alphabetic Character.” Basically, it counts when you have an exclamation point after a letter, or an open parenthesis before a letter, and similar stuff.

  14. Mike Rouse
    February 22, 2014 at 1:05 am

    Well, the keycaps for my newly purchased Cherry G86-63400 point-of-sale keyboard, with 144 gloriously programmable keys in a matrix format, come in on Monday. Sadly, I have to roll my own “E on the left thumb” MTGap format. Any suggestions on how to tweak your MTGap software to do that? I assume that removing, disabling, or somehow locking e and space (left and right thumb, respectively) somewhere in the algorithm and letting the rest of the program works its magic may work, but I’ve never compiled a C program before, so suggestions on what I need to download, install, and tweak on my Windows 7 computer first would be great. :)

    • February 22, 2014 at 1:10 am

      If you think putting E on the left thumb is the best idea, you should try tweaking the scoring algorithm to get that. It makes more sense to write a strong scoring algorithm than to put constraints on the program, since you should get a better layout that way. In this case, however, there is no left thumb key, so I’d suggest replacing the E key with whatever other key you want to put on the main keyboard instead.

      About running C on Windows: I don’t use Windows so you’ll have to ask Mr. Google.

  15. Mike Rouse
    February 28, 2014 at 4:57 pm

    I’ve been roaming the Internet, looking for more bigram frequency data to play with in “The Keyboard Layout Project” program (Peter Norvig’s Google data was great, but limited to 676 2-letter bigrams). I found the article “Case-sensitive letter and bigram frequency counts from large-scale English corpora” by Michael N. Jones and D. J. K. Mewhort, and it considered all uppercase and lowercase letters separately, as well as 32 nonalphabetic characters including the 10 digits (ASCII 33–64; ! to @).

    But the absolute best of all is the supplementary material “Jones-BRM-2004.zip” which gives all of the data in several formats, including Excel.

    If anyone would like to utilize this fun resource, here is the Springer link:

    http://link.springer.com/article/10.3758%2FBF03195586

    Just head down the page until you see supplementary material. The article itself is interesting as well. Sadly, the authors didn’t count spaces, but that is fixable. Making “The New York Times Keyboard” or the “Usenet Keyboard” should be fun…

  16. Dave Ferree
    May 17, 2014 at 8:10 pm

    I don’t suppose we could get an official release for the Main 31 (main 30 + apostrophe/quote)?

    … if you are feeling super generous, an official Wide-Mod* optimization would be nice too.

    I’m going to try to give it a crack myself, but… I’m not getting my hopes up.

    *Home position on qwerty asdf kl;’ keys. Improves wrist position and decreases strech to R.Shift, Enter, Backspace, etc. Supposedly makes AltGr a bit easier as well.

    • May 17, 2014 at 8:39 pm

      A wid-mode layout sounds like a cool idea! That would require a substantial amount of work though, and I don’t have the time for that right now. I’d love to see you give it a try. If you come up with anything, please post it here!

  17. Sasha Viminitz
    June 7, 2014 at 11:54 pm

    Hi Michael,
    I too have been sucked down the dark rabbit hole of alternate keyboard layouts. It seems to hook those of us with a particular propensity for approaching the elusive limits of perfection.
    Three years ago I spent the better part of a year playing with layouts. I used Andong’s keyboard analyzer for my analysis, my goal being to create a layout that improved on both Dvorak and Colemak’s respective strengths.
    The results of my efforts are HIEANRSTM or Balance 12 (being the 12 iteration of a theme):
    BYOU’KDCLPQ
    HIEA,MTSRNV
    X”-.?WGFJZ
    This layout matches Dvorak for hand alteration and improves on inward rotation. It also matches Colemak’s low same finger court and home row statistics. I also borrow an idea from Andong, using the coma as a deadkey SHIFT, further reducing pinky usage and finger balance.
    I have been typing on this layout for about a year now. On occasion (like today) I play around with trying to improve it, but I seem to have found the limit—any improvement in one matrix reduces performance in another.
    It’s remarkable to me how similar our two layouts are. I would very much be interested in seeing the results of running HIEAMTSRN (or Balance 12, as I dubbed it) through your analysis. When two people working independently come to such similar conclusions, it lends confidence that we may be approaching an optimal solution. Looking again at your layout above, I have to admit, I think it may be a subtle improvement to my own—the only thing it seems to sacrifice is hand alteration, which as many of the forums point out, may not be that relevant. Run mine through the numbers and let me know how they compare.
    —Sasha Viminitz, Fellow Keyboard Enthusiast

    • June 8, 2014 at 1:47 am

      That layout looks awesome! Can you post the full keyboard layout (including number keys and all the punctuation keys on the right side of the keyboard) so I can properly analyze it?

      Also, have you posted this online anywhere else? I’d like to link to your layout on my Alternative Layouts page.

  18. Sasha Viminitz
    June 8, 2014 at 6:33 pm

    Hi Michael,

    Here’s the complete layout for Balance Twelve, following your format above (double spaces separate characters, Caps first):

    \ / # $ % ^ & * _ +
    B Y O U @ K D C L P Q { }
    H I E A ; M T S R N V
    X [ ] : ! W G F J Z

    1 2 3 4 5 6 7 8 9 0 – =
    b y o u ‘ k d c l p q ” —
    h i e a , m t s r n v
    x ( ) . ? w g f j z

    As I said earlier, I have made the coma a deadkey linked to the shift position. This prevents the awkward double stroke coming off the left shift onto the ‘h’ after a ‘Th’ digraph and better weights the left index finger. I have also made the Colemak swap between Caps Lock and Backspace. The more minor punctuation and numbers I have not spent time optimizing. For the rarely used characters it’s still nice to have the visual reference available on the standard keyboard.

    As an artifact of my process, I type with the mirror of the above, but I think the above version is preferable if for no other reason than it preferentially weights the right hand and provides hand alternation for terminal punctuation such as ‘.’ with the Enter key. This is also optimized for the standard asymmetrical keyboard placing the ‘w’ on the lower right as opposed to the upper left in its mirror

    Should you wish to keep the punctuation on the lower right, here is its mirror. For those committed to the zxcvb shortcut keys, this layout can be modified with minimal effect to its overall fitness:

    \ / # $ % ^ & * _ +
    P L C D W @ U O Y K Q { }
    N R S T M ; A E I H V
    Z J F G B ! : [ ] X

    1 2 3 4 5 6 7 8 9 0 – =
    p l c d w ‘ u o y k q ” —
    n r s t m , a e i h v
    z j f g b ? . ( ) x

    This layout, in either configuration scores very well statistically—particularly in hand alteration, same finger strokes, and inward rotation. It scores less well in overall finger and hand balance, weighting the index finger slightly heavily (a common feature of many layouts). To that end I have developed other layouts which try to maximize overall balance to the cost of inward rotation and hand alternation (ASTHL and STNDC for example, available on Patorjk’s site for comparison).

    I have not posted this layout elsewhere. I have uploaded a number of variations on Patorjk’s site if anyone is interested (Balance Twelve, STNDC, HEIAMTSRN).

    I have compared Balance Twelve to MTGAP and, not surprisingly, they score very closely with Balance Twelve eking out the slightest advantage (I suspect solely on the basis of hand alteration). As you say, Michael, at a certain point in the process the cost of switching layouts outweighs any measurable benefit.

    That said, it would be nice to determine definitively which layout—statistically speaking—reigns supreme. I found in my own process that subjective assessment can contribute to determining which characteristics of a layout are preferable, but when it comes to assessing individual layouts one needs objective statistical analysis.

    Here’s to forming some consensus on which layout those of us interested in this rather obscure and pedantic predilection prefer—even if in the end, we each stick to our own pet favourites.

    • June 8, 2014 at 7:02 pm

      I replaced the en-dash (–) with a pipe (|) because the program can only handle ASCII characters right now.

      It looks like my program has a bug with the way it prints out individual statistics; I’ll have to see about fixing that. I only got the overall score to work right. For comparison, here are the scores for a few different layouts.

      MTGAP: 1737
      Balance 12: 1999
      Colemak: 2306
      Dvorak: 2472

      Overall, Balance 12 scores very similarly to my best layouts. The biggest difference is that Balance 12 doesn’t do as good a job of balancing the load on the weaker fingers.

      I’ll post a complete comparison once I fix the bugs in my program.

  19. Sasha Viminitz
    June 8, 2014 at 10:12 pm

    Michael,

    I agree, you get to the point where you either sacrifice inward rotation and hand alteration (as MTGAP does) or finger and hand balance (as Balance Twelve does, somewhat ironically). A given layout’s fitness score will then depend on how you weigh the scoring algorithm accordingly. I became fixated finding a layout that beat both Dvorak and Colemak on their respective strengths—inward rotation and hand alternation for Dvorak and Colemak’s incredibly low same finger count and low travel distance. Neither of these are particularly outstanding at distributing load over all fingers and so it was not a particularly constraining factor in layout design.

    An optimal finger balance would look something like 8-10-16-16 (in percent of total keystrokes) for both hands. For layouts that that optimize this distribution of load, try the following:

    / @ # $ % ^ & * { } [ ]
    V M H G P X L O U Y J + |
    S T N D C W R A E I _
    Z B K F Q ; : !

    1 2 3 4 5 6 7 8 9 0 ( )
    v m h g p x l o u y j = \
    s t n d c w r a e i –
    z k b f q , . ‘ ” ?

    again, with the “,” as a dead-key shift.

    Or this one, generated after seeing MTGAP seeking optimal distribution of finger effort.

    ( ) 0 1 2 3 4 5 6 7 8 9
    X C D R K B F U Y _ + |
    A S T H L M N E I O ”
    Z V G J Q P W : ; !

    [ ] # $ % ^ & * { }
    x c d r k b f u y – = \
    a s t h l m n e i o ‘
    z v g j q p w . , ?

    Both of these do a better job of finger load than Balance Twelve but they sacrifice other things.

    MTGAP does a very good job of balancing all factors but at the expense of inward rotation and hand alternation. Again, the importance of these factors remain open to debate.

    When we get down to the minutia, so much depends on the weighting of the scoring algorithm and the sample text used to evaluate a given layout’s fitness. Agreement on these weightings seems like a prerequisite to forming a consensus on best fit. I sought to resolve the tension between Colemak and Dvorak, and I think both our layouts do this admirably. But further distinctions among the myriad layouts, all of which perform admirably, seems like a problem of underdertimination. Any suggestions on how to have that discussion?

    In the end, we should have all likely thanked Dvorak for improving on Qwerty and then thanked Shai Coleman for improving on Dvorak and all left well enough alone. I now wish someone would just come along and say decisively, “This one.” Alas, that is not our condition.

    Thanks for the forum and the discussion. It’s been awhile since I’ve played among the keys.

    • June 8, 2014 at 11:58 pm

      But further distinctions among the myriad layouts, all of which perform admirably, seems like a problem of underdertimination. Any suggestions on how to have that discussion?

      I agree. To progress any further, I think we need more empirical data. Ideally, we could get groups of people and train them on keyboard layouts optimized for different combinations of factors and see which one performs best. I don’t know how we would do that though.

      Even more, I would expect each person to have a different optimal layout, since people’s hands work differently. Once layouts are this similar, the variation among them is as big as the variation between different people’s hands.

      I have a vision of the future where every child gets their own customized keyboard layout….

      • Sasha Viminitz
        June 29, 2014 at 10:40 pm

        Hi Michael,

        Did you ever get the full statistics on Balance 12? Since Andong’s layout analyzer (more detailed than Patorajk’s) is no longer taking new layouts, I’ve been using Parorajk’s for my analysis. Unfortunately it does not offer as detailed statistics as yours.

        When working on layouts, I realized the impact of sample texts. How did you resolve this in your program? I ended up generating a sample text based on word-frequency which generated letter and bi-graph distributions nearly identical with those of large corpus analysis.

        I remain skeptical of subjective weightings and so continue to look to the individual parameters rather than any overall fitness score. The optimization of each individual parameter is indisputable, and so the solution which varies least from these optimal solutions should govern our notion of best fit.

        As we said, once layouts are this similar, their fitness scores will have more to do with how we tweak the scoring algorithm than any objective measure of fitness.

        Still, it seems we can set certain limits or boundaries and optimize within them. I imagine by tweaking the settings on your program, one could determine the optimal layout for any one parameter: distance, hand-alteration, inward rolls, or what have you. You would then have a set of optimal solutions which would not be subject to any measure of “overall fitness”.

        Next, you could determine how far from optimal any solution might be for any given parameter. This could be expressed as a ratio over the optimal figure, yielding a standard figure of parameter result/optimal result. Adding these, you could determine the cumulative fitness score for any given solution, without weighting any particular parameter. The only question that would remain is which parameters to include in your solution set, but at least the optimal solutions would be explicit for a given set of criteria.

        Lastly, I did find a minor improvement in fitness according to Patorjk’s analysis tool. by making an adjustment to Balance 12. It’s layout is below. But I’ll stick to my “sub-optimal” solution for now and likely into perpetuity.

        \ / # $ % ^ & * _ +
        B Y O U @ V C D L P Q { }
        H I E A ; F S T R N K
        X [ ] : ! W G M J Z
        1 2 3 4 5 6 7 8 9 0 – =
        b y o u ‘ v c d l p q ” —
        h i e a , f s t r n k
        x ( ) . ? w g m j z

        • July 1, 2014 at 5:13 pm

          When working on layouts, I realized the impact of sample texts. How did you resolve this in your program?

          I collected a corpus of text from a broad range of sources. I talk about this more here.

          Next, you could determine how far from optimal any solution might be for any given parameter. This could be expressed as a ratio over the optimal figure, yielding a standard figure of parameter result/optimal result.

          That sounds like a really interesting approach. As you said, it still requires weighting each parameter to calculate the overall fitness, so I don’t know if this would actually work any better than the current way of scoring layouts.

  20. June 26, 2014 at 8:28 pm

    Two questions:
    1) how do I set the starting layout that the program uses? I can’t get it to start with e.g. Dvorak…… (I did surf, try and change all sorts of files, comment stuff out etc… to no avail. Please tell me what to do!) I want to optimize the 30 keys, shifted.

    2) is there a way to tell the program to optimize for alternation or for rolls? Or for some happy middle?

    Thanks!

    • June 26, 2014 at 8:49 pm

      1) You probably don’t want to do this. Right now the program always starts with a random keyboard layout. This allows it to explore the full range of possibilities. If it always started from the same layout, it would be more likely to get stuck with a sub-optimal result. If you really want to do this, you need to go to keyboard.c:initKeyboard() and remove the call to shuffleLayout(k). Then, in tools.h, change the definition of DEFAULT_KEYBOARD_30 to contain the keys for the keyboard you want.

      2) This is easy to do. Just change the fitness costs for alternation or rolls. You can change costs at run time by typing, for example, “set inwardRolls -5″ which sets the cost of inward rolls to -5 (i.e. fitness increases for every inward roll). Or you can permanently change the costs as they are defined in values.c:initCosts(), in which case you’ll have to re-compile the program.

  21. June 27, 2014 at 8:19 am

    Thank you Michael. I’m not @ my own pc right now, will try it out this weekend. Regarding question 1, I was suspicious because every time I run the program it gives the same layout. A fine layout, yes, but I wondered how random the starts were…….

    Does this mean that layoutStore.txt and fullLayoutStore.txt (spelling? I’m not seeing the program right now) are not being called by the program? I uncommented and commented some stuff there (using double slashes // ) , would I have to change anything there?

    If the program starts with a random keyboard, how would I force some keys in a position? Let’s say I want to force ?! in the top right. How would I do that?

    My language is Dutch. Which is close to German and (being a germanic language) also quite close to English. Still, spelling rules and words differ as well. For instance, the English word “the” is in Dutch “de”. The roll on many keyboards “th” is therefore less useful in Dutch.

    On letter-level, some of the more extreme differences are:
    Z: English 0,1% German 1,1% Dutch 1,4%
    K: English 0,8% German 1,4% Dutch 2,2%
    C: English 3,5% German 2,7% Dutch 1,2%
    Q English 0,1% German 0,02% Dutch 0,01%

    What this means is that QWERTY is bad in English, and slightly worse in Dutch. It alsow means that MTGAPx.x, Dvorak, Carpalx.x, Colemak, Asset are all large improvements over Querty, but being optimized for English they score lower in Dutch. But, as I said, much much better than Qwerty.

    I type most of my stuff in Dutch (90% ?) , some in English (9% ? like this post), and occasionally (1%) in other languages (German, French, Spanish, mostly in forums)

    And English optimized layout (such as your best layouts, or Colemak, or Dvorak, Klausler or others) will do fine for my use and be still much better than Qwerty. An alternative could be to optimize for my use, so make a blend of input (Ducth, English, German etc) and optimize for that.

    I chose a different compromise, namely to optimize for the most used (90%) language, Dutch in my case. Meaning that 90% of the time I type on the (mathematically) best layout, and 10% is on a suboptimal layout. The Dutch layout would still be good for English and German (and even for French and Spanish)

    The Dutch optimized layout looks good. I’ll post the layouts in the weekend. It had like 16% inward rolls and 4% outward, 0% home row jumps (!) and 45% same hand use. Yet, I was looking for some alternatives. Useing a different starting point or different optimization rules (more alternation for instance) might give me some alternatives.

    Is there a way to see “near solutions”? The solutions that the program doesn’t spit out because they are not signifficantly better, can we see those “near solutions”?

    Sorry for the rambling

    • June 27, 2014 at 4:54 pm

      I was suspicious because every time I run the program it gives the same layout.

      That’s actually a good thing—it means the program quickly converges on the optimal layout. If you try to optimize one of the larger keyboards (standard or kinesis rather than main30), this probably won’t happen since the search space is so much larger.

      Does this mean that layoutStore.txt and fullLayoutStore.txt are not being called by the program?

      If you use the “compare” utility, it pulls keyboards from those files. The optimizer still starts with random layouts.

      If the program starts with a random keyboard, how would I force some keys in a position? Let’s say I want to force ?! in the top right. How would I do that?

      That’s a bit tricky. There are two ways to do it: either you can add a penalty for putting ?! in the wrong place, or you can actually force it to go in the right place. For the first method, you can add a penalty by adding a new function to fitness.c. Look at calcShortcuts() and calcQWERTY() for examples of similar things to what you’re trying to do.

      For the second, look at the top of keyboard.c for legalBox[]. Two keyboard positions are only allowed to swap if they have the same number in the legal box. Change legalBox or add a new one to do what you want. Make sure you search the code for where legalBox appears to make sure the code is using the correct legal box.

      I think the second method will be easier, and it seems more like what you’re trying to do.

      Is there a way to see “near solutions”? The solutions that the program doesn’t spit out because they are not signifficantly better, can we see those “near solutions”?

      Every time it comes up with a new best layout, it prints it. So you can see all of the previous-best layouts it came up with. It runs the optimizer a bunch of times and only prints the result if it comes up with a new best layout, but you could have it print the result every time. In cjalgorithm.c:runAlgorithm(), you’ll see there’s an if statement:

      if (arg.bestk.fitness < prevBestFitness)

      And then it calls printPercentages() in the body of the if statement. If you move printPercentages() outside the if statement, it will print the best keyboard for every round instead of just when it finds a new overall best.

      I’d be interested to see the Dutch layout you come up with!

  22. Pieter Hogendoorn
    June 28, 2014 at 12:30 pm

    Thanks for the fast answers, Michael! This morning it comes with slightly different solutions.

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

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

    Hands: 55% 44%
    Fingers: 9.0% 10% 21% 16% 0.00% 0.00% 16% 11% 9.0% 8.0%
    Fitness: 3885
    Distance: 4520
    Finger work: 0
    Inward rolls: 18.63%
    Outward rolls: 4.41%
    Same hand: 45.59%
    Same finger: 0.00%
    Row change: 8.82%
    Home jump: 0.00%
    Ring jump: 0.00%
    To center: 0.49%
    —————————————————-^

    —————————————————-v
    This one is nice as well.

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

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

    Hands: 42% 57%
    Fingers: 9.0% 9.0% 11% 13% 0.00% 0.00% 17% 22% 9.0% 9.0%
    Fitness: 4026
    Distance: 4550
    Finger work: 21
    Inward rolls: 19.12%
    Outward rolls: 2.94%
    Same hand: 46.08%
    Same finger: 0.00%
    Row change: 9.31%
    Home jump: 0.00%
    Ring jump: 0.49%
    To center: 1.47%
    —————————————————-^

    —————————————————- v
    A few days ago I found this one (I didn’t write down the metrics, but it was good as well). Dutch corpus.

    ?SCHJ :KLVB
    ADENP GITRO
    UZY WMFXQ

    .schj ;klvb
    adenp gitro
    u/,zy wmfxq
    —————————————————-^

    • Pieter Hogendoorn
      June 28, 2014 at 12:31 pm

      —————————————————- v
      Two more variants:
      J S C H , ; L K G B
      A D E N P V R O I T
      U X F Q

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

      Fitness: 3905
      Distance: 4590
      Finger work: 0
      Inward rolls: 19.12%
      Outward rolls: 3.92%
      Same hand: 45.10%
      Same finger: 0.00%
      Row change: 7.84%
      Home jump: 0.00%
      Ring jump: 0.00%
      To center: 0.98%
      —————————————————-^

      —————————————————- v
      J S C H , Y K L V B
      A D E N P G I T R O
      U ? X Z M W F Q

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

      Fitness: 3885
      Distance: 4540
      Finger work: 0
      Inward rolls: 18.63%
      Outward rolls: 4.41%
      Same hand: 45.10%
      Same finger: 0.00%
      Row change: 8.33%
      Home jump: 0.00%
      Ring jump: 0.00%
      To center: 0.49%
      —————————————————-^

      —————————————————- v
      Two layouts with a mixed Dutch/ English corpus (sorry, no metrics) :

      .gscwhkv
      oadeu ltnir
      xjyfq bmp:z
      —————————————————-^

      —————————————————- v
      fpuwj .gshk
      atec lroid
      xy
      —————————————————-^

      Question is: why is the , sometimes in the shifted layer? Also, what does “finger work” mean ?

    • Pieter Hogendoorn
      June 28, 2014 at 12:33 pm

      That last one should be
      —————————————————- v
      fpuwj .gshk
      atec lroid
      xy
      —————————————————-^

      All layouts have great rolls. For instance “tien schapen lopen” (ten sheep walk). Very common words in Dutch are de and en (meaning the and and).

      I guess I’ll have to try some, to see which one feels best.

    • June 29, 2014 at 5:08 pm

      It looks like there’s a bug in the way it’s calculating same finger. It always says same finger is 0.0%, which is clearly not true.

  23. July 18, 2014 at 11:13 am

    After more analysis I came up with this one (ps, now logged in as myself). My corpus is 85% Dutch and consists of reports I wrote, forum postings, some emails etc. About 12% is English, from Wikipedia, forums, weblogs and so forth. The rest is a bit of German, French and some slivers of Spanis and Italian, languages I use – very – occasionally.

    The layout is appealing. I call this one Juli16, after the day and month (Juli, as we call it in Dutch) it was born… :-)

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

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

    Hands: 57% 42% Fingers: 9.0% 10% 22% 16% 0.00% 0.00% 14% 12% 10% 8.0%
    Inward rolls:7.54%; Outward rolls: 2.94%; Same hand:36.39%; Same finger:1.46%; Row change:12.27% Home jump: 0.66%; Ring jump: 1.44%; To center:3.94%

    The balance could be better: the left middle finger, and hence the left hand, has a lot to do. But, as you can see, most other stats are very good; a nice alternation, rolls, low home jump count.

    The remarkable thing is: I compared in (in Patorjk) to three other good layouts: Colemak, Dvorak and Balance12 (hi Sasha Viminity!) . For various languages. These are the winners – according to patorjk’s algorithm.

    For Dutch: winner is Juli16
    For German: winner is Juli16
    For French:winner is Juli16
    For Italian: winner is Juli16
    For Spanish: winner is Balance12. Number 2 is Juli16. Dvorak and Colemak rank 3 and 4.
    For English: winner is Balance12. Number 2 is Juli16. Dvorak and Colemak rank 3 and 4.

    The funny thing is that French scores very well in Juli16, better than English, although there was much more English in the ‘source corpus’ for which the layout was optimized…. This is partly to be expected: there are not many French words in Dutch, but there are in English. And partly it is good luck I suppose. I did some rough ‘post mortem’, LOL analysis based on http://www.mcld.co.uk/decipher/french.htm If i compare the most used digraphs and trigraphs in French and compare it to the Juli16 layout, it turns out that the nice roll EN is in Frenche the second frenquent used digraph (for the record, ES is the most used in French). OU is on place seven; AI on place eight.

    If we look at the 10 most used French tripraphs in order of frequency, we see that 7 of them are nice to type on Juli16, 2 are ok and one is bad; all based on subjective judgements by me. ENT:good QUE:bad EST:good LES:ok ION:ok AIT:good TRE:good AIS:good OUR:good MEN:good

    Now it’s time for live testing and learning. Later on I will implement some other ideas, such as making the key of q type qu This is one nasty home jump less, and in the languages I use, q is always followed by an u.

    tl;dr Qwerty sucks. Dvorak and Colemak are way better. Balance12 is even better. The best one however, for *my* uses, is Juli16. Juli16 consistently beats Dvorak and Colemak and scores number one for Dutch, German, French and Italian, and number two for Spanish and English – hot on the heels of Balance12.

    Thank you Michael Dickens for your research and nice mtgap software.

    • July 18, 2014 at 5:32 pm

      Interesting that Juli16 has the relatively-common OU digraph has a hand roll on the top row. You hardly ever see rolls not on the home row.

      This layout looks strong overall, but I’m a bit puzzled as to why it put D on the home row. I think it makes more sense to put H on the right index and then T on the right middle finger. Perhaps TH isn’t a very common digraph in Dutch?

      • July 18, 2014 at 7:51 pm

        Actually it also has the CL outroll and the BL inroll on the right top!

        My frequencies (absolute numbers). For comparison:
        1. n[space] 26370
        2. e[space] 25488
        3. en 24772
        4. er 19054
        5. in 15530
        6. de 15348
        7. an 15059

        30. th 7512 So th is digraph number 30 in Dutch, so not very common.

        The D is common. In digraphs:
        6. de
        9. [space]d
        25. d[space]
        27. nd

        And in characters. Space is the most common character, the top 20 is as follows:
        153014
        e 131661
        n 75812
        a 64661
        t 62001
        i 61617
        r 55141
        o 54372
        s 43318
        d 39204
        l 31717
        c 23156
        m 22053
        g 22024
        h 21980
        u 17724
        p 16980
        v 15756
        k 13952
        b 13210

        So d (39,204 occurences in my corpus) is nearly twice as common as H (21,980). In conclusion: d is much more common than h, and th is a quite rare digraph in Dutch – and remember that my corpus has parts of English in it – reflecting my use of languages on the keyboard. in pure Dutch the th use would be even lower.

  24. July 18, 2014 at 7:52 pm

    I/m sorry about the username confusion. Google (plus) and WordPress don’t always work well together it seems – maybe I’m doing it wrong ?

  25. pieterhog
    July 20, 2014 at 7:27 pm

    And by pure coincidence, it’s remarkably like a Dvorak mutant. This was never a goal, but it turned out like it.

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

    Dvorak:
    ‘ , . p y f g c r l
    a o e u i d h t n s
    ; q j k x b w mv z

    Meaning that the good Dr. Dvorak did it very right, in his day :-)

  1. October 28, 2012 at 3:18 pm

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Follow

Get every new post delivered to your Inbox.

%d bloggers like this: