Comparison matrix for keyboard layout proposals

[_wb_]

So the absolute worst aspect of any keyboard layout is the modifiers on mine, by unanimous decision with absolute weight...

Can you all read http://boards.openpandora.org/topic/18069-general-keyboard-design-layout-questions/#entry382899/URL]and tell me why that is the case?

I don't have to read all of that to diagnose the problem.

The problem is that you violate a quite important constraint (two Pyra-specific modifiers instead of just one), and no, it's not simply because you call it AltGr that it's not Pyra-specific.

Also, there are keys (the F-keys) that are not easily accessible because of that.

Shift+{Meta or AltGr} cannot be mashed, and you do not have a Super modifier.

So yes, your proposal just doesn't score well in terms of modifiers. It's a minor miracle that you even manage to assign weights in a way that makes it score well. Those weights are intellectually not very honest though, if you ask me.

 

[comradekingu]

So the absolute worst aspect of any keyboard layout is the modifiers on mine, by unanimous decision with absolute weight...


Can you all read http://boards.openpandora.org/topic/18069-general-keyboard-design-layout-questions/#entry382899/URL]and tell me why that is the case?

 
I don't have to read all of that to diagnose the problem.

Having read your answer, i still think you need to read it to give a coherent answer. 

.. it's not simply because you call it AltGr that it's not Pyra-specific.

I should think that its because its altGr, and in the case of shoulders, works as that same AltGr, and that AltGr exists on standard keyboards.


Modifier-keys that do F-keys are standard issue on keyboards that dont have dedicated F-row.


Thus, there are no pyra-specific modifiers included in my proposal. Mixing the two would make that 1. Since between its prevalence and functionality,


it becomes specific to the device it is on.

 
Shift+{Meta or AltGr} cannot be mashed, and you do not have a Super modifier.

Why would you need to mash shift+modifier if it werent for the fact that regional third level modifiers werent on a single button?

You even equated the functionality of meta with AltGr there, yet that is never the case.

Real fourth level modifier (shift+altGr) arent frequently used, so they dont need to be close together. Lest we forget regional fourth level modified symbols arent possible unless you

avoid mixing F-keys with a symbol-modifier, mixing the name of a shift modifier with the name meta, and mixing third level symbols and dedicated buttons onto the letterspace.

 

I'd much rather have easy 1 and 2, with a more difficult 3 when all are standard than

 

changed 1, invented 2, invented 3/possibly real 2

Where "inventions" range from removing dedicated letterkeys to putting symbols on letterkeys, tab or whatever else they dont belong on. Or straight up removing functionality.

I dont have super because its not used for anything in xfce. There are 2 hardware-modifiers, this which im sure isnt a zero in terms of modifiers, has none. Would you see it differently if i changed it? (according to current scores, no, everyone but me would still see it as the worst of the bunch by a wide margin)

I take it you think hardware-modifiers are irrelevant or that non-dedicated ones are just as good?

 
So yes, your proposal just doesn't score well in terms of modifiers. It's a minor miracle that you even manage to assign weights in a way that makes it score well. Those weights are intellectually not very honest though, if you ask me.

If you actually read my posts in this thread where i explain why, where i did ask you, not to pass on your assumptions, but actually defend the rationality behind the categories.

"My proposal is not particularly good at anything" does not equate balance.

 

[ible]

I like comradekingu's proposal, intriguing since it may be realizable to get two buttons out of the spacebar (pretty nice).  The biggest thing against it in my book is easily-misunderstood instructions, so it's hard to grasp what the multi-symbol buttons are doing (even still the instructions seem backwards).

And yes, it is less than ideal that you can't get all your F1-F12 keys easily.

I added two more rows in the matrix:  

• Home/PgUp/PgDn/End, Insert and Delete on facebuttons
• All standard symbols on lower keyboard only (including -+) [i.e., without using face buttons]

Thought people might have a preference for these things if they were included.

Link:  https://docs.google.com/spreadsheets/d/14mVNNzLhmhyA4sCIAPSoDv404xtctfLSiEMTtTlEzfw/edit

 

[comradekingu]

I aim to please, so here is super.  Sup-ørrrr, oui oui mounsieur zingu.

http://www.keyboard-layout-editor.com/#/layouts/8611950264c90c6df0c36f3ec1b653f3

