Current Keyboard Layout

[comradekingu]

People expect it away from the typewriter area, top left on the keyboard. Ctrl+q is not that place, not only because of accidental Esc, but considering there is an option of doing it where it is expected, unlike the pandora.

Not only is the comparison unwarranted, its also made worse by the proposal to put Fn on shoulders to accidentally trigger it even more. Having Shift and Fn together, when esc is in the middle of a cluster used with any of those, just takes the cake.

My rate of error with backlit keyboards is the exact same. If something+q for escape is good for anything, its to teach you how to save your stuff, the hard way.

The same anxiety I have for putting a product like that into users hands. It makes me physically unwell.

 
Just a quick recap of some usability errors, out of the ordinary, reported by reviewers lately:
 
First offender, I remember this, negative publicity galore.

Acer following suit because if anyone can undercut the standards of mediocrity

Apple invents it

Google tries not to be evil, and surely one of these solves the issue, right ?

Apple designs around the issue and renames backspace for good measure ¯\_(ツ)_/¯

To quote gizmodo from one such review "Putting the escape and power buttons so close together seems akin to placing a seat recline and cockpit eject button adjacently."

Luckily the hardware design solves this particular issue with the powerbutton residing a bit away from the rest of the columnkeys, however:

Designing the potential for alt+F4 and Ctrl+alt+F* and accidental esc is just not needed.

 

[Kev2442]

The "B" button on the lower level. I'm kind of a symmetry freak, so is there any reason why ?

Symmetry?  The Pyra layout has -more- symmetry than a standard keyboard does.


On the Pyra:  Although the B key is not dead center of the bottom row, G is.  The line between V and B is the 'center line'.  Moving up the keyboard a center line is maintained and the row to row key offset is maintained in a proper line.

Pretty sure this was a reference to the gaming buttons, not the keyboard section. B and Y have the letter below the arrow symbol, A and X have the letter above the arrow symbol. This makes A and B look asymmetrical. I don't think this was intentional on ED's part though, it's just how EightBit had entered them into the layout editor.


I honestly doubt that it would appear that way on a finished unit. We're only deciding on what goes where here, here not the actual look of how the keys will be printed.

This shows once again how easy it is to confuse two things with the same label, like keyboard keys A B X Y and action buttons A B X Y.

I would propose to prominently label the action buttons with "Home", "End", "PgUp", "PgDn" (in text, not symbols). If there's a need to add the letters A B X Y for backwards compatibility with the Pandora (which I doubt), then it suffices to use small letters A B X Y.

This. It's even more ironic knowing I've participated myself in the debate about possible confusion. I should have written ( B ).

About the shoulder buttons, I meant the horizontal level. Like R1 = R-Ctrl and R2 = AltGr. This way L1 and R1 would be the main keyboard functions, L2 and R2 the side characters selectors, L1 and L2 the character modifiers.

Thanks Grench for the other info, and for proving the possible confusion.

 

[Grench]

People expect it away from the typewriter area, top left on the keyboard. Ctrl+q is not that place, not only because of accidental Esc, but considering there is an option of doing it where it is expected, unlike the pandora.

Not only is the comparison unwarranted, its also made worse by the proposal to put Fn on shoulders to accidentally trigger it even more. Having Shift and Fn together, when esc is in the middle of a cluster used with any of those, just takes the cake.

My rate of error with backlit keyboards is the exact same. If something+q for escape is good for anything, its to teach you how to save your stuff, the hard way.

The same anxiety I have for putting a product like that into users hands. It makes me physically unwell.


Just a quick recap of some usability errors, out of the ordinary, reported by reviewers lately:

First offender, I remember this, negative publicity galore.

Acer following suit because if anyone can undercut the standards of mediocrity

Apple invents it

Google tries not to be evil, and surely one of these solves the issue, right ?

Apple designs around the issue and renames backspace for good measure ¯\_(ツ)_/¯

