Keymat Layout - the Final Poll!

[Saber]

Pfew, that was quite a study. Apologies in advance for my way too long motivation for my choices.


I am in favour of layouts 7, 6 and 1.


While layout 6 has some very strong points going for it, my biggest fear with it is that its merits will be poorly understood and the keyboard will be deemed weird by most. This has the potential to negatively affect reviews.


Overal themes I like in the layouts mentioned:

• Modifier placement.
  Shift & Fn on shoulders on one side and on keyboard on the other. This avoids finger acrobatics when having to press a shifted/Fn'ed key on the same side as the modifier. A very important quality to me. When typing tabletop this is much less of a constraint as the pinky can easily hit the modifiers.
  
  
  Also, slight preference for Ctrl/Alt on the right due to Emacs usage (Ctrl + x, Ctrl + c are very common prefix combinations. Many common combinations of the left side of the keyboard).
  
• True "dosbox compatibility" (layout 6) or cheat-sheet dosbox compatibility layout 7 and to a lesser degree layout 1.
  
  "Dosbox compatibility" is about maintaining the same assumptions about the keyboard layout as the most commonly target keyboard layout (US qwerty).
  
  
  This avoids key combination conflicts which lessens the need for developers to completely rethink keyboard shortcut design (which is a highly non-trivial semantic adaption when porting software). It also aids my memory due to pairing keys as they are ingrained in my mind.
  
• Logical positioning of keys on the keyboard. I.e. the closer to the "usual" position the better (primarily for US qwerty, secondary for German and then for the others, such as e.g. French). I personally only care for US qwerty, but the Pyra is a German device.
• Availability of international keys and diacritics
• Absence of layout design mistakes E.g. key up/down behaviour is poorly defined when a key occurs twice, therefore triple modifier keys is wrong.
  E.g. two key-down events of the same key without a key-up event in between should not be possible, this can lead to weird behaviour and needs special treatment in the driver. I am not convinced the benefits outweigh the disadvantages.
  
• Ease of use for Typing, programming, gaming as well as ease of Emacs, Awesome Wm, console and Vim usage.
  I do these things a lot. They are important to me and I believe they are useful for others. Naturally I understand that my heavy Emacs usage is the exception not the rule, but for me portable Emacs is the primary use-case of the Pyra. Similarly, I intend to run awesome wm on the Pyra. I would very much like to have a free modifier which I can utilize as my window-manager modifier key.
  
• Gaming buttons
  There seems to be concensus on this with the exception of one aspect: ins vs backspace. I simply prefer ins on the gaming keys. It feels more logical and familiar that way. More tidy. I can live with it either way though.
  
• My detailed ascii evaluation table:
  
  
  Spoiler

  | | Modifier | Dosbox compliance / | Key | International | Mistakes | |
  | Layout | placement | Shift pairing | Placement | Keys | | Comment |
  |--------+-----------------------+----------------------+-----------------------------------+--------------------------------------+-------------------------------------+-----------------------------------|
  | 1 | very good | Neutral (*4) | Good | good german & french | | |
  | 2 | bad | Good | Bad/Neutral backspace, ,<.> | good german & french | Fn+backspace conflicts while gaming | Math, Greek? Too uncommon, remove |
  | 3 | very bad (*1) | Good | Good | good german, diacritics | Super, SysRq (not entirely sure) | |
  | 4 | very good | Bad (no system) | Bad, random, () misplaced | decent german (no paragraph), | | |
  | | | | | french diacritic, bit of spanish | | |
  | 5 | neutral, see mistakes | Bad " | Bad, random, quote section messy | mainly compose based? | triple shift | |
  | 6 | good (*2) | Excellent! | Good, but odd | very good, multilingual | | Might feel weird to the masses |
  | | | US Qwerty compliant! | | with extensive diacritics | | |
  | 7 | very good | Good | Very good, systematic | good german & french | | |
  | 8 | very bad (*3) | Bad (no system) | impossible --> single width space | DIY, clear keys mappable, w/o labels | four alt keys, function keys | |
  | 9 | very bad (*3) | Bad (no system) | Bad/neutral | DIY | four alt keys, function keys | |
  | 10 | neutral, see mistakes | Bad (no system) | Neutral | good german, french diacritics | triple shift | |
  | 11 | very good | Bad () ~` | Bad/neutral, () misplaced, ~` | good german & french | | |
  
  (*1) Super is a key of its own, not a replacement for Meta or Fn.
  It is my preferred modifier for Awesome-wm and should be accessible both tabletop and handheld.
  
  
  Also, there is no shoulder Fn possible due to this.
  
  
  (*2) This satisfies the left/right modifiers but violates Ctrl+Alt on the right. There is no
  
  
  easy way to fix this without violating the regular ,< .> /? placement but it hurts emacs usage
  
  
  and Pandora backwards compatibility.
  
  
  (*3) Weird Fn placement, function keys not clear (is that Fn+number? What about F11 and F12?)
  
  
  Also, the super key is missing. I need that modifier.
  
  
  (*4) -_ placement is decoupled and <> swapped with ;:

