It's the keyboard layout.


Okay thanks, was confused why the numbers some put into were out of the "MIN MAX" range.
I did my rating into the doc.

It had been easier to use if the MIN-Max had been converted to 0-to-1 so the voter doesnt have to pay attention to it. Now if the MAX is pretty high, one have to create absurd numbers to rate it.

Example:

" [SIZE=100%]Only one extra, Pyra-specific modifier" MIN: 0 - MAX: 1[/SIZE]

-> "okay its important, I give it a 10." or "I hate it I give it a -10."

now this:

" [SIZE=90%]# other keys with extra labels (not counting F-keys on numbers)[/SIZE]" MIN: 3 - MAX: 14

-> "its important I give it something equal to 10, so... uh... 10/(14-3)? so 0.9091" or "I hate it I give it something equal to -10, so... uh.. -0.9091"

And nobody votes with "=10/11" or 0.9091, they say 0.9 or 1 and call it close enough. (in case they even understand it!) Layouts which are strong in these categories lose points this way (up to 10% this case) which is unfair.
 
Last edited by a moderator:
The notion that someone would pass up a device over not seeing a local currency-symbol when they arent available to type on the device baffles me. Who are those people?
We're in the early beginning of a time period when the scales will tip towards the majority of people tapping their first messages and even documents on touchscreens, not keyboards. So just you wait, it will only get worse ;-).

There's two slightly overlapping (at least IMO) criteria in the ones Eight Bit posted above. As it happens those two were also the only ones I ended up giving weight to in my Pandora key layout:

DosBOX (i.e. standard US PC101-key) compatibility, which, the way I see it automatically means you must use double modifiers for some keys, unless you can have at least the main portion of a PC keyboard "as is". Which, I believe, the Pyra wont have.

And the other criteria is coding friendliness which works best when stuff is as close to US PC101 as possible, because in practice that layout has has profound effect on symbol placement decisions for programming languages.

At least it works for me - I now code without looking at the Pandora keyboard.

(

As a sidenote: while coding, I do not use my country's national key layout on a PC. Never did. First - I learned on machines without national symbols. Then, when I tried, I felt it adds some stresspoints for common symbols like {}. And also I did a lot of work on remote shells and thus it was easier to learn to code with the lowest common denominator - US layout.

)

I wish the Pyra were available without any symbols on keys at all - just a big collection of black buttons... "Das Keyboard"-style. Now that would look wicked :)
 
I'll try to explain a little why I made the choices that I did. I know some of the less important symbols are on there but this basis-set includes just about every symbol to compose west european letters with.


As you might know dutch consists of many languages and we learn to read and write dutch, english, german and french in school by default. I guess that's why the dutch keyboard lay-out is so internationally oriented and diacritic heavy.


Almost every symbol that's on my standard dutch keyboard is in this lay-out. The only symbols I'm missing are ¦ ¬ « » ¹ ² ³ ¼ ½ ¾. I could try to cram them in there somehow but didn't see the need for that, I never ever use those and it would just clutter it up.


And yes, ofcourse [Meta+C] for a ç is a little bit faster than [Meta+O]-[C] like in my proposal but atleast all possibilities are there at a glance and findable without mapping custom keys. Same goes for ëäöïüéáóíõãàèìòùç etc. That are a lot of characters I don't have to put on the keymat because the dead diacritics are on there, labeled and well.


The ß is a bit different in that regards but I think it's still a pretty important character. Iirc in modern german SS is used rather than ß but it's still a very comon so I just had to put it on there somehow. ED can maybe shed some light on that ;) If the german majority says it doesn't have to be on the keymat I guess I can come up with something else to put there in it's place ;)


As mentioned earlier I also removed all double modifier keys (Shift+Meta) so that entire layer would be empty to put composed characters on. If people want a ç underneath the C key, I guess it can be mapped to [shit+Meta+C]. Right?


As far as the Valuta is concerned, why not put it on there?


Not everyone will use them all but I use the £ $ and € quite often myself, I guess the Japanese/Asian pandora users will use the ¥ like I use the € and the £?


I think this lay-out is english, german, dutch, belgian and french user friendly and does not exclude italian and spanish either.


Thanks for the feedback.

OK, but Œ Æ Ø are missing and cannot be formed with your selection of diacritics. Being exhaustive is quite hard (if you add Œ Æ Ø, then I'll start talking about Ð and Þ and Hungarian double acutes, and I'm pretty sure I can keep up that game until you have more than 4 labels on every single key). So I think it's better to not try to be fully exhaustive, but just cover the most important ones (e.g. if you have dead diacritics: acute, umlaut, grave and circumflex) and keep some free room available for people to remap things in the way that is best for their needs.


