Tab is essentially a long space. The Pandora had tab on space, but the implementation was bad since space was right next to the Fn button. With the Fn key on the left and space on the right, Fn+space=tab becomes a very easy combo.
This makes no sense to me. How is forcing the use of 2 fingers on opposite sides of the keyboard for tab better, when the Pandora allows you to press it with one finger in a single motion? (which to my mind almost a good as having a dedicated key for it) Much easier to trigger it with Fn and space together than not.
For doing a single Tab, the Pandora way is probably better indeed.
For doing multiple (repeated) Tabs, holding Fn/Meta with one thumb (or on a modifier) while repeatedly hitting Space is going to be better than what you can do on the Pandora.
If the Fn key equivalent is going to be on the shoulders, then using that would be the best solution for handheld use. (especially if it's on the left shoulder) If the Pyra is in a dock or tabletop then the ergonomics are completely different anyway, and it becomes much easier to use multiple fingers on the same hand.
That said, I also have no problem holding down fn and repeatedly tapping space with the same finger to get multiple tabs on the Pandora.
You could use one shoulder+another for tab. For the purpose of implementing tab on the keyboard area, for reasons its much more convenient when not holding it, and less treshold of entry there, tab is best implemeted as tab.
/? on the space bar simply 'feels wrong'.
`~ on Fn layer means they're related diacritics spread to other keys Fn layers. Ideally, where possible, the diacritics should all be bonded at the Fn layer to their root symbols, though that does mean that their related symbols should be root keys.
Giving `~ it's own key has some advantages too. ` is commonly used in gaming to 'open console'. ~ is insanely useful in navigating command line Linux.
With the Fn and Shift keys on the left with both shoulders and main keyboard area, that diacritic area on the lower left is a bit of a funky reach.
Ins and Del 'feels right' since it pairs nicely with PgUp, PgDn, Home and End, but could get in the way if 'stolen' for in-game play. I.e. if they're mapped to the game, then we loose them for in-game text use. I can live with that, but thinking it through, it feels 'more right' to give those two buttons something semi-unique that isn't 'in use' for something else.
It no longer has separate dead tilde and grave, because I think it is not really necessary if àèùñ are available.
Spanish does not use graves, and the only tilde it uses is ñ.
In French, the only graves are àè (and ù for the word "où" -- yes, that letter is only used in specifically that word!), and there are no tildes, so that's OK.
In Portuguese, the only grave is à, but there's also ãõ. Portuguese does not use umlauts though. So they can either remap the German äö to ãõ, or they can make ~ a dead key (like in e.g. US-International).
In Italian, there are graves on all vowels, but àèù are the most common ones. They can make ` a dead key (which doesn't really hurt, since it's not really used for anything). Italian has no tildes.
In Dutch, the only grave that (rarely) occurs is è, so that's OK. It does not use tildes. Same with Afrikaans.
Estonian has õ, and they can't apply the 'Portuguese trick' because they also use üäö. They would have to map their õ to some available position, e.g. Meta+T. In any case they probably wouldn't want to use the dead diacritic method, because õ is a rather common letter in their language.
I don't think other major languages use grave or tilde diacritics besides àèùñ.
Meta/Shift shoulders on the left or on the right does not matter much -- I use L1 for shift on the Pandora, and I notice no big difference between writing a capital Q and a capital P. But even if there is a difference, then I rather have them on the left, so the punctuation symbols on (Shift+)Meta get priority.
I think the action button thing is no problem: it will not interfere with games. If games let you type so much that Ins and Del are useful, then surely Home and End would also be useful, and the dpad for that matter? After all, if you can't move the cursor, what's the point of Ins and Del? So I wouldn't worry about it.
English: just try to manage to ignore the funny letters
Spanish: ñ is at Meta+N, acute is available as a mashable dead key on Meta+'
Portuguese: ç is available on Meta+C, acute at Meta+', circumflex at Meta+>, à at Meta+A. You would probably remap äö to ãõ.
French: é and à are available as mashable combos on Meta+Z and Meta+A, èùç are at Meta+EUC, circumflex at Meta+>, diaeresis at Meta+"
German: üöä are available at Meta+YGH in a cluster that resembles the German keyboard ÜÖÄ cluster. The left thumb can hold Meta while the right thumb types üöä. ß is at Meta+S.
Italian: àèùé are available. ìò are not available, so you either map them as direct keys somewhere (e.g. Meta+DF), or you make backtick ` a dead grave.
Some examples for smaller languages:
Dutch: diaeresis and acute are available. For loanwords (or Afrikaans), circumflex is available.
Scandinavian languages: your letters are available, not in particularly nice spots and not as dedicated primary keys, but at least you can type without having to remap or remember things.
Polish: ąę can be made using Meta+, (or you could map them to Meta+AE), ćńóśź can be made using acute at Meta+', ż can be made using Meta+. (or you could map it to Meta+Z), Ł is missing so you would have to map it somewhere (e.g. Meta+X).
Czech: áéíóúý can be made with acute (Meta+'), ČĎĚŇŘŠŤŽ can be made with caron (Meta+<), ů can be made with dot/ring (Meta+.) or could be mapped to e.g. Meta+U.
Hungarian: áéóú can be made witht acute (Meta+'), the German öü can be used, and for the double-acute őű you either remap Meta+" to double-acute, or you remap e.g. ØÚ to ŐŰ.
Turkish: çöü are available already, ş can be made with cedilla (Meta+,), ğ can be made with caron/breve (Meta+<), dotless i (ı) can be made with Meta+. Alternatively, şğı can be mapped to available Meta keys, e.g. Meta+DFT.
My thumb typing on tablets doesn't have any "muscle memory" from a full sized keyboard, just because a full sized keyboard does it that way is no justification for doing it on a smaller keyboard, potentially quite the reverse!
My thumb typing on tablets doesn't have any "muscle memory" from a full sized keyboard, just because a full sized keyboard does it that way is no justification for doing it on a smaller keyboard, potentially quite the reverse!
I agree with codifies when it's about "muscle memory": ten-finger muscle memory simply does not translate to two-thumb muscles. If it would, then you could only type spaces
I agree with Grench when it's about "knowing where to look".
Whatever we do, muscle memory is not going to be very useful for our purposes, but "mind memory" (which is just regular memory I guess ) can still be exploited. That's also the reason why nearly all of us want to have QWERTY and standard shift+number symbols.
My thumb typing on tablets doesn't have any "muscle memory" from a full sized keyboard, just because a full sized keyboard does it that way is no justification for doing it on a smaller keyboard, potentially quite the reverse!
Not everyone is a touch typist. For those of us who learned to type primarily through the hunt and peck method, the "muscle memory" involved can simply be a matter of knowing approximately where to look, especially for the symbols one doesn't use frequently.
Agree with Eight Bit and Comradekingu here about too many languages incorporated being too many languages in general. If French and Dutch are the gold standard to go by then Acute, Grave, Circumflex are the epitome of a functional dead key diacritic base. Many "foreign" Pyra users will need these three. Umlauts for all too obvious reasons as well. Rounding it out are letters for Å, Æ, Ç, Ñ, and a few others.
Sometimes the painting is more beautiful when you don't dip your brush into every color.
Dutch and French need ë and ï probably more frequently than ü ä ö, so a dead umlaut is more useful to them than dedicated üäö keys.
Tilde as a diacritic is useful for ã and õ in Portuguese (and ñ if it is not already available).
Å and Æ are not that useful, they're only really used in Scandinavian languages.
With just acute, grave, umlaut, circumflex, tilde, caron/breve, cedilla/ogonek/comma, ring/dot and stroke (9 diacritic keys) you can in principle cover everything (except Æ Œ), but of course it's more convenient to have some of them as precomposed letters.
True, but the Dutch and French people could write ë and ï to one of the three umlauts, or ß, €, § in my layout. There's Shift + Fn + r, t, y, d, f, g, available also if those first six places aren't enough(highly unlikely for the average user). Å, Æ, Ç, Ñ, Ż and others each or all can be mapped there too. Being truthful here, most people will maintain only one nationality for the life of the device.
As I've expressed, loading up the layout with increased content isn't the only answer. I feel it's also a burden in some of these layouts to lose a dedicated Tab key, and to require Shift + Fn for ~ { } | : " and ? for all these extra diacritics most people will never on a per individual basis ever need. I realize it's a layout's selling point to fill it to the brim, but admittedly the user will fashion their layout according to their own specifications. In some cases it may be as simple as an å and Å at Fn + L and Shift + Fn + L.
Can I live with that? Yes. Would I rather have the tweaks noted above added? Sure, but I'm not going to harp on them at risk of having one of the other layouts highlighted.
At this point you and I are 'splitting hairs' over minor differences in layout and efficiency tweaks. I'm good with backing this one if you're willing to make it your 'primary' and push for it as well. If we can get a few more of the other keyboard builders on-board, I think this has a solid message to push up to EvilDragon.
There are a few typographic/formatting tweaks that should probably be fixed before presentation.
The '" key (left side) has two diacritic marks, should be reduced to 1 to match the format of the ones on the right side - it looks cleaner that way.
On the O key, the - of the Fn layer's -_ has fallen off the key.
Also, we should note somewhere that ALL non-modifier keys are expected to produce unique sanscodes for normal, shifted, Fn and Fn+shift values, regardless of whether there is or is not something printed on the key for those levels. Nobody panic - this isn't a hijack, it's to make sure that the keyboard produces a code for the end user to grab to map to whatever they want.
So, if we were to go with the _wb_ layout as listed above, who's in with us?
As I've said before, I like it for the most part, but there may be technical issues. I'm not going to let myself get too attached to any layout unless I know the hardware will support it.
As I've said before, I like it for the most part, but there may be technical issues. I'm not going to let myself get too attached to any layout unless I know the hardware will support it.
As far as I understand, diodes can be put at the keys that will be used as modifiers, to avoid the potential masking/ghosting issues you were referring to. If that's the case, then we can basically freely design a layout without having to worry about those technical issues.
As far as I understand, diodes can be put at the keys that will be used as modifiers, to avoid the potential masking/ghosting issues you were referring to. If that's the case, then we can basically freely design a layout without having to worry about those technical issues.
@Neelix, I was actually given an early schematic of the keyboard wiring as I'm actually planning a big project of making a working mock-up of the Pyra keyboard for my Devboard using Cherry MX key switches. I was warned that the design isn't final, but I could use it as a guide on how to start. EvilDragon didn't want me publicly sharing the design as it's not final. I can assume that the final keyboard design will finalize how it's truly wired. In my project I'm attempting to make it easy to re-wire to try different layouts until a final design is chosen.
Currently from what I saw of the design there are schottky diodes on the modifiers keys. Also to note the four shoulder buttons are using GPIOs directly connected to the SoC, and not the I2C chip that the keyboard matrix is tied to, so I assume that reduces some of the issues for those buttons when hitting multiple keys.
@Neelix, I was actually given an early schematic of the keyboard wiring as I'm actually planning a big project of making a working mock-up of the Pyra keyboard for my Devboard using Cherry MX key switches. I was warned that the design isn't final, but I could use it as a guide on how to start. EvilDragon didn't want me publicly sharing the design as it's not final. I can assume that the final keyboard design will finalize how it's truly wired. In my project I'm attempting to make it easy to re-wire to try different layouts until a final design is chosen.
Currently from what I saw of the design there are schottky diodes on the modifiers keys. Also to note the four shoulder buttons are using GPIOs directly connected to the SoC, and not the I2C chip that the keyboard matrix is tied to, so I assume that reduces some of the issues for those buttons when hitting multiple keys.
I realize that you're not able to give out full information, but can you define which keys on the board design have the diodes? I.e. which keys are "modifier keys"?
That would go a long way towards understanding the constraints that would define this entire exercise.
Good to know there is some flexibility there. Though to be honest I don't understand how the diodes would help with the masking problem.
FWIW I'm happy with that mapping as a default if it is technically feasible. (This one, to be clear) I would probably add œ to it somewhere, but there is room to do that, so that's not a problem.
Maybe move Backslash and Pipe to J which allows you to slide the other pairs in that row one key to the right. Not a fan though of where comma and period are hidden or Tab but it is manageable. Two keyboard Meta's is a nice touch.
Good to know there is some flexibility there. Though to be honest I don't understand how the diodes would help with the masking problem.
FWIW I'm happy with that mapping as a default if it is technically feasible. (This one, to be clear) I would probably add œ to it somewhere, but there is room to do that, so that's not a problem.
Even though the symbols are compressed over to the right edge like they usually are on a full size keyboard, I don't understand how requiring the user to press two keys(Shift and Fn) together for ~ { } | _ + : " ? is not intolerable to some of you. That's abhorrent as how I've seen it done so far in some of these layouts.
So, if ED jumps all over this to bring happiness to this here kingdom, I alternatively propose we have a custom keyboard-only key that merges a Shift and Fn into one unique key. We then cluster the three modifiers all on the left side's corner. One Shift, one Meta(or Fn as we might call it), and one "S.Meta", which is a composite of Left Shift and Right Meta. Once more, this is just in case if ED wants the main punctuation all heaped to the right.
Even though the symbols are compressed over to the right edge like they usually are on a full size keyboard, I don't understand how requiring the user to press two keys(Shift and Fn) together for ~ { } | _ + : " ? is not intolerable to some of you. That's abhorrent as how I've seen it done so far in some of these layouts.
I don't understand why it would be. With Meta and Shift on adjacent keys it's just as easy to press both at once with a single finger as it is to press just one.
If you don't believe me, try it in the Pandora Input Tester. (the keys on the Pyra are the same size horizontally)
My thumb typing on tablets doesn't have any "muscle memory" from a full sized keyboard, just because a full sized keyboard does it that way is no justification for doing it on a smaller keyboard, potentially quite the reverse!
The letters are definitely muscle memory. There is no exception to dedicated letters in any language. Try switching I and G on a pandora. Or replace I with AltGr+8 and G with AltGr+7 Even if you think you are a visual QWERTY user, it is initially very detrimental to change to for example COLEMAK.
And as a general rule, I think with the least of visual clutter presented, you maximize the goodwill for any changes. It shouldnt be easy to point to troublesome areas, or things that are clearly compromised. That is the first thing people see, and it throws me off in a major way.
Where things differ, is with efficiency. Relating to the punctuation and heatmap, some changes can be made here. A 2 thumb layout becomes more efficient if , and . is at either side of space. From thereon logistics can be optimized quite a bit without appearing otherworldly.
With that covered, you wont really get a whole lot of efficiency out of symbols either way. On the whole, its more important that the international users can have letters that arent effectively symbols.
However i also think there is such a thing as mental mapping. I expect a certain amount of conventions. And i expect things in places i know them to be, as do we all. With that in mind, if we try to keep things within reason, its also the most familiar to everyone.
This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
By continuing to use this site, you are consenting to our use of cookies.