• Spoiler

  Disqualifiers:
  
  
  - 3, 8 and 9 have issues with their modifiers. Therefore they fail my acceptance criteria.
  
  
  - 5 and 10 need to remove their extra shift keys
  
  
  - 8 and 9 need to adjust their quadruple alt.
  
  
  Strong layouts
  
  
  - 1 scores good, I prefer the regular ,< .> vs the way chosen and some shifted pairs could be better
  
  
  - 6 is an extremely strong layout. It does require shifted Fn and is certainly the odd-one-out. As said, I fear it might be perceived as complex and weird despite all its merits
  
  
  - 7 is an extremely strong layout. Good balance of known placement, US compatibility and international support.
  
  
  Disclaimer:
  
  
  These metrics are based on my own perception. I do not use international keys and cannot comment on the nativeness of their placement very well.
  
  
  Saber, comradekingu. Design wise I have been more in the Grench and _wb_ camp and thus I may come accross very critical on some decisions in your layouts. However, I wish to express my gratitude to you guys for working so hard on this for the past months. You have greatly influenced the discussion and given clear alternatives to the other layouts. This is always a good thing. Thank you guys for offering a choice.
  
  
  Likewise, my thanks to all the others for the countless hours spent on refining the designs. I regret I could not participate as actively this time as I would have liked. Most of the discussion I spent lurking on the side. That said, I enjoyed the discussion and applaud all of your efforts to make the best of this in spite of the animosity that the community tends to express towards keyboard layout discussions. I have learned a lot during the past months. My thanks for that, I hope many more interesting discussions will follow in the future.

 

Okay, that's all very nice of you but I do question your choices so let's use #7 as an example which you say is the burliest layout as many others agree with you. -_-

 

How do you explain it's strength based on the ( and ) and the one Shift key dilemma I stated pages back? The one where the only keyboard Shift we have is too close to press them with the other thumb without using the shoulder button, which some people don't ever use. Also, F12 on Enter being a tricky place for it. Or / and ? being too close on the right half to the keyboard Fn/Meta key which brings them up. Or how does someone get the Grave diacritic and not the backtick?

 

What about keyboard backlighting which in this layout requires the Meta key, which happens to be on the same side as it(unless we use the Shoulder trigger)? What if the person doesn't use the Shoulder trigger for Fn/Meta? They are now forced to for a basic feature which cost a few Euros to incorporate, or they'd have to get used to pressing FnLock and moseying up the right half to the brightness controls, adjust the keyboard backlight, then mosey on back down to the FnLock to turn it off, hoping they don't have to turn it off anytime soon. They'd repeat this when they don't need it after BTW.  

 

Sure, much of the above could be fixed in #7 with some ingenuity perhaps, but we aren't talking about what it will be but what is. It's perplexing this layout won over ED's which is superior to it. :mellow:

 

About my layout though, besides the extra keyboard Shift(which most keyboards have two keyboard Shifts BTW), I have yet to hear what is "wrong" with it, functionally speaking. Works too well is it? Symbols too easy to get to and not scrambled around sufficiently to lose them? Not enough gimmicks, obscure glyphs, or finger acrobatics required to get in the way of usage? Key backlighting on Shift too smart? Not enough symbols loaded on top of modifiers? 

 

