How to calculate the ideal keyboard layout for programmers?

I'm thinking about creating a new keyboard layout for programming. Now I mostly program in HTML, JavaScript/jQuery/CoffeeScript, CSS/LESS/SASS, though I may dabble in shell scripting & RegEx soon, with perhaps LUA, C++, & Java in a few years. I want to have scientific proof to the key's placements. I do have ideas/requirements, some invented myself, some taken or derived from others:

• Almost All keys may be re-arranged
  • RETURN, Left SHIFT, Left CONTROL, SPACE-bar, & TAB need to stay, but all others, including numbers, symbols, & movement keys are open to moving
  • Might be optimal to leave zxcv & perhhaps s to stay in place, due to common Undo/Cut/Copy/Paste/Save habits :)
  • DELETE key likely to be moved to where CAPS LOCK is :)
  • Unlikely to keep matching brackets like (){}[]<> next to each other; see below
• The only accurate way IMHO to count key usage is by key-logging, not key counts of files:
  • Much of "programming" is sending emails, posting to forums, twitter, bug reporting, web surfing, etc.
  • I believe much of keyboard usage is "movement"; tabbing between fields, page down, moving cursors around, etc. These are not captured by file outputs
  • Many editors use auto-complete & macros, so close-deliminators: )}]> may not be as often typed as openers, thus only key-logging & not parsing files will accurate.

So my questions:

1. What are safe free/open source software keyloggers, that will not upload files unless you send a separate file yourself? I would prefer NOT to collect log-in names & passwords, not only for security but also for because that can throw of my analysis IMHO.
2. What programs can be used client-side to digest single & pair key-counts? Or how to best build one?
3. Where is it best to find volunteers to help out?

Best research so far: http://www.michaelcapewell.com/projects/keyboard/layout_capewell.htm

http://viralintrospection.wordpress.com/category/technology/keyboard-layouts/

& Wikipedia: Keyboard_layout#Non-QWERTY_keyboards_for_Latin_scripts

TIA!

Solution 1:

Use a program like WhatPulse to record which keys are hit, and how many times.

After asking on the FreeNode IRC network about how to get the key frequencies together, a user lead me to this:

1. Get your text, such as a program(s), and copy them.
2. Go to http://type.trmnl.org/
3. Under the buttons, Be Sure to uncheck 'autostart with clipboard contents on paste'
4. Then, paste your program into the text box.
5. Press Cntrl+Shift+K, which will open a console.
6. Type in count_digraphs() and press Enter.

The results are read like this: "ar" 7 17 10 "ra" which means 'ar' was pressed 7 times, 'ra' was pressed 10 times, and all together 'ar' and 'ra' were pressed 17 times together

Solution 2:

Keys for movement in editors are most often adapted to fit with as efficient usage with QWERTY as possible, and so they will most certainly need to be remapped if you change key layout and want the optimal placement of everything, which you strive. E.g. in Vim, the HJKL buttons are used for a reason with QWERTY, and would most probably need to be remapped back to the same placement after the key map has been modified.

What I mean is that it won't help you much to track movement and editing keys and use it as a basis for a new layout, since they are easily reconfigurable (in any editor worth it's salt, and since we are talking about a programmer's layout, we are most likely talking about Vim or Emacs), shouldn't interfere with the placement of the literal keys and have already been optimized (again: we are not talking about Notepad).

You are trying to solve a problem which is an inefficient way to productivity, especially for a programmer, **imho**. There would be a much greater effect in simply learning more about the tools (once again: probably Vim/Emacs). You will find that less and less time is spent actually writing characters when programming, and more (but more efficient) time is spent on auto-completion, auto-tagging, auto-indenting, quick function definition look-ups, etc. The keys to do all this are already adapted to allow efficiency, and the big speed boost comes simply with familiarity. Thus I argue that a different keyboard layout is right on comparably destructive for productivity, since you already have many years of QWERTY exercise. If the same analytical training time was spent on QWERTY as people who switch layouts spend on Dvorak, they would also notice a speed boost. Speed comes with explicit training.

If you were a copywriter/translator/author/etc., someone who actually spends his time doing work with the literal meaning of the keys, then a different layout might be of help. For a programmer, the best tip is usually to at least get an English keyboard layout, since programming idioms have been shaped by these and their key placement (on my local key layout, @$[]{}~ are all behind AltGr which is quite sub-optimal).

tldr: Dvorak/Colemak/[the next "best thing since sliced bread"] (arguably) solves a problem only for those who enter a lot of flowing text in a specific language (most often English). For programming, the needed keys have not been subject to the same restriction as literal language, and thus it has already been optimized for its purpose (which is not just "write as fast as you can"; it builds more on logical operations. See Vim). I believe that the time spent in learning alternate layouts and the confusion that most certainly occurs time and time again is definitely not worth the effort in most cases (not just your own confusion; others who sit down at the same terminal you last used will throw things at you), very much including the programmer's.