It's the keyboard layout.

[rygD]

On a different note, is there a good reason you've got the shoulder Fn and Shift being lock-able? Seems to me it causes more problems than it solves but I may be misunderstanding.

I can imagine some problems with locking shoulders as well.

 

[_wb_]

I'm not saying that US-QWERTY makes more sense than German QWERTZ or French AZERTY. It doesn't. None of the frequently used keyboard layouts really make sense. They just are what they are.


But I do think that it's better to try to follow just one of them (and I would argue it should be US-QWERTY), and follow it as closely as possible (within the constraints of having limited keys etc). I think it's a bad idea to do the letters like in the US, the shifted comma and period like in Germany and the shifted number row like something else again.

By follow I think you mean approximate. I remember how adamant you were for an uncentered "left-centric" lettered keyboard. P+2 and L+3. How it was "the way". Then it was Greek letters instead of ABXY. Then the single key spacebar protesting. Back to Greek again. None of those came to be. So in practice the act of respecting a convention, any convention, needs to be diregarded when developing a layout for the Pyra. Otherwise we end up nowhere fast by imposing these limits that no one seems to know why are being followed in the first place, only that others have before us and vaguely we must as well, for a handheld that isn't a desktop.

You make it sound like I do not know what I want. For the record: I'm still in favor of single-width space, left-aligned letters, and Greek/PlayStation action buttons. But it seems that not enough other people agree with me on those design choices, so instead of stubbornly sticking to my minority opinion, I started looking at compromises.

 

[codifies]

Compromise is a sign of maturity not weakness... For the keymat design to be a usable as possible within the (quite limiting) physical limitations we will all have to make compromises ...

 

[Saber]

Compromise is a sign of maturity not weakness... For the keymat design to be a usable as possible within the (quite limiting) physical limitations we will all have to make compromises ...

Exactly as I feel. That we shouldn't confine ourselves with layout developments by guidelines(Qwerty being the unanimous exception) we're imposing on our ideas, but it is interesting that some haven't applied this purported openness to the AltGr key, which varies by what it produces with which key it is pressed with in every different language specific keyboard layout: http://en.wikipedia.org/wiki/AltGr_key#International_keyboard_layouts

For example, on German keyboards, AltGr + 2 gives ² 

while on French keyboards AltGr + 2 is ~

but on German again AlGr with + is ~

It varies widely. Whose standard should we follow? I say none of them, but that doesn't mean there won't be overlaps.

To _wb_, I meant no offense to you above. I was making a point that being rigid about these things has lead us astray at times.   

 

[_wb_]

Compromise is a sign of maturity not weakness... For the keymat design to be a usable as possible within the (quite limiting) physical limitations we will all have to make compromises ...

Exactly as I feel. That we shouldn't confine ourselves with layout developments by guidelines(Qwerty being the unanimous exception) we're imposing on our ideas, but it is interesting that some haven't applied this purported openness to the AltGr key, which varies by what it produces with which key it is pressed with in every different language specific keyboard layout: http://en.wikipedia.org/wiki/AltGr_key#International_keyboard_layouts

For example, on German keyboards, AltGr + 2 gives ² 

while on French keyboards AltGr + 2 is ~

but on German again AlGr with + is ~

It varies widely. Whose standard should we follow? I say none of them, but that doesn't mean there won't be overlaps.

My point was: standard ascii symbols like ; : / ? [ ] \ { } | - = _ + are not AltGr keys on normal keyboards (US, German, French, whatever), they are regular keys (with or without shift, but dedicated keys).

So if the Pyra-specific modifier (which I call Meta, and which was called Fn on the Pandora) will be called "AltGr", then you are taking away the option for users to define a 'real' AltGr key (typically Right Alt) and have 'real' AltGr symbols on all the keys, like e.g. ¡ and ¿ at AltGr + ! and ? or ß at AltGr+S, because those keys already have an AltGr symbol or they already are AltGr symbols themselves.

So I think it's better not to call it AltGr.

Do you understand my point or do you want me to elaborate further on it?

 

[ible]

AltGr does different things in different locales, but that's good.  Keep it to what users expect.  Users can remap a key to give AltGr if desired (perhaps the Shoulder Alt, for example), so they can use their own specific locale's AltGr's offerings.

Use "Meta" or "Fn" to describe what we're doing:  we're creating our own modifier, which won't do what users would expect of AltGr.

 

[Saber]

Compromise is a sign of maturity not weakness... For the keymat design to be a usable as possible within the (quite limiting) physical limitations we will all have to make compromises ...