I could give you the reason for every piece of my layout and why I put what where I did. No padding anywhere.       

 

[Neelix]

Personally I consider having ( and ) on the Shift layer of 9 and 0 (respectively) where I would normally expect to find them as a strength of layout 7, and a weakness of the layouts that put them elsewhere.

No matter how you rearrange the symbols on the fn-layer half of them are going to end up on the right hand side of the keyboard, (especially since using the fn+shift layer for additional symbols was ruled out) but by your logic it isn't fair to put any symbols on the fn layer on the right side of the keyboard at all. I'm sorry but that just doesn't wash, especially since there is a perfectly usable shift+fn modifier pair on the left side of the unit.

@_wb_ Is there really a need for separate Print Screen and SysRq keys? Why not leave SysRq on Print Screen like with a normal keyboard? I see no need to specifically label it, as it would be a ) where people expect to find it and b ) described in the documentation and c ) as I believe you have previously noted it's something that would normally only be used by those willing to rtfm anyway.

-Neelix

 

[EvilDragon]

So you prefer having () in location you expect them to be, but are hard to reach?


Did you ever had problems with that on the Pandora (where almost every key is in an unfamiliar location, but based on the importance).


Because that's something I will most likely change in any final layout... () is too important in my opinion to be in an uncomfortable location. Okay, if you have Shift on the left side...

 

[Saber]

Personally I consider having ( and ) on the Shift layer of 9 and 0 (respectively) where I would normally expect to find them as a strength of layout 7, and a weakness of the layouts that put them elsewhere.


No matter how you rearrange the symbols on the fn-layer half of them are going to end up on the right hand side of the keyboard, (especially since using the fn+shift layer for additional symbols was ruled out) but by your logic it isn't fair to put any symbols on the fn layer on the right side of the keyboard at all. I'm sorry but that just doesn't wash, especially since there is a perfectly usable shift+fn modifier pair on the left side of the unit.


-Neelix

The symbols on the left in my 8.0 layout in my sig I consider more important to more people than the ones I placed more over on the right half.

As for ( and ), take away the shoulder Shift, which is how some use the Pyra, and see how strong your favored layout becomes where you have a hard time reaching those braces now. With one keyboard Shift, we are back to where we started with the Pandora, but if you can come up with at least one reason, one symbol or key you think is excluded from my layout that you find it's omission dire, please do tell. I keep hearing repeatedly about my layout having one Shift too many but not what is missing because I included the "extra" keyboard Shift.

What is this mystifying key we need so badly that's gone AWOL? Euro? Yen? Trademark? What is wrong with leaving the remapping of this lone Left Shift key I placed on the right keyboard half to the after sales market, should they want to reassign it to their own key? Possibilities are Pause/Break, PrintScreen, SysRq, Compose, any vowel with a diacritic you can think of with it's uppercase counterpart, and even the dynamic duo / and ?. Lot of good customization can come with two keyboard Shifts if the user decides they only need one keyboard Shift later. 

 

[Kev2442]

I posted this earlier, got a little bit burried in posts, hope this helps :

http://boards.openpandora.org/topic/18315-keymat-layout-the-final-poll/?p=391868/URL]

 

[Wrath Of Khan]

I dont much mind as long as its a sensible layout.


I dont need perfection.


Im not sure what would be best so ill not vote.


What about a pyra case colour poll ed? Excluding the dark red colour that we already agreed on.


Everyone agreed on that cos I remember that they did and the internet never lies.

 

[Foxgod]

I would vote for metallic dark blue

Blue fire is a thing too

 

[Neelix]

So you prefer having () in location you expect them to be, but are hard to reach?

Did you ever had problems with that on the Pandora (where almost every key is in an unfamiliar location, but based on the importance).

Because that's something I will most likely change in any final layout... () is too important in my opinion to be in an uncomfortable location. Okay, if you have Shift on the left side...

Except that I don't regard them as being hard to reach in that location. We *do* have a Shift on the left hand side, and you've confirmed that the shoulder buttons work well and are easy to press.