To quote gizmodo from one such review "Putting the escape and power buttons so close together seems akin to placing a seat recline and cockpit eject button adjacently."

Luckily the hardware design solves this particular issue with the powerbutton residing a bit away from the rest of the columnkeys, however:

Designing the potential for alt+F4 and Ctrl+alt+F* and accidental esc is just not needed.

And IBM got it just right all those years ago with Esc on the furthest upper-left key on the system out where it's easy to get to deliberately, but hard to accidentally brush.

https://en.wikipedia.org/wiki/Model_M_keyboard#/media/File:IBM_Model_M.png

Funny - that looks kind of familiar...

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

Esc where escape should be - just like a model M.

Backspace where backspace should be - just like a model M.

6 button Insert, delete, Home, End, PgUp, PgDn cluster in-tact.

     Insert and Delete paired logically.

     Home and End paired logically.

     PgUp and PgDn paired logically.

Expected special use keys in a logical order down the right side of the machine.

     Backspace is above Enter which is above Shift which is above Fn.

Super, L-shift, R-shift, L-Alt, R-Alt (AltGr), L-Ctrl, R-Ctrl, L-Fn, R-Fn all accounted for and on dedicated keys.

     *Adding a 2nd Super to the lid switch is an interesting thought - but I could see it as being a simple 'key' as an event driver as well.

Tab, Space, Enter, Period, Comma and number keys all on top layer.

F1-F12 in a contiguous row.

Direct German support with 4 letters in a row on the Fn layer.

Direct Spanish support with 1 letter and 2 symbols on the Fn layer.

Symbol pairings created/maintained in a logical manner.

     \ with /

     . with ,

     < with >

     [ with ]

     { with }

     ( with )

     | with _

     + with - with =

Single key brightness control with 'looped' settings.  It does not get any simpler than 1 button, push to increase brightness.

Two menu activation keys.  One is a direct shortcut to hardware.  The other is currently labeled 'Help' but could just as easily be a simple shortcut to the main menu OR applied to whatever we need a direct control button for.  This layout is so efficient that I actually had a button more or less left over and since ED wanted this to be great for new users - a direct keyboard link to the help and documentation might not be a bad thing.

There is no good reason why the back lights need to consume both the main and Fn layer of two physical buttons.  It doesn't need separate buttons for up and down - it only needs to go up to max, then loop to off OR go down to off then loop to Max (may be better).  But it does NOT need to consume 2 keys.  That gives Esc back the key on the top left that it truly needs and deserves.

Super IS a modifier key and should be treated as one.  We are making a general use keyboard, not a single-OS specific one.  New real keyboards have 'Super' or 'Windows' keys.  On Windows the capability of the key is dumbed down to just pull up the Start menu - but what did you expect from Windows?  Yes, actually using 'Super' is in it's infancy on Linux.  BUT - it also has huge potential to the Pyra.  End users who CHOOSE to use it can tie entire functions to Super+key or Super+Fn+key or even Super+LFn+RFn+LShift+RShift+LCtrl+RCtrl+LAlt+RAlt(AltGr)+key

Heck,  in theory you could even make your login password a combination of modifier keys plus any one of the main keyboard area keys and be relatively secure from the casually snoopy.

Esc on Fn+Super is an error, plain and simple.  Let's not argue it any more - just fix it please?

As for utilizing the lid switch as the 2nd Super - I'm not opposed but have one concern.  If we close the door and the light doesn't go out how will we know?  (Insert refrigerator engineering joke here.)  Seriously - that actually sounds like a pretty good idea.  I'm not seeing a clear drawback to it.

 

[comradekingu]

I thought we were done with many of the things on the proposed layout, hopefully insight can be shared. An even quicker way to discard bad ideas is to show them to novices who know little to nothing about keyboards.

The model M is many things, having been made in all (?) layouts. The key-pairs are different among those, but moving , and . which are always bottom right to the left side, to observe one of them, is where i lost your trail of thought.