Putting ç at Shift+Meta+C makes capital Ç impossible (probably not a big deal, just saying though).


About the currency symbols: If "why not?" is your argument, then why not ₹ (the Indian rupee) or (the Russian ruble), just to name two? 144 million people live in Russia, 1.27 billion people live in India, 64 million people live in the United Kingdom. So why exactly is £ more important than and ₹ ?

Could you add your proposal to this thread please? http://boards.openpandora.org/topic/17568-final-keyboard-layout-proposals//URL]
 
Last edited by a moderator:
Okay thanks, was confused why the numbers some put into were out of the "MIN MAX" range.
I did my rating into the doc.

It had been easier to use if the MIN-Max had been converted to 0-to-1 so the voter doesnt have to pay attention to it. Now if the MAX is pretty high, one have to create absurd numbers to rate it.

Example:

" [SIZE=100%]Only one extra, Pyra-specific modifier" MIN: 0 - MAX: 1[/SIZE]

-> "okay its important, I give it a 10." or "I hate it I give it a -10."

now this:

" [SIZE=90%]# other keys with extra labels (not counting F-keys on numbers)[/SIZE]" MIN: 3 - MAX: 14

-> "its important I give it something equal to 10, so... uh... 10/(14-3)? so 0.9091" or "I hate it I give it something equal to -10, so... uh.. -0.9091"

And nobody votes with "=10/11" or 0.9091, they say 0.9 or 1 and call it close enough. (in case they even understand it!) Layouts which are strong in these categories lose points this way (up to 10% this case) which is unfair.
You have a point, so I made it easier. Now the scaling of the weights happens automatically, so you can input your priorities in a uniform way, without having to do this kind of calculation in your head.

Here's a link to the table:

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

Here's a link to an .ods file for those who cannot or don't want to use Google docs:


comparison_table_May_2_2015.zip
 

Attachments

  • comparison_table_May_2_2015.zip
    31.9 KB · Views: 183
Okay thanks.

Btw I guess there is an error at the average score formular in line 70. Its only =Average(X74:X78) but have to be atleast =Average(X74:X80) or more.

I would edit it by myself but I dont know how do you like it if I would mess around with it.
 
There is already a way to included dead-key compose for all the western style diactrics. The option is to have compose-key or ^, dont know if thats the same, but using a button on it means its a lost key for everyone, rather than for the people who need it. Whom often find it on P+2.

The matrix spreadsheet is misguided atm.
 
Last edited by a moderator:
OK, but Œ Æ Ø are missing and cannot be formed with your selection of diacritics. Being exhaustive is quite hard (if you add Œ Æ Ø, then I'll start talking about Ð and Þ and Hungarian double acutes, and I'm pretty sure I can keep up that game until you have more than 4 labels on every single key). So I think it's better to not try to be fully exhaustive, but just cover the most important ones (e.g. if you have dead diacritics: acute, umlaut, grave and circumflex) and keep some free room available for people to remap things in the way that is best for their needs.
I didn't try to make the keyboard fully exhaustive, I just wanted to cover the main western european languages and english.

I didn't put those on because they were not on my own big size keyboard at home either. For the sake of completeness you are right. Œ Æ Ø can be added on a meta+shift layer though, or at the expense of the £, ¢ and ¥ on the meta layer in which case I would also switch the Underscore with the ß for consistancy.

Putting ç at Shift+Meta+C makes capital Ç impossible (probably not a big deal, just saying though).
 
 
That depends, the capital Ç could be mapped next to the C key on the V instead?
 

About the currency symbols: If "why not?" is your argument, then why not ₹ (the Indian rupee) or (the Russian ruble), just to name two? 144 million people live in Russia, 1.27 billion people live in India, 64 million people live in the United Kingdom. So why exactly is £ more important than and ₹ ?
Hah! Somehow I knew this would come. :)

How many indian people will buy a Pyra you think? Or russians for that matter? Maybe a few but most probably not more than 0.000000001% of them if any. The £ is certainly not more important but it is used more often by Pyra users than the ₹ or I'd say.

Taking short-cuts on this forum isn't an option eh? ;)



Yes, ofcourse... done!
 
Last edited by a moderator:
Okay thanks.

Btw I guess there is an error at the average score formular in line 70. Its only =Average(X74:X78) but have to be atleast =Average(X74:X80) or more.