-Neelix

 

[Ivididiviividi]

To be proud of my future Pyra, i demand to have a label-less, blue metallic, 2.6mm travel distance, glass covered keymat with Kvass aroma.

For the shell, voting for a keymat layout where / (slash) doesn't require a key combination.

 Did you my topic nr. 2?

Please do NOT only vote what you would like for your special occasion.

Try to think about ALL possible tasks and choose the best one for that.

This is still a terrible experience a serious bunch of us had with the Pandora.

And even a person who would prefer only numbers would understand that it doesn't make sense for the rest of the world and would not choose this as best layout in that case.

I don't think its not wise to rush making such assumptions about people who do only need numbers on a handheld like Pyra.

 

[Eight Bit]

I hope the final layout will have 2 keyboard shifts

 

[rygD]

I wish people would give more information about why they like the ones that they do - just a few qualitative color pieces to go with the stark quantitative nature of the poll results. Emphasis on what features/themes/placements people -like- about a given layout or layouts. Enough of the negative campaigning against the 'others' though.

That would be perfect to finalize the Layout in the end.


What I love about Layout 11 is the F11 key up there. It might be weird at first, but for X, it's basically a Fullscreen toggle key, which is a neat feature


Well, there are quite a few designs I like, I also voted for multiple ones, as some are really good

I was worried I was going too far, because I voted for more than 1 or 2.  I like and dislike some things about all of them.  If it will help I can type up a short explanation of what I liked most about what I picked.  I can probably also include the major things I disliked of others.

 

[TrashyMG]

I hope the final layout will have 2 keyboard shifts

Well many like having a shift on a shoulder button as it's convenient and having three shift buttons is a bit excessive. 

 

[rygD]

So you prefer having () in location you expect them to be, but are hard to reach?


Did you ever had problems with that on the Pandora (where almost every key is in an unfamiliar location, but based on the importance).


Because that's something I will most likely change in any final layout... () is too important in my opinion to be in an uncomfortable location. Okay, if you have Shift on the left side...

Having keys close to where I expect them compared to a normal US keyboard is important to me, as well.  This is why I was wondering about sticky modifiers.  I don't use the shoulder buttons on the Pandora much while typing.  I agree with _wb_ that if those of us that don't use shoulders have trouble with some keys/characters we should turn sticky modifiers on.

 

[ible]

sticky modifiers could be default, since power users know how to change these things...

also, i'm not fond of _wb_'s mod of 7, because it would make Space=Space hard to type (code combo).  i feel like there's a way to rearrange the bottom two rows to help make code combos more efficient.  but it still is "hard" to type certain combos if you give yourself the handicap of not using the shoulder modifiers...

 

[Grench]

I posted this earlier, got a little bit burried in posts, hope this helps :

http://boards.openpandora.org/topic/18315-keymat-layout-the-final-poll/?p=391868/URL]

Thank you for doing so - things do move very fast in this conversation. You're one of a small handful of non-keyboard-designers that has provided input. THANK YOU!!!

 

[DAP]

8 is the only acceptible one, it is the only one without a double wide space key.

 

[comradekingu]

Eight bit has made many keyboardlayouts. It would really help if everyone stated why it is they are of any given opinion, and the languages they speak.

All the keyboardthreads are autosaged, which is why there arent many eyeballs on this.

 

[Eight Bit]

I hope the final layout will have 2 keyboard shifts

Well many like having a shift on a shoulder button as it's convenient and having three shift buttons is a bit excessive. 

I'd give up the shoulder shift for 2 keyboard shifts tbh.

I'm not sure what to put there instead though

 

[Eight Bit]

Eight bit has made many keyboardlayouts. 

I'm just not very vocal/mouthy and thus often disregarded or overseen.

Story of my life

 

[Neelix]

sticky modifiers could be default, since power users know how to change these things...

*nods* I don't see a problem with sticky keys on the keyboard shift and meta keys being enabled by default as long as it doesn't also affect the shoulder button versions. (and as long as they can be unstuck without triggering anything)

-Neelix