It's the keyboard layout.

[WizardStan]

Fortunately for the sake of rationality, ED prefers keys that are labeled nice and relatively squint-free and less busied, leaving the fourth level modified characters to user memorization, should they ever need them.

Well that's what I'm saying, if you can fit three characters on a key then you can fit a fourth. Period. No need to make anything smaller. If you need to squint with four characters than you'll need to squint with three as they'll all be the same size.

 

[Saber]

Fortunately for the sake of rationality, ED prefers keys that are labeled nice and relatively squint-free and less busied, leaving the fourth level modified characters to user memorization, should they ever need them.

Well that's what I'm saying, if you can fit three characters on a key then you can fit a fourth. Period. No need to make anything smaller. If you need to squint with four characters than you'll need to squint with three as they'll all be the same size.

But... if the numbers will also have fourth level values, then they must/should also be "printed" on those caps. Look at the number buttons on this here Pandora, which are identical in dimension to what they'll be on the Pyra. I don't see how anything on those keys won't be scaled down to fit a fourth mark, unless they are super cozy(=cluttered).  -_-

 

[_wb_]

But I'm still concerned that we don't know if the keyboard is capable of certain 3 key combos, bare in mind matrices can be odd being able to do certain multi key combos but not others...

It's a valid concern, but I think keyboard Fn/Meta should be a sticky modifier (like on the Pandora), and I would argue that keyboard Shift should also be sticky. So in that case we're not talking about combos but sequences. Also if you use shoulder button modifiers, it's obviously no problem since they're not part of the keyboard matrix.

 

[WizardStan]

Look at the number buttons on this here Pandora, which are identical in dimension to what they'll be on the Pyra

Ah yes, had forgotten how the Pandora labels were offset like that. I remembered square lined up labels. I'll have some thoughts on this. I'm still convinced it wouldn't be a problem to have a few keys with 4 labels on them, I'm just thinking of how best to present it.

 

[codifies]

Sticky modifiers should never be foisted on the end user, they are the domain of a configuration GUI, its up to the end user if they want to use sticky modifiers or keys without marmalade...

The Pandora keyboard is a busy as anything wants to be - any more and you'll never find what you're looking for!

 

[Grench]

But I'm still concerned that we don't know if the keyboard is capable of certain 3 key combos, bare in mind matrices can be odd being able to do certain multi key combos but not others...

It's a valid concern, but I think keyboard Fn/Meta should be a sticky modifier (like on the Pandora), and I would argue that keyboard Shift should also be sticky. So in that case we're not talking about combos but sequences. Also if you use shoulder button modifiers, it's obviously no problem since they're not part of the keyboard matrix.

I disagree.  No key should be 'sticky' unless modified by another key to 'lock' it AND the behavior of the keyboard keys should be the same as their corresponding shoulder buttons (left shift does the 'same' as right shift).

I thought this through and came to the conclusion that for shift+key combinations, sticky keys weren't really needed IF the modifier (shift) could be done with one hand's fingers while the other pushed the key selected.  By placing the shift and Fn keys close enough to be chorded (both at once), the same rule applies.

However, sometimes you want that caps-lock function.  Sometimes you might want the F1-F12 keys to stay forward.  Rather than holding shift or Fn for indefinite periods of time, there needs to be a way to 'lock' them.  My solution was to create a rule that when modifier keys were struck in pairs (shoulder shift + keyboard shift) that they should 'lock'.  I then applied that to Fn and liked the idea so much that I also applied it to Alt and Ctrl for consistency.  The Alt and Ctrl locks may be excessive.  I tend to err on the side of greater flexibility for the end user and assume the end user to be an intelligent agent - which may be argued as a false assumption.

 

[Grench]

Fortunately for the sake of rationality, ED prefers keys that are labeled nice and relatively squint-free and less busied, leaving the fourth level modified characters to user memorization, should they ever need them.

Well that's what I'm saying, if you can fit three characters on a key then you can fit a fourth. Period. No need to make anything smaller. If you need to squint with four characters than you'll need to squint with three as they'll all be the same size.

