Comparison matrix for keyboard layout proposals

[_wb_]

I'm not keeping the ods file up-to-date, but I guess I could export an .ods from the google docs spreadsheet...

Keyboard-based modifiers are not explicit in the sheet on one row, but the number of keys for each modifier is. So there's the number of Shifts, Alts, Ctrls, and Metas. If that number is 2, than it's safe to assume that not both of them will be on the shoulder buttons. If the number is 1, it doesn't say the location though.

Also no distinction is made (at least not in the numbers) between having e.g. Ctrl where SELECT is (like on the Pandora), and having Ctrl in the main keyboard area (bottom left or right, like on a normal keyboard). The Grench proposals do that for Ctrl and Alt. All the proposals have Shift in the main keyboard area, and almost all of them have Meta/Fn/AltGr there as well (exception being comradekingu).

So what would be a suitable spreadsheet row? Number of different modifiers in the main keyboard area? Then the answers would be 1 (ck), 2 (everyone else) or 4 (Grench). Number of modifiers somewhere on the keyboard? Then everyone has all 4 of them.

 

[levi]

I'd say a simple true/false; do all modifiers that are necessary to produce all keys the keyboard can produce on both shoulders and in the keyboard area?  That's the nub of the requirement as I understand it.  Or maybe you could split it into two booleans; one for desktop use, testing if all needed modifers are on the keyboard, and then for handheld, testing if all are on the shoulders.  Different users could set the weightings based on their predicted use.

As for the location of the modifers on the keyboard area, I'm personally less bothered, as I can see the benefit of maintaining compatibility, and also the benefit of putting those modifiers in a more sensible location, because I'll admit that pressing ctrl+z on the Pandora was /weird/.  For me, as a handheld user, I'll probably switch to using shoulders, but for desktop users, maybe you could have a row that asks if the modifier are in the same place as on Pandora (as opposed to being in a more standard place for keyboards).  Users can score it positively or negatively depending on their preference, if that's not too complicated for most people.

I suppose you could also split that out into two positively asked booleans, although in this case they're guaranteed to not both be true or both be false.

I'd appreciate an up to date spreadsheet file as I say, thanks.  If you can export from docs that sounds easiest.

 

[_wb_]

Here's an updated version of the .ods file

Here's the google docs link:

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

So now there are these questions:

"All symbols with shoulder(s) + 1 thumb"

"
[SIZE=100%]All symbols with keyboard modifiers"[/SIZE]

[SIZE=100%]"
All symbols with bottom-keyboard only"[/SIZE]

[SIZE=100%]"
All modifiers on bottom-keyboard"[/SIZE]

[SIZE=100%](this one also includes Ctrl and Alt, the previous ones were about Shift and Meta/AltGr/Fn)[/SIZE]

[SIZE=100%]"
Pandora-compatible Alt/Ctrl on START/SELECT"[/SIZE]

[SIZE=100%](currently this is just the negation of the previous question, though theoretically you could have a proposal which has two Ctrl keys on the keyboard)[/SIZE]

comparison_table.zip

 

[comradekingu]

So if we dont add any positive things not present in the paper-ideal layout, can we at least deduct some points here and there?

Like having a confusing ABXY-arrangement. That is a solid drawback in any configuration.

To pick just one of the things that have a numerical chance: http://www.keyboard-layout-editor.com/#/layouts/5b345f9c3f7b142e6add280f30b3d279

These are the things i think of straight away:

There is only enough letters for english. If you consider the scale at which this fails, the remaining speak-english-only-audience should be _a lot_ more pleased as a result. This is how optimization-math actually works.

But if we pick a weighted default. Somehow its supposedly much more pleasing to everyone to have modifiers on the bottom row.

On a two-thumb keyboard that lacks keys. Im having trouble getting my head around the assumptions.

There are symbols on the letters. Those symbols belong on number-row. And the part of the layout that isnt there.

There is no AltGr.

Slalom-typing to get over to shift every sentence. Tying up both thumbs at non-ideal positions before moving on.

There is a button called Meta which does things its not supposed to do.

The - and + arent on the keyboard.

There is junk on shift and tab backspace and enter and esc. Edit: and Ins and Del

There are foreign o-symbols present.

The position of the letter-prints on the letter keys, dictate that they shouldnt be big versals.

And considering the audience:

Zero coding keys can are primary on the keyboard. (There is however a hold-combo for " and another hold-combo for /)

Hold-combos are among the only thing we can improve on two focus on raising efficiency up from the rather dull concept of having two thumbs only.

Other things: The most central column-key does _nothing_.

Ins and del not in the same orientation or cluster as the rest of the 87-keys.

′ is on the same key as ", that complicates deadkeys. - is on a button that can be claimed in games. No deadkey (or - for that matter in games) 

' seems to be missing completely. Dead-key fail and language fail.

Only one hardware modifier, non-symmetrical column-row.

The numberrow is US shift+, but then the other stuff is spread arbitrarily to any layout across the letters. Pick a selection of things that match.

Please point out the things you see wrong about my layout.

Im going to keep asking, who is it better for, and what novice users arent scared away, let alone understand it?

Edit2: Only one pyra-specific modifier?  What does this even mean, and why is more standard worse...?

 

I actually have doubts whether a 105-key keyboard would even stand a chance against "the competition"

 

"All symbols with bottom keyboard only" I dont know where to start.

"Full ISO keyboard due to hardware FN" There are no hardware interrupts, FN doesnt belong on any standard keyboard. Much less ISO. What is the benefit?

Only one pyra-specific modifier?  What does this even mean, and why is more standard modifiers worse...?

"All punctuation behind at most 1 modifier" Completely forgetting that this "all punctuation" is actually less. In less standard ways.

"All symbols with shoulder(s) +1 thumb." Same broken reasoning with less symbols, same intrinsic flaw. Out of having the standard, and being able to type F-keys with shoulders, there are drawbacks to _both_

There are 2 additional points from printing german letters, where they dont belong, under modifiers that dont exist, to having a system where you can type them dedicated. Where the first one is 4.5 points.

And then there is 10 solid points to be claimed for this:

"Pyra compatible Ctrl/select,  alt/start"

 

[TrashyMG]

 

[comradekingu]

I aint even mad. Just hurts my brain.

 

[fusion_power]

MORE keyboard threads?!?!?   :rolleyes:

Seriously, I guess it's time for an entire sub-forum for keyboard releated threads.  And you guys know that every new thread makes it even harder for ED to decide, no matter how "helpful" the treads are meant.

 

[comradekingu]

If you cant sum up the extent of issues adapting 105-key typing not only to an arbitrary number of keys, but also to two thumb typing, then it fails. We are trying to see why here.

If you dont know what kind of logic any approach is derived from, then that fails.

The only thing its strictly possible to do without, is your post. The one which ironically is very much what it sets out to solve.

 

[levi]

Here's an updated version of the .ods file

Is there a duplicate of 'All symbols with shoulder(s) + 1 thumb' now?  Under 'general properties' and 'modifiers'.  Or is that deliberate?

 

[comradekingu]

And "International support" is a category of its own, rather than being a general property.

                                            English  German Spanish  French

Can you type on it             Yes          No            No          No         etc

I guess calling it "international support" hides the issue that its really about "regional exclusivity"  where as much NO as possible, is the right answer.

Edit: And why is american shift+ orientation better? It doesnt make sense in itself, it doesnt make sense for half the audience. It doesnt even make any sense with a reduced layout.

The important part isnt sequence on keys, its _orientation_ of keys.  And in US layout, the brackets are to be found on their own keys. On ISO keyboards, <> is its own key.

So not only is dedicated keys better, and more US-standard to the issue at hand, having more standard english keys, its also better for coding. Which the pandora failed at for this reason.

A handful of people doing it, if we are generous, is about the same as the ones trying to type polish. Similarly against all odds.

And no, it doesnt make it "dosbox compatible". It only makes it "dosbox without keyconfig"-compatible.  Which is a subset to a subset usecase+laziness. Just to deal with the nature of the argument, Of that, the major use is games, which dont use any of that to begin with.

To use laziness, of what i assume is going to be an upstream effort, as a primary concern for everyones keyboard, is misguided.

 

[_wb_]

comradekingu: You are giving reasons for giving some of the properties in the comparison table a zero or negative weight. Feel free to add a column with your weights, or to add additional properties.

 

[_wb_]

Added two properties to the table:

"Shift-number row does !@#$%^&*()"

and "Mashable symbols" (symbols like Tab on the Pandora that can be typed in one thumb mash)

I also added a column with weights corresponding to what I think are comradekingu's priorities. Of course comradekingu is free to adjust that column to correct me.  And at the very bottom it now shows the score for each set of weights, instead of just the averaged scores.

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

Here's an .ods:

comparison.zip

 

[levi]

Oh cool, I like the 'your scores' bit at the bottom.  I was having to delete everyone else's weights to see that before, thanks.

 

[ible]

I'll bat, but not sure any of this will make a difference.

Question:  _wb_, can you put links to your layouts "1", "2" and "3"?  I've added a row in the spreadsheet for links, near the bottom.  I'm not sure which ones you mean.

 

[_wb_]

I have added and updated links:

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

Split the dead diacritics into "labeled", "unlabeled but easy to remember" and "hidden". For example, Saber has a "labeled" acute, and an "unlabeled but easy to remember" umlaut at Shift+", and a "hidden" circumflex at Fn+Shift+X. Of course it's a bit hard to say what is easy to remember and what is not, but I think this is more or less fair. You can always come up with mnemonics (like circumfleX), but I would say it's easy to remember only if there is a label that looks like the diacritic.

 

[ible]

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?

 

[comradekingu]

I think there should be a "paired" option for the dead-diacritics. Where you get less points for having more pairs on the same keys.

Labeled dedicated dead-keys should get a deduction for clutter.

"Numbers on top layer"  this shouldnt be an addition, it should be a deduction for not having it.

To award 15 points for "Only one pyra-specific modifier" when that category means "Alternate graphics hidden symbols lumped in with F-key modifier" is quite absurd.

It should never be the default, or even considered so, because that is never the case anywhere.

There is the category for adding points for effectivly "being able to do F-keys with shoulders", but there is nothing for not being able to use AltGr on the keys F-keys are on in the case of lumping.

For case of argument, you could lump F-keys into the QWERT-row and miss that functionality, which would be a similar, offence, and it still wouldnt be equal.

Its just that with Fkey/AltGr lumping you are missing a whole lot more functionality. Which there is zero deduction for.

There isnt even anything for being able to use thirdlevelshift on all letters, if you dont count the resulting "clutter" category. But that is a problem in itself.

Then there is the "all symbols with bottom keyboard only" still forgetting a lot of stuff isnt possible without thirdlevelshift AltGr, as if typing with bottom keyboard is somehow ideal when you have two thumbs.

There are zero points awarded for having keys with one letter on them...

In wb-scoring its only worth 4 points to go from 113 symbols to 75, making that completely irrelevant. Its not a clutter-scoring if you get _more_ points elsewhere for messing things up.

Edit: i will knock down my scoring on the 1per key and others when it can be deversified how things fail.

For example 2or 3 things on numberrow are fine, and largely the same. 1 or 2 on letterkeys A-Z is _not_ _at_ _all_ the same.

 

[Grench]

I think there should be a "paired" option for the dead-diacritics. Where you get less points for having more pairs on the same keys.

Labeled dedicated dead-keys should get a deduction bonus for clutter clarity.

"Numbers on top layer"  this shouldnt be an addition, it should be a deduction for not having it.

Fixed that for you.  There is already a deduction for 'clutter'.

Numbers not on top layer is a trade off for top level symbol keys AND actual AltGr (In addition to Fn) functionality.

Sorry if I seem absent from this - I haven't had time to even open _wb_'s matrix.  It may be a few days before I can.

 

[ible]

"Numbers on top layer"  this shouldnt be an addition, it should be a deduction for not having it.

To award 15 points for "Only one pyra-specific modifier" when that category means "Alternate graphics hidden symbols lumped in with F-key modifier" is quite absurd.

Anybody who doesn't have numbers on the top row loses the 10 or so points everyone has been weighting it by, so while the scheme may not be ideal it is capable of encoding your preference.

Also, it's a high priority for ED to have only one extra modifier (not a Fn and a meta, for example).  At any rate, you're free to make your own weights...

Oh, question:  what's your "new" layout?  If you link it on the matrix I will add in the code combo score.

 

[comradekingu]

It is something ED wants, we dont know if its a priority. Because we dont know if he has made that assesment.

From my point of view, it needs to be tested to see whats on the line. If ED knew that already we'd have a layout.

From what he says we can make a guess as to why. I can reason some of the way, but for the rest i need to look into things.

I dont see the point in inflating scores based on assumtion.

Sometimes not having a number-row is good, but the reasons why arent even up for measure, so its impossible to compete.

Similarly it looks quite impossible to compete against wbs own rating in his own system, because it doesnt deduct points for much of anything.

The points you can get for improving on it, are less than what you dont get for straying away.