It is inefficient too.

Direct language-support would be the same approach you have to typing directly in English, putting you outside of the keyboard for the languages you mention. On a model M, ANSI or ISO or JIT, A is always A.

< with > on one button is actually how its done on ISO 105key. Its the 105th key, which is useful, but functions as an afterthought since the other stuff was already laid out before it.

If you type a single key to adjust brightness, there is no fine control, unless you want to press 100 times, and 98 times over if you overshoot it.

If you need a manual to explain anything important, the battle is lost.

 

[Grench]

I thought we were done with many of the things on the proposed layout, hopefully insight can be shared. An even quicker way to discard bad ideas is to show them to novices who know little to nothing about keyboards.

That sounds like a way to get a knee jerk opinion based response from an uniformed person who has absolutely no interest in what the device actually does. That would be the same person who will be utterly confounded with trying to figure out how to do anything besides input letters on your layout.

The model M is many things, having been made in all (?) layouts. The key-pairs are different among those, but moving , and . which are always bottom right to the left side, to observe one of them, is where i lost your trail of thought. It is inefficient too.

On a US standard keyboard, -=[]\;',./ and Backspace, Enter, Shift, Alt, Ctrl and 4 arrow keys and Insert, Delete, Home, end, PgUp, PgDn are ALL on the right. And we also need to add Fn to that mix.
Placing Fn+Shift on the right means that every symbol that is on the shift or Fn layer is going to be easier and more efficient on the left. ED has expressed that he prefers shift&Fn to be on the right. So, that highly used <> pair on , and . need to be somewhere easily accessible to the LEFT thumb as the RIGHT thumb is busy hitting shift.

Conveniently enough this also gives a minor homage to how it was done on the Pandora.

Direct language-support would be the same approach you have to typing directly in English, putting you outside of the keyboard for the languages you mention. On a model M, ANSI or ISO or JIT, A is always A.

< with > on one button is actually how its done on ISO 105key. Its the 105th key, which is useful, but functions as an afterthought since the other stuff was already laid out before it.

Several of us have explained this over and over - there simply is not room for a P+1 L+2 layout without sacrificing necessary modifier keys from the main keyboard area. A potential solution was found to your stated desire - that of moving the number row to the Fn layer. You didn't like that either. I have gotten the idea that you will not be satisfied by any keyboard not of your own design - and will continue to refuse to accept that your design simply will not, in it's current form, function for a normal user with a normal OS.

If you type a single key to adjust brightness, there is no fine control, unless you want to press 100 times, and 98 times over if you overshoot it.

On my Pandora, I use OFF, Minimum (lowest on setting), 2 or so down from brightest and maximum. Off, Low, 33%, 66%, Max should be quite adequate. Nobody needs 100 distinct levels of brightness and to suggest it is simply an absurd statement.

If you need a manual to explain anything important, the battle is lost.

Do not confuse my above explanation of functions and reasoning behind what is placed where as a 'manual'. Everything in this layout is intuitive and clearly labeled to functionality. I have kept it simple and the differences to ED's original layout are very limited.
ED's original:

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

My modification to ED's to fix a few errors and a few organizational and clean up items:

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

Flip back and forth to see the changes. They are not dramatic.

The entire explanation of what was changed and why is here:

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

 

[ible]

my vote is for <> on Fn rather than Shift, as in the original ED post .  it makes coding combos more natural, despite being nonstandard English (though standard german).

 

[comradekingu]

The person who wants the keyboard, wants it to be usable for the most people.

A US layout is just a layout, a keyboard is always the same.

The reason novices are able to use keyboards, is due to this reason.

Symbols on Fn breaks this, numbers not primary breaks this. Quite frankly things on Fn doesn't work, don't make it worse than it is.

Dont start with the pandora layout or the US layout, start with all the layouts. And show it to people, dont assume what works.

Some people colour-calibrate their screens, some people suffer from eye fatigue, that is not nobody, and brightness matters.