But... if the numbers will also have fourth level values, then they must/should also be "printed" on those caps. Look at the number buttons on this here Pandora, which are identical in dimension to what they'll be on the Pyra. I don't see how anything on those keys won't be scaled down to fit a fourth mark, unless they are super cozy(=cluttered).  -_-

5 and % are probably the largest symbols on the Pandora number rows.  If you look at the picture, the blue F5 is spaced to the right of the % sign.  It could easily be moved UNDER the % sign with no reduction in clarity of purpose.  A 4th symbol could then be added up & right of it.  With the color differentiation, there is no confusion about what key or key combination does what.  However, you wouldn't want to do this with any F1-F12 keys since Shift+F1 already has meaning, much like shift+A does.

I could also argue that this key already has 4 symbols on it.  5, %, F, 5.

Obviously I prize clarity of function over 'empty space'.  There is plenty of room on these buttons for 4 symbols - as shown in the Pandora example above.  What there isn't room for is a bunch of wasted empty space at the expense of actually communicating to the end user what the function of that button under a given circumstance actually does.

 

[_wb_]

Sticky modifiers should never be foisted on the end user, they are the domain of a configuration GUI, its up to the end user if they want to use sticky modifiers or keys without marmalade...

The Pandora keyboard is a busy as anything wants to be - any more and you'll never find what you're looking for!

Yes, I agree that it would be a good thing if the keyboard matrix allows non-sticky modifier keys in all possible combinations. I'm just saying that even if it doesn't, there's still the shoulder modifiers and the option of sticky keyboard modifiers. According to my personal taste, shoulder modifiers are the superior method anyway.

I also agree that we should avoid things to look busy, so just the ASCII characters on the labels would be fine. We don't need € £ ¥ § like on the Pandora, and I would argue against having labels for Ä Ö Ü ß on the keymat, though it's fine to have those in the default keymap, preferably at Meta+AOUS.

 

[comradekingu]

Clarity of function is mutually exclusive to filling up the 'empty space'

 

[codifies]

Guys lets not have this...

 

[comradekingu]

View attachment 11076  94 prints.

Spoiler

 

[codifies]

 

Spoiler

nr68text2.png

I just know people are going to hate this but all the other stuff can go in the regionalised case or interchangeable template

Clean, simple, elegant - easy to find stuff....

 

[Neelix]

Guys lets not have this...

pyra.png

I'm sorry, but that's just being absurd. There's been no call to have key labels that are that crowded. With what Grench (among others) has been suggesting letter keys would have at most 3 symbols, while number and punctuation keys would have at most 4.

I would also argue that the main number and symbol labels on the Pandora's number keys would only need to be marginally smaller to fit vertically stacked, (The F-key labels prove that smaller labels can still be legible and those are smaller than they need to be IMHO) and the keys are wide enough to leave a nice gap between symbol pairs to avoid looking cluttered.

Personally I would leave the international letter key symbols off the keymat anyway, as the optimal layout for those will vary from language to language. I would recommend coming up with standard mappings for each of the most common languages though and allowing the user to select those mappings on first boot. (and switchable via the config button) For those I'd suggest including a program that can be activated via the config button applet that (when active) shows the current mapping of those keys on an framebuffer overlay when AltGr/Fn is pressed.

- Neelix

 

[codifies]

Guys lets not have this...

pyra.png

I'm sorry, but that's just being absurd....

...errrm it *was* a joke / OTT exaggeration... well kind of....

 

[Grench]

 

Spoiler

nr68text2.png

Spoiler

I just know people are going to hate this but all the other stuff can go in the regionalised case or interchangeable template

Clean, simple, elegant - easy to find stuff....

Sorry to disappoint, but can we please put this one to rest?  It simply will not work.

Not DosBox/QEMU compatible.  Keys and their shifted pairs are broken.

Not desktop/dock compatible.  Keyboard cannot be used without the shoulder buttons accessible.

Illogical/random symbols to decipher and guess at instead of clear markings.  Game pad symbols do not exist in any 'normal' character set.  

Use of 6 colors for key tops (black, purple, yellow, red, blue, green) would rapidly escalate production costs.

Several keys from a standard keyboard are simply missing.  Where is the Escape key?  Print screen?

