It's the keyboard layout.

[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.

 

[_wb_]

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).

Typically English is the best language for any software, since typically it is the first language that software supports.

Working out accents based on some kind of auto-correct / guess mechanism is probably not a good idea. One of the main advantages of a real, physical keyboard is that it is so much more accurate than a touch keyboard: if you make a typo, it's you who made the typo, not some inaccuracy in the touch detection hardware or some kind of incorrect guess by some kind of auto-correct mechanism.

Also it is not that easy. E.g. in French, both "a" (has) and "à" (in/to/at) are very common words. So working out the accent is not trivial: at the very least the software would need to understand French grammar. It's even worse in a language like Dutch, where accents can be used for emphasis. E.g. "háár haar" means "her hair" while "haar háár" means "her hair". Another use of accents in Dutch is for disambiguation: "voorkomen" is usually spelled without any accent, but it can mean both "prevent" ("voorkómen") and "occur" ("vóórkomen"), and depending on the context, it can be impossible to know which one is meant if you don't write the accent. Same with "één" (one) and "een" (an) - typically both are grammatically possible, and it depends entirely on the writer's intention which one is meant.

So in summary: With the current state of the art in artificial intelligence, there is no way that software can automatically solve this problem. If software can work out the accents, then it can basically also pass a Turing test.

 

[codifies]

Its a well known problem with at least one commercial solution reaching less than 1% error rate easily correctable on the fly, there are a buch of papers on this problem as it lends itself to stochastic analaysis