Unofficial keyboard layout poll (bis)

[Saber]

I think those persons with layout proposals shouldn't be voting for their own or against any others, to keep things honest numbers-wise.  

I've never understood this viewpoint. How are people making things (be it competition entries or keyboard layout proposals) not part of the community voting for their favorites? Of course authors will probably vote for their own entry, and should vote honestly about the others as they would had they not created something themselves. Compare with the situation that someone else had made the exact same entry. Why should it matter who made the entry as long as the authors are fair toward others as well?

I can see truly you don't understand. In simpler terms let's just say that when you've cast your ballot already(by submitting your own proposal) you shouldn't have a second vote in the process counted for yours and against others. 

Suppose five people want to make a choice that reflects their collective will. Four of the five people offer a proposal. Which of the following yields the best representative result:

1. Only people with no proposals get a vote
   
2. Everyone gets one vote (simple majority vote)
3. Everyone orders the proposals by preference, the one with the best average rank wins

Yes, I'm cherry picking the situation to prove a point. Making a suggestion is not the same as a vote. Everyone can make suggestions. If only people with no suggestions vote, the voting result will reflect the will of that segment of the total population, limited by the options presented by the rest. It's not representative of the entire population.

I agree with you that doing what we have seen in a previous vote, that is an author ranking his proposal the best, all the other the worst, is (and was) a bad thing. Average ordering is better in representing collective will.

A proposal is not a suggestion though, it’s a declaration from yourself for yourself. Mine over theirs. If instead we’re talking of having a second independent cast for “if I don’t win, then let’s go with this other guy” then that is a separate race, and is okay if need be depending on the circumstances, but this poll’s choices as we agree, ranging from “I wouldn’t want a Pyra if…”, or “I LOVE this layout”, to “No opinion” render the samplings valueless if assessed in total.

 

The “best” scenario of accurate representation would be if everyone votes for their favorite proposal then, for what it’s worth, the winner is declared after the tally. No averaging just a clear victor(since there won’t be two keymats). Ever heard the expression second place is first loser? 


 

As for your statement "Obviously there are alternative ways to do those things. You can use the menus, for example. Or e.g. in LibreOffice, you can easily modify the shortcuts. But that's not the point. The point is: why make things complicated and make Shift + F-keys do weird stuff?", that there are alternative ways shouldn't be dismissed when we can get even more distinct keys out of the Pyra layout(which you've rallied for as well).   

I'll simplify this.

It is a keyboard.  It must behave as a keyboard.

If you can't do F2, shift+F2, alt+F2, ctrl+F2, alt+ctrl+shift+F2 then the layout is broken.

ALL of the F1-F12 keys MUST work in all cases with and without modifiers or the layout is broken and must be re-thought.

Does that make it easier to understand?

Oh for a layout that had the control keyboard actually on the keyboard! Rather useful when doing maintenance via SSH on various systems...

If you mean a Control key, and you don't want to hold Select(which is Left Control) or shoulder R1(which is Right Control), why not map one of the keyboard Left Shifts to it, if you are backed into a corner that is? 

But there IS one that does this the way the user wants to use his keyboard.  Actual Alt and Control (Ctrl) keys on the keyboard in a usable position where the end user would expect to find them.  No Vulcan death grip to reach the center keys in combination with others required - even without using the shoulder buttons.

There is a proposal that meets this user's needs.

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

Key pairs retained.  Keys present where the user expects them to be - or as near to that as possible.  Fully functional F1-F12 keys.  Language support clearly stated.  AltGr (Right Alt) retains it's capability if a non-US keyboard map is assigned at the OS level.

Since I didn't want to blemish the official thread with my response to this rather antagonistic member, I appended their post from the other thread and my remarks to it here...

