Here is my list of "issues":
- The ;: and \| are in a too hard to reach place (requires stretching or hand placement change). These are VERY common programming keys (esp ;: ) and deserve a more premium position to me (this is even worse if you don't use the international keys, I do like that they are in German default position)
I suspect this is a misconception about hand/thumb placement and reach. With the Pyra in the palms of your hands and thumbs on the nubs, your thumb from palm to tip has described a line. That line can describe an arc from the nubs down to the center (actually a bit past center) of the lowest row of the keyboard.
Try this on a Pandora. The natural arc from a thumb pivoting without changing hand placement should land both thumbs directly on the space between the Pandora's V and B keys.
That is the same overlap spot as \| and ;: occupy.
http://www.keyboard-layout-editor.com/#/layouts/ee8d3bc8b446f99c027105d3810f8d07
So, the ;: key on this layout is not only reachable without changing hand position - it's also in one of the easiest to find and reach places on the whole keyboard. It can be reached with the natural arc of the right hand and is also reachable with a very minor stretch of the left thumb. Those two keys, \| and ;: are actually in the most accessible spot on the keyboard - they can be 'reached' or found with BOTH thumbs.
I would have loved to have put the space bar there, but case production moved forward without giving that kind of layout any second thoughts.
- Double modifiers for shifted numbers is not the greatest, but I think the advantages outweigh the downsides, provided the double modifier is easy to hit. I am not convinced that is currently always the case. Pressing shoulder buttons and keyboard keys on the same side of the keyboard feels awkward to me and the double button is harder when typing on tabletop.
I prefer to have balanced modifiers on both left and right side (I am fine with one side being on the shoulders). My preference is to move both shift and Fn towards the right on the keyboard to maintain backwards compatibility with the Pandora shoulder buttons (and I also prefer Ctrl+Alt on the right since I use them more often in combination with keys on the left (in Emacs). Easier said then done though.
The right side of a 'normal' keyboard is heavily weighted with 'functional' rather than 'symbol generating' keys. With any Pyra layout you'll wind up with it being tight to incorporate all of the needed keys before even considering shoving Fn and shift into the mix.
From your own experiments you can see what kind of a, "Well - if I put these here then I have to push those to there and those to there and where the hell am I going to put this..." scenario that leads into.
I do agree that it would be good to have the shoulder Fn+shift combination on the opposing side to the keyboard Fn+shift combination. To get there, though, I think it would need to be the shoulder button definitions swapping sides instead of moving the keyboard Fn+shift to the right. There just isn't room for all of that on the right.
- Minor issue, `~ belongs on the left hand, [{ and ]} on the right.
Not an issue, just a question, on which keyboard layouts have you based your zxcvbnm Fn key assignments?
I combined what ED said he wanted with what had been discussed and in many cases used on other layouts and thought long on what makes sense to put on what keys in which combinations. In many cases their placements were feedback from _wb_.
I put ß on Z because ß is a letter with upper and lower cases and nothing else fit Z better.
The ¡¿ Spanish punctuation symbols made sense to map together. It may make sense to flip them to ¿¡.
C to Ç is a pretty natural mapping.
I put Euro and Pound signs on V for 'Valuation'.
Next to the V I put the international currency symbol on the Fn+shift+B in case someone needed to map a key to an additional 4th currency.
The Fn+B key got the § sign - it needed to go somewhere and I had a symbol without a pair on the B key.
N to Ñ is a natural map.
M to micro µ is a natural map. There is no capital for µ, leaving a spot on Fn+shift+M for °.
You'll notice that there are 3 keys on the lower left that have no Fn or Fn+shift mapping. -_ =+ \|
If there is a need or call for additional symbols - i.e. if I missed anything needed to support a language that should have direct support, those are likely spots to add them on the Fn and Fn+shift layers.
An idea I'm toying with...
One of the issues with having backspace and delete both on the game pad area is that when in 'game mode' all of those buttons will potentially be re-mapped into the game itself. So I'm toying with the idea of adding a second backspace on the Fn layer. I'm not fond of dual-mapping, but in this case it might not be a bad idea.
That lead me to this:
http://www.keyboard-layout-editor.com/#/layouts/bcac3a9de15b01c4b1146b0118a46ea6
Which made me think - how often is Ü<sup>È<sup>Å going to be needed? Can it live on the Fn layer? Like this? Germanic language users could choose which they want 'on top' - the letter key or backspace. Yes, this gives some compromise to the language capabilities, which isn't ideal, but is it an acceptable trade off?
http://www.keyboard-layout-editor.com/#/layouts/b76ffdc065642c07243bad385b4a06a8
At that point that top right corner of the keyboard gets a bit wonky looking, but functionally is pretty awesome. It reunites the Insert key with Delete, Home, End, PgUp, PgDn. It makes the space bar 100% dedicated as space bar under all modes. I explicitly labeled Compose at Fn+↵ on this one, but I don't know if that would be 100% needed as an explicit label on the end product. I also flipped the shoulders on this one. Does that make it 'better'?
