Comparison matrix for keyboard layout proposals

[ible]

I disagree.  With a different weighting scheme (e.g. yours), you can see that your keyboard comes out at the top.  This matrix is quite good at encoding our preferences, though it may miss some of our general taste for things.

 

[_wb_]

I added a row for my "Code combos" (a rough selection, with a rough grading on how easy a given combo is:  1 for keys on top of or next to each other, 0.5 for keys that are one away, and then some subjectiveness thrown in).  Also I think your summation formulas were wrong for everyone but ED (it was starting to go down from row 3 to row 4, 5, etc. for the start of the selections, but you may want to double check my changes).

Outright winner of the max code combo is Grench's new keyboard which has a snowball's chance in hell .  Runner up is Saber's new one, due to some of his alternate shifts.

This matrix actually has a really nice way of quantifying our own preferences .  Like how I don't like _wb_'s latest, but prefer his earlier (_wb_ 2).  Fun to see them come out like this.

More important topic:  Will ED care/listen to investigate and have a poll of his favorites?

This "code combos" concept in itself I like, but your selection of combos is a bit weird to me. Of course the selection heavily depends on the programming language and even the type of program you're coding.

For example, in Prolog I need :- a lot, and a bit of -> and ==> and <=>.

In C++ I need e.g. {} and ->

When writing HTML/XML, you need a lot of </>

and so on...

 

[_wb_]

Thanks, ible and comradekingu, for adding properties to the comparison table!

I added a few myself, like F-keys on corresponding numbers or all in a row on the QWERTY-row.

Here's the link again, for convenience:

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

To everyone: please add your own priorities/weights, so we can get more representative aggregated opinions!

