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
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%
Mathematical Multicore 
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!
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.
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.
Why no mention of Maltron?
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.
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
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/
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?
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.
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?
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.
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.
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
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!
Okay, thanks. I’ll look into it once I get a chance.
Hi, you haven’t had a chance, have you?
Thanks for checking back with me. I’ll try to look into it within the next few days.
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
Ok, thanks.
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?
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_30which 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.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.
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.
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.
Feel free to submit it yourself. I’m calling it MTGAP.
Was just attempting to plug-in Arensito into the Patorjk Keyboard Layout Analyzer and became curious; Is there an optimized AltGr layer for MTGAP?
I actually did create an AltGr layer about six years ago: http://mtgap.bilfo.com/completed_keyboard.html I used it for a while but I stopped. I found that, while it was quite comfortable, it was too slow to have to hit an extra key. I haven’t made any updated versions.
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.
That’s fine. That’s more or less the configuration I’m currently using.
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.
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. 🙂
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.
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…
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.
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!
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
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.
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.
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.
Hi
Just curious, where do these single-scores come from? Or will I see that when I run your program (as opposed to all the stats listed in your main post)?
thanks,
Yes, you’ll see them. The actual score is many more digits but I truncated them. The score is calculated as a weighted average of all the different penalties (as described here).
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.
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….
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
I collected a corpus of text from a broad range of sources. I talk about this more here.
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.
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!
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.
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
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.
If you use the “compare” utility, it pulls keyboards from those files. The optimizer still starts with random layouts.
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.
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:
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!
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
—————————————————-^
—————————————————- 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 ?
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.
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.
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.
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?
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.
That actually makes sense then. According to http://www.letterfrequency.org/, NTRDS are the most common consonants, and those are the ones on your home row.
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 ?
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 🙂
After a holiday I am now back, learning two things at a time: touch typing on a new layout – and this after 25 years of qwerty “hunt & peck”. Which, to put it mildly, requiers a lot of dedication. Put less mildly: ¡qué chingada!
I must say though that I am happy with the layout, hard as it is to learn.
A big “thank you” to Michael Dickens (for sharing research & software) and to the people behind/active on
– mkweb.bcgsc.ca/carpalx/
– patorjk.com
– colemak.com
Quick note: patorjk.com’s layout analyser’s consecutive finger use measurement is flawed. Specifically, it does not properly calculate where R.Shift and Enter keys are used. For example, use capital-A capital-P Return capital-A capital-P as your text input. With qwerty this should be six consecutive finger uses (R.Shift A, 0; L.Shift P, 2; Return, 3; R. Shift A, 4; L.Shift P, 6). It only counts as four.
Ok, apologies, but attempts at getting a wide mod optimization to run failed spectacularly.
Current project is optimization of an office mousing and gaming friendly layout. Considering past failure to make sense of the program: How would I set a mask for the first 4 columns (q-r, a-f, z-v) plus number row? … or if any one is feeling particularly generous (I hate to ask this way); what is the result?
What do you mean by “set a mask”?
Wow, that was fast!
As for mask, I mean a way to set an area as unmovable, uneditable or ignored. For instance, applying a numberbar mask and zxcv mask would tell the program to leave those two keys locked in their starting position and optimize the rest of the layout around them.
I’m looking to optimize the main 30/31 keys right of the 4th column. … actually, to be specific, I’m looking to create an optimized layout that leaves the lefthand shortcut and gaming keys roughly in the same area, around a W-ASD or AWD-S cluster. I figure I can do most of the left hand manually. Pinning down T-P, G-‘, and N-. would be a big help though.
(A more advanced version would be to fix the WASD cluster in position , then mask it and everything to the right of the 4th column; optimize; then optimize the resulting layout again, masking everything left of the 5th column.)
Also, sorry about asking for asking for someone to run the optimization for me. It’s just the frustration talking. I’m not used to being quite so lost.
That’s actually pretty easy to do. If you look at the top of keyboard.c, you can see a bunch of boxes named legalBox.
In those boxes, each position corresponds to a position on the keyboard. Any two positions that have the same number may be swapped with each other, and positions that have different numbers may not be swapped. So you can just create a box where every key you want to keep in place has a unique number. Then do a find/replace in the files to find wherever legalBox/bigLegaBox/kinesisLegalBox gets referenced and replace it with the name of your box.
If that’s still unclear or you have any more questions, let me know.
Ok, had some problems, but then I tried running the ‘make’ command AFTER editing keyboard.c. Then it worked.
I didn’t even try making a new legalbox, just edited the default.
While it is running an optimization now, I still haven’t figured out how to run an optimization starting from a specific layout. Improve seems to just run until the layout is “improved”, then stops. Running it several times will get you different results. I don’t know what the purpose of the Use command is, as it doesn’t seem to do what I think it should. I’m not really sure why the program started doing what I wanted it to do. Maybe ‘improve’, then ‘run’?
Ah, nevermind. I got it working.
Results of gaming friendly optimization, by placement of WASD:
*R-DFG keys had the best scores, but would make gaming awkward, with long reaches for shift, tab and ctrl.
*W-ASD staying right were it was turned out surprisingly well, giving the second best fitness score of the bunch. E obviously gets placed on the F key, so it ends up with a rather high samefinger score. Increasing the weight of the sameFinger variables gave a very different result, cutting down the samefinger to managable levels but hammering fingerwork score.
*E-SDF keys forced E onto the A key, which more or less killed the fitness score.
*E-ADF puts an awkward strech on the ring finger, so I did not test it.
*W-ASF ends up being my preferred version. The extra reach to D is tollerable for gaming, and putting the D on the F key keeps the samefinger scores down, if not low. Higher travel distance than the WASD layout, but the lowest fingerwork score.
WASF (Basic Punctuation)
Hands: 48% 51%
Fingers: 8.0% 9.0% 14% 17% 0.00% 0.00% 20% 11% 12% 9.0%
XWFCY ;MUP.
ASEDG LNITO
QVZRJ BH,K/
Fitness: 19091132
Distance: 12446080
Finger work: 50182
Inward rolls: 6.96%
Outward rolls: 4.85%
Same hand: 50.07%
Same finger: 2.72%
Row change: 26.83%
Home jump: 1.59%
Ring jump: 3.18%
To center: 6.55%
You’ll notice quite a few seemingly arbitrary key placements; where a minor tweak will put them into a more familiar arrangement, AND give better scores, such as:
Hands: 48% 51%
Fingers: 8.0% 9.0% 14% 17% 0.00% 0.00% 20% 11% 12% 9.0%
QWFRY ;MUP.
ASEDG LNITO
XVZCJ BH,K/
Fitness: 19210552
Distance: 12266910
Finger work: 50182
Inward rolls: 7.15%
Outward rolls: 4.88%
Same hand: 50.07%
Same finger: 2.72%
Row change: 26.43%
Home jump: 1.18%
Ring jump: 3.18%
To center: 6.55%
Too much tweaking, on the other hand, and you end up re-implementing qwerty errors.
If only I didn’t need that damnable E on the left. But without it I’d more or less be recreating Colemak.
David, I don’t completely get what you are trying to achieve. Do you want to keep the qwerty rows qaz. wsx, edc fixed and optimize the rest of the keyboard? Or do want to keep these letters in the first 3 columns, but not necessariliy on their exact qwerty-positions? Or do you wish to keep asdw in its exact qwerty-position, and optimize the rest of the board?
In your layouts the crucial (or not?) letter D moved, as well as zxcv.
You know that some games are programmed wrong, in the sense that they use the scancodes instead of the letters that are mapped to those keys. In other words, they use for instance “the key under the 2 and 3” for “arrow up”. Regardless if you mapped a W or a different letter to it… So the safest thing is to keep the much used letters at their exact qwerty locations.
Also, how important is (whole) keyboard optimalisation for games? In which you use only a few keys, most of the times, and in which you don’t input lots of text… ? But then again, I do not completely grasp your goals!
You could of course use a qwerty keyboard for games and an MTGAP board (layout programmed in the controller) for other stuff…. . just a thought!
I wouldn’t call the layout Goal Driven. It is more of an exercise. “What is the best layout we can get, with XYZ as a limitation.” In this case, ‘XYZ’ is keeping the keys left of the center (TGBYHN), left of center; and keep a loose, but tolerable WASD block.
As such, D moved, and ZXCV got scrambled. That QRG stayed in their Qwerty positions and ZXCV remained on the bottom row was more of a happy coincidence than anything. The original optimization called for (top to bottom) XAQ on L.Pinkie and CDR on L.Index; but swapping them back to their Qwerty rows decreased home row jumps and increased inward rolls.
As for having multiple keyboards… um… no? That sounds incredibly irritating. The only keyboards I know that allow reprogramming the controller are the Gateway Anykey and the Kinesis Advantage. Neither are available to me. That means an external hardware solution, or software. OSes usually don’t distinguish between two inputs of the same type, so you either constantly swap your layout through system settings (ick), an keyhook application like AHK (tried it, causes conflicts; so, not much better), or you need some sort of external programmable interface. Low demand means it is a DIY job. Double Ick.
I stumbled upon a very recent, different layout for the Dutch language. It was calculated by Martin Krzywinski (the man behind the Carpalx website) by request of the Dutch online magazine [i]De Correspondent[]/i, who would like to (quote) “allow their reporters to spend more effort on the stories and less on typing” (unquote). The story in De Correspondent is about path dependency, why qwerty is dumb, and then in presents the alternative “dutch language specific” carpalx layout.
That layout is (as always with the carpalx layouts) nothing like neither qwerty nor dvorak. This in contrast to MTGAP layouts that look a bit like Dvorak… Anyway, here it is. For comparison my Dutch optimized layout (as calculated with the MTGAP software) is below it.
carpalx, Dutch
Q F K L M W V U J Y
S D T N R I A E O G
; Z B H X P C , . /
my layout, Dutch
. 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
Similarities:
– most of the homerow (duh…)
– all vowels on one hand (carpalx puts them on the right side, I on the left)
Differences:
– I don’t see as many nice rolls in carpalx, although this is often hard to see, you have to really use the layout.
– carpalx puts O and G under the home row fingers, at the expense of R and I
– carpalx gives ; its own key, in my layout the more used : has it’s own key, ; is in the shift layer
– carpalx puts Q, Y, J and F in “too good” spots. On the other hand M and W are (in my opinion) in too bad spots.
– why keep , and . in their qwerty spots?
Anyway, all this is based on arm chair theorizing! I am happy to see a magazine write about our “fringe” hobby of custom layouts, and I’m happy that we now have several layouts for the Dutch language to chose from. I like my own “Dutch MTGAP” a lot and I suspect that it will be superior to ‘Dutch carpalx”, but I am curious enough to try that other layout out. Maybe it feels good and my critisism is all wrong 🙂
By the way, I have baptized my dutch mtgap layout the “[b]HERMANS layout[/b]”. Why?
– HERMANS can be written on the home row
– it is an hommage to W.F. Hermans (1921–1995), one of the greatest writers in the Dutch language
– He has lived in Amsterdam, Paris and Brussels; my layout does very well for the languages spoken there – Dutch and French (and German as well, which is also a – small – language in Belgium)
– Hermans was a typewriter-geek, he left a collection of 160 typewriters. Pic here: http://goo.gl/KH792F (for his work he only used one machine though: a red, electric IBM typewriter)
[b]- so all in all HERMANS is a fitting name for my AIENHMDRTS layout ![/b]
Ok, got two… three… no, four questions this time.
1) Are the variables defined somewhere? I have no idea what entries like handWarp and handSmooth are supposed to be.
2) Can the keepQWERTY penalty be increased?
3) Can custom variables be added? Or tweaked? I’m looking for a way to add a metric finger frequency. Consecutive-finger might be a great metric at lower typing speeds, but as you start typing faster, a single keypress of separation is not enough time to position fingers for the next keystrike.
So what I am looking for is a metric based on finger travel distance (previous key on that finger to current key, do not count travel back to home) divided by time (measured in keypresses). Then, penalize accordingly.
For example Qwerty ED has a travel distance of 20mm over 1 keypress = call it 2.0X penalty rate. FoR has a L.I. distance of 20mm over 2 keypresses = 1.0X penalty. TuRn: L.I. distance 19, time 2; UN R.I. distance 39, time 2. = 0.95X + 1.95X = 2.9X Penalty. ETC.
Part 2 of the same question is where do I start looking in the code?
4) … I’ve forgotten what question 4 was. Well, if it is important it will come back to me.
1) Variables are defined near the bottom of values.c.
2) Yes. In values.c, increase the value of
.
3) You can do this, but it’s a lot more complicated. In fitness.c, you can see the definitions of all the current penalties. You can define a new function
. Then look for the places where
and the other functions are called, and add in your function. The main place is in
.
The main problem here is that the program is only set up to compare pairs of keys (digraphs), and it sounds like what you want to do requires comparing longer runs of keys. The program works the way it does because it runs a lot faster. I have thought about adding code to support trigraphs as well as digraphs, but it hasn’t seemed worth it. If you want to add support for longer runs of keys, that would be great and I’d love to see what you come up with. But it’s a pretty substantial undertaking that will probably take 5+ hours of programming.
Thanks for the info! I was hoping the tweak would be easier, but the difficulty level you describe was expected. *sigh* not going to finish this project anytime soon.
As for the Variables, thanks for pointing out where the default values are stored. Notepad++ ‘find in files’ was not as helpful as I thought it might be. … the thing is, I still don’t know what some of them actually represent. What is ‘Hand Smooth’ or ‘Hand Warp’? For that matter, what is ‘double jump’? Is that a digraph with Number row and Bottom row?
@ dave – you may look at a different project, adnw.de (there is also a google group ADNW). ADNW stands for Aus Der Neo Welt, which is on Patorjk if you wan to take a quick look. In their program (written in C++) there is a possibility of running trigrams, which does give slightly different layouts. I’m not sure if they calculate ” indirect same finger”, which is what you are looking for.
Trigram optimization is good for preventing too long strings of letters on one hand.
The goals of MTGAP and ADNW are different. Both are great programs and valuable websites by the way ! Mtgap seems more geared towards nice rolls, and preventing “waves” on the keyboard (like qwerty adsd or were). Adnw has (I think) no attention for preventing waves, but it does focus on alternation and preventing neighbouring key strokes, especially on pinky and ring. So qwerty as is worse than ad. This is the opposite of the Colemak goal, Colemak prefers as over ad. What Colemak, Mtgap and ADNW have in common is the preference of inward rolls over outward rolls.
A minor difference (adnw – mtgap) is the distribution over fingers and preference for home and top row. Mtgap favors the top row and pinky use more than ADNW does – and i agree with Mtgap in this. This is easy to tweak though.
Optimization software is a rabbit hole, I found. Do I optimize for Dutch (which I type most)? Then I get a layout which is not so good for English (relatively, it’s still better than Dvorak, let alone Colemak which is not very good for my language). Or do I optimize for a mix of languages that reflects my use? This means that overall my keyboard is optimal, but also that in my most used language I type on a suboptimal keyboard.
For multi language (or text versus coding) there is also the question of special keys. Do I want ñüäöß keys? Means I have to give up nice keys as /?’]
Do I optimize for maximum inward/outward ratio? Then I have to accept a higher more same finger %. Or a larger distance. Etc. Do i WANT or should I prevent neigbouring keys (a.k.a. rolls)?
I the end, testing out is the best. The AIENHMDRTS layout in my post above is very good, but.. has some long strings on the left hand. It feels like doing too much work with the left hand. That’s why I started tweaking it, and also I started making ANDW layouts.
@dave, back to your question: go to adnw.de, download the program and look into the code to see if you find inspiration for your tweaks to the mtgap code. The ADNW code is well annotated, so even if you don’t know much of C++ it may be useful.
@michael: hope it’s OK to mention alternative solutions? also, correct me if I’m wrong on the goals of the programs. Thanks!
Ok, turns out I was just thinking about trigraphs the wrong way. The work around is; you take your corpus, set a marcro to delete every other character, then paste the resulting text at the bottom of the original text. Boom! Trigraphs, automatically scaled at 50% weight of digraphs.
Next problem: where is the tool for generating character/digraph files? I’d rather not have to run a count and enter the data for every character and digraph individually.
I hadn’t actually publicly released the program I used to generate character/digraph files until just now, and it’s not really set up in a way that’s easy to use. I just uploaded it to GitHub (https://github.com/michaeldickens/Frequency). I really should refactor it to make it easier to use, but in the mean time, you can look at it and see if you can get it to do what you want.
Thanks! I’ll take a quick look and-
…be completely stumped. Apparently.
Ok, not a problem. If I can’t sort it out I’ll just move on to Plan B. Wrangle something up in Autohotkey. Or maybe Excel. Spreadsheets are awesome.
I’m back! I may have mentioned this in one of the previous threads, but back in July 1960, an article was published in The Bell System Technical Journal titled
“Human Factors Engineering Studies of the Design and Use of Pushbutton Telephone Sets
By R. L. DEININGER.”
This article (available here: http://www.beatriceco.com/bti/porticus/bell/pdf/touchtone_hf.pdf ) gives a pretty in-depth description of the experiments done that resulted in the familiar 3×3 + 1 number format used in touch tone phones (and later, smartphones).
Several interesting facts emerge. First, they tested a lot of formats (the stairstep, the rainbow, the circle, the cross — well, read the article and see the 16 types they tried out).
Second, the calculator number pad layout (789 456 123 0) is measurably inferior to the touchtone layout (123 456 789 0), at least among people unfamiliar with either, though the difference was small.
Third, and most interesting to me, *the 3×3 plus 1 touchtone layout was not the layout most preferred.* Out of the five top designs, two horizontal rows of five keys (they tested 12345 67890) had the most preferred votes (the touchtone layout was third), and forth in “least preferred” votes (the touchtone format had the second highest “least preferred votes). Interestingly enough, while two horizontal rows was the most preferred, two vertical rows were the least preferred.
I do wish they had tested formats with 0 next to 1 — 01234 56789 rather than just 12345 67890 — because having the most common numbers on the numeric keypad “home row” might be advantageous for data entry, especially with Enter or Shift/Function under the thumb instead of an enlarged 0 key.
Have you tried your code to optimize the numeric keypad? For example, using the numbers and functions available on the 22-key Goldtouch GTC 0077 keypad (picture here: https://cdn.shopify.com/s/files/1/0274/7747/products/gtc-0077_ad457c48-3bba-4a2c-a707-73027bc182ba.jpg?v=1389210920 ) and trying different logical groupings of numbers and functions to see which scored best (you want some sort of numeric order, of course, having the numbers scattered all over isn’t good even if it scores well, and +-/* probably should be together).
I’ve never tried optimizing a numeric keypad, although it wouldn’t be too hard to adapt my program to do that. I think the major limiting factor for keypads isn’t typing efficiency but ease of learning. Numbers have a clear logical ordering (0123456789 or 1234567890), and a keypad should respect that ordering. A hand-designed keypad will probably produce better results. The most relevant fact is that 0 and 1 are the most common numbers, so they should be the easiest to press. The layout of the arithmetic keys probably doesn’t matter much.
I keep coming back. 🙂 On Geekhack, a person posted a link from the Department of Economics, University of Strathclyde, in Glasgow, Scotland, titled “QWERTY AND THE SEARCH FOR OPTIMALITY.” Here is the link: http://www.strath.ac.uk/media/departments/economics/researchdiscussionpapers/2013/13-24FINAL.pdf
The paper covers not only the thought that went behind Christopher Latham Sholes’ original QWERTY layout (adjacent typebars in the type basket tended to jam, so keep common pairs apart), but of a later version he came up with, plus a tweak to that version that makes it even less likely to jam. What’s really interesting to me is that it converts a two-dimensional keyboard to a 1-dimensional puzzle (or a circle, anyway), where you really have to consider only the keys immediately to the left and right in the type basket. It makes me curious if there is a keyboard that is “Sholes’ optimal” (least likely to jam in a mechanical format) as well as close to ergonomically optimal (common keys on the home row, few row changes, plenty of nice rolls to the center of the keyboard).
Here is Sholes’ later layout:
2 3 4 5 6 7 8 9 £ & Z
X P M C H R T N S D G K
J B W F L A E I O U Y
Q V : ; . , ! ? – | _
(Actually, the | at the bottom is three dots in the image. Not sure what that is.)
Here are two alternates that are a tiny bit better under Sholes’ criteria, according to the paper’s author:
2 3 4 5 6 7 8 9 £ & Z
Y P G C H R T N S D M K
J F W B L A E I O U X
Q V : ; . , ! ? – | _
(Swapping Y and X, F and B, M and G)
2 3 4 5 6 7 8 9 £ & Z
Y P M C H R T N G D S K
J F W B L A E I O U X
Q V : ; . , ! ? – | _
(Swapping Y and X, F and B, G and S)
Like many early keyboards, the number 1 (one) was replaced by a lower case L (l) , and zero (0) with capital o (O). Just so there is no confusion on why it was missing some numbers. The spacing is kind of weird, but I hope it’s clear enough, and the pictures in the paper are much better.
This is pretty cool! It should be feasible to modify my optimizer program to create a Sholes optimal keyboard: just modify the scoring function to add a penalty for common pairs of keys being next to each other.
I’m guessing a Sholes optimal keyboard would look similar to Dvorak, since optimizing for hand alternation is similar to optimizing for keeping key pairs far apart. The layouts from that paper look pretty bad though–they put all the most common keys (ETAOINSR) on the right hand.
Exactly, the layout gets it halfway right! Interestingly, Sholes Later has 11 letters on the home row, which is better than standard Sholes, that only has 9 letters on the home row. Also interesting is how many lettersSholes puts on the top row, and even one letter (Z) on the number row. As a consequence, there are only 2 letters on the bottom row.
This fits in the theory that on a typewriter, the bottom row is harder to hit that than the top rows. Whereas many people feel that on computer keyboards, the top row is easier than the bottom row.
Let’s compare ” Sholes Later” to AdNW (which is a sort of “Dvorak on steroids”).
xpmch rtnsdgk
jbwfl aeiouy
qv:;. ,!?–|_
kuü.ä vgcljf
hieao dtrnsß
xyö,q bpwmz
Like Michael says, Sholes has all the frequent letters on the right hand, which kind of sucks. This would be an improved version (let’s call it SH Improved) (also I could no tresist swapping D and R)
xpmch *jbwflk
aeiou dtnsrgy
qv:;. ,!?–|_
I’m not at my own computer now, so I have to use a web analyser (patorjk.com). For fun I compared Qwerty with Sholes later (jbwfl aeiouy), with an improved version of that (aeiou dtnsrgy) and with a very good keyboard (Mtgap, the older version that’s in patorjk.com). Text: Alice in Wonderland (complete book). The results:
– SH is *worse* that Qwerty. Important culprit is the overload of the right index. No wonder, that one finger types A E R T
– SH Improved is slightly better than Qwerty
– of course MTGap is far, far better.
All in all the typing world would not have been better with Sholes newer versions.
Ok, so I finally decided to sit down and make some progress on Trigraphs. Or, Secondary Samefinger as I’ve taken to calling it. An example would be RaT, KnIfe or HaNd on Qwerty; where the same finger is used one character apart on a different key.
Using an admittedly very limited American-English prose only corpus, locking punctuation & ZXVC (vc swapped to represent typing ZXCVB with Ring Middle Index Index Index) and ramping up samefinger penalties – the optimizer came up with this:
LRM (temp.)
LRMGQ JFOUY
SNTDW BHAEI
ZXVC: KP?
lrmgq jfouy
sntdw bhaei
zxvc; kp,./
Distance is just a bit worse than Colemak, SameFinger is just a bit better, and Secondary SameFinger is about 30% less. Hand Alternation is at least in the same ballpark as Dvorak, and rolls are about 4.1% inward and 4.2% outward.
It is funny how that hated Dvorak LSZ combo shows up. Also RN. Which means a lot of Dvorak style heavy Ring and Pinkie use.
So, a good start, but plenty of room for improvement.
For those who are curious, the method is; 2x Corpus, 1x Corpus deleting even characters, 1x Corpus deleting odd characters. Paste together and feed into layout tester of your choice.
Example:
The quick brown fox jumps over the lazy dog.
The quick brown fox jumps over the lazy dog.
Teqikbonfxjmsoe h aydg
h uc rw o up vrtelz o.
Question: Is the original Keyboard Layout Project corpus available somewhere? Not the frequency tables, but the bodies of text themselves.
Very cool, Dave! I like your technique for testing trigraphs.
Unfortunately the original corpus I used is not available because it contains some private texts. I had thought about trying to find an official corpus–my original reason for not doing this was that corpora tend to use just books and I wanted to include other kinds of text like informal writing, but there are modern corpora that include informal writing too. It hasn’t seemed worth the effort, but if I were starting over, that’s what I would do.
I wrote a script https://github.com/michaeldickens/Frequency which converts text files into a frequency list. If you can get a corpus, you could use this program to generate trigraphs.
Well that was a bit of a surprise, had forgotten I was subscribed to this. Any I have been working with Den (shenafu.com) and come up with some layouts which score well on Patrick’s analyzer, in particular on Den’s alternate scoring. It seems as if Patrick’s scoring rewards you for using AltGr as in Arensito, so Den modified the scoring to include both horizontal as well as vertical distance travelled.
I’ve got a site which compares the various layouts on various tests… those of Patrick plus a lot more I added. http://www.keyboard-design.com under the Best Layouts section.
The current best-scoring layouts are using the Arensito approach, with some twists. The idea is that one thumb lives on AltGr, so does not have to move to use it. This required a new physical layout, since ANSI/ISO sucks for something like this. ErgoDox/Kinesis is doable but key layout is not optimal for reducing finger travel.
Comments on the layouts welcome. The comparison charts may require some time for you to be familiar with pulling results from the database.
There are links to a forked version of Patrick’s KLA, mainly so that you can see the various layouts and play with them. Not trying to duplicate Patrick. Also the fork uses Den’s scoring, not Patrick’s.
BTW speaking of Arensito, the version on Patrick’s site is missing two characters, which affects scoring.
The sections with Patrick’s scoring are not as complete as with Den’s scoring, I need to add the new physical keyboards and then run all the tests. Will take a while.
Cheers, Ian
PokerHouse – poker house school pokerdom http://poker-house-school-pokerdom-45.pokerdom-power.ru – Click here!
Would you like to submit your ad on 1000’s of Advertising sites monthly? One tiny investment every month will get you virtually unlimited traffic to your site forever!To find out more check out our site here: http://lotsofadsposted.ddns.net