Edit: Looking at things, the rightmost columnrow-button is really close to the buttoncluster. See here.

With that button being mod, it means another button its possible to utilize in games.

Super is also up for grabs in that regard. Le bon bon bonuuus, aje!

Edit: Its a question about what you lose, but i also think pressing delete feels wrong in a sense.

 

[_wb_]

One more single-width space layout, this time a "DosBox compatible" one, but also one with German and French in mind, and five dead diacritics (just found out that Portuguese uses tilde not just on ñ). Also no more than 3 labels per key, and no more Meta labels on backspace and enter.

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

It's layout "_wb_ 2bis" in the big matrix:

https://docs.google.com/spreadsheets/d/14mVNNzLhmhyA4sCIAPSoDv404xtctfLSiEMTtTlEzfw/edit?usp=sharing

I think this is about as close as you can get to a full US-QWERTY keyboard.

I would also be fine with removing the explicit labels for dead diacritics and äöü߀àèéç, since besides circumflex, they are in easy to remember places. It looks like this if you omit those:

http://www.keyboard-layout-editor.com/#/layouts/4e8cff95b5eaa543edaf0122d3834e26

 

[ible]

I'm not sure who added "blank keymat" but the way it is included in the matrix doesn't make sense.
 
A blank keymat can't have the max of each row. There are tradeoffs between the different layouts, which can't be achieved all at once.

Also I think it would be a huge step backwards for newcomers to the Pyra, who would want some good default.

 

[_wb_]

I'm not sure who added "blank keymat" but the way it is included in the matrix doesn't make sense.


A blank keymat can't have the max of each row. There are tradeoffs between the different layouts, which can't be achieved all at once.

Also I think it would be a huge step backwards for newcomers to the Pyra, who would want some good default.

I added it, as a kind of sanity check.

I also added the property "Every standard (ASCII) symbol labeled", and I completely agree that this is very important.

I added the "blank keymat" proposal mainly to illustrate that comradekingu's priorities/weights are a bit bogus, since he assigns so much weight to minimizing "clutter" that a blank keymat (which is of course very non-cluttered) is better than his own proposals according to his own metric.

 

[ible]

I made some small changes to my ible 3 layout (,. on the left), in the direction of my ible 2 layout:

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

If desired, <> can now switch places with ;: and there wouldn't be any other changes to the layout.

I see what you mean with blank layout, but I might change "max" to "average" to get a better idea.  

 

[Grench]

I'm not sure who added "blank keymat" but the way it is included in the matrix doesn't make sense.

A blank keymat can't have the max of each row. There are tradeoffs between the different layouts, which can't be achieved all at once.

Also I think it would be a huge step backwards for newcomers to the Pyra, who would want some good default.

I added it, as a kind of sanity check.I also added the property "Every standard (ASCII) symbol labeled", and I completely agree that this is very important.

I added the "blank keymat" proposal mainly to illustrate that comradekingu's priorities/weights are a bit bogus, since he assigns so much weight to minimizing "clutter" that a blank keymat (which is of course very non-cluttered) is better than his own proposals according to his own metric.

I see where you're going with that, but I think it can be done one or two better. How about adding the most standard of standard keyboards to the mix? Maybe an "IBM Model M" keyboard? http://en.wikipedia.org/wiki/Model_M_keyboard
Or maybe, since we're space confined, the compact version of the same keybaord?

http://en.wikipedia.org/wiki/Model_M_keyboard#/media/File:IBM_Model_M_Space_Saving_Keyboard.png

Incidentally, that is the keyboard I used as a basis for creating my original layout:

http://www.keyboard-layout-editor.com/#/layouts/3909b1ca9e87a590a89d24608b7a5de9

Of course, the Pyra has fewer keys than even a 'Space Saving' model M, so it had to be further compressed. If only we could center that space bar...

 

[_wb_]

I removed the blank keymat column, it was a bit silly and it's not nice to force everyone to give a huge weight to some trivial property like "the keys have labels".

 

[comradekingu]

I think the "dosbox compatible" category can be removed. US keyboard-pairs is a legitimate concern though.

I dont know, but does reinstating it with "mod" work for the people who are used to that sort of thing?

It is free for all of the keys that would have pairs.

 

[Eight Bit]

I added a column for my 2nd (by now, again revised) keyboard.

It doesn't score high but I'd work with it