The only demand met for this user in your layout Grench is that it has Control in the lower left corner of the keyboard. The rest is bogged down under multiple locks and poorly thought ergonomics. Almost all of the common punctuation symbols(think - + _ = [ ] \ / ) are nestled on the same side as the modifier that’ll trigger them with even ; and : positioned far dead center(where ED didn’t want = as you may recall and presumably he wouldn't want : either). Ridiculously this includes , and . too which are used quite often or so I’ve heard. At least this user will be appreciative quick access to media functions and the degree symbol in your proposal has been integrated. 

 

If it wasn’t so apparent by your deftness of design you assume people will be joyous in getting by with just the L1 shoulder(which is now Fn rather than it’s traditional Right Shift), I’d point out that no person will want to hopscotch their right thumb from keyboard Fn to n every time they want to close a sentence. Call chording the feature of the year if you wish though, but these by operation are the very definitions of broken, as you call it. -_-    

1. This is an unofficial vote, so who cares?

2. This is a public vote, so if anyone is voting in a dishonest/manipulative way, everyone can see that.

I’m not in the least concerned where the votes lean _wb_. This poll though is ineffective for what it seeks to accomplish. Merely another board contrivance to pass the time until ED chimes in on the topic when he can. 

Saber, you are confusing keyboard labels and their functionality. Making it next to impossible for someone who doesnt know all these things to form an opinion.

Shift+altGr+nubers already does something. This is a reason why you cant call what it is that you are proposing to do, AltGr. It simply isnt.

I have confused nothing. For the last time please let it sink in that our AltGr key will not, will not, be exactly the same as other AltGr keys on other keyboards. It will be our own custom form with it's own unique mappings. 

 

[Grench]

Since I didn't want to blemish the official thread with my response to this rather antagonistic member, I appended their post from the other thread and my remarks to it here...

Groovy. So I'm your bad guy for providing feedback.


Another member had documented that your layout was broken. A commonly used capability of a standard keyboard is not possible on it. You defended it by stating that 'nobody needs to do that,' which is the wrong answer.

The only demand met for this user in your layout Grench is that it has Control in the lower left corner of the keyboard.

So, it's a bad thing that the layout services a user's need?

The rest is bogged down under multiple locks and poorly thought ergonomics. Almost all of the common punctuation symbols(think - + _ = [ ] \ / ) are nestled on the same side as the modifier that’ll trigger them with even ; and : positioned far dead center(where ED didn’t want = as you may recall and presumably he wouldn't want : either). Ridiculously this includes , and . too which are used quite often or so I’ve heard. At least this user will be appreciative quick access to media functions and the degree symbol in your proposal has been integrated. 

Interesting. Thank you for the feedback. I think I have a solution though. It might be a good idea to swap sides with the shift/Fn set and the Alt/Ctrl set on both the keyboard and the shoulders. That should fix the ergonomic issue for keyboard only users without damaging usability for shoulder modifier users.

If it wasn’t so apparent by your deftness of design you assume people will be joyous in getting by with just the L1 shoulder(which is now Fn rather than it’s traditional Right Shift), I’d point out that no person will want to hopscotch their right thumb from keyboard Fn to n every time they want to close a sentence. Call chording the feature of the year if you wish though, but these by operation are the very definitions of broken, as you call it. -_-    

Apparently we're using different definitions of "broken" and "needing refinement". Broken, in this respect, is when it is simply impossible to do a normal expected action (technical breakage). Needing refinement, in this respect, is that things that technically work need to be adjusted to make them work better.


Thank you for the feedback.  I'll take it into account on my next refinement.

 

[Grench]

On forum feedback I have swapped sides for the modifier pairs and removed the '_lock_' suggestion for Alt and Ctrl.  This is being done to ease English punctuation entry for non-shoulder users.  I.e. the Fn key is now on the left to make it easier to get to the punctuation with the right thumb.  It's a pretty good idea.

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

An added benefit to this is it allows for a 'real' AltGr on the right-alt key on the lower right of the keyboard, should a user enable it by choosing a language layout in Debian that would enable it.

You're welcome to make suggestions in:

http://boards.openpandora.org/topic/16872-and-now-for-something-completely-different-keyboard-option/page-10

Thank you.

 

[Saber]

On forum feedback I have swapped sides for the modifier pairs and removed the '_lock_' suggestion for Alt and Ctrl.  This is being done to ease English punctuation entry for non-shoulder users.  I.e. the Fn key is now on the left to make it easier to get to the punctuation with the right thumb.  It's a pretty good idea.

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

An added benefit to this is it allows for a 'real' AltGr on the right-alt key on the lower right of the keyboard, should a user enable it by choosing a language layout in Debian that would enable it.

You're welcome to make suggestions in:

http://boards.openpandora.org/topic/16872-and-now-for-something-completely-different-keyboard-option/page-10

Thank you.

Now you're using your noggin.

Also, discard the media playback keys. No one will notice they're gone.

 

[comradekingu]

Saber, you are confusing keyboard labels and their functionality. Making it next to impossible for someone who doesnt know all these things to form an opinion.

Shift+altGr+nubers already does something. This is a reason why you cant call what it is that you are proposing to do, AltGr. It simply isnt.

I have confused nothing. For the last time please let it sink in that our AltGr key will not, will not, be exactly the same as other AltGr keys on other keyboards. It will be our own custom form with it's own unique mappings. 

So which one is it, you are refusing to adhere to a concept i claim no ownership in, or? Im just asking you to acknoledge that what you are doing isnt AltGr.

Who is this "we", an appeal to authority? Notice how Wb asked you to stop doing it too.

You are confusing labels with concepts. You are breaking existing expectations, conventions, opening up the door to unforeseen problems now, and making future problems plausible.

As for how "my" AltGr key works, as in the one i have on my layouts, it does the exact same as AltGr. That however doesnt make it mine, its just that im without option to do anything else, since i want to call it AltGr. The concept of how AltGr works doesnt become invalid just because there is a change in the number of buttons available.

Your argument at its root says A is B because B is not a A, instead supposedly "unique and custom", because thats how it will be, says "we".

That its not exactly the same, as on other keyboard, is a misinformed argument already at its inception, because AltGr isnt the exact same on any. Its either dead-key invoker, or alternate and third level modifier. The latter varies betwen local layouts, depending on what people have use for.

AltGr+numbers does something

Shift+AltGr+numbers does something

AltGr+letters does something

Shift+AltGr+letters does something

(edit:  Shift+Fkeys also does something)

Breaking that means you are _forcing_ people to use your system, since they are without option, rather than the one they are used to. There are many such systems, and AltGr is rather important.

The only difference is we dont have the exact same number of keys to do alternate graphics on.

The only difference to the two methodologies you and me do is in one people have the option to use what they are used to, but not at a loss of other functionality.

Putting symbols on numbers and full layout actually is closer to real keyboards.

So your argument then becomes.

"Since I have trouble adhering to the standard/any (?) when the limitations in play make it a design-challenge, the design itself can be arbitrary. To the point where instead, redesigning AltGr makes sense. But i would like to keep calling it by its name, because that brings credibility to the flaws inherrent in the logic that doesnt make it AltGr."

 

[Grench]

On forum feedback I have swapped sides for the modifier pairs and removed the '_lock_' suggestion for Alt and Ctrl.  This is being done to ease English punctuation entry for non-shoulder users.  I.e. the Fn key is now on the left to make it easier to get to the punctuation with the right thumb.  It's a pretty good idea.

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

An added benefit to this is it allows for a 'real' AltGr on the right-alt key on the lower right of the keyboard, should a user enable it by choosing a language layout in Debian that would enable it.

You're welcome to make suggestions in:

http://boards.openpandora.org/topic/16872-and-now-for-something-completely-different-keyboard-option/page-10

Thank you.

Now you're using your noggin.

Also, discard the media playback keys. No one will notice they're gone.

Updated to fix my silly ABXY error:

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

Through other community feed back there was a conversation along the lines of:

"Wouldn't it be neat if the lid switch changed the shoulder buttons into media playback keys?"

Several of us thought this was a good idea.  You will see it on several layouts - media playback functionality in the shoulders when the lid is closed.

My thoughts, though, are, "What if you open the lid and want to skip to the next song using the same mechanism?  Shouldn't there be a way without closing the lid to generate the same codes as the shoulder buttons do when the lid is closed?"

THAT is why there are media playback keys encoded next to the Diacritic Key.  Unless we remove that functionality from the shoulders, I would like to keep the functionality on the keyboard.

So, who would miss them?  Anyone who wants an integrated experience with the "Lid closed media buttons" once they open the lid and can't stop the Pyra on random shuffle from playing, "Play That Funky Music," unless they close the lid or pull a media player full screen and mouse to the controls and...  You get the idea.

 

[Saber]

Saber, you are confusing keyboard labels and their functionality. Making it next to impossible for someone who doesnt know all these things to form an opinion.

Shift+altGr+nubers already does something. This is a reason why you cant call what it is that you are proposing to do, AltGr. It simply isnt.

I have confused nothing. For the last time please let it sink in that our AltGr key will not, will not, be exactly the same as other AltGr keys on other keyboards. It will be our own custom form with it's own unique mappings. 

So which one is it, you are refusing to adhere to a concept i claim no ownership in, or? Im just asking you to acknoledge that what you are doing isnt AltGr.

Who is this "we", an appeal to authority? Notice how Wb asked you to stop doing it too.

You are confusing labels with concepts. You are breaking existing expectations, conventions, opening up the door to unforeseen problems now, and making future problems plausible.

As for how "my" AltGr key works, as in the one i have on my layouts, it does the exact same as AltGr. That however doesnt make it mine, its just that im without option to do anything else, since i want to call it AltGr. The concept of how AltGr works doesnt become invalid just because there is a change in the number of buttons available.

Your argument at its root says A is B because B is not a A, instead supposedly "unique and custom", because thats how it will be, says "we".

That its not exactly the same, as on other keyboard, is a misinformed argument already at its inception, because AltGr isnt the exact same on any. Its either dead-key invoker, or alternate and third level modifier. The latter varies betwen local layouts, depending on what people have use for.

AltGr+numbers does something

Shift+AltGr+numbers does something

AltGr+letters does something

Shift+AltGr+letters does something

(edit:  Shift+Fkeys also does something)

Breaking that means you are _forcing_ people to use your system, since they are without option, rather than the one they are used to. There are many such systems, and AltGr is rather important.

The only difference is we dont have the exact same number of keys to do alternate graphics on.

The only difference to the two methodologies you and me do is in one people have the option to use what they are used to, but not at a loss of other functionality.

Putting symbols on numbers and full layout actually is closer to real keyboards.

So your argument then becomes.

"Since I have trouble adhering to the standard/any (?) when the limitations in play make it a design-challenge, the design itself can be arbitrary. To the point where instead, redesigning AltGr makes sense. But i would like to keep calling it by its name, because that brings credibility to the flaws inherrent in the logic that doesnt make it AltGr."

I may regret asking this but what do you think will happen if this person you speak of risks pressing the AltGr key in my layout, found soon on their Pyra, with one of the letters and doesn't receive the same "standard" value they are used to seeing generated onscreen from their homegrown full-size keyboard? Will they adapt to the change in value or will they scream for the hilltops? 

 

[comradekingu]

Grench: Mediakeys on the keyboard too, means there are two places to learn how to use them. Learn mediakeys on shoulders when in main mode( laptop) means you get accustomed to an additional use-case by default. Portable audio-player. Mediabuttons on shoulders makes sense then, because they are only useful for answering calls when they occur, and media.

If mediabuttons stay on shoulders only, the only diffrence in invoking them, is you have to use meta+ when the lid is open. You could of course turn off the shoulder-functionality and not have to use that meta+. But then it wouldnt work in games which require shoulders.

Meta+ however always works.

Saber: People to a large extent dont even know how to use regular AltGr. If you want to change something because of an already changed convention in the number of keys, change that. Design around it by only requiring shift, which people do understand.

Colour-codes also fail. And they look ugly.

Inability to press shift+Fkeys  takes away web and text functionality in KDE and GNOME, probably other DEs too.

Shift+AltGr to do a combination of what  real keys, shift and AltGr does fails wholesale.

All of the above isnt neccesary. So it begs the question, why? What is the benefit? If you reduce down to pandora amount of keys, i see it. Pyra i dont, because ive seen it done differently.

Compromise made due to lack of key real-estate isnt good. As soon as its not required, it should be done away with.

For the people that use AltGr, I can speak for myself.

Why should someone come and forcibly decide for me, where the AltGr letter symbols are, and take away my AltGr?

Its just visual noise that nobody has a full use of, so it gets on everyones goat. And if you have full use of it, its because you have been stripped of both full layout, french type accentuation on number row, compose character, and regular AltGr functionality.

Yes there can be a default, why does it have to be visual? AltGr symbols on letters never are. Regular symbols belong on the number-row. And on P+ and L+ if you have reduced layout.

2 letters per key looks like a toy keyboard. And you arent getting the benefit of that anyhow.

You are jumping ahead and implying it is a case of difference in use. Im saying its a case of difference of purchase.

Selling someone a keyboard works by selling a keyboard. No keyboard that strayed away from this has ever been accepted by the general mass. We are still to a great extent, using 1984 type keyboards.

I wasnt born then, but i know computing was a whole lot different. Things didnt change, because people dont buy irregular keyboards.

And with software changing, functionality was piled onto already existing buttons. Change something, and break something.

So if we agree conventions are better for compatibility and novices, what benefit does your layout provide pros which justifies raising the treshold on who can use it/will buy it?

You can disagree the pyrakeyboard isnt one because of a lack of keys, but it doesnt make the argument more sound if it doesnt work like one either.

When was ever mobile-keyboard better than regular keyboard?

On a related note, are there any features meant for two-thumb typing?

Ask people who have never used a pandora to explain to you how your keyboard works. Say only the words yes and no. As if what would happen if they tried to do it. I _guarantee_ you will be suprised.

 

[Saber]

People to a large extent dont even know how to use regular AltGr. If you want to change something because of an already changed convention in the number of keys, change that. Design around it by only requiring shift, which people do understand.

Colour-codes also fail. And they look ugly.

Inability to press shift+Fkeys  takes away web and text functionality in KDE and GNOME, probably other DEs too.

Shift+AltGr to do a combination of what  real keys, shift and AltGr does fails wholesale.

All of the above isnt neccesary. So it begs the question, why? What is the benefit? If you reduce down to pandora amount of keys, i see it. Pyra i dont, because ive seen it done differently.

Compromise made due to lack of key real-estate isnt good. As soon as its not required, it should be done away with.

For the people that use AltGr, I can speak for myself.

Why should someone come and forcibly decide for me, where the AltGr letter symbols are, and take away my AltGr?

Its just visual noise that nobody has a full use of, so it gets on everyones goat. And if you have full use of it, its because you have been stripped of both full layout, french type accentuation on number row, compose character, and regular AltGr functionality.

Yes there can be a default, why does it have to be visual? AltGr symbols on letters never are. Regular symbols belong on the number-row. And on P+ and L+ if you have reduced layout.

2 letters per key looks like a toy keyboard. And you arent getting the benefit of that anyhow.

You are jumping ahead and implying it is a case of difference in use. Im saying its a case of difference of purchase.

Selling someone a keyboard works by selling a keyboard. No keyboard that strayed away from this has ever been accepted by the general mass. We are still to a great extent, using 1984 type keyboards.

I wasnt born then, but i know computing was a whole lot different. Things didnt change, because people dont buy irregular keyboards.

And with software changing, functionality was piled onto already existing buttons. Change something, and break something.

So if we agree conventions are better for compatibility and novices, what benefit does your layout provide pros which justifies raising the treshold on who can use it/will buy it?

You can disagree the pyrakeyboard isnt one because of a lack of keys, but it doesnt make the argument more sound if it doesnt work like one either.

When was ever mobile-keyboard better than regular keyboard?

On a related note, are there any features meant for two-thumb typing?

Ask people who have never used a pandora to explain to you how your keyboard works. Say only the words yes and no. As if what would happen if they tried to do it. I _guarantee_ you will be suprised.

Okay. All that is double talk and gibberish. Like watching a dog chase it's tail. Nobody is forcing you to accept this keyboard. If you want a different layout then please work on yours some more and cut the nonsense. People have far greater comprehension skills then you give them credit. The labels color will match the modifier.

Honestly, I don't care if AltGr works differently on other keyboards. It absolutely does behave differently when pushed on every regional keyboard out there depending on where you plant your feet.

ED wants to use AltGr as our modifier. If he goes with another label name then that's fine. Sym or Char maybe or even Fn(on the surface). It'll have a mapping customized to our needs given the number of keys we have to work with, but it will still be an AltGr, our AltGr, a modifier that brings up symbols and characters when pressed in combination with a letter, with a keymap exclusive to the Pyra. Must I repeat this over and over?   B)   

 

[Grench]

Grench: Mediakeys on the keyboard too, means there are two places to learn how to use them. Learn mediakeys on shoulders when in main mode( laptop) means you get accustomed to an additional use-case by default. Portable audio-player. Mediabuttons on shoulders makes sense then, because they are only useful for answering calls when they occur, and media.

If mediabuttons stay on shoulders only, the only diffrence in invoking them, is you have to use meta+ when the lid is open. You could of course turn off the shoulder-functionality and not have to use that meta+. But then it wouldnt work in games which require shoulders.

Meta+ however always works.

Actually, no, Fn/Meta+shoulder buttons when the lid is up CANNOT run the media controls IF the shoulder buttons are then mapped to keyboard modifiers (Fn, Shift, Alt, Ctrl) as Fn+Shift+key must work, regardless of whether it is chorded on the keyboard, chorded on the shoulders or by pressing one each.

 

[comradekingu]

Saber: My post presented an argument. Your post was this "All that is double talk and gibberish. Like watching a dog chase it's tail."

I have worked with computer support, i know how regular keyboards fail, because i have shown people how to use them. Its not that the keyboards dont work for the people who know to use them. Its that getting there isnt intuitive, nor logical. When you only have in mind the intended use, and how that could work, however unproven and tested, you are forgetting about all the pitfalls a varied usergroup presents.

I have shown the layouts we have produced to regular people.

People having a level of comprehension is not a reason to elevate the bar on what level of knowledge and dedication you need to get going.

When you say "the nonsense" does that actually come with reasoning, or do i have to guess?

My layout has been fixed for 8 months. With only visual changes, one non-breaking one, or been laid out according to changes in premises.

On the topic of changing topic: When are yours going to be compatible, or stop changing? Ive asked for this again and again, but i guess the proof is in the pudding.

Back to the case at hand: So ED wants to use AltGr, at what point did you interpret that as anything other than AltGr? Isnt it fair to assume he actually meant AltGr?

If he supposedly doesnt know the difference, or doesnt care, no that isnt ok, nor does it bring any credibility to your use of the AltGr label to mean something other than the AltGr key.

There is a distinct difference between reduced buttons meaning:

A: AltGr with reduced amount of buttons.

B: AltGr becomes something else

The premise doesnt neccesitate B, it is A by default. Claiming reduced buttons makes it B, doesnt make it so. You are choosing to make it so and I dont know why.

With reduced buttons it makes sense to use it as third-level shift, since that puts it close to a regular keyboard, and deals with reduced amount of buttons in a manner that isnt ugly.

This is the ideal order:

A: AltGr with full number row and full layout

B: AltGr with reduced number row and reduced full layout

C: Not AltGr with reduced number row and reduced full layout

D: Not AltGr with reduced number row and reduced layout

E: Not AltGr with reduced number row and reduced layout and symbols where they dont belong

Just because it cant be A doesnt mean B isnt closer to A then E is.

Grench: What if the buttondown meta triggers a num-lock concept where shoulders change from modifiers to straight mediabuttons.

 

[Grench]

Grench: What if the buttondown meta triggers a num-lock concept where shoulders change from modifiers to straight mediabuttons.

Misses the point of having modifiers on the keyboard and not just the shoulders.  Desktop and eventual docking station use where the shoulder buttons are obscured, blocked or cannot be reached.

Anything done on the shoulder buttons MUST have an equivalent that -can- be done (even if not easily) without using the shoulder buttons.

Why?  This device needs to be usable when held in 2 hands  AND when it's sitting on the desk without picking it up.

 

[bzar]

You jumped to conclusion, and didnt at all consider swaying polls and tactical voting. Not voting for oneself isnt a new concept.


That destinction isnt taking away peoples ability to vote. There is only a fixed representative that does vote. Same reasons the many worthless threads arent possible, the ones participating in them are making the vote a representation of that. And thus, the same people who dont want to participate in that manner, are left out.


Hidden elections were made for this purpose.


You dont solve the problem of not being able to vote having made a layout, you create the problem of few voters misrepresentation.


Again, show layouts to non-pandora people. There you have a virtually endless supply of unbiased prospective buyers. If you dont help them, they are on their own, and  a very real representation of themselves.


Its not the people at fault, because they cant be changed by magic. Design for, not against.

The point of the vote is to get numbers. You may be after different numbers than I am. I'm after numbers that tell the relative support each proposition has within the entire voting community. This is not possible if everyone doesn't vote. So, again, 0% or 10% regarding my earlier question?


Yes, hidden vote system is better because it gets rid of ad-hoc voting tactics. I'm not disputing this the slightest.


We're voting within the community. What we want.

A proposal is not a suggestion though, it’s a declaration from yourself for yourself. Mine over theirs. If instead we’re talking of having a second independent cast for “if I don’t win, then let’s go with this other guy” then that is a separate race, and is okay if need be depending on the circumstances, but this poll’s choices as we agree, ranging from “I wouldn’t want a Pyra if…”, or “I LOVE this layout”, to “No opinion” render the samplings valueless if assessed in total.

A proposal and a suggestion are equivalent in this case. Whatever you call making something you'd like to win the vote and presenting it to the voting community.

Yes, the third option in my example was not the voting system used in this poll. I was asking which of the three yields best representative results.

This vote uses a system I'm not particularly fond of because it enables too much tactics.

The “best” scenario of accurate representation would be if everyone votes for their favorite proposal then, for what it’s worth, the winner is declared after the tally. No averaging just a clear victor(since there won’t be two keymats). Ever heard the expression second place is first loser? 

Simple majority vote system only works fairly if there are exactly two options to choose between. Allow me to illustrate:

A community is voting what fruit they get for a convention. The options have been reduced to Apples, Bananas and Cantaloupes. 51% would order these options by preference [A, B, C], 25% would order them [C, B, A] and 24% [b, C, A]. The community proceeds to vote using a simple majority system. Apples get 51% of votes, winning the election with 49% of the community being stuck with their least favorite option.

The 49% demand a new poll using average ranking instead. Weighting is decided to be a simple 3 points for first option, 2 points for the second, 1 point for the third. Apples get 3*51% + 2*0% + 1*49% = 2.02, Bananas get 3*24% + 2*76% + 1*0% = 2.24 and Cantaloupes get 3*25% + 2*24% + 1*51% = 1.74 points. Bananas win the vote.

Which result is more likely to be the least bad for the most?

 

[rygD]

Ever heard the expression second place is first loser?

I greatly prefered the first loser of the logo polls.  In the end people voted against it rather than for what they actually liked...

 

[_wb_]

Through other community feed back there was a conversation along the lines of:

"Wouldn't it be neat if the lid switch changed the shoulder buttons into media playback keys?"

Several of us thought this was a good idea.  You will see it on several layouts - media playback functionality in the shoulders when the lid is closed.

My thoughts, though, are, "What if you open the lid and want to skip to the next song using the same mechanism?  Shouldn't there be a way without closing the lid to generate the same codes as the shoulder buttons do when the lid is closed?"

THAT is why there are media playback keys encoded next to the Diacritic Key.  Unless we remove that functionality from the shoulders, I would like to keep the functionality on the keyboard.

So, who would miss them?  Anyone who wants an integrated experience with the "Lid closed media buttons" once they open the lid and can't stop the Pyra on random shuffle from playing, "Play That Funky Music," unless they close the lid or pull a media player full screen and mouse to the controls and...  You get the idea.

In my proposal, I solve this as follows:

- the Pyra logo button (below START and SELECT) is Left_Super

- the lid-closed sensor is Right_Super

- Super + Right_{Shift,Ctrl,Alt,Meta} are media buttons

The disadvantage of this is that you cannot use shoulder modifiers for things like Super+Shift+Ctrl+letter, but Super shortcuts are not so frequently used, and Super+other modifiers shortcuts are even rarer. Moreover you can still use Super with the left modifiers (the ones on the keyboard), and perhaps it makes sense to break commutativity and let LSuper+RShift (which would be a media button) do something else than RShift+LSuper (which could be used for Shift-Super-shortcuts).

This solution is similar to that of comradekingu.

The advantages:

• you can have the media buttons on the shoulders when the lid is closed and also when the lid is opened.
• the lid acts like a button ("RSuper down" means you closed the lid, "RSuper released" means you opened it), so applications or games that want to, can treat lid events just like any other keyboard input event. This could be useful.

 

[_wb_]

Edit: Wb: I am still interested in having my questions answered and returned in similar fashion. Open for anyone.

Oh, sorry, I didn't realise there were questions in that post.

Things i dont understand:

Why is there a sysRq key? What can be done when that is a key on the pyra?

When you went with standard US shift+ numbers, why is <> close to where you would find it on ISO keyboards on this?

Reasons i think yours is better:

You have printed F-keys which can be learnt without seeing the desktop wallpaper/conky.

It is easier to type F-keys.

You have a standard shift+numberrow

You have a super.

The reasons i think yours are better are the ones i want to hear about. I am probably missing something. Then we can find out what kind of users stand to benefit from it.

SysRq is not very important, but it can be used for the Magic SysRq (http://en.wikipedia.org/wiki/Magic_SysRq_key).

In one of my proposals I did have < > on Meta+Z X at some point, but I think it's better to have them at Shift+, . to remain close to US-QWERTY.

I don't really understand what you want to hear about the F-keys, standard shift+number row, Super. Do you want to know what those keys are used for?

 

[_wb_]

Grench: What if the buttondown meta triggers a num-lock concept where shoulders change from modifiers to straight mediabuttons.

Misses the point of having modifiers on the keyboard and not just the shoulders.  Desktop and eventual docking station use where the shoulder buttons are obscured, blocked or cannot be reached.

Anything done on the shoulder buttons MUST have an equivalent that -can- be done (even if not easily) without using the shoulder buttons.

Why?  This device needs to be usable when held in 2 hands  AND when it's sitting on the desk without picking it up.

If that were true, then why do we have shoulder buttons in the first place? If you're running an emulator emulating a game console which has one or two pairs of shoulder buttons, do you still insist that it has to be usable with the Pyra sitting on the desk, that is, without using its shoulder buttons?

The point of a docking station would be to use the Pyra like a desktop pc or like a game console, that is, you would most likely attach an external keyboard or use an external game controller. While I agree that it should still be possible to do everything while docked without attaching external stuff, I don't think it's a scenario we should optimize for. IF the docking station blocks the shoulder buttons, then perhaps it should have a mechanism to expose the shoulder buttons again (i.e. the docking station should have some buttons on it).

In particular, when it comes to media buttons: if you're using the Pyra as a dedicated music player, sitting on a table somewhere, attached to your music system, then the shoulder buttons are indeed a rather awkward mechanism to control the music player. But Fn+(Shift+)ZX is not much better. In this scenario, you would most likely have the music player application running full-screen, meaning it has keyboard focus, and you use more convenient keys anyway to control it (e.g. dpad and action buttons). Or perhaps someone will write a simple smartphone application to let you use your smartphone as a remote control for your Pyra, via bluetooth or wifi or something.

 

[ible]

So, _wb_ has changed the design quite a bit (and so have we all, besides comradekingu).

This is the layout I was thinking of when I voted for _wb_:

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

You had quite a positive score, people loving and liking it, without too many flaws.

Is the poll still valid for _wb_'s new one?

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

 

[bzar]

^ New poll!

 

[_wb_]

^ New poll!

If we do a new poll, I think it would make sense to include your proposal as well, B-Zar.

And I think it would also make sense to include both of my 'main' proposals: both the one with {}|~_+ as Shift+[]\;/`-= (so they're Shift+Meta symbols) and the one which has them as direct Meta symbols. I currently have a weak preference for direct Meta symbols, but both approaches have their pros and cons and I have no strong feelings about this.

I think ible also has multiple proposals that could be entered into the vote, and while Saber currently has only one proposal, I think it would make sense to also include his v1 proposal (and perhaps also his v2 proposal) since ED has explicitly mentioned that one.

So, looking at the Final keyboard layout proposals/URL] thread, should we do a vote then with the following options?

• _wb_ 1: http://www.keyboard-layout-editor.com/#/layouts/5b345f9c3f7b142e6add280f30b3d279
  
• _wb_ 2: http://www.keyboard-layout-editor.com/#/layouts/e1b05961a2c31a6b89288597b9642ae6
• Grench: http://www.keyboard-layout-editor.com/#/layouts/fcd69e93d9f1fdd811c8d13cc212f3a6
• comradekingu: http://boards.openpandora.org/topic/17568-final-keyboard-layout-proposals/?p=370029#entry370029/URL]
• ible 1: http://www.keyboard-layout-editor.com/#/layouts/4b09aa1d8ac88b44c0f81a6c4a048a27
• ible 2: http://www.keyboard-layout-editor.com/#/layouts/08a3152167333b3eb3796050d90d0683
• ible 3: http://www.keyboard-layout-editor.com/#/layouts/a067fd9ce3c4bbcc4362e6759227eeee
• Saber: http://www.keyboard-layout-editor.com/#/layouts/7c6cdf68494706754cd11c81e1071b66
• Saber original: http://i.imgur.com/gZWXHlU.png
• WizardStan: http://www.keyboard-layout-editor.com/#/layouts/26c83c7209cb135a24eeed7c901a53a3
• B-Zar: http://www.keyboard-layout-editor.com/#/layouts/e97a9926d50ea4ddf4c2daf2793d0abb

Would that be OK, or did I overlook something?

How should we do the vote? First choice, second choice, third choice, with the weighting 3,2,1 points?

The problem is that if there are many variants that are rather similar, the votes get spread thinly over those variants, giving some advantage to the 'weird' proposals.

What about a series of checkbox questions, the first one "which ones could you learn to live with, even if you don't really like them", the next one "which ones are OK", then "which ones do you like", then "which one(s) do you really like a lot"? The disadvantage is that strategic voters can maximize their influence by voting extreme (e.g. only pick one proposal in every question), and they can even vote inconsistently. But the advantage is that you can better express your opinion. If we make it a public vote again, then that is probably enough to discourage strategic or inconsistent voting.

Or maybe those are just too many proposals, and ED should make a pre-selection and create an official vote amongst the ones that he likes?