Symbol keys are seemingly randomly placed far from their original positions.

Commonly used Linux command line keys are difficult to find and use.  Took me a bit to even find ~.

Mixed key background color may be eye catching but will not be possible unless you want to finance TWO keymats.  The design as pictured would requre SIX individual keymats to handle the key background color changes (yes it's black and white - but look at the positions and carve it up).

Sorry CK, but I consider this layout and scheme to be dead on arrival.  It's pretty in a techno-fusion-disco kind of way, but it is completely impracticable.

 

[_wb_]

Minor iteration of my proposal: http://www.keyboard-layout-editor.com/#/layouts/e1b05961a2c31a6b89288597b9642ae6

Slightly tweaked the label layout.

Added five explicit dead key diacritics as meta-keys: acute, umlaut, grave, caron and circumflex. I think that covers a lot of languages. Plenty of letter keys are still empty, so you can still put Ä€ÖÜß on Meta+AEOUS if you're German and have other mappings (e.g. these: http://www.keyboard-layout-editor.com/#/layouts/86df760fd41803365c8390943101d4e1)to have direct access to your popular special letters. But I would prefer not to print those on the keymat.

Preferably I would make it a bit more obvious that the dead diacritics are actually dead diacritics, e.g. by making them look like this: ◌́ 

(but the placeholder dotted circle should be really thin and the actual diacritic should be big and fat).

 

[Saber]

Fortunately for the sake of rationality, ED prefers keys that are labeled nice and relatively squint-free and less busied, leaving the fourth level modified characters to user memorization, should they ever need them.

Well that's what I'm saying, if you can fit three characters on a key then you can fit a fourth. Period. No need to make anything smaller. If you need to squint with four characters than you'll need to squint with three as they'll all be the same size.

But... if the numbers will also have fourth level values, then they must/should also be "printed" on those caps. Look at the number buttons on this here Pandora, which are identical in dimension to what they'll be on the Pyra. I don't see how anything on those keys won't be scaled down to fit a fourth mark, unless they are super cozy(=cluttered).  -_-  

Spoiler

Spoiler

5 and % are probably the largest symbols on the Pandora number rows.  If you look at the picture, the blue F5 is spaced to the right of the % sign.  It could easily be moved UNDER the % sign with no reduction in clarity of purpose.  A 4th symbol could then be added up & right of it.  With the color differentiation, there is no confusion about what key or key combination does what.  However, you wouldn't want to do this with any F1-F12 keys since Shift+F1 already has meaning, much like shift+A does.

I could also argue that this key already has 4 symbols on it.  5, %, F, 5.

Obviously I prize clarity of function over 'empty space'.  There is plenty of room on these buttons for 4 symbols - as shown in the Pandora example above.  What there isn't room for is a bunch of wasted empty space at the expense of actually communicating to the end user what the function of that button under a given circumstance actually does.

Sure, let's say it's possible then because we want it to be.  :mellow:

 

[_wb_]

Fortunately for the sake of rationality, ED prefers keys that are labeled nice and relatively squint-free and less busied, leaving the fourth level modified characters to user memorization, should they ever need them.

Well that's what I'm saying, if you can fit three characters on a key then you can fit a fourth. Period. No need to make anything smaller. If you need to squint with four characters than you'll need to squint with three as they'll all be the same size.

But... if the numbers will also have fourth level values, then they must/should also be "printed" on those caps. Look at the number buttons on this here Pandora, which are identical in dimension to what they'll be on the Pyra. I don't see how anything on those keys won't be scaled down to fit a fourth mark, unless they are super cozy(=cluttered).  -_-  

Spoiler

Spoiler

5 and % are probably the largest symbols on the Pandora number rows.  If you look at the picture, the blue F5 is spaced to the right of the % sign.  It could easily be moved UNDER the % sign with no reduction in clarity of purpose.  A 4th symbol could then be added up & right of it.  With the color differentiation, there is no confusion about what key or key combination does what.  However, you wouldn't want to do this with any F1-F12 keys since Shift+F1 already has meaning, much like shift+A does.

I could also argue that this key already has 4 symbols on it.  5, %, F, 5.

Obviously I prize clarity of function over 'empty space'.  There is plenty of room on these buttons for 4 symbols - as shown in the Pandora example above.  What there isn't room for is a bunch of wasted empty space at the expense of actually communicating to the end user what the function of that button under a given circumstance actually does.

Spoiler

Sure, let's say it's possible then because we want it to be.  :mellow:

The Pandora has a Pyra-sized key with the label "SELECT CTRL" on it. Are you claiming that it is logically impossible to have a key on the Pyra with a label, say, "S E L E"? And if "S E L E" is possible, then why not something like  ", < ; :"  ?

Please note that I'm not arguing in favor of having 4 labels on every key; in fact I still want to avoid cluttering the keymat with too many labels. But frankly, I think my layout proposal looks less cluttered than yours. You have labels for  ä ö ü ß µ § € and caps lock, all of which are missing (or at least not printed) in my proposal. To be fair, my proposal is 'cluttered' with labels for ¨ ˇ ˆ ⎄, which you don't have, but I still think yours would look more cluttered.

 

[Saber]

Fortunately for the sake of rationality, ED prefers keys that are labeled nice and relatively squint-free and less busied, leaving the fourth level modified characters to user memorization, should they ever need them.

Well that's what I'm saying, if you can fit three characters on a key then you can fit a fourth. Period. No need to make anything smaller. If you need to squint with four characters than you'll need to squint with three as they'll all be the same size.

But... if the numbers will also have fourth level values, then they must/should also be "printed" on those caps. Look at the number buttons on this here Pandora, which are identical in dimension to what they'll be on the Pyra. I don't see how anything on those keys won't be scaled down to fit a fourth mark, unless they are super cozy(=cluttered).  -_-  

Spoiler

Spoiler

5 and % are probably the largest symbols on the Pandora number rows.  If you look at the picture, the blue F5 is spaced to the right of the % sign.  It could easily be moved UNDER the % sign with no reduction in clarity of purpose.  A 4th symbol could then be added up & right of it.  With the color differentiation, there is no confusion about what key or key combination does what.  However, you wouldn't want to do this with any F1-F12 keys since Shift+F1 already has meaning, much like shift+A does.

I could also argue that this key already has 4 symbols on it.  5, %, F, 5.

Obviously I prize clarity of function over 'empty space'.  There is plenty of room on these buttons for 4 symbols - as shown in the Pandora example above.  What there isn't room for is a bunch of wasted empty space at the expense of actually communicating to the end user what the function of that button under a given circumstance actually does.

Spoiler

Sure, let's say it's possible then because we want it to be.  :mellow:

Spoiler

The Pandora has a Pyra-sized key with the label "SELECT CTRL" on it. Are you claiming that it is logically impossible to have a key on the Pyra with a label, say, "S E L E"? And if "S E L E" is possible, then why not something like  ", < ; :"  ?

Please note that I'm not arguing in favor of having 4 labels on every key; in fact I still want to avoid cluttering the keymat with too many labels. But frankly, I think my layout proposal looks less cluttered than yours. You have labels for  ä ö ü ß µ § € and caps lock, all of which are missing (or at least not printed) in my proposal. To be fair, my proposal is 'cluttered' with labels for ¨ ˇ ˆ ⎄, which you don't have, but I still think yours would look more cluttered.

What I think is it will be much more difficult for your layout and the others to garner acceptance without the four labels per key wile. 

Seriously though, ", < ; : " ? per key? Even four in a line would be farcical, and we haven't even considered the backlight penetration. How small will the dots in ; and : become then? I'd say very but you'd likely say not much.   

 

[rygD]

The AltGr + Shift values wouldn't get a print. Space on the key's caps is just too limited for them to fit. 

This is the sort of stuff that is important to know.  You may have said this many times and I somehow still missed it.  Since we now have the layout popularity poll this is important to consider (I don't remember how you get each thing on your layouts, so I will take a look again in a few).  It could have a heavy impact on the usability of a layout if commonly used characters are not found when looking at the keyboard.   Would you be willing to modify the version of your layout that somebody put into the layout editor thing most others are using to reflect the actual appearance of your layouts, and include notes on how things are done, including things that may not be printed on keys?