Exactly as I feel. That we shouldn't confine ourselves with layout developments by guidelines(Qwerty being the unanimous exception) we're imposing on our ideas, but it is interesting that some haven't applied this purported openness to the AltGr key, which varies by what it produces with which key it is pressed with in every different language specific keyboard layout: http://en.wikipedia.org/wiki/AltGr_key#International_keyboard_layouts

For example, on German keyboards, AltGr + 2 gives ² 

while on French keyboards AltGr + 2 is ~

but on German again AlGr with + is ~

It varies widely. Whose standard should we follow? I say none of them, but that doesn't mean there won't be overlaps.

My point was: standard ascii symbols like ; : / ? [ ] \ { } | - = _ + are not AltGr keys on normal keyboards (US, German, French, whatever), they are regular keys (with or without shift, but dedicated keys).

So if the Pyra-specific modifier (which I call Meta, and which was called Fn on the Pandora) will be called "AltGr", then you are taking away the option for users to define a 'real' AltGr key (typically Right Alt) and have 'real' AltGr symbols on all the keys, like e.g. ¡ and ¿ at AltGr + ! and ? or ß at AltGr+S, because those keys already have an AltGr symbol or they already are AltGr symbols themselves.

So I think it's better not to call it AltGr.

Do you understand my point or do you want me to elaborate further on it?

I am not taking away this real AltGr option some may think they need/want. Unless you are privy to knowledge the rest of us aren't, there won't be two modifiers, Meta and AltGr. The same can be said for Super and perhaps SysRq. Continue to place them if you like. 

 

[bzar]

My point was: standard ascii symbols like ; : / ? [ ] \ { } | - = _ + are not AltGr keys on normal keyboards (US, German, French, whatever), they are regular keys (with or without shift, but dedicated keys).

Allow me to disagree. On finnish keyboard [ ] { } \ | are AltGr keys.

 

[ptitSeb]

Same on French keyboard for ~#{[|`\^@]}

 

[_wb_]

Sure, but my point still stands. Most of the symbols (letters, punctuation, numbers) in Saber's layout either already have an 'AltGr' label, or they _are_ an 'AltGr' label, so if you want to have an _actual_ AltGr, things get very confusing.

 

[codifies]

can we just call them M1 (modifier one) AKA shift - for caps and common symbols (including programming / shell?) , M2 (diacritics and less common symbols) and M3 (other stuff)

Then when we have figured out what belongs in what category *then* we can argue what M2/M3 should be called FN/AltGr/Banana

 

[_wb_]

I am not taking away this real AltGr option some may think they need/want.

Yes you are. If you already have something that is called "AltGr" both in software and on the physical labels, then you can no longer make e.g. Right_Alt a 'real' AltGr without having horribly confusing stuff. For some symbols you would need combinations of the form 'real AltGr' + 'Pyra AltGr' + key.

 

[comradekingu]

Confusing AltGr is not something that can be undone by introducing a non-confused AltGr after the fact. Same as BXAY, its not a pandora layout, its a sega or ninendo layout with buttons in the wrong places.


Shift Second level


AltGr For alternate Graphics, third level


Shift+AltGr Fourth level


Meta Bonus fifth level


Shift+Meta Bonus sixth level


Meta+^for^ For the people that need it


Ctrl+alt For dead-key


All smooth sailing, with room for improvement on ^


Edit: Exchanging keyboardshift for ^ at option is the least complicated possibility i see. Even though that isnt very sleek.

 

[Grench]

Wow, some great replies.  Thank you!

If we can accept that the symbol keys should take precedence over the numbers keys, something very interesting can happen.

http://www.keyboard-layout-editor.com/#/layouts/5396ee5f893d78a100dcce1859febcd0

...

I think it shows promise.  What are your thoughts?

You're right...   that's an interesting concept...   I really like that bottom row of punctuation keys... but...

I've already got 2 devices that have the number keys as secondary symbols on the qwerty row.  Both are a real pain in the arse if I want to enter a number or especially if I have to alternate numbers and letters. (like in a password or a MAC address)   That's kind of left me burned on the concept, so at this point I'm not willing to give up the dedicated number row, and I think to convince me otherwise would require a working prototype, which isn't going to happen.  *shrugs*

- Neelix

The main point is, something has to give.  We have 3 concepts that we 'want' but can only have 2.  It's like a mechanics shop sign that says, "Speed, Price, Quality.  Choose any two."  In our case it is, "Numbers on top with symbols on the Fn OR symbols on top with numbers on the Fn.  Pick one.  There are trade offs either way and must be carefully considered.  There are MANY advantages to sinking those numbers to the Fn level, there is also a glaring disadvantage, but it might not be so bad as the other devices you refer to.

