I think it is awesome, and I use one myself. Additionally, I've remapped the z and / keys as AltGr keys, marked as A below.

Here's mine:

  ~ { }   1 + [ ]  
@ # : * / 0 = ( ) ; !
A \   & | _ - < > A

That's because I remapped () to the original <> positions. On my keyboard, . and , are on the top row pinkies, making () easy. I put : ; there because there were two extra spots. I guess that's kind of useless. But besides that, the only ones that are available on my keyboard are [{, ]}, and =+, all of which are hard to reach. All the rows are shifted up, so there's no number row.

I should probably start using num lock instead. ;)

I have all the number-related stuff on the left side: / + = * ^

Well mine is fairly simple. I suppose the numbers could be removed, and the bottom row moved to the top, but I actually kind of like having those keys on the bottom.

! @ # $ % ^ & * ( )
1 2 3 4 5 6 7 8 9 0
¡ ™ £ ¢ ∞ § ¶ • ª º

You mean like that?

My new one with numbers and extra stuff eliminated:

< > ^ % | { } &
+ = * / \ @ [ ] $ #

Hmm... there's some empty spots. I'll look at all the AltGr keys...

`¡™£¢∞§¶•ªº–≠œ∑´®†¥¨ˆøπ“‘«åß∂ƒ©˙∆˚¬…æΩ≈ç√∫˜µ≤≥÷ unshifted
⁄€‹›fifl‡°·‚—±Œ„´‰ˇÁ¨ˆØ∏”’»ÅÍÎÏ˝ÓÔÒÚƸ˛Ç◊ı˜Â¯˘¿     shifted

¨ ´ ` ˜ ß ¿ are international characters. I'm not sure how common some of them are, but I do know that ´ is very common in Spanish, ˜ is fairly common in Spanish, and ß is fairly common in German. Those 3, plus ¨ and ¿, deserve a spot. Right now they're placed over the letter that they go over most commonly: E frequently has an accent, so altGr-E = accent. N gets ˜, S gets ß because ß is pronounced like an S, and U gets ¨. Since this is English, those won't go on the main keyboard. ¿ deserves an upgrade, because it requires altGr-shift-/ to use.

÷ ∞ ≠ ≈ and √ are math symbols. They might get spots. ÷ is replaceable with / in almost every situation though.

Other than those, the only thing that looks common enough is º.

The way I have it set up, space is a dead key, so it's separate from altGr. I can still use altGr. And since ´ ¨ and ˜ are dead keys, that means there's a dead key within a dead key.

< > ^ % | ¡ { } & º
+ = * / \ @ [ ] $ #
≈ ≠ ∞ ÷ √ ¿ ´ ˜ ¨ ß

EDIT: I put in ¡ directly above ¿.

That looks harder to remember. Now I have to focus on making it easier to remember. I could move <> to below the other brackets, but that would complicate things. Plus, it's easy to remember when ^ is next to them. So how can I improve on that? One thing that can be done is put keys over the key that makes sense. But I use a different layout from most people. One thing that can be done is put it under its QWERTY position. But that wouldn't work for some things. Since I have the keyboard shifted upward, ´ would be on the altGr home row. It's too rare for that. Same problem with ¨. ˜ would work, but then it would be below the bottom row, on what I'm using as space. Sigh.

I use the layout for programming. I find that it both speeds me up and is more comfortable. I do not feel it was particularly hard to commit the layout to memory.

The layout I use has been developed using first computer aid, then fine-tuning it subjectively.

I used a home-grown genetic algorithm similar in spirit to ones used to develop regular keyboard layouts. My corpus was C++ and Python code from my earlier work. It tried to minimise same-finger, but maximise same-hand. This is because I use dual AltGrs similar to the way people use shift, and alternating shift on every other keystroke is very slow.

After I obtained a reasonable starting point from the computer program, I started to move stuff about to make it more logical, checking back with the computer program to make sure I didn't do any blunders. The layout was at every step tested subjectively.

