It's the keyboard layout.

[Grench]

Examples of why it would be a bad idea to have a public vote determine the keyboard layout.  It's amazing how people can so grossly underestimate the amount of work and detail that is required to make something functional, let alone highly usable -and- international friendly.  That combined with misconceptions that the Pyra/Pandora are really full size laptops is actually kind of funny.

Someone needs to put a US quarter and a Euro next to the Pandora (and the Pyra renders) and take a picture so that there is some sort of size reference.  This is a device that fits in a loose pants pocket.   It may have 90% or more of the functionality of a laptop, but it's very much a palm-top computer.

((Has not read the entirety of the topic.))

I only recently got a Pandora and one thing I have noticed is that there are no raised surfaces/bumps on the keys that would aid touch-typing. This means that, when typing in the dark, it is much easier to use the keys near the edges (especially left and right) of the mat than those in the middle: the edge keys are easily memorized and can be quickly found without too much counting of spaces between keys. Those in he middle need both memorization and the counting of the keys felt with the fingers.

You do understand that the device is less than HALF the width of a touch typing standard keyboard, right?  There is some value in having an intentional defect in the surface of F and J for thumb typing by feel.  This has been brought up before, but I can't blame you for not wanting to read all of the threads.  They are quite lengthy.  But touch typing?  That again?  Is there a large population of Pixies or Keebler Elves looking for computers to touch type on or something?

Take your smartphone.  Lay it on the table in front of you.  If you have a 'normal' smartphone, that is the approximate surface area of this entire keyboard.  If you have a 'phablet' type smartphone, then just the screen area is the entire surface area involved.

Touch typing requirements.  Again.  *thud*

I am surprised this isn't just being resolved in software. It would make sense to me for symbols to be featured on the keys and then have a dedicated row where you push AltGr or Fn or whatever, on screen shows a single row of the characters you have assigned in software to this row, and then you push the relevant button on the row. You'll never please everyone so really the best you can hope for is that people have the facility of getting the characters they want and the on screen box would provide a reference that you wouldn't make permanent on the keypad.

In that case all we really need is one row of 12 keys and 6 shift/modifier keys.  Thanks for solving it!

 

[comradekingu]

How do you know its not you who underestimate how much work goes into it/is required? With how much time is spent by people actually designing layouts, they do differ a whole lot.

I think its irrelevant, because all designs are for those people you seem to be discrediting. Getting them to give votes on what they like, will make it easier to pick one that will suit most people.

What makes it not a small laptop btw? The desktop OS? The desktop apps? The desktop resolution? The desktop connectivity?

If its the artifically made-to-be-different keyboard, that answers neither why it is different, nor why that is preferable. Underneath the shell its standard keyboard stuff. Deviate from it at any point and you have to hack that in. Outside of the shell people bring expectations of regular keyboard. Because having used, or using, a keyboard that is foreign, is a foreign concept.

Touch typing has everything to do with position. Mess that up and people who type in this manner wont be able to. I dont have any labels for the letters on my keyboard, and have no problems, picking up a pandora, touch-typing on smaller buttons is just a question of adapting to smaller buttons.

Adapting to new non-standard conventions and non-full keyboard, uuuuuuuuugh. But the biggest problem, is the inefficiency, you can never get that back.

 

[_wb_]

Even a left-aligned, 'P+2 L+2 enabled' layout like yours is still very much non-standard, comradekingu. Don't pretend it is possible to make something that is identical to a normal full-size keyboard, which you can use immediately with the same efficiency and muscle memory as before. If that were possible, then why would keyboard companies still make keyboards that are larger than the Pyra?


Adapting will be necessary anyway. We can try to keep the learning curve reasonable, and we can aim at maximizing the eventually obtainable efficiency. Ideally both. But it will always still be worse than a real full-size keyboard. Maybe only 10% worse, and still 1000 times better than a touch-screen virtual keyboard, but it will be different, and it will be worse.

 