I would edit it by myself but I dont know how do you like it if I would mess around with it.
Fixed it. Feel free to correct such things yourself - it's a community document, and if someone really messes up, changes can be reverted.

There is already a way to included dead-key compose for all the western style diactrics. The option is to have compose-key or ^, dont know if thats the same, but using a button on it means its a lost key for everyone, rather than for the people who need it. Whom often find it on P+2.
With compose you always need 3 keypresses (possibly more if you count modifiers) per accented letter, e.g. Compose " U to get ü.

With a dead diacritic you always need 2 keypresses (possibly more if you count modifiers), e.g. [dead ¨] U to get ü.

With a dedicated precomposed key you always need 1 keypress (possibly more if you count modifiers), e.g. [P+1] to get ü.

Dead diacritics are less efficient than dedicated keys, but more efficient than compose. They are particularly practical for acute, grave, umlaut and circumflex, since those diacritics occur in quite a lot of languages, and there is obviously no room for dedicated precomposed keys for all of áéíóúàèìòùäëïöüâêîôû.

In the big table:

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

can everyone please check their priorities? Now with the normalized priorities, it's much clearer how your scores work, so maybe you want to correct the balance a bit. Also there are some new properties that you may have missed.

The property "# letter keys with extra labels" is currently the most "controversial" property: comradekingu gives it a huge negative weight of -130, while Eight Bit gives it a huge positive weight of +130. Since this was one of those properties with a big range (which used to amplify those weights invisibly), I suspect that maybe you both want to reduce the absolute value of that weight...
 
About the currency symbols: If "why not?" is your argument, then why not ₹ (the Indian rupee) or (the Russian ruble), just to name two? 144 million people live in Russia, 1.27 billion people live in India, 64 million people live in the United Kingdom. So why exactly is £ more important than and ₹ ?
 
Hah! Somehow I knew this would come. :)


How many indian people will buy a Pyra you think? Or russians for that matter?
Not a single one of them, duh, because nobody would buy a device that doesn't include their currency symbol! ;)
 
The property "# letter keys with extra labels" is currently the most "controversial" property: comradekingu gives it a huge negative weight of -130, while Eight Bit gives it a huge positive weight of +130. Since this was one of those properties with a big range (which used to amplify those weights invisibly), I suspect that maybe you both want to reduce the absolute value of that weight...
Well I suspect that Eight B was aware of this huge offset of comradekingu and used his vote to compensate it. You can see that on some other properties, too. :D
 
^ Well I absolutely refuse point blank to buy a Pyra or even to continue to be a part of this community if my currency symbol is not included in the layout.


In fact, I would do unspeakable things to little kittens if the Pyra is released without my currency symbol.


Edit:
 
Last edited by a moderator:
^ Well I absolutely refuse point blank to buy a Pyra or even to continue to be a part of this community if my currency symbol is not included in the layout.


In fact, I would do unspeakable things to little kittens if the Pyra is released without my currency symbol.


Edit:
Well, it's quite hard to design a qweRty keyboard without your currency symbol on it :)

The property "# letter keys with extra labels" is currently the most "controversial" property: comradekingu gives it a huge negative weight of -130, while Eight Bit gives it a huge positive weight of +130. Since this was one of those properties with a big range (which used to amplify those weights invisibly), I suspect that maybe you both want to reduce the absolute value of that weight...
Well I suspect that Eight B was aware of this huge offset of comradekingu and used his vote to compensate it. You can see that on some other properties, too. :D
Yes, but the thing is: it doesn't work like that. The final average does not use the average of all weights, it makes an average of the individual scores (normalized per individual). So you can divide or multiply all the weights in your column by 100, and it will not change a thing to any of the scores you can see.
 
Yes, but the thing is: it doesn't work like that. The final average does not use the average of all weights, it makes an average of the individual scores (normalized per individual). So you can divide or multiply all the weights in your column by 100, and it will not change a thing to any of the scores you can see.
Well it would if you put into every property something like "=AE59*-1", which would be some pretty hard trolling on one user.

please dont do that guys

;)
 
Last edited by a moderator:
Ok, as I've been asked to participate, here goes:


@ED:


I have no idea what layout is going to work for me, all I know is I would like some of the irritations of the Pandora keyboard resolved... I.e I want full dosbox compatibility and all the other benefits that would bring. I also really like the idea of compose, so would like to be able to do that with the Pyra, regardless of what characters end up on the keys.


Oh, and I think that full stop and comma should be dedicated, but I don't mind if things like exclamation and question mark are on modifiers.


Right, I have now contributed. ;)
 
Back
Top