If you want to adjust brightness, then adjust it, three levels is brings almost nothing over regular controlpanel autosettings, a timeout, on power, and not on power, with settings for each.

Incremental settings can be done, if Fn isnt on the shoulders. One of the many adverse effects you avoid by not having Fn on the shoulders.

 

[TrashyMG]

The person who wants the keyboard, wants it to be usable for the most people.

Actually I only really care if it's usable for me. 

 

[comradekingu]

You are one of many, what i meant is I hope ED picks something that works comparably well for me, as it does for you. Me being mainland european, and you getting a default without any mainland european signs on it.

That way we can all type like we are used to. No need for a manual, no need for hacks.

I have a reason to care about me, and I have a reason to care about you. Collectively, making it a good compromise sells more units.

 

[rygD]

...

So please - don't turn this thread into another "let's see how many posts can be made!"-thread - only post, when you REALLY go something important to post!

...


But don't explain it in long texts.


One or two sentences should be enough to explain why a key should be somewhere else!


DO NOT do lengthy posts please - they are hard to read and I don't have too much time. Keep it simple and readable, okay?

...

 

[Neelix]

I have to say I really wouldn't want looped brightness settings... I like to take them to one extreme or the other, without worrying about how many times I have to press it to get there. If I hold down the Br+ button I want it to take me to maximum brightness and stop, not to keep cycling endlessly.

-Neelix

 

[Grench]

I have to say I really wouldn't want looped brightness settings... I like to take them to one extreme or the other, without worrying about how many times I have to press it to get there. If I hold down the Br+ button I want it to take me to maximum brightness and stop, not to keep cycling endlessly.


-Neelix

Cycling endlessly. With off, min, 33%, 66%, max? You really wouldn't be able to figure that out?


As for, "OMG my eyes are so insanely sensitive that I need 100 brightness settings!!!" Nothing in this plan prevents someone from opening up the hardware control menu and changing what the intermediary values are - or for that matter prevent us from having more than 5 possible values.


I had another recommendation that was deemed too complex for the normal user to follow.


Key labeled as:


☼ +/-

☼ +/-


Press the ☼ key and the display back light level increases.

Press shift + ☼ key and the display back light level decreases.

Press Fn+☼ key and the keyboard back light level increases.

Press Fn+shift+☼ key and the keyboard back light level decreases.

I find -either- method to be far better than loosing 2 physical keys to this VERY simple hardware control.  Maybe have both methods as options with the easy to use looping behavior as default?


Neelix, you do realize that by arguing against using a single button for brightness that you are arguing FOR embedding the Esc key on the Fn layer of the main keyboard and wasting an otherwise perfectly good key at the top left that should be used for Esc, right?

I found in the main/old keyboard threads that a lot of people will argue positions without understanding the trade off that they're promoting.

Really, this will work, it's simple, intuitive and logical AND it does not prevent advanced use in order to allow for ease of use.

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

 

[iprice]

This may well have already been discussed, and apologies if it has, but... How often do you use brightness controls on any of your devices? Do we really need to waste key(s) for a function that is used rarely (I presume)? Can it not just be controlled via the OS menus? Or do peeps really change their screen light often enough to make it an essential requirement?

 

[ible]

I use my brightness settings all the time (except kb brightness, which i turn permanently off).  this is because i work with varying levels of ambient brightness, which my laptop doesn't recognize.  i don't want full bright screen when in the dark, and i can also save battery that way.

 

[Grench]

This may well have already been discussed, and apologies if it has, but... How often do you use brightness controls on any of your devices? Do we really need to waste key(s) for a function that is used rarely (I presume)? Can it not just be controlled via the OS menus? Or do peeps really change their screen light often enough to make it an essential requirement?

Brightness Up MUST be a physical hardware control.  The rest is optional and can be controlled via OS menus.  Why?  

1.  Because if the screen back light is off, nothing is displayed.  