[codifies]

I am surprised this isn't just being resolved in software. It would make sense to me for symbols to be featured on the keys and then have a dedicated row where you push AltGr or Fn or whatever, on screen shows a single row of the characters you have assigned in software to this row, and then you push the relevant button on the row. You'll never please everyone so really the best you can hope for is that people have the facility of getting the characters they want and the on screen box would provide a reference that you wouldn't make permanent on the keypad.

Far too sensible - people would rather argue their religious corner and end up with something that inconveniences everyone...

The absolute bare minimum of characters should be on the keymat, key mapping aided by printed characters on the case, or a clip on overlay, or visual onscreen aide can then be taylored to the exact need of a specific individual, inconveniencing no one...

 

[comradekingu]

For the purposes of muscle memory, it works. Even if you don't know where to find it blindly, you know where it should be. I have an eee-PC, which features a keyboard where the typewriter part is 92% that of a regular keyboard. Its a little bit worse, but not by much. If the typing was different then the typing-conventions i brought along wouldn't work. Thats not a little bit worse, that's a lot worse.

Nothing other than I end up pressing enter and nothing on the pandora happens if I want to type Norwegian.

Im not saying a different keyboard isnt an adaption, im saying make the transition as _small_ as possible.  The keyboard has lasted, in current form, since 1870s and 1980s, changing the things that do work, isn't clever.

Making up entirely new ways to type international language is for example a fail on a multitude of levels. I didn't invent that, i just acknowledged it. And i think i understand the issue well enough since i use it frequently.

Think of it as A-aligned. A is always A, so that the other keys can be included. Given the right amount of keys, that is the international way to see it.

If you dont have the right amount of keys, you have an A-aligned keyboard with some of the right part cut off. Now that is understandable if you only have 10 keys on the querty-row like on the pandora.

My motivation here is that we can do better now, it can actually work.

Pretending that is ok for the pyra to be different because its different is making it a niche for the wrong reasons.

I want the pyra to succeed so much, and i think this is one of those changes that broadens the audience and brings it down to usability for regular people.

The people who voted are 100% userbase, pretty technical people, even they want it. There is no question as to why that is. The nr.1 first thing people who need it look for is if the keys to the right of P and L are included, without that, nothing else matters. Because the entirety of such keyboards are in a league of toy-keyboards.

For how much its a two-thumb keyboard, at least pay attention to distance travelled, the bottom left and right is actually the worst place to be. If you have to go there, go there once and get what needs doing done. There is no must in placing ctrl and alt there. Its not ideal on the pandora either, but its known to work reasonably well. That wasnt the issue.

And can we _please_ never put , and . on the opposite side of enter and space. Nobody expects , and . to be on the left. We cant pretend the pandora layout only needs minor tweaks when its that broken. That change alone just makes things so much better.

 

[Saber]

And if the user is blind?


Seriously, what do you have against this? I don't understand why you are so opposed to it.


Personally, I rather suspect my main method of finding keys is going to be the back-light, but I still think having a method to orient ones fingers on the keyboard by touch is a good idea.


- Neelix

Blind? Okay.

I am not so opposed to it Neelix, but with four rows of narrow keys I don't think it will bring the benefit that raises do on a normal keyboard. The keys are tiny and key surface area so limited(not to mention the backlighting and ED's time clock).

My suggestion to do it if possible is not by little dashes or dots like on a big keyboard, but by an outline or surround on the peripheries of the F and J keycaps, wherever they will fit. Doesn't have to cover the whole border. Have a feeling they'll be unnoticed if done the more traditional way. This will leave the backlighting unaffected(hopefully). 

 

[comradekingu]

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.

 

[Saber]

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. 

 

[Glyph Reader]

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

 

[Neelix]

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

 

[Twinbee]