http://www.keyboard-layout-editor.com/#/layouts/7b6e155fe43f204ba7570184d05cf066

 

[Grench]

I think the "dosbox compatible" category can be removed. US keyboard-pairs is a legitimate concern though.

I dont know, but does reinstating it with "mod" work for the people who are used to that sort of thing?

It is free for all of the keys that would have pairs.

No, it should not be removed. There are several layouts that are claiming DosBox compatibility by having the end user 'remember' US standard keyboard key pairs and use the 'root' key of the pair with shift or Fn+shift to generate the paired symbol. Although this may be a viable work around on the Pandora, it's far from ideal. If I press a key or combination labeled >, I expect it to generate a > symbol to every application. That is not the case in many of the layouts proposed.

It could/should be noted that retaining key pairs in symbol mapping is far more important than it may appear on the surface, and it is not easily overcome in application re-mapping.

http://boards.openpandora.org/topic/17881-its-the-keyboard-layout/?p=383115/URL]

With the Pyra and ExaGear there are going to be a lot more X86 Linux applications coming to the Pyra. The same issue of the applications reading shift+. is >, and a stand alone key labeled > is nothing, regardless of what is printed on the key, will likely persist in many of them.

Can we at least all finally agree that retaining the symbol pairs on the US standard keyboard is preferable? No, don't create a poll. That is simply asking for input from people who haven't read up on and understand the issue (see post linked above for the run-down). It -would- be appropriate, though, for everyone who does understand the importance of retaining symbol pairs to weight it accordingly in the keyboard matrix.

 

[WizardStan]

Can we at least all finally agree that retaining the symbol pairs on the US standard keyboard is preferable?

Of course we can't. As much as I'd like to I'm pretty sure it isn't going to happen, Saber and comradekingu have both been extremely adamant against it.

 

[Eight Bit]

How is the final keyboard going to be chosen again?

 

[Neelix]

I think the "dosbox compatible" category can be removed. US keyboard-pairs is a legitimate concern though.


I dont know, but does reinstating it with "mod" work for the people who are used to that sort of thing?


It is free for all of the keys that would have pairs.

No, it should not be removed. There are several layouts that are claiming DosBox compatibility by having the end user 'remember' US standard keyboard key pairs and use the 'root' key of the pair with shift or Fn+shift to generate the paired symbol. Although this may be a viable work around on the Pandora, it's far from ideal. If I press a key or combination labeled >, I expect it to generate a > symbol to every application. That is not the case in many of the layouts proposed.

Actually, if that were the case then the Pandora keyboard could be considered Dosbox compatible. It already works that way.  The whole point of the DosBox compatibility requirement is that you shouldn't have to remember that a symbol is at a different location in Dosbox than where it is labelled on the keyboard, so any keyboard that claims dosbox compatibility on the basis of "it works there but is unlabelled" is completely missing the point.

- Neelix

 

[Saber]

Can we at least all finally agree that retaining the symbol pairs on the US standard keyboard is preferable?

Of course we can't. As much as I'd like to I'm pretty sure it isn't going to happen, Saber and comradekingu have both been extremely adamant against it.

No, I am not against it. I want them paired up how they are in my layouts(like on a U.S. keyboard).

How is the final keyboard going to be chosen again?

It'll start out as Rock, Paper, Scissors, followed by a rigorous competition between entrants rubbing their stomach's while patting their heads the longest. It's all very scientific and incalculable to the average human.

 

[WizardStan]

No, I am not against it. I want them paired up how they are in my layouts(like on a U.S. keyboard).

Oh, sorry. I've missed some developments.

 

[_wb_]

Here's another one:

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

 

[Grench]

Can we at least all finally agree that retaining the symbol pairs on the US standard keyboard is preferable?

Of course we can't. As much as I'd like to I'm pretty sure it isn't going to happen, Saber and comradekingu have both been extremely adamant against it.

No, I am not against it. I want them paired up how they are in my layouts(like on a U.S. keyboard).

You have them paired up but hidden. For someone to use them, they would need to have memorized the US standard keyboard's paired sets.You also have the shifted version as a labeled unshifted Fn key, which is a 'false positive' resulting in people pressing those keys expecting that symbol and getting unpredictable or random results.

So, it's confusing AND misleading to do it that way. Just like it was confusing and misleading on the Pandora, which isn't a feature to repeat.