It's the keyboard layout.

[szr]

Left side of the keyboard is at any time the least physically accessible, given how the things you use shift in conjunction with, are on the right side.

I think it makes more sense to have shift on the top left shoulder, since the button is above ctrl on a regular keyboard.

Sorry if I wasn't clear. I have no problem with physical position of the shift keys in ible's last layout, but only which shift key (left or right) that they represent. In that layout, the shfit key that is physically on the the left side (on a left shoulder button) is "right shift" and the shift key on the keyboard, which is on the right-hand side is "left shift", which strikes me as backward. It would seem to make more sense if the left most one sent "left shift" and the right most one sent "right shift", would it not?

 

[TrashyMG]

Left side of the keyboard is at any time the least physically accessible, given how the things you use shift in conjunction with, are on the right side.

I think it makes more sense to have shift on the top left shoulder, since the button is above ctrl on a regular keyboard.

Sorry if I wasn't clear. I have no problem with physical position of the shift keys in ible's last layout, but only which shift key (left or right) that they represent. In that layout, the shfit key that is physically on the the left side (on a left shoulder button) is "right shift" and the shift key on the keyboard, which is on the right-hand side is "left shift", which strikes me as backward. It would seem to make more sense if the left most one sent "left shift" and the right most one sent "right shift", would it not?

I believe this is to match how it's done on the Pandora.

 

[Haraldur]

My gripe with nudges on the keys is those annoy me. Concavity is nicer, but thats very hard to do when the membrane has to be convex in the other direction. At best you end up with a thinner key, and a thinner key is less durable. In the end depending on if you wear out the membrane or keytop first.

Really? I find the dashes under the F and J on my laptop indispensable. They're subtle yet evident. 

I agree with Saber here.  However, it might be an issue with the Pyra keyboard. 

Considering the fact that the keys will be shorter but wider (from what I can recall; correct me if I am wrong), the bump might get in the way of the print. 

-Glyph Reader

I think Saber had the right idea with a slight ridge around the edge of the key. (or part of it) Just a subtle difference that gives those keys a slightly different texture to the touch, that's all it needs.


- Neelix

Indeed, it matters less what the differentiator is than that it exists to discriminate between keys. Options include, but are not limited to:

Bumps (which could be to the side of, rather than below, the symbols if that is more appropriate -- or surrounding)

Ridges

Making most keys convex (as on the Pandora keyboard) with some special ones concave

Use of different materials: the Pandora keyboard keys have a very smooth 'glossy' feel, but the face buttons are different (ridged* with their symbols, a more 'matte' material)

* I assume that there have been no problems with the face buttons scratching the screen, so there should be no worry about ridged F and J keys being a problem.

 

[ible]

Spoiler

I agree we should get the keyboard right, and I think it would be nice to have a lot of "free" keys, which do not have any AltGr printed on them, but which can be remapped.  One of ED's implicit design criteria from the first post, however, seems to have AltGr's printed on everything.

I put some stuff in green, which I think doesn't need to be printed on the keymats, but ED may want to put in the umlauts, even if they are on the "reasonable" keys:

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

I'm trying to put symbols like []{} on keys that typically don't have an alternative form for international layouts, but Grench'ifying things for extra free keys.  Still no more than 3 prints per key, though.  

I know some things end up on the "wrong side" of the keyboard, but this is to keep room for some of those free keys I'm talking about, as well as making it easier to chord common mathematical expressions (<=, +=, -=, :Enter, etc.).

Spoiler

I like this layout, but have one question. In the description, you say that the modifier keys on keyboard are the left-hand set while the ones on the shoulders are the right-hand set. This appears to work fine, with the exception of shift. Since shift on the keyboard is physically on the right-hand side and the other shift is on a left hand shoulder button, shouldn't the they be right and left shift, respectively, instead of the opposite, to match the physical side they are on?

Thanks!

Yeah, I would prefer it to be the way you suggest, but I don't have a strong opinion about it. As long as they're differentiable, that's what counts .

 

[_wb_]

Keyboard left, shoulders right, that's how it is on the Pandora. SELECT is LeftCtrl, R1 is RightCtrl, and so on.


ible: how do you like my most recent proposal?

 

[ible]

which, this one? http://www.keyboard-layout-editor.com/#/layouts/8c97d978364024477776b181cb8032de

i already commented a bit on that one (overall very nice, but i'd rather have insert and delete on the small game buttons). But a little bit more in depth...

I'd prefer not to have 4 prints on any key, which happens on your ,. keys (not a huge problem, but against ED's guidelines I think). I very much like the layout from a "keeps fairly true to a US keyboard layout" location-wise for keys. but at the same time, that makes it slower to type certain common code combinations (e.g., <=, [0], :Enter), but perhaps not too much slower. Oh, and I'm not so excited about Shift/Meta for shoulders and keyboard being on the same side of the device. But again, not a huge problem. One big plus, writing-wise, is that words typically end in the letters ESTD http://letterfrequency.org/, which are all on the left side, which makes putting ,. on the right-side a more reasonable thing.