I am surprised this isn't just being resolved in software. It would make sense to me for symbols to be featured on the keys and then have a dedicated row where you push AltGr or Fn or whatever, on screen shows a single row of the characters you have assigned in software to this row, and then you push the relevant button on the row. You'll never please everyone so really the best you can hope for is that people have the facility of getting the characters they want and the on screen box would provide a reference that you wouldn't make permanent on the keypad.

Yes, exactly. Software could help accomodate most of the requirements of a multilingual / international user base.


To paraphrase the title of a Michael Moore documentary: "It's the software, stupid!"

(Note that I am not calling anyone on this board a stupid person.)

 

[Neelix]

That's all very well, but it doesn't change the fact that we still need to design a decent default layout, because while people *could* get creative about finding software solutions to things, most people are probably going to stick with the default, and expect it to mostly serve their needs as is. Also once the keymats are made, whatever we end up with is what we'll be stuck with for at the very least the entire initial production run.

Being able to do things in software is not a good excuse not to design the hardware right.

- Neelix

 

[ible]

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

 

[comradekingu]

Yes, having less stuff on the keys makes it look more like a keyboard, and less cluttered at the same time. Knowing it differs from region to region, ideally we should make no choices here.

Take it one step further by not printing anything besides letters on the letter-keys, as per how AltGr really works. Thus, not breaking with how people expect AltGr to work.

Edit: The reason you cant do it there, is because , and . is on the side that isnt effective, that people dont expect it on. : and ; too.

I see tab in a slightly more traditional spot, but there is stuff on it that doesnt belong on tab.

< > i understand, but only for non-english euros. I think <> belongs with the other brackets ( ) [ ] { } all of which always are to be found on the right side. And are used for coding.

<> when on the left side is actually an extra button that ansi keyboards dont have (in favour of longshift), this is how you can defend moving it to the right.

TL DR   , . not effective at the cost of putting it where it is not expected. < > halfway where expected at the cost of not making it effective.

 

[ible]

Whether or not it is effective, that is where ED had ,. in the OP.  I argue that my layout makes it easiest to combo common mathematical/coding expressions, everything except &= and *=.  Also, [] are close to numbers, which helps with array indexing.  Putting : on shift . means that you won't accidentally hit :F12 instead of :Enter when you want to make a new python block.  That is different from the standard <> shifted on ,. but this also makes <= and >= have the same modifier.

It works out quite nicely if you attempt to code with my layout, I think.  And you get the benefit of a fairly clean keyboard (which we both appreciate).  Oh, and you get -+ on jk, which is the Vim way to go down/up.  Kinda neat.

 

[comradekingu]

There isnt enough keys on the pandora to do anything better than isolated left , . on a pandora. That isnt a good reason to continue something when there are more keys.
 
"Please post any issues and suggestions you have here - so we can rearrange everything a bit so it's useful for everyone."
 
I dont see how what makes , . on the left worse, is better for anyone. To make matters worse its all people, all of the time.
 
And if we agree, then we should do something about it.
 
Accepting legacy as good is how to institutionalize problems. We cant just point to whoever did it first, it has to be better than that. Conditions are better than that now.

Spoiler

 
<> shifted on , . isnt standard, its around half.      Shifted   , and :     is       ; and :      in germany.
 
I see the logic in that its the same, but only if change is accepted. First go back to where change was introduced and see if there is a broader platform there.
 
I think having it a bit closer to where it is expected is how to get the biggest benefit quick, not to take away from similar modifiers. Its just that the people who do , ; have a dedicated key for <>.   + should ideally be dedicated, along with <> and shift+ to get :
 
People who use vim use a keyboard only based on motorical learning. The more stuff is moved around, the less good those people become at vim. They have to re-learn.
 
You make it easy to type _ , but harder yet to type -. If it was a calculator i'd see the point in grouping the math-symbols. However i think that grouping extends to the number-row, where most are expected to be found by most poeple.

I like the dedicated ', but its most often used after n, which is at the other side of the keyboard. Moving it there is also where its expected.

 

[szr]

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

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?

 

[comradekingu]

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.

 

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