* I keep the most frequently used stuff on the home row
* Semicolon is in its old qwerty place
* I line up the brackets
* Special care has been given to common digraphs (<=, >=, !=)
* 0 and 1 get special places because they are so common in code, especially in conjunction with = , -, +
* - and + are mirrored around =, - is grouped with _
* Left hand covers multiplication, division, logic operators (&, |), code commenting (//, #), and pointer/reference (*, &), roughly grouped
* @ on A because it's "at"

I've found that it's surprisingly important to have comfortable rolls - perhaps the most important criterion. This means no same-finger or hand alternation for common digraphs. I've compiled a list of these digraphs in case you find it useful for your own layouts:

<= >=   Compare greater and less than or equal
!=        Compare not equal
= 0       Set variable to 0
-1        The number -1 (surprisingly common)
->        C pointer
[0] [1]  Common subscripts for arrays
/* */    C comments
);         A lot of rows in C end like this, eg. f->function(0, 1);
:/        for use in paths, eg. C:/folder
${       python string variable substitution

Yes, it's highly annoying. I have to use non-standard fingering for that similar to the way I type "walk" and "talk" (but mirrored). I haven't found a way to get rid of it; I guess no layout is perfect.

I've found that switching in and out is the worst thing to do. By switching in and out I mean for instance typing hand-alternation-high all-caps words like AERO without using caps lock. But if all you are going to give up are the [0] and [1] trigraphs, I wouldn't worry too much - they're not THAT common.

Sure; But if common joe is a programmer he uses special symbols a lot. Since common joe managed to learn Colemak, it should be well within common joe's capabilities to learn something like this. :)

The original qwerty positions are no less arbitrary (and in fact are probably more arbitrary) and people learn them eventually. Having said that, I wouldn't really recommend an AltGr special character block for non-programmers.

To close, in my experience just putting the symbols anywhere on the AltGr positions of the alphanumeric keys gets you 70% of the benefit, so if you want to put them in the most logical order instead of some other meaning of "optimal" that is fine too. I am willing to invest a few neurons to get those last few percent of benefits.

To map AltGr in Windows, you'll need a registry remap. That's fine though.

What I'd do is put an extra AltGr on the B key, and move ZXCVB one to the left. This obviously works only if you actually have a key to the left of Z and not one of those key-challenged US boards - unless you're willing to do the drastic thing and put Z on the CapsLock key. The CapsLock could move to the old AltGr key!

I thoroughly recommend it. I've sacrificed z and / to do so. I don't miss / at all (since it's in my special characters block), and I've moved z to the Colemak ; position. The latter is admittedly a bit of a bother as z would really rather want to be on the left hand, and I don't like to move alphabetic characters from their Colemak position. Fortunately it is an uncommon letter so I don't suffer very much in comparison to what I gain.

If you have a European keyboard you don't have to move z - just use vk_102 instead of z, or put it on b like Dreymar does.

Alternatively, you _could_ use CapsLock for the left AltGr, meaning z could stay, but you would have to move backspace elsewhere. I've got a TypeMatrix board so a) I don't even have that option, and b) backspace is nicely placed anyway.

I've actually used AutoHotKey for that purpose. Doing it that way means you have a little more flexibility. For instance, I can retain undo on the z position, since AutoHotKey can detect whether you are pressing ctrl. The z key thus becomes an AltGr/Undo. It sounds a little strange but works really well once you get used to the idea. As an added perk, if you use AutoHotKey it should be possible to make it compatible with portable Colemak if need be.

Sure thing Simon. I've changed the virtual key codes of the z and / keys using Keyboard Layout Manager to 0x8a and 0x8b, respectively. I then catch them in AutoHotKey by virtual key code and send RAlts (AltGr). If ctrl or ctrl+shift are down, I send z:s instead for undo/redo.

I admit can't remember why I changed the virtual key codes and if it's really necessary. It could be that it was necessary during some earlier step in my experimentation and now it's still there as an historical accident.

EDIT: I was driven to find out, and it was indeed for historical reasons. In my first version, I typed z with AltGr+z instead of moving the key, which required changing the key codes. This is no longer necessary. Just make sure the keys you pick for AltGr do not have anything assigned to their own AltGr positions, or they will start autorepeating.

The AutoHotKey script is:

; Z key
vk5A::
Send {RAlt down}
KeyWait vk5A
Send {RAlt up}
return

; / key
vkBF::
Send {RAlt down}
KeyWait vkBF
Send {RAlt up}
return

Here is my modified version. It is designed to be useful to both programmers and non-programmers. I'm really happy with the left side and the home row, but the right side above and beneath the home row still needs work. The forward slash is intentionally duplicated. I think the numbers are fine to stay where they are.

! ? # $ &  * < > /
- _ ( ) @  % [ ] { } ^ 
| \ / + =

One last thing. I have put what I believe to be the most commonly used symbols on the left side so that people can remap /? key as suggested by tomlu (fantastic idea, by the way). I think that most keyboards have this key. I'm not too sure that remapping z is something everyone would want to do. If they have the vk_102 key then they can use the right side of the board too.

Any thoughts on this whole thing Shai? Could it be beneficial to include something like this as an optional add-on for Colemak?

I see what you mean tomlu. How long have you been using your layout? Have you noticed any strain in the pinkies?

Disclaimer: I, most obviously, am not Shai - and yet I'd like to answer anyway!  ;)

No. Something like this will be too involved for general use, and the ones with high enough geekness to go for it will either be able to map it themselves or find it on your/Tomlu's/whatever site it will reside on eventually. Furthermore, Shai has already expressed his inability to devote time to maintaining multiple versions of Colemak so "optional add-ons" are off the menu I think.

I'm taking a somewhat different approach to these things myself: Multiple shift-state keys (or transpose keys as I like to call them). When I'm done with it we'll see how good it gets, but basically the idea is to bring the NumPad, arrows and other keys to where you are (i.e., the home row) using a modifier key for each such transposition. The benefits to this include that the actual scan codes are transposed instead of just sent glyphs (most of the time) thus allowing for the use of other modifier keys with the transpositions, that the positions of transposed keys will be easily recognizable from their original positions (for the most part) thus requiring very little learning, and that each such transposition will be relatively moderate so it's not too overwhelming. One transposition for the half-colemak (one-handed typing), one for the NumPad (plus a few extras), one for the nav keys, maybe one for bringing the top row down etc.; and it will be modifiable by the user. I'm hoping to get this added as a module for PKL eventually - PKL already has one very nifty "extend key" so it only needs a tidy way to add lots of them.