This is what I might do to merge your and my layout, but I'm not sure I like it more than my original:

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

Any further critique/suggestions on my original?

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

Here's hoping some of our work makes it into the final Pyra. As I conjectured earlier, I worry that ED wants most keys to have AltGr prints on them, which would render our work useless .

 

[szr]

I believe this is to match how it's done on the Pandora.

Keyboard left, shoulders right, that's how it is on the Pandora. SELECT is LeftCtrl, R1 is RightCtrl, and so on.

Thanks, I didn't realize that that was the case with the Pandora. That is definitely something I could live with.

 

[Malleus]

Long time lurker here

only the letter "å" missing to make it swedish compatible (åäö), possible to squeeze in?

 

[ible]

Yes, I think on _wb_, Grench, and my keyboard, you can map any non-AltGr'd key, e.g. AltGr-P on mine, to get the å.

In the OP, however, ED seems to like filling up the keyboard with AltGr combos, none of which was å.

I'm excited to do a few additions myself if that's easy software-wise, and if ED leaves a few keys untouched .

 

[Saber]

Long time lurker here

only the letter "å" missing to make it swedish compatible (åäö), possible to squeeze in?

Hello Malleus, you can software remap any key you don't need like for example the ü for an å.

 

[jes3]

510 replies? wow. Do we have a keyboard yet? I just want the Pyra.

 

[TrashyMG]

510 replies? wow. Do we have a keyboard yet? I just want the Pyra.

you mean only 510 replies, You have to see the 50 other threads relating to the keyboard.

 

[Willhelm]

we need another thread for the pyra screws! :rolleyes:

 

[Daniel Jackson]

510 replies? wow. Do we have a keyboard yet? I just want the Pyra.

Yeah this surprises me too. I was just following this topic without posting, but it's amazing to see how much discussion there is.

 

[Rockthesmurf]

How well does Swype work with non English languages? I am forever impressed with how well it works for English and wonder if it is as good with other languages. I am not suggesting we should use touch input for the Pyra more thinking if Swype can guess the right word with squiggles on the screen, it should be possible for software on the Pandora to work out what accents to use (based on spelling and context).

 

[Grench]

510 replies? wow. Do we have a keyboard yet? I just want the Pyra.

Yeah this surprises me too. I was just following this topic without posting, but it's amazing too see how much discussion there is.

It's interesting to me how many people will take the time to read the thread and instead of posting something helpful, find it necessary to post a complaint about the length and detail of the discussion.

That there are people who have taken the time to dissect the needs, examine the planned usage, learn international needs, propose potential solutions, dissect each other's work, modify and adjust designs and feed off of each other's findings is a GOOD thing.

If any portion of what has been learned in the process makes it into the final Pyra keyboard design, the Pyra will be better for it.

Yes, we're all proponents of our own design ideas.  Everyone likes their own ideas.  However, you will notice that we're also modifying layouts to fit issues that were unknown in first iterations and merging ideas and findings.  It is an iterative, collaborative group process and it is working.  We now have several viable layouts.  Each has strengths.  Each has been made better by the process.

 

[sebt3]

We now have several viable layouts.  Each has strengths.

So.. let's make a forum pool

 

[codifies]

We now have several viable layouts.  Each has strengths.

So.. let's make a forum pool

...yeah.... just make sure we have plenty of chlorine !

 

[Daniel Jackson]

It's interesting to me how many people will take the time to read the thread and instead of posting something helpful, find it necessary to post a complaint about the length and detail of the discussion.

That there are people who have taken the time to dissect the needs, examine the planned usage, learn international needs, propose potential solutions, dissect each other's work, modify and adjust designs and feed off of each other's findings is a GOOD thing.

If any portion of what has been learned in the process makes it into the final Pyra keyboard design, the Pyra will be better for it.

Yes, we're all proponents of our own design ideas.  Everyone likes their own ideas.  However, you will notice that we're also modifying layouts to fit issues that were unknown in first iterations and merging ideas and findings.  It is an iterative, collaborative group process and it is working.  We now have several viable layouts.  Each has strengths.  Each has been made better by the process.

Please don't get me wrong, that was just an observation - not a complaint. The length of the discussion just surprised me, that's all. But of course I understand what it's all for. 

 

[Wrath Of Khan]

The back-light is to light the way when you wake in the dark of night, bursting for a piss, having forgotten where the light switch is located.

(Its been known to happen)

Whilst standing excitedly over the bowl, in the "Wee" hours, Pyra in one hand and man-snake in the other, you can exclaim your dissatisfaction at the imperfect keyboard layout...

Perfection is an unattainable beast.