2.  If the screen back light is 'minimal' and you're out in the bright sunshine, it may as well be off and you need a button, not a menu, to increase it.

So, something has to be engineered to take this into account.  At minimum, one 'key's function' must be ascribed to this.  

I feel it is adequate to do the entire needed up and down functionality for both the screen and the keyboard back lights with a single physical key by using normal, shift, Fn and Fn+shift on that key.  This was criticized as 'too complex' or 'too advanced'.  So, I suggested using a looping mechanism so that pushing Brightness Up when the device is on Max turns the backlight off and it starts over.

I think BOTH profiles can be done - but either way it only needs ONE button assigned to brightness control, not two.

Why is it important to do brightness on only one button instead of two?  Because that 2nd button that we're saving from relegation to brightness is where Esc should live.

 

[Neelix]

My issue is specifically with the looping idea.   I'd also want  somewhat finer control than just 3 presets.   

I'm not entirely against having all four brightness functions on one key with chorded modifiers, though I can't think of a good way to communicate that scheme to the user in an area the size of the key.

That said, I'm also not against having Esc on the Fn layer.  (Having it on Fn-Q on the Pandora worked well enough for me, and I don't see any real problem with having it similarly located on the Pyra)

-Neelix

 

[comradekingu]

Fn+↑ and Fn+↓ is still buttons, just not dedicated. If you do shift+ and Fn+shift+ its too complex, looping is too simple. You dont have to engineer anything.

You can still see the keys with backlight off, unless the room is fully dark and you have your screen fully off, which only happens when the device is off, so the dedicated button you are looking for is the powerbutton.

 

[Grench]

Fn+↑ and Fn+↓ is still buttons, just not dedicated. If you do shift+ and Fn+shift+ its too complex, looping is too simple. You dont have to engineer anything.

You can still see the keys with backlight off, unless the room is fully dark and you have your screen fully off, which only happens when the device is off, so the dedicated button you are looking for is the powerbutton.

That is a fantastic solution - one that has been proposed before thought and subsequently trashed.  Still, it might be worth re-floating.

There is a contingent that was previously adamantly opposed to utilizing the Fn+GameControls for ANYTHING.  Is this still the case?

We have two backlights to control.  Though I imagine in your scenario Left- and Right+ for keyboard back light could work.

So - do people still hate using the Fn layer of the left game pad (Pyra arrow key equivalent) as screen and keyboard brightness controls?  Or is that OK now?

That could free up yet more of the 'above the nubs' row for alternate tasks.

It would potentially work like this:

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

Though I don't know if ANY markings can happen on the single-piece left game pad.  So, those brightness controls would potentially be left un-printed OR printed to the case plastics...  Hmm..

And yes, there can be more debate on what would go in the row over the nubs.

 

[comradekingu]

It was never OK, it sucks, but it sucks less than the reason for Fn to begin with, which is not enough buttons. Dedicated brightnessbuttons just dont make sense when you have less than laptop amount to work with.

Fn+GameControls is only a problem if Fn is one of your game control buttons. You would start adjusting brightness in a game requiring dpad and shoulders. I also think Fn+gamepad buttons for things like scrolling (or other) is useful.

Fn+any button as a decide-yourself is only a problem if you put a FN-combo on it.

 

[Neelix]

It was never OK, it sucks, but it sucks less than the reason for Fn to begin with, which is not enough buttons. Dedicated brightnessbuttons just dont make sense when you have less than laptop amount to work with.

Fn+GameControls is only a problem if Fn is one of your game control buttons. You would start adjusting brightness in a game requiring dpad and shoulders. I also think Fn+gamepad buttons for things like scrolling (or other) is useful.

Fn+any button as a decide-yourself is only a problem if you put a FN-combo on it.

And there you have it... Fn *Is* one of the game control buttons.  (it's on one of the shoulder buttons remember)   I'm not willing to give up Fn on  the shoulder button for the sake of having Fn combos on the dpad.

-Neelix