To comradekingu: please check your weights. You have set a lot of negative weights, which is a bit weird. If there's something you don't care about, a weight of zero makes sense. If it's something you really don't like for some reason, it can make sense to have negative weights (e.g. I gave negative weights to having a third Shift key because I think that's a bad idea, and also to having German symbols äöüß, because not only I don't need them (which would justify weight zero), but they make it look German-centric which I don't like, justifying the negative weight). I think you are giving negative weights to things not because you dislike them, but because they somehow might imply other things you don't like, but then I think it's better to split things up and give positive weights to the good things and negative weights to the bad things, instead of also giving negative weights to the good things that might imply bad things. E.g. you give a big negative weight to the property "Only one Pyra-specific modifier" but I suspect that's mostly because you want to keep the letter keys free of extra labels, which is impossible if you have only one Pyra-specific modifier. Or you give a negative weight to the property of having both Shift and Meta/Fn/whatever on the bottom part of the keyboard, but I don't really see why anyone would be opposed to that, in itself. Of course it implies that less keys are available for other things, like P+2 L+2, but then you should give a higher weight to those other things, instead of punishing the good thing that implies the bad things. Now it looks as if you think my proposal would become better by moving its Shift and Meta keys from the bottom left to the top row, which is nonsense.

Also some properties were added like "Amount-of-keys-on-buttons-they-dont-belong-on", which is something that is not clearly defined. Please make well-defined properties, so the meaning is not ambiguous.

Now: can anyone convince ED to look at this comparison table, correct the preliminary numbers we have put in 'his' column, and tell us which properties we missed? That would be great

 

[ible]

Good point, I just did a random smattering of coding symbols.  I will add in a few more (-> and />), but some of the rest of yours are close to the others I already have (=> ==> <=>, etc.).  Also I would hope that {} are next to each other, so that would be a plus 1 for everyone.

Also, it's ok if comradekingu puts large negative weights in; I normalized everyone's score to go between 0 (min they can give) and 100 (max they can give to a layout).  Primarily because it looked like comradekingu was trying to swing the average in his favor .

Of course, the real average (community-wise) would need many more people's weights.  So the average is a bad indicator now anyways.

 

[ible]

Also, not sure what happened, but now one of mine is ED's favorites.  Did I mess something up?

 

[_wb_]

Also, not sure what happened, but now one of mine is ED's favorites.  Did I mess something up?

No, I just modified ED's column because it contained some numbers that were not based on anything at all. In any case I wouldn't take the "ED" results too seriously at the moment, because after all, ED himself hasn't even looked at the table afaik

 

[comradekingu]

"Only one pyra specific modifier" to me means having AltGr in with F-keys and mediabuttons.  Which i have never seen before, and it also means less of an AltGr key that im used to. Even less when you consider the symbols from the F-row are thrown around.

 

Which brings us to the important part of clutter, Amount-of-keys-on-buttons-they-dont-belong-on is very clearly defined.

 

You will never find symbols on letterkeys on a real keyboard. This is where the line between toy and real is for me.

 

If i expand on that, its to have 2perkey, which isnt something that can be done overall.

 

Junk on buttons other than letters is the category for putting ' on tab, or ~ on backspace.

 

Buttons on keys they don't belong on, is the category for putting escape on Q.

 

Its not even like there are 4 prints on each key, but they are thrown together. I think we are joking ourselves if we pretend those two things are the same.

 

I see having a fuller layout as much more keyboard-like than having ctrl and shift at the bottom row. Remappable-things on P+2 and L+2 doesnt answer the full question as to why reduced is worse.

 

I would value (wbs) layout more if shift was on the same side of the keyboard as , .   Since that avoids slalom-typing. Which isnt a category.

 

Furthermore doing so would enable you to put , to the left of space and . to the right. Which means more efficiency. Which isnt a category.

It also means you wouldnt have to do

,<;

.>:

 

Which isnt a category.

 

Which alone is enough to cancel out the familiarity of having the main shift on the left for me.

 

It thats me swinging the vote, then i dont know. I dont care about my own vote. What bothers me is that the things wb has considered with his categories, there isnt any room to compete.

 

75 vs 113 (!) symbols only amounts to 4 points difference. I could give the normal extensive summary about why that is bad, but lets just sum it up by saying the clutter-category needs some incentive to avoid clutter.

 

And yes, i would give negative points for shoulder "alt" and shoulder "altGr" -functionality having to be via-remapped to do their things. If that was a category.

 

Edit: If you add 100 keys with 4 labels on them, wb automatically rating goes to 100% and others go to 0. Strange.

 

[WizardStan]

You will never find symbols on letterkeys on a real keyboard.

The standard German keyboard, which has @ printed under Q, € printed under E, and μ printed under M, begs to differ.

 

[comradekingu]

Ok, i see that, some minor less negative rating could be employed for those.

Those symbols being there on one of the keyboards, does not explain them on others. Least of all it explains the notion of bringing in things at random.

If we assume the mass of people are used to a normative keyboard, we should treat that as a guideline. So long as it doesnt exclude.

Visuals is the first hurdle to overcome. First impressions matter a whole lot when buying something. If i see anything out of place im much more likely to scrutinize the rest of it with that negative sentiment in mind.

 

[_wb_]

[...] Which isnt a category.


[...] Which isnt a category.


[...] Which isnt a category.


[...]  If that was a category.

You are free to add rows to the table if you think there is something that is missing.

Edit: If you add 100 keys with 4 labels on them, wb automatically rating goes to 100% and others go to 0. Strange.

Not so strange. I give a positive weight to the number of keys. So if you add 100 keys, no matter how many labels they have, it will be better.

 

[Grench]

I made some updates to the spreadsheet to correct some misconceptions around my layout.  

I've gotten the idea that many of you simply can't get past the numbers on Fn key thing.  I don't think you're seeing the big picture.  EVERY layout is going to make some compromise(s).  DosBox (Symbol pairs), programming priorities, editing priorities, capable of TRUE AltGr usage, keeping the key cap symbol counts down, etc.  By putting the numbers on the Fn layer I was able to eliminate ALL of the other compromises.  Yes, that is a bold claim.  See if you can prove me wrong.

http://boards.openpandora.org/topic/16872-and-now-for-something-completely-different-keyboard-option/?p=382406

Yes, putting the numbers on the Fn level IS a compromise, but it isn't as bad as you might think.  If that is the cost for ELIMINATING all of the other compromises, I think it's worth it.

 

[_wb_]

I made some updates to the spreadsheet to correct some misconceptions around my layout.  

I've gotten the idea that many of you simply can't get past the numbers on Fn key thing.  I don't think you're seeing the big picture.  EVERY layout is going to make some compromise(s).  DosBox (Symbol pairs), programming priorities, editing priorities, capable of TRUE AltGr usage, keeping the key cap symbol counts down, etc.  By putting the numbers on the Fn layer I was able to eliminate ALL of the other compromises.  Yes, that is a bold claim.  See if you can prove me wrong.

http://boards.openpandora.org/topic/16872-and-now-for-something-completely-different-keyboard-option/?p=382406

Yes, putting the numbers on the Fn level IS a compromise, but it isn't as bad as you might think.  If that is the cost for ELIMINATING all of the other compromises, I think it's worth it.

Sorry but I have to correct a few of your changes. Didn't you think it was a bit weird that according to the table, I like your proposal more than I like any of my own proposals?

"Everything behind at most 1 modifier" : your proposal does not have this property, e.g. all the shift-numberrow symbols !@#$%^&*() are behind two modifiers (Shift+Fn).

"Full ISO keyboard (hardware Fn)" -> only B-Zar's proposal has this. Yours does not, unless you are prepared to accept the consequence that games can only use 3 of the shoulder buttons. If that's what you intend, then I will add a row for "All shoulder buttons can be used in games". But I think that's not what you meant.

"Has Super modifier?" -> Your proposal has Super at Fn+Space, so yes, it 'has' a Super modifier. But a modifier that is not a primary key, that's a pretty weird concept, and I don't see how this is practical at all. I don't even know if it would work. For example, in Ubuntu, Super+numbers and Super+letters are both used in shortcuts by default. How would this work in your layout? Not only would it be very uncomfortable, but how would there be any difference between Super+W and Super+2, since both would be Fn+Space+W?  So in summary, I think you cannot claim that you really have a Super modifier. I set the value to 0.1 and not 0 to account for the fact that you do have a Super key labeled, but I don't think it could really be used as a modifier.

"Unlabeled, easy to remember diacritics" -> You had repeated the 4 labeled diacritics here, which would mean they get double-counted. Fixed that. So that leaves only ~. I don't see where you put dead tilde though, so please explain. It's not at the ` ~ F1 key (because there's no room on that key for a dead tilde, it already has Fn and Shift-Fn actions).

"P+2, L+2" available -> I'll accept your argument that even P+3, L+2, M+3 are available since you have dedicated keys for [ ] \ ; ' , . /. But the fact that those keys are not in their normal position should be taken into account, if you ask me. You have L+2 at M+2 and P+2 below CVB, so in terms of muscle memory and expectations, that's pretty weird. Keep in mind that someone who is used to, say, a German keyboard typically does not even know that [ ] ; ' are the keys that are on P+2, L+2 on a US-QWERTY keyboard, because on German keyboards you would have Ü + Ö Ä at those positions. I'll solve this by adding another row to distinguish between the P+2, L+2 keys and their actual position.

Here's the link again, for convenience. Now at least I'm back to liking my own proposal, which makes sense

https://docs.google.com/spreadsheets/d/14mVNNzLhmhyA4sCIAPSoDv404xtctfLSiEMTtTlEzfw/edit#gid=1574311258

 

[Grench]

I made some updates to the spreadsheet to correct some misconceptions around my layout.  

I've gotten the idea that many of you simply can't get past the numbers on Fn key thing.  I don't think you're seeing the big picture.  EVERY layout is going to make some compromise(s).  DosBox (Symbol pairs), programming priorities, editing priorities, capable of TRUE AltGr usage, keeping the key cap symbol counts down, etc.  By putting the numbers on the Fn layer I was able to eliminate ALL of the other compromises.  Yes, that is a bold claim.  See if you can prove me wrong.

http://boards.openpandora.org/topic/16872-and-now-for-something-completely-different-keyboard-option/?p=382406

Yes, putting the numbers on the Fn level IS a compromise, but it isn't as bad as you might think.  If that is the cost for ELIMINATING all of the other compromises, I think it's worth it.

 Sorry but I have to correct a few of your changes. Didn't you think it was a bit weird that according to the table, I like your proposal more than I like any of my own proposals?

Not really. It has everything that you want BUT the numbers are on the Fn level.

"Everything behind at most 1 modifier" : your proposal does not have this property, e.g. all the shift-numberrow symbols !@#$%^&*() are behind two modifiers (Shift+Fn).

If Fn+Shift are paired and mashable both on the keyboard AND on the shoulders, that is one modification action. This is different and distinguishable from something that requires 3 fingers and 3 'strokes' to get to those layers. Maybe it's something 'in between', but it is definitely closer to 1 modifier action than it is to 2 distinct modifier actions.

"Full ISO keyboard (hardware Fn)" -> only B-Zar's proposal has this. Yours does not, unless you are prepared to accept the consequence that games can only use 3 of the shoulder buttons. If that's what you intend, then I will add a row for "All shoulder buttons can be used in games". But I think that's not what you meant.

Ahh - I was under the interpretation that this requirement was based around having all keys present from a 105 key US keyboard.

"Has Super modifier?" -> Your proposal has Super at Fn+Space, so yes, it 'has' a Super modifier. But a modifier that is not a primary key, that's a pretty weird concept, and I don't see how this is practical at all. I don't even know if it would work. For example, in Ubuntu, Super+numbers and Super+letters are both used in shortcuts by default. How would this work in your layout? Not only would it be very uncomfortable, but how would there be any difference between Super+W and Super+2, since both would be Fn+Space+W?  So in summary, I think you cannot claim that you really have a Super modifier. I set the value to 0.1 and not 0 to account for the fact that you do have a Super key labeled, but I don't think it could really be used as a modifier.

I think I see the confusion. The 'Pyra' Graphic on the space bar was simply decoration. My interpretation of 'Super' was essentially a 2nd modifier capability, which I have in a true AltGr capability (if the end user chooses to activate it.) There wasn't a classification for keyboards that could actually become international by activating the right Alt as AltGr.

"Unlabeled, easy to remember diacritics" -> You had repeated the 4 labeled diacritics here, which would mean they get double-counted. Fixed that. So that leaves only ~. I don't see where you put dead tilde though, so please explain. It's not at the ` ~ F1 key (because there's no room on that key for a dead tilde, it already has Fn and Shift-Fn actions).

Dead ~ exists IFF the end user activates the AltGr key/layout. All 5 dead keys then exist in their US International layout positions. The keyboard under AltGr maps as:http://www.keyboard-layout-editor.com/#/layouts/2a0d638adab6a5b607c27fc6d3af6f14

Please excuse the removal of much of the text. The layout editor has a net code limit that I've reached with all of the color coding and sup/sub flags needed to make those symbols line up right.

In the case of an international user with AltGr enabled, it works as AltGr+~ then the key to be modified to result in being able to input the following:

ã ñ õ Ã Ñ Õ

See this page in how to create symbols on a US standard keyboard with AltGr activated on Right alt:

http://www.forlang.wsu.edu/help/keyboards1.asp

"P+2, L+2" available -> I'll accept your argument that even P+3, L+2, M+3 are available since you have dedicated keys for [ ] \ ; ' , . /. But the fact that those keys are not in their normal position should be taken into account, if you ask me. You have L+2 at M+2 and P+2 below CVB, so in terms of muscle memory and expectations, that's pretty weird. Keep in mind that someone who is used to, say, a German keyboard typically does not even know that [ ] ; ' are the keys that are on P+2, L+2 on a US-QWERTY keyboard, because on German keyboards you would have Ü + Ö Ä at those positions. I'll solve this by adding another row to distinguish between the P+2, L+2 keys and their actual position.

It's a thumb keyboard. Muscle memory isn't so relevant.VERY fast access to Ü Ö Ä is driven by simply touching the Diacritic Key then U, O or A. That is available without even pressing Fn or activating the AltGr.

Arguably, Ü Ö Ä are not explicitly labeled, but are VERY accessible and clear. As are:

ç Ç

á é í ó ú ý

Á É Í Ó Ú Ý

ä ë ï ö ü ÿ

Ä Ë Ï Ö Ü Ÿ

à è ì ò ù

À È Ì Ò Ù

â ê î ô û

I have considered adding ~ as a 5th no AltGr dead key by placing it on the Fn -_ key and ß on Fn+S to complete the set, but then the clutter police would chase after me.

Here's the link again, for convenience. Now at least I'm back to liking my own proposal, which makes sense

https://docs.google.com/spreadsheets/d/14mVNNzLhmhyA4sCIAPSoDv404xtctfLSiEMTtTlEzfw/edit#gid=1574311258

Thank you for the efforts in setting this up. I hope it continues to generate good feedback and discussion.

 

[levi]

I'll just point out that it makes a difference whether you leave a cell blank or put in 0 in your weightings, because of the way the averaging works, at least on OpenCalc which I use. If you leave it blank, it eliminates it from the average (averaging over one less value), whereas if you put 0 in it bring the average towards 0 accordingly.


i.e. if the weights are 10, 0 and 17 the average is 9, whereas if you put the 0 as blank it would be 13.5. Personally I use blank rather than 0, as blank corresponds to either 'I don't understand this category', or 'I couldn't care less'. If I dislike a category I put a negative number, if approve, I put positive - I don't know what putting 0 would signify.

 

[_wb_]

I'll just point out that it makes a difference whether you leave a cell blank or put in 0 in your weightings, because of the way the averaging works, at least on OpenCalc which I use. If you leave it blank, it eliminates it from the average (averaging over one less value), whereas if you put 0 in it bring the average towards 0 accordingly.


i.e. if the weights are 10, 0 and 17 the average is 9, whereas if you put the 0 as blank it would be 13.5. Personally I use blank rather than 0, as blank corresponds to either 'I don't understand this category', or 'I couldn't care less'. If I dislike a category I put a negative number, if approve, I put positive - I don't know what putting 0 would signify.

Putting 0 would mean "I actively think that this is a criterion that should not matter".

But the average of the weights no longer matters, the overall aggregate is computed in a fairer way.

 

[levi]

Oh? Would anyone mind making me an ods export so that I can see?

 

[_wb_]

Here's a snapshot of how it looks now:

comparison_table_May_1_2015.zip

 

[comradekingu]

If you make a clean version, i can put up some questions i think make sense.

 

[_wb_]

If you make a clean version, i can put up some questions i think make sense.

A clean version of what?

 

[Urben]

One question, if one property is colored red at higher numbers and green in lower numbers, does that mean the higher the worse? If I prefer the higher ones, do I have to use a negative score on it?