If we can accept that the symbol keys should take precedence over the numbers keys, something very interesting can happen.
http://www.keyboard-layout-editor.com/#/layouts/5396ee5f893d78a100dcce1859febcd0

Yet another really clever idea. Again, it feels wrong, and there are some obvious objective measures that say numbers are more important than brackets, but it does bring some good benefits. Do the benefits outweigh the cost of a secondary number row? Gonna have to ponder that.

On a different note, is there a good reason you've got the shoulder Fn and Shift being lock-able? Seems to me it causes more problems than it solves but I may be misunderstanding.

Benefits:

• Only 3 symbols per key.
• Uncluttered layout.
• True AltGr compatibility.  The right Alt on the keyboard.
• DosBox and QEMU compliant.  All US standard keyboard pairs are retained.
• Numbers and F1-F12 keys are both easily found and are contiguous.
• There is a HUGE amount of keys available for custom Fn mappings if you so choose.
• It still had room for a dedicated Diacritics key, which should ease AltGr use a bit.
• Diacritics key and nothing explicitly mapped to Fn+B means no need to have German characters explicitly written on the Fn+keys.  (I can explain this at length if someone needs.
• With F1-F12 and the number keys 1-0 on the same lockable Fn level, it opens them up as a 'hot key bank' for games that allow the user to program actions to keys.  This will be GREAT for first person shooters (Half Life anyone?) as well as MMORPGs or RPGs in general.
• Number keys and F1-F12 keys are VERY easy to find even in the dark with the back light off.  Just count keys from left to right.

Disadvantages:

• To type in numbers, you will need to press/hold one of the two Fn keys then select the number.
• To type in a long string of numbers, you will press BOTH Fn keys (keyboard AND shoulder) to _LOCK_ the Fn layer forward.  To undo the _Lock_, press both Fn keys again.
• Symbol keys have migrated from their 'normal' positions.  Can't be helped though.

Note, this is a first attempt at yet another completely different layout.  It will likely require some refining and adjusting.  It is posted here as an idea for thought and discussion.  It is a prop for the question of, "What if we gave symbols precedence over the number row."

I think it shows promise.  What are your thoughts?

I want to give brief feedback.  I probably have not yet any replies to this post.  The first thing I dislike, but that should not be a problem, is having "Pyra" (is it Super, Menu or something else?) on the spacebar.  I think it might be best to skip it if it won't have the logo and be in an attention grabbing and useful (in the Pandora sense) place. Tab seems annoying to use (two hands, or shoulder button, or locked to use Tab?).  Any key!!!

Are Fn and Shift sticky?  I am fine with those, but some seem to be opposed to sticky keys.  Being able to lock the numbers should be useful in many cases.  It might be better for some to go with a num pad layout, however that is probably "too different" without a number row.

There are good aand bad in the F1-F12 row.  Some will like that it is all on one row.  You can do shift+Fwhatever as far as I can tell.  It requires full F# markings on those keys, and are not associated with the numbers, but should be easy to learn pretty quick (4th key in second row is F4, same for number row).

The top row, above the nubs, has what I think ED wants there, but some are not primary.  I wish Esc was closer to the keyboard, however I can tolerate it there.  Does display brightness go up and down (and if so how?...I can guess the answer), or does it just keep stepping up until maximum brightness, and the next step is off/minimum?  Good choice on keeping 3G/4G and bluetooth as secondary functions.  With possible voice users these may become more important.  I can imagine problems from having Esc on the keyboard light button, but no clue if they would really happen more than once per user.

Is Delete on the c button?  Could the keys between the nubs cause problems in games/emus if used for start, select and, uh, pause, which in many games I play is done by pressing start (I understand it is the pause key, not in addition to start and select as gaming buttons, but it looks like it is).

I am interested in seeing what people who need more than just English have to say, and if it works for QEMU/DOSBox (I didn't compare it to a normal keyboard).

I hope my comments are useful.

The 'Pyra' and 'Any' key labels on the space bar are an ongoing joke from the first people making layouts.  They do not need to be there for any other reason other than it's a fun and running inside joke.  When the program asks you to, "Press any key to continue," there will be no doubt.  (laugh)

Fn and Shift are NOT sticky.  There are two Fn keys (keyboard and shoulder) and two shift keys (keyboard and shoulder).  Pressing both at the same time 'locks'.   So Shift+Shift = Caps Lock.  Fn+Fn = Fn Lock.

Top row hardware controls.  Esc needed to go somewhere a bit 'out of the way' so it didn't get confused into the other key sets.

Display brightness goes up AND down.  Press the LCD button and the brightness goes UP until maximum then stays there.  Hold one of the Shift keys and press the LCD button and brightness goes DOWN until it goes off then stays there (alternatively we could have excess brightness down presses go 3 steps up then continue down again?).  Keyboard brightness is Fn+Esc key to go up, Shift+Fn+Esc key to go down.  You don't have to use it.  Each of these functions will be adjustable in-menu as well.  Screen back light up is 'top level' on purpose - you can probably figure out why.

Delete is on the © button on the game pad, yes.  It is part of the set of Insert, Delete, Home, End, PgUp, PgDn.  I'm not sure how to answer the Start/Pause gaming controls question.

I'm interested in what the non English users have to say as well.  The fact that this has the dedicated Diacritics key, nothing mapped in several key spots for Fn and has true AltGr capability should help a lot.

This should work perfectly with QEMU/DOSBox.  All key pairs are retained.

Thank you for your comments - hopefully it will help clarify this for others as well.

On a different note, is there a good reason you've got the shoulder Fn and Shift being lock-able? Seems to me it causes more problems than it solves but I may be misunderstanding.

I can imagine some problems with locking shoulders as well.

It is the pair of Fn keys that lock each other and the pair of Shift keys that lock each other.  The fact that 1/2 of those pairs are on the shoulders is less relevant.

Shift+Shift = Shift _Lock_ (CapsLock)

Fn+Fn = Fn _Lock_ (numbers and F1-F12 keys locked forward)

 

[WizardStan]

It is the pair of Fn keys that lock each other and the pair of Shift keys that lock each other.  The fact that 1/2 of those pairs are on the shoulders is less relevant.

Ah, I got it now. For some reason I thought you had said double tap was lock, but that must've been someone else. Sorry, got confused.For the keyboard-only people, I probably would also suggest a double-tap = lock on the keyboard Fn and Shift, but that's a completely different discussion, one that can be had a long time from now, something we can change easily, even, after the Pyra has shipped.

edit: and just for technical sake, the locked key should be the keyboard one. If the keyboard shift is "L_SHIFT" then pressing "L_SHIFT" (keyboard) and "R_SHIFT" (shoulder) should lock "L_SHIFT". I'm assuming you already figured that as well but I think it's important to explicitly say.

edit edit: actually, is that even necessary? It's just a caps_lock basically, it doesn't need to lock a key code to make the system do the right thing. I'm an idiot, nevermind. We can replicate the same behavior with the Fn_lock.

 

[_wb_]

It is the pair of Fn keys that lock each other and the pair of Shift keys that lock each other.  The fact that 1/2 of those pairs are on the shoulders is less relevant.

Ah, I got it now. For some reason I thought you had said double tap was lock, but that must've been someone else. Sorry, got confused.
For the keyboard-only people, I probably would also suggest a double-tap = lock on the keyboard Fn and Shift, but that's a completely different discussion, one that can be had a long time from now, something we can change easily, even, after the Pyra has shipped.


edit: and just for technical sake, the locked key should be the keyboard one. If the keyboard shift is "L_SHIFT" then pressing "L_SHIFT" (keyboard) and "R_SHIFT" (shoulder) should lock "L_SHIFT". I'm assuming you already figured that as well but I think it's important to explicitly say.

I'm in favor of not labeling any locking mechanism, and let it be something user-configurable. I don't need any locking at all, since with shoulder modifiers it is comfortable enough to just hold down the modifier (and I don't like to accidentally get stuck in some locking mode). Others will like to have L_SHIFT + R_SHIFT for CAPS_LOCK (while yet others will prefer to have a SHIFT_LOCK, which is something else again). And yet others might like to have double-tap L_SHIFT for shift or caps lock. Or Fn+L_Shift. Or loooooooong press L_Shift, and get a rumble confirmation when caps lock becomes ayve. Or hold down shift while vigorously shaking the device. Or whatever.

My point is: no need to squeeze in *Lock labels on the keymat, we can better do it in software and let the user decide how they want their modifiers: sticky or not, locking or not, media buttons when the lid is closed or whatever.

 

[Grench]

It is the pair of Fn keys that lock each other and the pair of Shift keys that lock each other.  The fact that 1/2 of those pairs are on the shoulders is less relevant.

Ah, I got it now. For some reason I thought you had said double tap was lock, but that must've been someone else. Sorry, got confused.
For the keyboard-only people, I probably would also suggest a double-tap = lock on the keyboard Fn and Shift, but that's a completely different discussion, one that can be had a long time from now, something we can change easily, even, after the Pyra has shipped.


edit: and just for technical sake, the locked key should be the keyboard one. If the keyboard shift is "L_SHIFT" then pressing "L_SHIFT" (keyboard) and "R_SHIFT" (shoulder) should lock "L_SHIFT". I'm assuming you already figured that as well but I think it's important to explicitly say.

I'm in favor of not labeling any locking mechanism, and let it be something user-configurable. I don't need any locking at all, since with shoulder modifiers it is comfortable enough to just hold down the modifier (and I don't like to accidentally get stuck in some locking mode). Others will like to have L_SHIFT + R_SHIFT for CAPS_LOCK (while yet others will prefer to have a SHIFT_LOCK, which is something else again). And yet others might like to have double-tap L_SHIFT for shift or caps lock. Or Fn+L_Shift. Or loooooooong press L_Shift, and get a rumble confirmation when caps lock becomes ayve. Or hold down shift while vigorously shaking the device. Or whatever.

My point is: no need to squeeze in *Lock labels on the keymat, we can better do it in software and let the user decide how they want their modifiers: sticky or not, locking or not, media buttons when the lid is closed or whatever.

I'm glad the mechanism of this is starting to catch on, or at least be understood.  I think in practice it could become very natural to use and nearly intuitive.

I agree that it is something that can be driven in software to make it user configurable.  Lock, double tap sticky, long hold sticky, none of the above should all be easy to implement IFF the keys are present and arranged to support it (as in this layout).

BUT, I also think it is important at this stage to notate 'something' on the layouts that support this feature, even if it does not need to be explicitly labeled on the keys during production.  Why?  Because with the above layout and it's Fn-layered 1-0 and F1-F12 keys people are going to wrongly assume that they have to hold the Fn key to enter a chain of numbers (they don't as it can '_Lock_'.)

 

[Grench]

edit edit: actually, is that even necessary? It's just a caps_lock basically, it doesn't need to lock a key code to make the system do the right thing. I'm an idiot, nevermind. We can replicate the same behavior with the Fn_lock.

Yep - you got it.  It's as simple as that.

 

[Saber]

Updated my layout. A variety of changes. 

• Changed the name of the prime modifier from AltGr to Fn. Wrote what Fn really is, or might be, in the layout's summary block.
• Arranged the brackets to how they look on a U.S. keyboard(and probably several others). 
• Restricted the Shift + Fn values to only the usual U.S. shifted values for ` [ ] \ ; ' / which are ~ { } | : " ? and of course the German Umlauts and some additional diacritics(mentioned in the summary key). I didn't write it in but Fn + u could be dead key for the Caron diacritic. We'll see.
• Kept Euro instead of Section Sign on Fn + L. I think more people know of the currency symbol. This is a good location to remap over with lowercase and uppercase å æ ç or ż and the like if people loathe Compose sequences.
• Added a suggestion to have Print Screen, Scroll Lock, and Pause Break at the top two keys under Fn to the left of Power. Fn and the other two top keys, BT and WiFi, for _wb_ could be GPS and HDMI toggles. 
• Cleaned up the picture a little. 

I've been fighting a cold for the past week or more, so I apologize if I've been a little cranky and short-tempered. I dislike being sick now that the weather is warmer.    :wub:

Anyways... 

v1.1 http://i.imgur.com/uvEPf3B.png

Spoiler

A list of Compose key sequences can be found here.

Previous layouts in my sig.

 

[rygD]

The 'Pyra' and 'Any' key labels on the space bar are an ongoing joke from the first people making layouts.  They do not need to be there for any other reason other than it's a fun and running inside joke.  When the program asks you to, "Press any key to continue," there will be no doubt.  (laugh)

I know.  I was the one asking everyone to mark their space bars with "Any" in case it made it to the actual keyboards.  I still hope it does.  Please, ED, let us have this little joke.

I am not quoting each line I want to reply to...

I prefer sticky  FN and Shift.  I guess those that want only a single instance of each modifier on the keyboard and dislike sticky keys will be happy with your choice to lock by hitting key and button.  Sucks for the desk (dock?) users, or those that don't use shoulder buttons. 

Display brigthness button works how I thought.  My guess is that any user looking at it and wondering how to turn it down will get it pretty quick.  Thanks for the confirmation.

I was asking if using Start and Select in a game or emu would cause problems based on what the actual key is.  Someone with knowledge of a wide range of emus and such may need to give a best guess for that.  My comment about Pause didn't need a response, just know that it might confuse the people that are more familiar with console gaming than computer use since it is included under start and select which are found on some console controllers.

Thanks for the answers.  There are goods and bads, as with all of these layouts, however this is not one where I immediately notice tons of usability issues.  The locking F/number rows are nice, however it would take real use for me to see if it bugs me not having the numbers as primary functions.