You don't need any of those in the lower left. Actually i cant see a reason why they should be. Handheld use with pinkey-fingers active
isnt as easy as the mental transition from 10fingers. Its a fallacy to pretend it isnt.
Shift: should be close to . since that is a frequent chain of events. And they all have to be on the right since as you said, space on
the left is limited if you want P+2. No loss though.
Ctrl: As with shift, there should be a keyboard part only, without the use of shoulders to type this. So it doesnt have to be lower left.
Also lower left is much much worse a position on 2-thumbs than it is on a 10finger keyboard. The need for ctrl as an effective key aligns with
shoulders because its a more technical thing than the use-case of someone who has enough with trying to figure out the keyboard-part alone. (beginner)
Fn: Any modifier that is in the lower left (or lower right) alone, (since you cant dual-fn or other such) means typing Fn+anything is a lesser use. Thats not so good, increasingly so the more
functionality the modifier has, especially basic functionality used often.
Numbers on anything but top row just facilitates a "im unhappy and have good reason to"-situation, so yes. The people who need M+2
are fortunately not the bread-and-butter. M+2 being the "i need 6-keys other than A-Z" we can at most give everyone 4, where one of
them is the shift-key. (since earlier mentioned, that should be a shoulder to get more efficiency out of the two-thumb paradigm)
A reminder here people that AltGr is Left Control and Right Alt, so any of the other possible Control and Alt combinations will be fine with the Spacebar key for whatever program needs it should we put say the Menu key on Spacebar to have a dedicated Escape key(as in my alternative v2c layout in my sig).
I'm not saying above that Escape will be moved to Menu's position, but it could be with only a minor imperceptible sacrifice.
I dont understand this. Is anything other than "space" or "|__|" printed on the space-key? Given a bar-key, how do people feel about staying with bar-look, and going double-duty, like this:
http://boards.openpandora.org/uploads/post-2326-0-41907700-1427028696.png To me that is the good-compromise between those who want
a bar-key, and those who want more keyboard functionality. I think the losers are dvoraks, or something else where you need to use M+2 for typing, but that is the minority in this case. One that unfortunately cant be fully happy with the compromise that works for everyone else (given how you have print on the letters (pretending remapping is ok isnt ok. It is for the dvoraks, but they are very few, and the people you sell a lackluster M+2 idea to isnt a huge bonus)
Why do we need ANY specialized characters on the keymat ?
the better place for them is printed on the case next to the key, or have an overlay that can be clipped onto/over the keyboard with the keys poking through
This means just one keymat that is dedicated to programming / terminal tasks - with any specialized characters provided by mapping and simple printing - rather than multiple keymats (probably not practical) or one keymat that tries to make everyone happy and fails for everyone...
It is simply not possible to make a single keymat that will be convenient for all users and all languages
You are raising a lot of issues, let me try and solve them in a constructive manner:
Implied that we is the current community, (and an even more international one if the pyra keyboard is more international.) "Specialized" characters on the keymat makes it painful for others, and with those differing as much as they do, you have to rely on motorical memory rather than visual clues. Again, anything visual needs to be minimal, because more info, and especially non-standard info, is chaotic, and ruins everyones experience increasingly as you put everyones characters in.
There is a great deal of difference between doing everything over, and trying to do everything normally. One becomes chaotic quick, and the other falls short
of being perfect where perfection is its ability to be normal.
Since what we are working from is the basis of something that works for english people, and they are the single biggest group, they should get the default behavior.
On the pandora it was a factor of neccesity, that same limitation fails just as hard in 2010 as it will do in 2015. That is what we should improve on, without losing the working prospects of english/pandorakeyboard. That is after all the false positive basis the community was built on. Fortunately, there is little praise for its bad concepts. We can even do more of what it really does english/keyboards, meaning something that is in line with how they work, and why. Yes you have to condence the differences between layouts into one default. You however get some things for free, ISO and ANSI keyboards have the same amount of keys (minus <>) english is better for coding, international is better for respective regions. Fortunately the key difference is predominantly in
the typing letters outside of A-Z.
There is a design-win here, because in a standard way, that also means the default is better for coding, and that fits really nicely with what makes the pyra usergroup special. If it only suited them, it would be a nieche within a nieche. I see instead everyone happier when the full and broad appeal of the pyra is utilized. More sales mean better prices for everyone.
With expectations of a keyboard, its already a battle to implement a keyboard.
You can do that up until a point where it isnt feasible anymore. The number of keys on a pyra exactly facilitates 87-key behaviour.
If you try and save a key by doing double-duty on a key with expected behavior, like AltGr, then that is a loss (compared to fully functional AltGr).
The pyra keyboard can be a real keyboard in all aspects except for F-keys (dictated by the number of keys available)
(Fortunately F-keys are losing relevance, and are more 10finger desktop centric than nubs/touchscreen/handheld, but alas, they need
to be available at all times because of the user demographic.) This shouldnt mean losing AltGr, or a modified AltGr, instead it should
be an extra key, that is a F-key modifier.
Do one thing, do it well. It would be nice to have it called "F-" and a different colour, because that can be intuitivly picked up.
Fortnately, if the only functionality you depend on for that is F-keys, you also just need the people who need F-keys to understand it.
You dont bring any chaos if you solve the problem right at its
foundation.
